Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

IESG Secretary
The IESG has received a request from the isms WG (isms) to consider the
following document:

- 'Transport Layer Security (TLS) Transport Model for the Simple Network
   Management Protocol (SNMP) '
  RFC 5953 as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[hidden email] mailing lists by 2011-05-03. Exceptionally,
comments may be sent to [hidden email] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

This specification contains eight normative references to standards
track documents of lower maturity: RFCs 1033, 3490, 3584, 4347, 4366,
5246, 5280, and 5952.

The file can be obtained via
http://datatracker.ietf.org/doc/rfc5953/

Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/rfc5953/

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

sm-7
At 14:14 19-04-2011, The IESG wrote:

>The IESG has received a request from the isms WG (isms) to consider the
>following document:
>
>- 'Transport Layer Security (TLS) Transport Model for the Simple Network
>    Management Protocol (SNMP) '
>   RFC 5953 as a Draft Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[hidden email] mailing lists by 2011-05-03. Exceptionally,
>comments may be sent to [hidden email] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>This specification contains eight normative references to standards
>track documents of lower maturity: RFCs 1033, 3490, 3584, 4347, 4366,
>5246, 5280, and 5952.

In Section 7:

   "A hostname is always in US-ASCII (as per [RFC1033]);
    internationalized hostnames are encoded in US-ASCII as domain
    names after transformation via the ToASCII operation specified
    in [RFC3490]."

As a quick comment, RFC 1033 is a down-ref.  A better reference is
RFC 1123.  As it is part of STD 3, a down-ref is no longer
needed.  The reference to RFC 3490 could be updated to RFC
5890.  That also avoids a down-ref in a Draft Standard to a document
that has an Obsolete status.

Regards,
-sm

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Sean Turner
On 5/1/11 12:41 AM, SM wrote:

> At 14:14 19-04-2011, The IESG wrote:
>> The IESG has received a request from the isms WG (isms) to consider the
>> following document:
>>
>> - 'Transport Layer Security (TLS) Transport Model for the Simple Network
>> Management Protocol (SNMP) '
>> RFC 5953 as a Draft Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [hidden email] mailing lists by 2011-05-03. Exceptionally,
>> comments may be sent to [hidden email] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> This specification contains eight normative references to standards
>> track documents of lower maturity: RFCs 1033, 3490, 3584, 4347, 4366,
>> 5246, 5280, and 5952.
>
> In Section 7:
>
> "A hostname is always in US-ASCII (as per [RFC1033]);
> internationalized hostnames are encoded in US-ASCII as domain
> names after transformation via the ToASCII operation specified
> in [RFC3490]."
>
> As a quick comment, RFC 1033 is a down-ref. A better reference is RFC
> 1123. As it is part of STD 3, a down-ref is no longer needed. The
> reference to RFC 3490 could be updated to RFC 5890. That also avoids a
> down-ref in a Draft Standard to a document that has an Obsolete status.

As SM noted, the reference to RFC 3490 needs to be updated.  In fact, I
know the Apps ADs will place a DISCUSS on this particular point based on
some exchanges about a DKIM draft on a similar topic.  The change is
slightly more complicated than replacing the references because ToASCII
went bye-bye in RFC 5890.  After some exchanges with an Apps AD, the
following change would "work" (this very similar to the changes proposed
by DKIM to their draft) - and "work" means won't force a recycle at DS:

OLD:

   A hostname is always in US-ASCII (as per [RFC1033]);
   internationalized hostnames are encoded in US-ASCII as domain
   names after transformation via the ToASCII operation specified
   in [RFC3490].  The ToASCII operation MUST be performed with the
   UseSTD3ASCIIRules flag set.  The hostname is followed by a
   colon ':' (US-ASCII character 0x3A) and a decimal port number
   in US-ASCII.  The name SHOULD be fully qualified whenever
   possible.

NEW:

   A hostname is always in US-ASCII (as per [RFC1033]);
   internationalized hostnames are encoded as A-labels as specified
   in [RFC5890].  The hostname is followed by a
   colon ':' (US-ASCII character 0x3A) and a decimal port number
   in US-ASCII.  The name SHOULD be fully qualified whenever
   possible.

