Re: [Isms] Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 02 May 2011 15:07 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: isms@ietfa.amsl.com
Delivered-To: isms@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2BE06AD for <isms@ietfa.amsl.com>; Mon, 2 May 2011 08:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.157
X-Spam-Level:
X-Spam-Status: No, score=-103.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn0hf-46Nqs5 for <isms@ietfa.amsl.com>; Mon, 2 May 2011 08:07:01 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 27162E0695 for <isms@ietf.org>; Mon, 2 May 2011 08:07:01 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81ACC20BF7; Mon, 2 May 2011 17:07:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j9ZLQj9749cB; Mon, 2 May 2011 17:06:59 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8610E20BF2; Mon, 2 May 2011 17:06:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CBED3185718B; Mon, 2 May 2011 17:06:53 +0200 (CEST)
Date: Mon, 02 May 2011 17:06:53 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Sean Turner <turners@ieca.com>
Message-ID: <20110502150653.GA1312@elstar.local>
Mail-Followup-To: Sean Turner <turners@ieca.com>, isms@ietf.org
References: <20110419211456.203DAE084A@ietfc.amsl.com> <6.2.5.6.2.20110430150731.029f3fd8@resistor.net> <4DBEC59F.2030902@ieca.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4DBEC59F.2030902@ieca.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: isms@ietf.org
Subject: Re: [Isms] Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isms>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2011 15:07:02 -0000
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 > >>ietf@ietf.org mailing lists by 2011-05-03. Exceptionally, > >>comments may be sent to iesg@ietf.org 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] Last Call: rfc5953 (Transport Layer Securi… The IESG
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Sean Turner
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Juergen Schoenwaelder
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… SM
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Sean Turner
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Juergen Schoenwaelder
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Sean Turner
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Juergen Schoenwaelder
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Wes Hardaker
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Wes Hardaker
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Wes Hardaker
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Sean Turner
- Re: [Isms] Last Call: rfc5953 (Transport Layer Se… Wes Hardaker