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

From: Sean Turner <[email-masked]>
Date: Mon, 02 May 2011 16:54:23 +0200

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
>> [email-masked] mailing lists by 2011-05-03. Exceptionally,
>> comments may be sent to [email-masked] 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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 May 2011 17:06:53 +0200

On Mon, May 02, 2011 at 04:54:23PM +0200, Sean Turner wrote:
> 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:
> 

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?
> 
> 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/>

---

From: SM <[email-masked]>
Date: Sat, 30 Apr 2011 15:41:15 -0700

In Section 7:

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 03 May 2011 08:43:44 +0200

> So you kept [RFC1033] instead of the suggested [RFC1123] by intention

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).

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 May 2011 08:54:16 +0200

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

> 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

---

From: Sean Turner <[email-masked]>
Date: Tue, 03 May 2011 09:10:56 +0200

>> 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.

> representation?? I am just trying to understand what the perspective

I blew it: RFC XXXX will be DS.

spt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 May 2011 09:16:19 +0200

> I blew it: RFC XXXX will be DS.

That sounds much better. ;-)

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2011 07:16:37 -0700

>>>>> On Tue, 03 May 2011 08:43:44 +0200, Sean Turner <[email-masked]> 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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2011 07:18:03 -0700

>>>>> On Mon, 02 May 2011 16:54:23 +0200, Sean Turner <[email-masked]> 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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2011 07:22:04 -0700

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.

---

From: Sean Turner <[email-masked]>
Date: Thu, 05 May 2011 09:57:05 -0400

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<[email-masked]>  said:
>

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 May 2011 07:25:26 -0700

>>>>> On Thu, 05 May 2011 09:57:05 -0400, Sean Turner <[email-masked]> 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