FYI I also asked about setting the UseSTD3ASCIIRules flag and Pete said
it was completely unnecessary as far as he could tell.  That's why I
just dropped it.

Does anybody object to this change?  (It's perfectly okay to object to
these words.  We'll just need to work some other text out with Pete/Peter).

What do others feel about the reference change from RFC 1033 to 1123.
Are there any technical reasons to not make this change?

As a result of the change for the 3490 reference (and maybe 1033
references), either a new draft is needed or I need to enter an RFC
editor note.*  I'm willing to enter these changes as RFC editor notes.
  Just let me know which path you'd like to follow.

spt

*  The new draft or RFC editor note will need to include the editorial
errata filed against RFC 5953.
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Juergen Schoenwaelder-2
On Mon, May 02, 2011 at 04:54:23PM +0200, Sean Turner wrote:

> On 5/1/11 12:41 AM, SM wrote:
> >At 14:14 19-04-2011, The IESG wrote:
> >>The IESG has received a request from the isms WG (isms) to consider the
> >>following document:
> >>
> >>- 'Transport Layer Security (TLS) Transport Model for the Simple Network
> >>Management Protocol (SNMP) '
> >>RFC 5953 as a Draft Standard
> >>
> >>The IESG plans to make a decision in the next few weeks, and solicits
> >>final comments on this action. Please send substantive comments to the
> >>[hidden email] mailing lists by 2011-05-03. Exceptionally,
> >>comments may be sent to [hidden email] instead. In either case, please
> >>retain the beginning of the Subject line to allow automated sorting.
> >>
> >>This specification contains eight normative references to standards
> >>track documents of lower maturity: RFCs 1033, 3490, 3584, 4347, 4366,
> >>5246, 5280, and 5952.
> >
> >In Section 7:
> >
> >"A hostname is always in US-ASCII (as per [RFC1033]);
> >internationalized hostnames are encoded in US-ASCII as domain
> >names after transformation via the ToASCII operation specified
> >in [RFC3490]."
> >
> >As a quick comment, RFC 1033 is a down-ref. A better reference is RFC
> >1123. As it is part of STD 3, a down-ref is no longer needed. The
> >reference to RFC 3490 could be updated to RFC 5890. That also avoids a
> >down-ref in a Draft Standard to a document that has an Obsolete status.
>
> As SM noted, the reference to RFC 3490 needs to be updated.  In
> fact, I know the Apps ADs will place a DISCUSS on this particular
> point based on some exchanges about a DKIM draft on a similar topic.
> The change is slightly more complicated than replacing the
> references because ToASCII went bye-bye in RFC 5890.  After some
> exchanges with an Apps AD, the following change would "work" (this
> very similar to the changes proposed by DKIM to their draft) - and
> "work" means won't force a recycle at DS:
>
> OLD:
>
>   A hostname is always in US-ASCII (as per [RFC1033]);
>   internationalized hostnames are encoded in US-ASCII as domain
>   names after transformation via the ToASCII operation specified
>   in [RFC3490].  The ToASCII operation MUST be performed with the
>   UseSTD3ASCIIRules flag set.  The hostname is followed by a
>   colon ':' (US-ASCII character 0x3A) and a decimal port number
>   in US-ASCII.  The name SHOULD be fully qualified whenever
>   possible.
>
> NEW:
>
>   A hostname is always in US-ASCII (as per [RFC1033]);
>   internationalized hostnames are encoded as A-labels as specified
>   in [RFC5890].  The hostname is followed by a
>   colon ':' (US-ASCII character 0x3A) and a decimal port number
>   in US-ASCII.  The name SHOULD be fully qualified whenever
>   possible.

So you kept [RFC1033] instead of the suggested [RFC1123] by intention
or was this an accident?
 

> FYI I also asked about setting the UseSTD3ASCIIRules flag and Pete
> said it was completely unnecessary as far as he could tell.  That's
> why I just dropped it.
>
> Does anybody object to this change?  (It's perfectly okay to object
> to these words.  We'll just need to work some other text out with
> Pete/Peter).
>
> What do others feel about the reference change from RFC 1033 to
> 1123. Are there any technical reasons to not make this change?
>
> As a result of the change for the 3490 reference (and maybe 1033
> references), either a new draft is needed or I need to enter an RFC
> editor note.*  I'm willing to enter these changes as RFC editor
> notes.  Just let me know which path you'd like to follow.
>
> spt
>
> *  The new draft or RFC editor note will need to include the
> editorial errata filed against RFC 5953.

So you are saying we have to republish RFC 5953 in order to make this
change in order to advance?

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Sean Turner
On 5/2/11 5:06 PM, Juergen Schoenwaelder wrote:

> On Mon, May 02, 2011 at 04:54:23PM +0200, Sean Turner wrote:
>> On 5/1/11 12:41 AM, SM wrote:
>>> At 14:14 19-04-2011, The IESG wrote:
>>>> The IESG has received a request from the isms WG (isms) to consider the
>>>> following document:
>>>>
>>>> - 'Transport Layer Security (TLS) Transport Model for the Simple Network
>>>> Management Protocol (SNMP) '
>>>> RFC 5953 as a Draft Standard
>>>>
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final comments on this action. Please send substantive comments to the
>>>> [hidden email] mailing lists by 2011-05-03. Exceptionally,
>>>> comments may be sent to [hidden email] instead. In either case, please
>>>> retain the beginning of the Subject line to allow automated sorting.
>>>>
>>>> This specification contains eight normative references to standards
>>>> track documents of lower maturity: RFCs 1033, 3490, 3584, 4347, 4366,
>>>> 5246, 5280, and 5952.
>>>
>>> In Section 7:
>>>
>>> "A hostname is always in US-ASCII (as per [RFC1033]);
>>> internationalized hostnames are encoded in US-ASCII as domain
>>> names after transformation via the ToASCII operation specified
>>> in [RFC3490]."
>>>
>>> As a quick comment, RFC 1033 is a down-ref. A better reference is RFC
>>> 1123. As it is part of STD 3, a down-ref is no longer needed. The
>>> reference to RFC 3490 could be updated to RFC 5890. That also avoids a
>>> down-ref in a Draft Standard to a document that has an Obsolete status.
>>
>> As SM noted, the reference to RFC 3490 needs to be updated.  In
>> fact, I know the Apps ADs will place a DISCUSS on this particular
>> point based on some exchanges about a DKIM draft on a similar topic.
>> The change is slightly more complicated than replacing the
>> references because ToASCII went bye-bye in RFC 5890.  After some
>> exchanges with an Apps AD, the following change would "work" (this
>> very similar to the changes proposed by DKIM to their draft) - and
>> "work" means won't force a recycle at DS:
>>
>> OLD:
>>
>>    A hostname is always in US-ASCII (as per [RFC1033]);
>>    internationalized hostnames are encoded in US-ASCII as domain
>>    names after transformation via the ToASCII operation specified
>>    in [RFC3490].  The ToASCII operation MUST be performed with the
>>    UseSTD3ASCIIRules flag set.  The hostname is followed by a
>>    colon ':' (US-ASCII character 0x3A) and a decimal port number
>>    in US-ASCII.  The name SHOULD be fully qualified whenever
>>    possible.
>>
>> NEW:
>>
>>    A hostname is always in US-ASCII (as per [RFC1033]);
>>    internationalized hostnames are encoded as A-labels as specified
>>    in [RFC5890].  The hostname is followed by a
>>    colon ':' (US-ASCII character 0x3A) and a decimal port number
>>    in US-ASCII.  The name SHOULD be fully qualified whenever
>>    possible.
>
> So you kept [RFC1033] instead of the suggested [RFC1123] by intention
> or was this an accident?

I was going to take it as two different suggested changes.  If we accept
replacing 1033 with 1123, then the text above would include 1123.  And,
I the exact words I sent to the Apps AD was above (but I bet they
wouldn't object to the r/1033/1123 change).

>> FYI I also asked about setting the UseSTD3ASCIIRules flag and Pete
>> said it was completely unnecessary as far as he could tell.  That's
>> why I just dropped it.
>>
>> Does anybody object to this change?  (It's perfectly okay to object
>> to these words.  We'll just need to work some other text out with
>> Pete/Peter).
>>
>> What do others feel about the reference change from RFC 1033 to
>> 1123. Are there any technical reasons to not make this change?
>>
>> As a result of the change for the 3490 reference (and maybe 1033
>> references), either a new draft is needed or I need to enter an RFC
>> editor note.*  I'm willing to enter these changes as RFC editor
>> notes.  Just let me know which path you'd like to follow.
>>
>> spt
>>
>> *  The new draft or RFC editor note will need to include the
>> editorial errata filed against RFC 5953.
>
> So you are saying we have to republish RFC 5953 in order to make this
> change in order to advance?

Hmm what I'm saying is that when this document is published it won't be
RFC 5953 it'll be RFC XXXX but it will be at PS.  RFC XXXX will include
the changes and the errata.  There are two ways to tell the RFC editor
how to do this: a) via an ID or b) via an RFC editor note.  I believe b
will be quicker and it's definitely the option I'd prefer.

spt
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Juergen Schoenwaelder-2
On Tue, May 03, 2011 at 08:43:44AM +0200, Sean Turner wrote:

> >So you are saying we have to republish RFC 5953 in order to make this
> >change in order to advance?
>
> Hmm what I'm saying is that when this document is published it won't
> be RFC 5953 it'll be RFC XXXX but it will be at PS.  RFC XXXX will
> include the changes and the errata.  There are two ways to tell the
> RFC editor how to do this: a) via an ID or b) via an RFC editor
> note.  I believe b will be quicker and it's definitely the option
> I'd prefer.

So in order to advance RFC XXXX to DS, we then need in N months an
interoperability report on internationalized domain name
representation?? I am just trying to understand what the perspective
of this is.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Sean Turner
On 5/3/11 8:54 AM, Juergen Schoenwaelder wrote:
> On Tue, May 03, 2011 at 08:43:44AM +0200, Sean Turner wrote:
>
>>> So you are saying we have to republish RFC 5953 in order to make this
>>> change in order to advance?
>>
>> Hmm what I'm saying is that when this document is published it won't
>> be RFC 5953 it'll be RFC XXXX but it will be at PS.  RFC XXXX will

ugh (red faced) .... but it will be DS not PS.  Sorry about this confusion.

>> include the changes and the errata.  There are two ways to tell the
>> RFC editor how to do this: a) via an ID or b) via an RFC editor
>> note.  I believe b will be quicker and it's definitely the option
>> I'd prefer.
>
> So in order to advance RFC XXXX to DS, we then need in N months an
> interoperability report on internationalized domain name
> representation?? I am just trying to understand what the perspective
> of this is.

I blew it: RFC XXXX will be DS.

spt
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Juergen Schoenwaelder-2
On Tue, May 03, 2011 at 09:10:56AM +0200, Sean Turner wrote:
>
> I blew it: RFC XXXX will be DS.
>

That sounds much better. ;-)

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Wes Hardaker-2
In reply to this post by Sean Turner
>>>>> On Tue, 03 May 2011 08:43:44 +0200, Sean Turner <[hidden email]> said:

ST> Hmm what I'm saying is that when this document is published it won't
ST> be RFC 5953 it'll be RFC XXXX but it will be at [DS].  RFC XXXX will
ST> include the changes and the errata.  There are two ways to tell the
ST> RFC editor how to do this: a) via an ID or b) via an RFC editor note.
ST> I believe b will be quicker and it's definitely the option I'd prefer.

I'm fine with either; if you want to do it via editor notes that's just
fine with me!  [and, yes, we definitely need to include the errata]
--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Wes Hardaker-2
In reply to this post by Sean Turner
>>>>> On Mon, 02 May 2011 16:54:23 +0200, Sean Turner <[hidden email]> said:

ST> FYI I also asked about setting the UseSTD3ASCIIRules flag and Pete
ST> said it was completely unnecessary as far as he could tell.  That's
ST> why I just dropped it.

FYI, that was required by something or someone.  I'll need to look
through history to figure out why I put it in there.  It certainly
wasn't because "I thought it needed to be".  I'm admittedly fairly
clueless when it comes to the proper ways to specify
internationalization and the text in the document came from multiple
discussions.
--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Wes Hardaker-2
In reply to this post by Sean Turner
>>>>> On Mon, 02 May 2011 16:54:23 +0200, Sean Turner <[hidden email]> said:

ST> FYI I also asked about setting the UseSTD3ASCIIRules flag and Pete
ST> said it was completely unnecessary as far as he could tell.  That's
ST> why I just dropped it.

I'm glad I took good notes last time.  The flag setting came from
comments from Peter Saint-Andre:

******* CLOSED The definition of SnmpTLSAddress states that
        "internationalized hostnames are encoded in US-ASCII as
        specified in RFC 3490", but I think this could be defined more
        precisely because (1) RFC 3490 does not talk about
        "internationalized hostnames", (2) you need to state that you
        are using the ToASCII operation, and (3) you need to specify
        whether the UseSTD3ASCIIRules flag is set. This definition
        also appears to make normative references to RFC 1033 and RFC
        3490, but those specifications are not included in the
        Normative References section. Finally, this definition
        references RFC 3986 but that specification is never used here.

        + WH: I've changed the text to the following to address your
          concerns; please let me know if you believe it needs further
          changes.

            A hostname is always in US-ASCII (as per RFC1033);
            internationalized hostnames are encoded in US-ASCII as
            domain names after transformation via the ToASCII
            operation specified in RFC 3490.  The ToASCII operation
            MUST be performed with the UseSTD3ASCIIRules flag set.
            The hostname is followed by a colon ':' (US-ASCII
            character 0x3A) and a decimal port number in US-ASCII.
            The name SHOULD be fully qualified whenever possible.


        + WH: references for 3490 and 1033 moved to the normative section.

        + WH: The 3986 reference has been removed (in the process of
          responding to other similar comments).

        + Peter: Excellent.

--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Sean Turner
Wes,

I asked Peter Tuesday about this and he confirmed that we don't need to
say anything about setting the flag in the new text but you did need to
say something about it with the old text.

spt

On 5/3/11 10:22 AM, Wes Hardaker wrote:

>>>>>> On Mon, 02 May 2011 16:54:23 +0200, Sean Turner<[hidden email]>  said:
>
> ST>  FYI I also asked about setting the UseSTD3ASCIIRules flag and Pete
> ST>  said it was completely unnecessary as far as he could tell.  That's
> ST>  why I just dropped it.
>
> I'm glad I took good notes last time.  The flag setting came from
> comments from Peter Saint-Andre:
>
> ******* CLOSED The definition of SnmpTLSAddress states that
>          "internationalized hostnames are encoded in US-ASCII as
>          specified in RFC 3490", but I think this could be defined more
>          precisely because (1) RFC 3490 does not talk about
>          "internationalized hostnames", (2) you need to state that you
>          are using the ToASCII operation, and (3) you need to specify
>          whether the UseSTD3ASCIIRules flag is set. This definition
>          also appears to make normative references to RFC 1033 and RFC
>          3490, but those specifications are not included in the
>          Normative References section. Finally, this definition
>          references RFC 3986 but that specification is never used here.
>
> + WH: I've changed the text to the following to address your
>  concerns; please let me know if you believe it needs further
>  changes.
>
>              A hostname is always in US-ASCII (as per RFC1033);
>              internationalized hostnames are encoded in US-ASCII as
>              domain names after transformation via the ToASCII
>              operation specified in RFC 3490.  The ToASCII operation
>              MUST be performed with the UseSTD3ASCIIRules flag set.
>              The hostname is followed by a colon ':' (US-ASCII
>              character 0x3A) and a decimal port number in US-ASCII.
>              The name SHOULD be fully qualified whenever possible.
>
>
> + WH: references for 3490 and 1033 moved to the normative section.
>
> + WH: The 3986 reference has been removed (in the process of
>  responding to other similar comments).
>
>          + Peter: Excellent.
>
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard

Wes Hardaker-2
>>>>> On Thu, 05 May 2011 09:57:05 -0400, Sean Turner <[hidden email]> said:

ST> I asked Peter Tuesday about this and he confirmed that we don't need
ST> to say anything about setting the flag in the new text but you did
ST> need to say something about it with the old text.

Ok, thanks for checking on it and good to know!
--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms