From peter@denic.de Mon Aug 1 05:53:25 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6694911E8626 for ; Mon, 1 Aug 2011 05:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, GB_I_LETTER=-2] 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 b8RF6rUPsRev for ; Mon, 1 Aug 2011 05:53:24 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 3608D11E86E6 for ; Mon, 1 Aug 2011 05:52:57 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QnrzR-0007ET-S1; Mon, 01 Aug 2011 14:53:01 +0200 Received: from localhost by x27.adm.denic.de with local id 1QnrzR-00071U-O5; Mon, 01 Aug 2011 14:53:01 +0200 Date: Mon, 1 Aug 2011 14:53:01 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20110801125301.GM2998@x27.adm.denic.de> Mail-Followup-To: IETF DNS Directorate , liman@netnod.se, joe.abley@icann.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: joe.abley@icann.org, liman@netnod.se Subject: [dns-dir] review of draft-liman-tld-names-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:53:25 -0000 All, this is a review of draft-liman-tld-names-05.txt for the DNS Directorate. To my knowledge this document has not been last called yet, but is considered as an AD sponsored Individual Submission. An earlier version of this draft has been discussed in the DNS Operations working group. Since it aims at updating a Standrads Track RFC, it was not considered for adoption in this particular WG. However, independent of this formal obstacle, it did not gain traction. > Top Level Domain Name Specification > draft-liman-tld-names-05 > Abstract > The syntax for allowed Top-Level Domain (TLD) labels in the Domain > Name System (DNS) is not clearly applicable to the encoding of > Internationalised Domain Names (IDNs) as TLDs. > This document provides a concise specification of TLD label syntax > based on existing syntax documentation, extended minimally to > accommodate IDNs. > This document updates RFC1123. Summary: To the extent that RFC 1123 actually or allegedly is in conflict with today's content of the DNS root zone (or vice versa), an IETF action might be advised. However, this draft goes far beyond what would be necessary to resolve the potential ambiguity posed by RFC 1123 and in fact mixes protocol and registration policy in a way that does not seem appropriate to me in today's environment which is more complicated than when RFC 1123 was published. My recommendation is to remove all attempts from the draft that phrase what "correct", "inambiguous" or "alphabetic" IDN TLDs or IDN labels are and strictly update only the one paragraph in RFC1123 that suggests "xn--" may ot appear in a TLD label. If there is enough support, the IETF could attempt to give recommedations regarding the IDN TLD registration policy, but this has to happen in a different document that will not be on standards track. Eventually the responsibility for the TLD name registration policy remains with the IANA function at ICANN that is not governed by the IETF and in particular is out of the scope of RFC 2860. > 1. Introduction > The syntax of TLD labels ("TLD DNS-Labels", as defined in Section 2) > is specified in [RFC1123], where such labels are asserted to be > "alphabetic" within a section of that document entitled "DISCUSSION". > This can be interpreted as requiring that the hyphen character ("-") > and numeric digits be excluded from TLD DNS-Labels. Such a > restriction would not accommodate the US-ASCII encoding of > Internationalised Domain Names (IDNs), as specified in [RFC5890]. A > more detailed discussion of the existing specifications can be found > in Section 3. > This document extends the syntax of allowable TLD DNS-Labels to > support IDNs, but places some restrictions on the choice of IDN > labels. These restrictions are intended to be consistent with the > existing specification for US-ASCII TLD DNS-Labels. See Section 4 > for the updated specification. > This document focuses narrowly on the issue of allowable DNS-Labels > in TLDs and does not (and is not intended to) make any other changes > or clarifications to existing domain name syntax rules. > It is carefully noted that the specification in this document is not > the only factor in choosing suitable TLD DNS-Labels, and that many > considerations external to the IETF are included in that wider > policy. See Section 5 for more discussion of policy considerations. > 2. Definitions > The term DNS-Label is used in this document to have precisely the > same meaning as the term "label", as introduced in [RFC1034], section > 3.1. A DNS-Label denotes one node in a DNS tree. A DNS-Label is > zero to 63 octets in length. The term "DNS-Label" refers exclusively > to the "wire format" of the label, and not to any presentation format > of the label. > A Top-Level Domain (TLD) DNS-Label is the right-most ("highest- > level") DNS-Label in a fully-qualified domain name. > The terms A-Label and U-Label are used in this document as defined in > [RFC5890]. > 3. Background > [RFC0952] defines a host name as follows: > 'A "name" ... is a text string up to 24 characters drawn from the > alphabet (A-Z), digits (0-9), minus sign (-), and period (.). > Note that periods are only allowed when they serve to delimit > components of "domain style names". (See RFC-921, "Domain Name > System Implementation Schedule", for background). No blank or > space characters are permitted as part of a name. No distinction > is made between upper and lower case. The first character must be > an alpha character. The last character must not be a minus sign > or period.' [Unnumbered section titled "ASSUMPTIONS", first > paragraph] > [RFC1123] reaffirms this definition, but makes one change to the > syntax: > 'The syntax of a legal Internet host name was specified in RFC-952 > [DNS:4]. One aspect of host name syntax is hereby changed: the > restriction on the first character is relaxed to allow either a > letter or a digit. Host software MUST support this more liberal > syntax.' [Section 2.1] > In addition, the DISCUSSION section of Section 2.1 says: > 'However, a valid host name can never have the dotted-decimal form > #.#.#.#, since at least the highest-level component label will be > alphabetic.' [Section 2.1] > Some implementers may have understood the above phrase 'will be > alphabetic' to be a protocol restriction. This _may_ be true, but since this restriction is only applicable in the context of the complete paragraph which the draft fails to quote: If a dotted-decimal number can be entered without such identifying delimiters, then a full syntactic check must be made, because a segment of a host domain name is now allowed to begin with a digit and could legally be entirely numeric (see Section 6.1.2.4). However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. These considerations apply to confusing an FQDN with a dotted quad and just deduce from the shape of then current TLDs that a full ambiguity "never" can happen. No harm is done unless and until we'd see an all-digits TLD. In today's environment it might be a good idea to spend some cycles on IPv6 literals, too. > Neither [RFC0952] nor [RFC1123] explicitly states the reasons for > these restrictions. It might be supposed that human factors were a > consideration; [RFC1123] appears to suggest that one of the reasons > was to prevent confusion between dotted-decimal IPv4 addresses and > host domain names. In any case, it is reasonable to believe that the > restrictions have been assumed in some deployed software, and that > changes to the rules should be undertaken with caution. This is hand waving, IMHO. > In order to accommodate the wish to express TLD names in scripts > other than Latin (or rather, the US-ASCII subset of Latin), it is > necessary to allow non-alphabetic characters in the corresponding TLD > DNS-Labels. To minimize changes, the U-label form of a TLD name is > restricted in ways functionally compatible with the restrictions > (from [RFC0952] and [RFC1123]) on US-ASCII TLD names, by applying > rules analogous to those already imposed on US-ASCII TLD DNS-Labels > to TLD U-labels. > However, deployed software that checks DNS top-level labels for > conformance with an alphabetic restriction will not recognize such > corresponding A-Labels (i.e., U-labels represented in their US-ASCII > form). So, since A-labels will always start with "xn--" and are likely to contain digits and another "-", "deployed software" that makes (misguided) assumptions about the characters used in TLD labels is not helped. > 4. TLD Label Syntax Specification > This document relaxes the existing specification to allow TLD DNS- > Labels to be well-formed A-Labels, but places restrictions on their > corresponding U-Labels. That is, not every well-formed A-Label is a > valid TLD DNS-Label. Nit: as per the definition above "DNS-Label" refers to the wire format whereas "A-label" as per RFC 5890 are in presentation format, thus they cannot be equal but only represeantations of each other. > The ABNF expression that matches a valid TLD DNS-Label is as follows: > tld-dns-label = traditional-tld-label / idn-label > traditional-tld-label = 1*63(ALPHA) > idn-label = Restricted-A-Label > ALPHA = %x41-5A / %x61-7A ; A-Z / a-z > A Restricted-A-Label is a DNS-Label which satisfies all the following > conditions: > 1. the DNS-Label is a valid A-Label according to [RFC5890]; > 2. the derived property value of all code points, as defined by > [RFC5890], is PVALID; > 3. the general category of all code points, is one of { Ll, Lo, Lm, > Mn }. > This new specification reflects current practice in registration of > TLD names by the IANA, extended to accommodate IDNs. There is no justification or explanation given for this restriction and also no way in which this change to the U-label would help deployed software that allegedly checks TLD labels for being "alphabetic". > 5. Policy Considerations > This document provides a technical specification that limits the set > of TLD DNS-Labels that are available for assignment; it does not aim > to encapsulate the full policy framework within which TLD names are > chosen. > At the time of writing, the policy under which TLD names are chosen > is developed and maintained by ICANN in consultation with a wide base > of stakeholders. As the Internet continues to grow to serve new user > communities, applications and services, it is to be expected that the > corresponding policy will be changed accordingly. It is unclear whether this draft attempts to reflect current IANA/ICANN root zone TLD naming policy into an IETF standard and why that would be advised, justified or desirable - or vice versa in which case the documents lacks a justification for the restriction of TLD labels. > 6. IANA Considerations > While this document makes no requests of the IANA, management of the > root zone is an IANA function. This document expands the set of > strings permitted for delegation from the root zone, and hence > establishes new limits for the corresponding IANA policy. Management of the root zone is an IANA function outside the scope of RFC 2860, whereas "IANA considerations" guide IANA under exact that MoU. Therefore, this text has no effect. The last sentence, though, answers my question raised after the previous paragraph: again, the technical justification for limiting the TLD code points in the context of the RFC 1123 ambiguity is missing. > 7. Security Considerations > This document is believed to have limited security implications. > General discussion about the security effects of internationalized > labels can be found in [RFC5890], section 4. Those considerations > apply equally to TLD labels. > The creation of new TLDs has the potential to conflict with software > which (for example) predates and correspondingly does not accommodate > new TLD names. Such software problems might in turn lead to security > vulnerabilities, e.g. in the case where a DNS name specified by a > user is truncated or otherwise misinterpreted, causing an application > to interact with a different remote host from that which the user > intended. It should be noted that this is not a new phenomenon, and > has been observed following the creation of new (US-ASCII) TLD names > prior to the publication of this document. > The issue that some Unicode characters can be confused with each > other is discussed at length in the Security Considerations section > of [RFC5890]. With the remarks made above, this is mostly irrelevant to the issue at hand. What might be discussed here is the confusion of IP address literals (v4 and v6, for that matter) with FQDNs and how the (clarified) section of RFC1123 relates to this problem. I do not feel right comfortable to "send text" for changes since basically i believe the draft would need a completely different approach that explains the non-normative nature of the "can never happen" remark. If anyone shares this view i'd be happy to come up with a counter proposal. -Peter From mark@townsley.net Fri Jul 22 00:48:51 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D9F21F8545 for ; Fri, 22 Jul 2011 00:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gZsRCamaDpse for ; Fri, 22 Jul 2011 00:48:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30CFD21F850F for ; Fri, 22 Jul 2011 00:48:49 -0700 (PDT) Received: by wyj26 with SMTP id 26so1503512wyj.31 for ; Fri, 22 Jul 2011 00:48:49 -0700 (PDT) Received: by 10.216.202.40 with SMTP id c40mr990617weo.58.1311320929104; Fri, 22 Jul 2011 00:48:49 -0700 (PDT) Received: from [172.20.2.84] ([213.174.124.25]) by mx.google.com with ESMTPS id v11sm1345078weq.33.2011.07.22.00.48.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 00:48:48 -0700 (PDT) From: Mark Townsley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jul 2011 07:54:17 +0200 Message-Id: <2C9A8F75-E427-423E-A08B-B666B73B40F6@townsley.net> To: dns-dir@ietf.org, Chris Griffiths , Ray Bellis , Wouter Cloetens Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 04 Aug 2011 08:04:02 -0700 Subject: [dns-dir] dns clue invited to homenet X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 07:48:51 -0000 DNS Directorate,=20 Please attend the homenet WG meeting Wed afternoon if possible. Chris = will be leading at least one discussion that is related to DNS. Please = see recent homenet@ietf.org archives for background. Thanks, - Mark= From joe.abley@icann.org Mon Aug 1 07:13:00 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBD21F8CDB for ; Mon, 1 Aug 2011 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 v6Le9LHP7yih for ; Mon, 1 Aug 2011 07:12:59 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8564521F8C1E for ; Mon, 1 Aug 2011 07:12:46 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 1 Aug 2011 07:12:52 -0700 From: Joe Abley To: dns directorate Date: Mon, 1 Aug 2011 07:12:51 -0700 Thread-Topic: draft-liman-tld-names-05, advice sought Thread-Index: AcxQVRptQFUqcnUATHOi3qdKWChgAw== Message-ID: <01450745-EF80-4518-B6B4-8C0EE5CD8139@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Aug 2011 08:04:02 -0700 Cc: Peter Koch , "liman@netnod.se" Subject: [dns-dir] draft-liman-tld-names-05, advice sought X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:13:00 -0000 Colleagues, I think it's fair to say that the authors of this document feel a little ad= rift with respect to direction for this work. If the DNS Directorate could = give us some advice, that would be appreciated. The current situation with respect to TLD label syntax is: 1. There is an ambiguous, existing specification in the IETF regarding TLD = label syntax, in RFC1123. Even the description of this as a specification i= s contentious, never mind the interpretation of the text. I believe it is r= easonable to say that there is the potential for the text in 1123 to be int= erpreted as a specification, however, even if we have no clear idea how wid= espread that interpretation might be. Discussion of the existing "specifica= tion" can be found in draft-liman-tld-names. 2. In practice, policy which incorporates syntax restrictions is developed = at ICANN and implemented by the IANA. ICANN's policy products are constrain= ed by technical specifications produced by the IETF. 3. The A-Label representation of IDN TLD labels is not consistent with the = pre-IDN "specification" pseudo-described in 1123. Since IDN TLD labels are deployed in the public DNS, (2) and (3) represent = a potential conflict between what ICANN has deployed and what the IETF has = specified. The ambiguity here has caused some discomfort, and that was one = of the motivations for this work. The document draft-liman-tld-names has not met with any particular enthusia= sm in the places it has been circulated. The general consensus seems to be = that of apathy. This might be fair enough; if the IETF doesn't want to invo= lve itself in TLD policy, that seems fine, for example. But a clear stateme= nt to that effect would be better than the sound of crickets. I can see a few ways forward. No doubt there are others. (a) do nothing Leave the ambiguous specification in 1123, leave the question of whether th= e IETF has an interest in constraining label syntax for TLDs open, and do n= othing. (b) a label is a label is a label State clearly that there is no special restriction for TLD labels, distinct= from the protocol restrictions for any other label in the DNS tree; in oth= er words, release any interest in TLD label syntax at the IETF, and defer i= t all to ICANN. I've heard this approach promoted by people in DNSOP. I expected to hear di= ssent from the App area people, since the problem remains of how to disting= uish between a literal IPv4 address and a domain name in the unlikely event= that a TLD exists that is syntactically a legal final component of an IPv4= address. But in Qu=E9bec those that did express an opinion seemed to say "= this is ICANN's business, we don't care". But I'd be hard-pushed to identif= y consensus in either venue. (c) koch proposal Formalise the "alphabetic" constraint for wire-format TLD labels, and exten= d it specifically to permit "xn--" wire-format labels. This leaves it possi= ble for TLD U-Labels to contain punctuation and digits (i.e. it retains the= alphabetic restriction for US-ASCII TLD labels, but does not impose one fo= r IDNs). (d) draft-liman-tld-names As discussed (and reviewed exhaustively by Peter, many thanks for that) for= malize the "alphabetic" constraint for US-ASCII and for IDNA2008 U-Labels (= i.e. keep the restriction consistent for users who may not be aware of whet= her they are typing, in effect, a U-Label or a US-ASCII label). (e) something else . . . What does the DNS Directorate think about this? Thoughts, opinions? Joe= From joe.abley@icann.org Mon Aug 1 08:10:07 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5C21F8B92 for ; Mon, 1 Aug 2011 08:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 FHZ3lEwHyPWc for ; Mon, 1 Aug 2011 08:10:06 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2963321F8B65 for ; Mon, 1 Aug 2011 08:10:06 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 1 Aug 2011 08:09:44 -0700 From: Joe Abley To: Peter Koch Date: Mon, 1 Aug 2011 08:09:33 -0700 Thread-Topic: review of draft-liman-tld-names-05.txt Thread-Index: AcxQXQwWOYejSPljRkmeVRKuQy9lzg== Message-ID: <86EBF837-8C52-4721-8925-AB0C08AD5107@icann.org> References: <20110801125301.GM2998@x27.adm.denic.de> In-Reply-To: <20110801125301.GM2998@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Aug 2011 08:04:02 -0700 Cc: IETF DNS Directorate , "liman@netnod.se" Subject: Re: [dns-dir] review of draft-liman-tld-names-05.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:10:07 -0000 Hi Peter, Thanks for the thorough review. I think we need some guidance at a higher-level for how (or if) to proceed = with this work. I've sent a separate message to the DNS Directorate which p= resumably someone will get around to approving from the non-members-post ma= ilman queue at some point. Until we identify the preferred direction here, I'll defer responding to th= e points you raised below. Joe On 2011-08-01, at 08:53, Peter Koch wrote: > All, >=20 > this is a review of draft-liman-tld-names-05.txt for the DNS Directorate. > To my knowledge this document has not been last called yet, but is consid= ered > as an AD sponsored Individual Submission. An earlier version of this dr= aft has > been discussed in the DNS Operations working group. Since it aims at upd= ating > a Standrads Track RFC, it was not considered for adoption in this particu= lar WG. > However, independent of this formal obstacle, it did not gain traction. >=20 >> Top Level Domain Name Specification >> draft-liman-tld-names-05 >=20 >> Abstract >=20 >> The syntax for allowed Top-Level Domain (TLD) labels in the Domain >> Name System (DNS) is not clearly applicable to the encoding of >> Internationalised Domain Names (IDNs) as TLDs. >=20 >> This document provides a concise specification of TLD label syntax >> based on existing syntax documentation, extended minimally to >> accommodate IDNs. >=20 >> This document updates RFC1123. >=20 > Summary: To the extent that RFC 1123 actually or allegedly is in conflict= with > today's content of the DNS root zone (or vice versa), an IETF action migh= t be > advised. However, this draft goes far beyond what would be necessary to r= esolve > the potential ambiguity posed by RFC 1123 and in fact mixes protocol and = registration > policy in a way that does not seem appropriate to me in today's environme= nt which is > more complicated than when RFC 1123 was published. My recommendation is = to remove > all attempts from the draft that phrase what "correct", "inambiguous" or > "alphabetic" IDN TLDs or IDN labels are and strictly update only the one > paragraph in RFC1123 that suggests "xn--" may ot appear in a TLD label. >=20 > If there is enough support, the IETF could attempt to give recommedations= regarding > the IDN TLD registration policy, but this has to happen in a different do= cument that > will not be on standards track. Eventually the responsibility for the TL= D > name registration policy remains with the IANA function at ICANN that is = not > governed by the IETF and in particular is out of the scope of RFC 2860. >=20 >> 1. Introduction >=20 >> The syntax of TLD labels ("TLD DNS-Labels", as defined in Section 2) >> is specified in [RFC1123], where such labels are asserted to be >> "alphabetic" within a section of that document entitled "DISCUSSION". >> This can be interpreted as requiring that the hyphen character ("-") >> and numeric digits be excluded from TLD DNS-Labels. Such a >> restriction would not accommodate the US-ASCII encoding of >> Internationalised Domain Names (IDNs), as specified in [RFC5890]. A >> more detailed discussion of the existing specifications can be found >> in Section 3. >=20 >> This document extends the syntax of allowable TLD DNS-Labels to >> support IDNs, but places some restrictions on the choice of IDN >> labels. These restrictions are intended to be consistent with the >> existing specification for US-ASCII TLD DNS-Labels. See Section 4 >> for the updated specification. >=20 >> This document focuses narrowly on the issue of allowable DNS-Labels >> in TLDs and does not (and is not intended to) make any other changes >> or clarifications to existing domain name syntax rules. >=20 >> It is carefully noted that the specification in this document is not >> the only factor in choosing suitable TLD DNS-Labels, and that many >> considerations external to the IETF are included in that wider >> policy. See Section 5 for more discussion of policy considerations. >=20 >> 2. Definitions >=20 >> The term DNS-Label is used in this document to have precisely the >> same meaning as the term "label", as introduced in [RFC1034], section >> 3.1. A DNS-Label denotes one node in a DNS tree. A DNS-Label is >> zero to 63 octets in length. The term "DNS-Label" refers exclusively >> to the "wire format" of the label, and not to any presentation format >> of the label. >=20 >> A Top-Level Domain (TLD) DNS-Label is the right-most ("highest- >> level") DNS-Label in a fully-qualified domain name. >=20 >> The terms A-Label and U-Label are used in this document as defined in >> [RFC5890]. >=20 >=20 >> 3. Background >=20 >> [RFC0952] defines a host name as follows: >=20 >> 'A "name" ... is a text string up to 24 characters drawn from the >> alphabet (A-Z), digits (0-9), minus sign (-), and period (.). >> Note that periods are only allowed when they serve to delimit >> components of "domain style names". (See RFC-921, "Domain Name >> System Implementation Schedule", for background). No blank or >> space characters are permitted as part of a name. No distinction >> is made between upper and lower case. The first character must be >> an alpha character. The last character must not be a minus sign >> or period.' [Unnumbered section titled "ASSUMPTIONS", first >> paragraph] >=20 >> [RFC1123] reaffirms this definition, but makes one change to the >> syntax: >=20 >> 'The syntax of a legal Internet host name was specified in RFC-952 >> [DNS:4]. One aspect of host name syntax is hereby changed: the >> restriction on the first character is relaxed to allow either a >> letter or a digit. Host software MUST support this more liberal >> syntax.' [Section 2.1] >=20 >> In addition, the DISCUSSION section of Section 2.1 says: >=20 >> 'However, a valid host name can never have the dotted-decimal form >> #.#.#.#, since at least the highest-level component label will be >> alphabetic.' [Section 2.1] >=20 >> Some implementers may have understood the above phrase 'will be >> alphabetic' to be a protocol restriction. >=20 > This _may_ be true, but since this restriction is only applicable in the > context of the complete paragraph which the draft fails to quote: >=20 > If a dotted-decimal number can be entered without such > identifying delimiters, then a full syntactic check must be > made, because a segment of a host domain name is now allowed > to begin with a digit and could legally be entirely numeric > (see Section 6.1.2.4). However, a valid host name can never > have the dotted-decimal form #.#.#.#, since at least the > highest-level component label will be alphabetic. >=20 > These considerations apply to confusing an FQDN with a dotted quad and > just deduce from the shape of then current TLDs that a full ambiguity > "never" can happen. No harm is done unless and until we'd see an all-digi= ts > TLD. In today's environment it might be a good idea to spend some cycles > on IPv6 literals, too. >=20 >> Neither [RFC0952] nor [RFC1123] explicitly states the reasons for >> these restrictions. It might be supposed that human factors were a >> consideration; [RFC1123] appears to suggest that one of the reasons >> was to prevent confusion between dotted-decimal IPv4 addresses and >> host domain names. In any case, it is reasonable to believe that the >> restrictions have been assumed in some deployed software, and that >> changes to the rules should be undertaken with caution. >=20 > This is hand waving, IMHO. >=20 >> In order to accommodate the wish to express TLD names in scripts >> other than Latin (or rather, the US-ASCII subset of Latin), it is >> necessary to allow non-alphabetic characters in the corresponding TLD >> DNS-Labels. To minimize changes, the U-label form of a TLD name is >> restricted in ways functionally compatible with the restrictions >> (from [RFC0952] and [RFC1123]) on US-ASCII TLD names, by applying >> rules analogous to those already imposed on US-ASCII TLD DNS-Labels >> to TLD U-labels. >=20 >> However, deployed software that checks DNS top-level labels for >> conformance with an alphabetic restriction will not recognize such >> corresponding A-Labels (i.e., U-labels represented in their US-ASCII >> form). >=20 > So, since A-labels will always start with "xn--" and are likely to contai= n > digits and another "-", "deployed software" that makes (misguided) assump= tions > about the characters used in TLD labels is not helped. >=20 >> 4. TLD Label Syntax Specification >=20 >> This document relaxes the existing specification to allow TLD DNS- >> Labels to be well-formed A-Labels, but places restrictions on their >> corresponding U-Labels. That is, not every well-formed A-Label is a >> valid TLD DNS-Label. >=20 > Nit: as per the definition above "DNS-Label" refers to the wire format wh= ereas > "A-label" as per RFC 5890 are in presentation format, thus they cannot be > equal but only represeantations of each other. >=20 >> The ABNF expression that matches a valid TLD DNS-Label is as follows: >=20 >> tld-dns-label =3D traditional-tld-label / idn-label >=20 >> traditional-tld-label =3D 1*63(ALPHA) >=20 >> idn-label =3D Restricted-A-Label >=20 >> ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z >=20 >> A Restricted-A-Label is a DNS-Label which satisfies all the following >> conditions: >=20 >> 1. the DNS-Label is a valid A-Label according to [RFC5890]; >=20 >> 2. the derived property value of all code points, as defined by >> [RFC5890], is PVALID; >=20 >> 3. the general category of all code points, is one of { Ll, Lo, Lm, >> Mn }. >=20 >> This new specification reflects current practice in registration of >> TLD names by the IANA, extended to accommodate IDNs. >=20 > There is no justification or explanation given for this restriction and a= lso no > way in which this change to the U-label would help deployed software that= allegedly > checks TLD labels for being "alphabetic". >=20 >> 5. Policy Considerations >=20 >> This document provides a technical specification that limits the set >> of TLD DNS-Labels that are available for assignment; it does not aim >> to encapsulate the full policy framework within which TLD names are >> chosen. >=20 >> At the time of writing, the policy under which TLD names are chosen >> is developed and maintained by ICANN in consultation with a wide base >> of stakeholders. As the Internet continues to grow to serve new user >> communities, applications and services, it is to be expected that the >> corresponding policy will be changed accordingly. >=20 > It is unclear whether this draft attempts to reflect current IANA/ICANN r= oot zone > TLD naming policy into an IETF standard and why that would be advised, ju= stified > or desirable - or vice versa in which case the documents lacks a justific= ation > for the restriction of TLD labels. >=20 >> 6. IANA Considerations >=20 >> While this document makes no requests of the IANA, management of the >> root zone is an IANA function. This document expands the set of >> strings permitted for delegation from the root zone, and hence >> establishes new limits for the corresponding IANA policy. >=20 > Management of the root zone is an IANA function outside the scope of RFC = 2860, > whereas "IANA considerations" guide IANA under exact that MoU. Therefore= , this > text has no effect. The last sentence, though, answers my question raise= d after > the previous paragraph: again, the technical justification for limiting t= he > TLD code points in the context of the RFC 1123 ambiguity is missing. >=20 >> 7. Security Considerations >=20 >> This document is believed to have limited security implications. >=20 >> General discussion about the security effects of internationalized >> labels can be found in [RFC5890], section 4. Those considerations >> apply equally to TLD labels. >=20 >> The creation of new TLDs has the potential to conflict with software >> which (for example) predates and correspondingly does not accommodate >> new TLD names. Such software problems might in turn lead to security >> vulnerabilities, e.g. in the case where a DNS name specified by a >> user is truncated or otherwise misinterpreted, causing an application >> to interact with a different remote host from that which the user >> intended. It should be noted that this is not a new phenomenon, and >> has been observed following the creation of new (US-ASCII) TLD names >> prior to the publication of this document. >=20 >> The issue that some Unicode characters can be confused with each >> other is discussed at length in the Security Considerations section >> of [RFC5890]. >=20 > With the remarks made above, this is mostly irrelevant to the issue at ha= nd. > What might be discussed here is the confusion of IP address literals > (v4 and v6, for that matter) with FQDNs and how the (clarified) section > of RFC1123 relates to this problem. >=20 > I do not feel right comfortable to "send text" for changes since basicall= y > i believe the draft would need a completely different approach that > explains the non-normative nature of the "can never happen" remark. > If anyone shares this view i'd be happy to come up with a counter proposa= l. >=20 > -Peter From peter@denic.de Thu Aug 4 08:49:17 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AEB21F8B2D for ; Thu, 4 Aug 2011 08:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] 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 vqkMXcqW43oE for ; Thu, 4 Aug 2011 08:49:17 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8721F8B1D for ; Thu, 4 Aug 2011 08:49:17 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Qp0Aq-0003M0-14; Thu, 04 Aug 2011 17:49:28 +0200 Received: from localhost by x27.adm.denic.de with local id 1Qp0Ap-0002wP-Tv; Thu, 04 Aug 2011 17:49:27 +0200 Date: Thu, 4 Aug 2011 17:49:27 +0200 From: Peter Koch To: Joe Abley Message-ID: <20110804154927.GA32003@x27.adm.denic.de> Mail-Followup-To: Joe Abley , dns directorate , "liman@netnod.se" References: <01450745-EF80-4518-B6B4-8C0EE5CD8139@icann.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01450745-EF80-4518-B6B4-8C0EE5CD8139@icann.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: dns directorate , "liman@netnod.se" Subject: Re: [dns-dir] draft-liman-tld-names-05, advice sought X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:49:18 -0000 On Mon, Aug 01, 2011 at 07:12:51AM -0700, Joe Abley wrote: > (c) koch proposal > > Formalise the "alphabetic" constraint for wire-format TLD labels, and extend it specifically to permit "xn--" wire-format labels. This leaves it possible for TLD U-Labels to contain punctuation and digits (i.e. it retains the alphabetic restriction for US-ASCII TLD labels, but does not impose one for IDNs). that's not quite what i had in mind, but since i only said what not so far, let me clarify: i do not see 'xn--' and the later '-' special in any case. So, my proposal would be to clarify that the 'will always be alphabetic' clause is, in hindsight, a wrong prediction and in any case should not be read in a normative way. This may or may not change the obligation of or advice to teh implementor when they exercize the 'dotted quad' confusability checks. Whether or not we can or should assume 'will never be digit only' instead, is subject to debate, but history tells us we shouldn't make such broad assumptions. -Peter From dromasca@avaya.com Thu Aug 4 22:22:28 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0426C21F8A51; Thu, 4 Aug 2011 22:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, 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 8gset1T2Oge8; Thu, 4 Aug 2011 22:22:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB021F8A4F; Thu, 4 Aug 2011 22:22:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFN9O07GmAcF/2dsb2JhbABChEeiMXd3gUABAQEBAxIGCw0EUQYBCA0IAgMCBgYMCwECAgMBRAcBAQUEAQQBEggarH0Cik+RPIErhAsxXwSYJYtD X-IronPort-AV: E=Sophos;i="4.67,321,1309752000"; d="scan'208";a="295397196" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Aug 2011 01:22:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Aug 2011 01:19:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 5 Aug 2011 07:22:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the August 11, 2011 IESG Teleconference Thread-Index: AcxS+Km6RbnadWQnSwSsJ6TQqXwHvAANlg1Q From: "Romascanu, Dan (Dan)" To: , , , "YANG Doctors" , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 11, 2011 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:22:28 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgOC8xNCB0ZWxl Y2hhdC4gUGxlYXNlIHNlbmQgbWUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzIGFuZCBjb25jZXJu cyBiZWZvcmUgOC8xMyBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGllc2ctYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFU0cgU2VjcmV0YXJ5 DQpTdWJqZWN0OiBQUkVMSU1JTkFSWSBBZ2VuZGEgYW5kIFBhY2thZ2UgZm9yIHRoZSBBdWd1c3Qg MTEsIDIwMTEgSUVTRyBUZWxlY29uZmVyZW5jZSANCg0KLi4uDQoNCjIuIFByb3RvY29sIEFjdGlv bnMNCjIuMSBXRyBTdWJtaXNzaW9ucw0KMi4xLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRm LW1wbHMtcDJtcC1sc3AtcGluZy0xNw0KICAgIERldGVjdGluZyBEYXRhIFBsYW5lIEZhaWx1cmVz IGluIFBvaW50LXRvLU11bHRpcG9pbnQgTXVsdGlwcm90b2NvbA0KICAgIExhYmVsIFN3aXRjaGlu ZyAoTVBMUykgLSBFeHRlbnNpb25zIHRvIExTUCBQaW5nIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAg ICBOb3RlOiBSb3NzIENhbGxvbiAocmNhbGxvbkBqdW5pcGVyLm5ldCkgaXMgdGhlIGRvY3VtZW50 IHNoZXBoZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtaWV0Zi1t cGxzLWxzcC1waW5nLWVuaGFuY2VkLWRzbWFwLTEwDQogICAgTWVjaGFuaXNtIGZvciBwZXJmb3Jt aW5nIExTUC1QaW5nIG92ZXIgTVBMUyB0dW5uZWxzIChQcm9wb3NlZA0KICAgIFN0YW5kYXJkKQ0K ICAgIE5vdGU6IFJvc3MgQ2FsbG9uIChyY2FsbG9uQGp1bmlwZXIubmV0KSBpcyB0aGUgZG9jdW1l bnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFN0ZXdhcnQgQnJ5YW50DQoNCiAgbyBkcmFmdC1pZXRm LWJlaGF2ZS1mdHA2NC0xMg0KICAgIEFuIEZUUCBBTEcgZm9yIElQdjYtdG8tSVB2NCB0cmFuc2xh dGlvbiAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogRGFuIFdpbmcgKGR3aW5nQGNpc2Nv LmNvbSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5n dG9uDQoNCiAgbyBkcmFmdC1pZXRmLWNjYW1wLWFzeW1tLWJ3LWJpZGlyLWxzcHMtYmlzLTAyDQog ICAgR01QTFMgQXN5bW1ldHJpYyBCYW5kd2lkdGggQmlkaXJlY3Rpb25hbCBMYWJlbCBTd2l0Y2hl ZCBQYXRocyAoTFNQcykNCiAgICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogRGVib3Jh aCBCcmluZ2VyIChkYjM1NDZAYXR0LmNvbSkgaXMgdGhlIERvY3VtZW50DQogICAgU2hlcGhlcmQu DQogICAgVG9rZW46IEFkcmlhbiBGYXJyZWwNCg0KICBvIGRyYWZ0LWlldGYtcm9sbC1vZjAtMTUN CiAgICBSUEwgT2JqZWN0aXZlIEZ1bmN0aW9uIFplcm8gKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAg IE5vdGU6IEpQIFZhc3NldXIgKGpwdkBjaXNjby5jb20pIGlzIHRoZSBkb2N1bWVudCBzaGVwaGVy ZC4NCiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtaWV0Zi1tcGxzLW1sZHAt cmVjdXJzLWZlYy0wNA0KICAgIFVzaW5nIE11bHRpcG9pbnQgTERQIHdoZW4gdGhlIEJhY2tib25l IGhhcyBubyBSb3V0ZSB0byB0aGUgUm9vdA0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBO b3RlOiBMb2EgQW5kZXJzc29uIChsb2FAcGkubnUpIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZC4N CiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xp dGUtcmFkaXVzLWV4dC0wNA0KICAgIFJBRElVUyBFeHRlbnNpb25zIGZvciBEdWFsLVN0YWNrIExp dGUgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6IFlvbmcgQ3VpIChjdWl5b25nQHRzaW5n aHVhLmVkdS5jbikgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBE cm9tcw0KDQogIG8gZHJhZnQtaWV0Zi1tc2VjLWdkb2ktdXBkYXRlLTA5DQogICAgVGhlIEdyb3Vw IERvbWFpbiBvZiBJbnRlcnByZXRhdGlvbiAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTog VmluY2VudCBSb2NhICh2aW5jZW50LnJvY2FAaW5yaWEuZnIpIGlzIHRoZSBzaGVwaGVyZC4NCiAg ICBUb2tlbjogU2VhbiBUdXJuZXINCg0KMi4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0K DQoyLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucw0KMi4yLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFm dC1ndXRtYW5uLWNtcy1obWFjLWVuYy0wNQ0KICAgIFVzaW5nIE1BQy1hdXRoZW50aWNhdGVkIEVu Y3J5cHRpb24gaW4gdGhlIENyeXB0b2dyYXBoaWMgTWVzc2FnZQ0KICAgIFN5bnRheCAoQ01TKSAo UHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogUGV0ZXIgR3V0bWFubiAocGd1dDAwMUBjcy5h dWNrbGFuZC5hYy5ueikgaXMgdGhlIERvY3VtZW50DQogICAgU2hlcGhlcmQuDQogICAgVG9rZW46 IFNlYW4gVHVybmVyDQoNCjIuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4gRG9j dW1lbnQgQWN0aW9ucw0KMy4xIFdHIFN1Ym1pc3Npb25zDQozLjEuMSBOZXcgSXRlbXMNCg0KICBv IGRyYWZ0LWlldGYtdHN2d2ctcnN2cC1zZWN1cml0eS1ncm91cGtleWluZy0xMA0KICAgIEFwcGxp Y2FiaWxpdHkgb2YgS2V5aW5nIE1ldGhvZHMgZm9yIFJTVlAgU2VjdXJpdHkgKEluZm9ybWF0aW9u YWwpDQogICAgTm90ZTogSmFtZXMgUG9sayAoam1wb2xrQGNpc2NvLmNvbSkgaXMgdGhlIERvY3Vt ZW50IFNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5ndG9uDQoNCiAgbyBkcmFmdC1p ZXRmLWRlY2FkZS1zdXJ2ZXktMDUNCiAgICBBIFN1cnZleSBvZiBJbi1uZXR3b3JrIFN0b3JhZ2Ug U3lzdGVtcyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBIYWliaW4gU29uZyAoaGFpYmluLnNv bmdAaHVhd2VpLmNvbSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZp ZCBIYXJyaW5ndG9uDQoNCiAgbyBkcmFmdC1pZXRmLW9wc2F3Zy1vYW0tb3ZlcnZpZXctMDUNCiAg ICBBbiBPdmVydmlldyBvZiBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5h bmNlIChPQU0pDQogICAgTWVjaGFuaXNtcyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBTY290 dCBCcmFkbmVyIChzb2JAaGFydmFyZC5lZHUpIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZC4NCiAg ICBUb2tlbjogUm9uIEJvbmljYQ0KDQozLjEuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoN CjMuMiBJbmRpdmlkdWFsIFN1Ym1pc3Npb25zIFZpYSBBRA0KMy4yLjEgTmV3IEl0ZW1zDQoNCiAg byBkcmFmdC1zaGlvbW90by1jY2FtcC1zd2l0Y2gtcHJvZ3JhbW1pbmctMDUNCiAgICBBZHZpY2Ug b24gV2hlbiBJdCBpcyBTYWZlIHRvIFN0YXJ0IFNlbmRpbmcgRGF0YSBvbiBMYWJlbCBTd2l0Y2hl ZA0KICAgIFBhdGhzIEVzdGFibGlzaGVkIFVzaW5nIFJTVlAtVEUgKEluZm9ybWF0aW9uYWwpDQog ICAgTm90ZTogRGFuaWVsIEtpbmcgKGRhbmllbEBvbGRkb2cuY28udWspIGlzIHRoZSBEb2N1bWVu dCBTaGVwaGVyZC4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KICBvIGRyYWZ0LWJ1cmdp bi1pcHNlYy1zdWl0ZWItcHJvZmlsZS0wMQ0KICAgIFN1aXRlIEIgUHJvZmlsZSBmb3IgSW50ZXJu ZXQgUHJvdG9jb2wgU2VjdXJpdHkgKElQc2VjKQ0KICAgIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5v dGU6IFBhdWwgSG9mZm1hbiAocGF1bC5ob2ZmbWFuQHZwbmMub3JnKSBpcyB0aGUgZG9jdW1lbnQg c2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAgbyBkcmFmdC1sYXctcmZjNDg2 OWJpcy0wMQ0KICAgIFN1aXRlIEIgQ3J5cHRvZ3JhcGhpYyBTdWl0ZXMgZm9yIElQc2VjIChJbmZv cm1hdGlvbmFsKQ0KICAgIE5vdGU6IFBhdWwgSG9mZm1hbiAocGF1bC5ob2ZmbWFuQHZwbmMub3Jn KSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAg byBkcmFmdC1mb3J0ZS1sb3N0LWV4dGVuc2lvbnMtMDcNCiAgICBMb2NhdGlvbi10by1TZXJ2aWNl IFRyYW5zbGF0aW9uIChMb1NUKSBQcm90b2NvbCBFeHRlbnNpb25zDQogICAgKEV4cGVyaW1lbnRh bCkNCiAgICBOb3RlOiBSaWNoYXJkIEJhcm5lcyAocmJhcm5lc0BiYm4uY29tKSBpcyB0aGUgZG9j dW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJvYmVydCBTcGFya3MNCg0KMy4yLjIgUmV0dXJu aW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQozLjMgSVJURiBhbmQgSW5kZXBlbmRlbnQgU3VibWlzc2lv biBTdHJlYW0gRG9jdW1lbnRzDQozLjMuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LXNpbXBzb24t aXNpcy1wcHAtdW5pcXVlLTAxDQogICAgR2VuZXJhdGlvbiBvZiBVbmlxdWUgSVMtSVMgU3lzdGVt IElkZW50aWZpZXJzIChFeHBlcmltZW50YWwpDQogICAgTm90ZTogSVNFIFN1Ym1pc3Npb24NCiAg ICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KMy4zLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9O RQ0KDQo0LiBXb3JraW5nIEdyb3VwIEFjdGlvbnMNCjQuMSBXRyBDcmVhdGlvbg0KNC4xLjEgUHJv cG9zZWQgZm9yIElFVEYgUmV2aWV3DQoNCiAgTk9ORQ0KDQo0LjEuMiBQcm9wb3NlZCBmb3IgQXBw cm92YWwNCg0KICBOT05FDQoNCjQuMiBXRyBSZWNoYXJ0ZXJpbmcNCjQuMi4xIFVuZGVyIEV2YWx1 YXRpb24gZm9yIElFVEYgUmV2aWV3DQoNCiAgbyBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKHBj ZSkNCiAgICBUb2tlbjogQWRyaWFuDQoNCiAgbyB2Q2FyZCBhbmQgQ2FyZERBViAodmNhcmRkYXYp DQogICAgVG9rZW46IFBldGVyDQoNCg0K From peter@denic.de Fri Aug 5 06:25:49 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB40021F8BAA for ; Fri, 5 Aug 2011 06:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] 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 aSCDW9J-Zf+h for ; Fri, 5 Aug 2011 06:25:49 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id D640821F8B98 for ; Fri, 5 Aug 2011 06:25:48 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QpKPc-0004Hk-Lx; Fri, 05 Aug 2011 15:26:04 +0200 Received: from localhost by x27.adm.denic.de with local id 1QpKPc-0005Ez-Ib; Fri, 05 Aug 2011 15:26:04 +0200 Date: Fri, 5 Aug 2011 15:26:04 +0200 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20110805132604.GJ32003@x27.adm.denic.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , IETF DNS Directorate References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 11, 2011 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:25:49 -0000 Dan, i've checked the drafts > o draft-ietf-mpls-p2mp-lsp-ping-17 > o draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 > o draft-ietf-behave-ftp64-12 > o draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-02 > o draft-ietf-roll-of0-15 > o draft-ietf-mpls-mldp-recurs-fec-04 > o draft-ietf-softwire-dslite-radius-ext-04 > o draft-ietf-msec-gdoi-update-09 > o draft-gutmann-cms-hmac-enc-05 > o draft-ietf-tsvwg-rsvp-security-groupkeying-10 > o draft-ietf-decade-survey-05 > o draft-ietf-opsawg-oam-overview-05 > o draft-shiomoto-ccamp-switch-programming-05 > o draft-burgin-ipsec-suiteb-profile-01 > o draft-law-rfc4869bis-01 > o draft-forte-lost-extensions-07 > o draft-simpson-isis-ppp-unique-01 for a few keywords. draft-ietf-decade-survey-05 mentions the DNS a few times, noting to worry about. draft-ietf-softwire-dslite-radius-ext-04 has some nits/minor issues: o In the introduction, AFTR should be expanded once, before first use o I'm not too familiar with RADIUS folklore, so this might be obvious to others, but section 4 does not clearly state which format is used for DS-Lite-Tunnel-Name. Section 5 later states that "The data type of DS-Lite-Tunnel-Name is a string", but earlier it is suggested that DS-Lite-Tunnel-Name be fed with the data obtained through DHCP in OPTION_AFTR_NAME, which is clarly in DNS wire format. If this option uses text (presentation) format instead, it would need to say whether it's all ASCII (A-Label) or not (where it is unlikely amnybody intended to use U-Labels). The picture at the top of page 9 suggests the DS-Lite-Tunnel-Name has a fixed length (of 6 octets, for taht matter), so a more open ended graph as used in the RADIUS RFCs might be advised. -Peter From rdroms.ietf@gmail.com Fri Aug 5 06:27:33 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3B21F8B78 for ; Fri, 5 Aug 2011 06:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, 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 gWirhaeHLf2D for ; Fri, 5 Aug 2011 06:27:32 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5621F8B65 for ; Fri, 5 Aug 2011 06:27:32 -0700 (PDT) Received: by qyk35 with SMTP id 35so1474512qyk.10 for ; Fri, 05 Aug 2011 06:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Iz+IxPYvC7PMRE54q20eaZUb0bzbQmQHxUnDBkGv7xQ=; b=PKsVnDlDjHJMiKPFLjvcydY0UneeRwzFaP6IW4gxIaa4EZlsexC6XfJWapViksKAjo lfQ7Hley5RCcROF358gsJaA9CNkN7yB7+hH7db6/fC4hqAu9udhqoPQvXIAaMjuFgSVB 753kdoh7jvo815UngQ3sRSbTnK93ZdpZJVxeM= Received: by 10.224.174.201 with SMTP id u9mr1682499qaz.351.1312550867022; Fri, 05 Aug 2011 06:27:47 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id m7sm2106085qct.29.2011.08.05.06.27.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 06:27:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <20110805132604.GJ32003@x27.adm.denic.de> Date: Fri, 5 Aug 2011 09:27:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110805132604.GJ32003@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1084) Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 11, 2011 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:27:33 -0000 Thanks, Peter. Coincidentally, I was updating the state of = draft-ietf-softwire-dslite-radius-ext-04 this morning. Do you mind if I = enter your review verbatim as a Comment? - Ralph On Aug 5, 2011, at 9:26 AM 8/5/11, Peter Koch wrote: > Dan, >=20 > i've checked the drafts >=20 >> o draft-ietf-mpls-p2mp-lsp-ping-17 >> o draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 >> o draft-ietf-behave-ftp64-12 >> o draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-02 >> o draft-ietf-roll-of0-15 >> o draft-ietf-mpls-mldp-recurs-fec-04 >> o draft-ietf-softwire-dslite-radius-ext-04 >> o draft-ietf-msec-gdoi-update-09 >> o draft-gutmann-cms-hmac-enc-05 >> o draft-ietf-tsvwg-rsvp-security-groupkeying-10 >> o draft-ietf-decade-survey-05 >> o draft-ietf-opsawg-oam-overview-05 >> o draft-shiomoto-ccamp-switch-programming-05 >> o draft-burgin-ipsec-suiteb-profile-01 >> o draft-law-rfc4869bis-01 >> o draft-forte-lost-extensions-07 >> o draft-simpson-isis-ppp-unique-01 >=20 > for a few keywords. draft-ietf-decade-survey-05 mentions the DNS a = few > times, noting to worry about. >=20 > draft-ietf-softwire-dslite-radius-ext-04 has some nits/minor issues: >=20 > o In the introduction, AFTR should be expanded once, before first use >=20 > o I'm not too familiar with RADIUS folklore, so this might be obvious = to > others, but section 4 does not clearly state which format is used > for DS-Lite-Tunnel-Name. Section 5 later states that > "The data type of DS-Lite-Tunnel-Name is a string", but earlier it is = suggested > that DS-Lite-Tunnel-Name be fed with the data obtained through DHCP = in > OPTION_AFTR_NAME, which is clarly in DNS wire format. If this option > uses text (presentation) format instead, it would need to say whether = it's > all ASCII (A-Label) or not (where it is unlikely amnybody intended to > use U-Labels). > The picture at the top of page 9 suggests the DS-Lite-Tunnel-Name > has a fixed length (of 6 octets, for taht matter), so a more open = ended > graph as used in the RADIUS RFCs might be advised. >=20 > -Peter > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From joe.abley@icann.org Thu Aug 4 09:03:12 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003EA21F856C for ; Thu, 4 Aug 2011 09:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.685 X-Spam-Level: X-Spam-Status: No, score=-6.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TWiOww2T3wQO for ; Thu, 4 Aug 2011 09:03:11 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 806DB21F8BAB for ; Thu, 4 Aug 2011 09:03:11 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 4 Aug 2011 09:03:26 -0700 From: Joe Abley To: Peter Koch Date: Thu, 4 Aug 2011 09:03:24 -0700 Thread-Topic: [dns-dir] draft-liman-tld-names-05, advice sought Thread-Index: AcxSwAt6Qa+EeShBTWK0ANbUlgPJ8w== Message-ID: References: <01450745-EF80-4518-B6B4-8C0EE5CD8139@icann.org> <20110804154927.GA32003@x27.adm.denic.de> In-Reply-To: <20110804154927.GA32003@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 08 Aug 2011 01:31:44 -0700 Cc: dns directorate , "liman@netnod.se" Subject: Re: [dns-dir] draft-liman-tld-names-05, advice sought X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:03:12 -0000 On 2011-08-04, at 11:49, Peter Koch wrote: > On Mon, Aug 01, 2011 at 07:12:51AM -0700, Joe Abley wrote: >=20 >> (c) koch proposal >>=20 >> Formalise the "alphabetic" constraint for wire-format TLD labels, and ex= tend it specifically to permit "xn--" wire-format labels. This leaves it po= ssible for TLD U-Labels to contain punctuation and digits (i.e. it retains = the alphabetic restriction for US-ASCII TLD labels, but does not impose one= for IDNs). >=20 > that's not quite what i had in mind, but since i only said what not so fa= r, > let me clarify: OK, then let's re-cast (c) as the pseudo-Koch option; I think your proposal= then amounts to option (b). I believe the situation remains that the consensus-enthusiasm needle for op= tion (d) lies somewhere between "apathy" and "mild dislike", and the opinio= ns of the DNS Directorate would still be beneficial in identifying a path f= orward. Joe > (a) do nothing >=20 > Leave the ambiguous specification in 1123, leave the question of whether = the IETF has an interest in constraining label syntax for TLDs open, and do= nothing. >=20 > (b) a label is a label is a label >=20 > State clearly that there is no special restriction for TLD labels, distin= ct from the protocol restrictions for any other label in the DNS tree; in o= ther words, release any interest in TLD label syntax at the IETF, and defer= it all to ICANN. >=20 > I've heard this approach promoted by people in DNSOP. I expected to hear = dissent from the App area people, since the problem remains of how to disti= nguish between a literal IPv4 address and a domain name in the unlikely eve= nt that a TLD exists that is syntactically a legal final component of an IP= v4 address. But in Qu=E9bec those that did express an opinion seemed to say= "this is ICANN's business, we don't care". But I'd be hard-pushed to ident= ify consensus in either venue. >=20 > (c) pseudo-koch proposal >=20 > Formalise the "alphabetic" constraint for wire-format TLD labels, and ext= end it specifically to permit "xn--" wire-format labels. This leaves it pos= sible for TLD U-Labels to contain punctuation and digits (i.e. it retains t= he alphabetic restriction for US-ASCII TLD labels, but does not impose one = for IDNs). >=20 > (d) draft-liman-tld-names >=20 > As discussed (and reviewed exhaustively by Peter, many thanks for that) f= ormalize the "alphabetic" constraint for US-ASCII and for IDNA2008 U-Labels= (i.e. keep the restriction consistent for users who may not be aware of wh= ether they are typing, in effect, a U-Label or a US-ASCII label). >=20 > (e) something else >=20 > . . . From ajs@anvilwalrusden.com Thu Aug 11 12:52:26 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704DD11E8090 for ; Thu, 11 Aug 2011 12:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ5AQUTrEZTy for ; Thu, 11 Aug 2011 12:52:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DFEE111E8081 for ; Thu, 11 Aug 2011 12:52:22 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1D2011ECB41D; Thu, 11 Aug 2011 19:52:58 +0000 (UTC) Date: Thu, 11 Aug 2011 15:52:55 -0400 From: Andrew Sullivan To: Joe Abley , dns directorate , "liman@netnod.se" Message-ID: <20110811195255.GP95640@shinkuro.com> References: <01450745-EF80-4518-B6B4-8C0EE5CD8139@icann.org> <20110804154927.GA32003@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110804154927.GA32003@x27.adm.denic.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dns-dir] draft-liman-tld-names-05, advice sought X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:52:26 -0000 On Thu, Aug 04, 2011 at 05:49:27PM +0200, Peter Koch wrote: > read in a normative way. This may or may not change the obligation of or advice > to teh implementor when they exercize the 'dotted quad' confusability checks. It's not merely "'dotted quad' confusability checks" we have to worry about. There are lots of protocol slots that can either take a domain name or an IP address. In the happy case of mail, we are relieved of the burden because you are supposed to use [] around IP addresses. But everything else (including URIs, last I checked) can have raw IP addresses. Moreover, there is no requirement that the IP address be in a dotted-anything notation. Raw apparent integers work in at least some contexts I have seen. It is problems like this that set some people on edge. I think the document should be pursued, and I think it should go on as it currently does, on the quite correct grounds that whatever happens, it is always possible to open the door wider later. (It should perhaps suggest to IDNA application implementers that they should not rely on the restrictions to do validity checks, on the grounds that a wider policy is always possible later.) To me, this is only an effort to maximise interoperation and minimise surprise, and therefore to say that the names are required to work this way on the grounds of minimising such surprise. Strictly speaking, there is plenty of room for policy innovation here. That doesn't mean there are no potential technical implications. A -- Andrew Sullivan ajs@anvilwalrusden.com From pfaltstr@cisco.com Mon Aug 15 03:35:07 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9394F21F876A for ; Mon, 15 Aug 2011 03:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[AWL=1.881, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-hBz6a7wi5o for ; Mon, 15 Aug 2011 03:35:06 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6821F863E for ; Mon, 15 Aug 2011 03:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pfaltstr@cisco.com; l=1727; q=dns/txt; s=iport; t=1313404552; x=1314614152; h=mime-version:subject:from:date:cc: content-transfer-encoding:message-id:references:to; bh=c6+95bXxRBVocO1vNZ90pbwgsj3ogHSqNFI9a5TU6Wg=; b=MxNJDnrcYvqoDwiczTe8j1qp78oG3zA7wNFWYRZ50/ffa+38hGP9a2Ap juFXFDUtwI9fKxkPQFkACKM/SFHMmHkZSTLB45vONuErsiyTQlC/LCYYw elwJoMO3FZB94aXKB/fG5e075hf4UvN9t6f+9RQbdUEUvHJGC+JOz92R1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwHAAD2SE6Q/khR/2dsb2JhbABAmHqPCneBQAEBAQECAQEBAQ8BJzQLBQscAwECAS4hBigIGSKHTgSWRAGeHYVoXwSTEol2hwE X-IronPort-AV: E=Sophos;i="4.67,373,1309737600"; d="scan'208";a="50518533" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 15 Aug 2011 10:35:51 +0000 Received: from dhcp-10-55-89-113.cisco.com (dhcp-10-55-89-113.cisco.com [10.55.89.113]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7FAZouI005535; Mon, 15 Aug 2011 10:35:51 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 15 Aug 2011 12:35:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <629C7B65-181D-46BB-9E73-7E85359FF61F@cisco.com> References: <4E4657BB.5060902@gmail.com> To: iana@iana.org X-Mailer: Apple Mail (2.1084) Cc: dns directorate Subject: [dns-dir] Information on references X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 10:35:07 -0000 Hi, I just notice that in the registry for DNS Resource Types you do not = really have any reference section. Just a reference to "me" in this case = of the URI resource record type. Is that correct (that you do not have the definitions), or is it me that = fails in my clicking - karma? My personal view is that the list at IANA should have pointers to the = actual definitions. No, the URI spec was not done via the RFC process, but the faster(?) = review on the IETF dnsext mailing list etc. Patrik Begin forwarded message: > From: Mykyta Yevstifeyev > Date: 13 augusti 2011 12.53.47 CEST > To: "Patrik Faltstrom (pfaltstr)" > Cc: dnsext@ietf.org > Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs >=20 > 13.08.2011 13:48, Patrik Faltstrom (pfaltstr) wrote: >> On 13 aug 2011, at 12:27, "Jim Reid" wrote: >>=20 >>> Don't bother. HINFO is essentially dead. Pretty much nothing uses = it. I doubt any software queries for HINFO records. Few zones, if any, = publish them. >> Instead, if new such things really are needed, use more modern = mechanisms like NAPTR or URI rr types >=20 > Patrik, >=20 > I guess you refer to URI RR, which is registered as follows: >=20 >> URI 256 URI = [Faltstrom] >=20 > So you are indeed a right person to ask: where can I find the = documentation for this RR? >=20 > Mykyta >=20 >> (together with definition of the service you are after). >>=20 >> Patrik >>=20 >>=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From narten@us.ibm.com Mon Aug 15 05:20:42 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4C521F8B61 for ; Mon, 15 Aug 2011 05:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.246 X-Spam-Level: X-Spam-Status: No, score=-106.246 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcGpRaGZ9KAS for ; Mon, 15 Aug 2011 05:20:42 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7421F8B5F for ; Mon, 15 Aug 2011 05:20:42 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7FCI6fP015580 for ; Mon, 15 Aug 2011 06:18:06 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7FCLFuO117216 for ; Mon, 15 Aug 2011 06:21:15 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7FCQuMo026414 for ; Mon, 15 Aug 2011 06:26:56 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-235-172.mts.ibm.com [9.65.235.172]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7FCQtBQ026389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Aug 2011 06:26:56 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7FCLCcU004779; Mon, 15 Aug 2011 08:21:13 -0400 Message-Id: <201108151221.p7FCLCcU004779@cichlid.raleigh.ibm.com> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-reply-to: <629C7B65-181D-46BB-9E73-7E85359FF61F@cisco.com> References: <4E4657BB.5060902@gmail.com> <629C7B65-181D-46BB-9E73-7E85359FF61F@cisco.com> Comments: In-reply-to =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= message dated "Mon, 15 Aug 2011 12:35:50 +0200." Date: Mon, 15 Aug 2011 08:21:12 -0400 From: Thomas Narten Cc: dns directorate Subject: Re: [dns-dir] Information on references X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 12:20:42 -0000 > I just notice that in the registry for DNS Resource Types you do not > really have any reference section. Just a reference to "me" in this > case of the URI resource record type. Most of RFCs, as they should.. > Is that correct (that you do not have the definitions), or is it me > that fails in my clicking - karma? What is a better reference to insert here? IANA is always willing to put in a proper reference... if it has one. Most likely, IANA wasn't given a reference to point to when the expert approved the assignment. Thomas From pfaltstr@cisco.com Mon Aug 15 06:01:30 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47321F8B8E for ; Mon, 15 Aug 2011 06:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.358 X-Spam-Level: X-Spam-Status: No, score=-9.358 tagged_above=-999 required=5 tests=[AWL=0.941, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD1HK14C1Vvk for ; Mon, 15 Aug 2011 06:01:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0F22D21F8B89 for ; Mon, 15 Aug 2011 06:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pfaltstr@cisco.com; l=1565; q=dns/txt; s=iport; t=1313413335; x=1314622935; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9n1a+IUv1OPT66WKTuQKa/oQFqB9RCnrpITJxdO6jj0=; b=HEtLTQly9Kko/jqlGVOJoJxH9b/t5+BdMjZ1ZFNNHk7/hv0upSYTfbFa wgy1oLLM9PQ+XvG05Ls65QU1lcgozVoxdyMjQJIMS6DYi0LGHzdaUGoWi VPH2NpUKqsM6wTvIERo4uIDhx6HizABDQS6Un1a6340mcDh+qsoHCaoRe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEIXSU6Q/khL/2dsb2JhbABAqAR3gUABAQEBAgESAScxAwsFCwtGVwY1h06VfwGeK4VoXwSTEpB3 X-IronPort-AV: E=Sophos;i="4.67,374,1309737600"; d="scan'208";a="110843623" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Aug 2011 13:02:13 +0000 Received: from dhcp-10-55-89-113.cisco.com (dhcp-10-55-89-113.cisco.com [10.55.89.113]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7FD2C7k016584; Mon, 15 Aug 2011 13:02:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <201108151221.p7FCLCcU004779@cichlid.raleigh.ibm.com> Date: Mon, 15 Aug 2011 15:02:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65F6D198-FA60-4642-A457-4C710C990E71@cisco.com> References: <4E4657BB.5060902@gmail.com> <629C7B65-181D-46BB-9E73-7E85359FF61F@cisco.com> <201108151221.p7FCLCcU004779@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: dns directorate Subject: Re: [dns-dir] Information on references X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:01:30 -0000 On 15 aug 2011, at 14.21, Thomas Narten wrote: >> I just notice that in the registry for DNS Resource Types you do not >> really have any reference section. Just a reference to "me" in this >> case of the URI resource record type. >=20 > Most of RFCs, as they should.. >=20 >> Is that correct (that you do not have the definitions), or is it me >> that fails in my clicking - karma? >=20 > What is a better reference to insert here? IANA is always willing to > put in a proper reference... if it has one. The problem is that there is a "template" that is to be filled out by = the applicant (in this case me). That is vetted on the mailing list, and = finally approved. > Most likely, IANA wasn't given a reference to point to when the expert > approved the assignment. I think the problem might then be that the vetted and approved template, = as it is not an RFC, is not in the IETF a stable document. And because = of that IANA has nothing to reference. I suggest IANA in this case should have a repository with "whatever = document they where sent" when the approval was made. As a kitchen sink. = Then reference that in parallel with the references that they have = already now. I.e. in this specific case, I must say I thought IANA did have the = vetted and approved template for the RR Type on the IANA website. But = then I understand the reason why IANA does not have it might be because = we (IETF) has not asked IANA to store it (things that are basis for = parameter allocations that are not RFCs). Patrik From dromasca@avaya.com Fri Aug 19 00:48:32 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFAA21F8581; Fri, 19 Aug 2011 00:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryTxdndqtjPl; Fri, 19 Aug 2011 00:48:31 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8621F8574; Fri, 19 Aug 2011 00:48:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAJwUTk7GmAcF/2dsb2JhbABBhEuXRIpzdneBQAEBAQEDEhENBFEGAQYCDQgFAgYGDAsBAgIDAR8lBwEGBAEEARIIGqRdAopQkUeBLIQMMV8EmD2ETIcB X-IronPort-AV: E=Sophos;i="4.68,250,1312171200"; d="scan'208";a="298383456" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Aug 2011 03:49:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Aug 2011 03:45:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Aug 2011 09:49:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the August 25, 2011 IESG Teleconference Thread-Index: Acxd8+oZjGs6sf3ESV2HUb+wglzX6gAUEMog From: "Romascanu, Dan (Dan)" To: , , "IETF DNS Directorate" , , "YANG Doctors" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 25, 2011 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 07:48:32 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgOC8yNSBJRVNH IHRlbGVjaGF0LiBQbGVhc2Ugc2VuZCBtZSB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGNv bmNlcm5zIHJlbGF0ZWQgdG8gdGhlIGRvY3VtZW50cyBhbmQgV0cgY2hhcnRlcnMgb24gdGhlIGFn ZW5kYSBiZWZvcmUgOC8yNCBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVTRyBTZWNy ZXRhcnkNCg0KDQoNCjIuIFByb3RvY29sIEFjdGlvbnMNCjIuMSBXRyBTdWJtaXNzaW9ucw0KMi4x LjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXB3ZTMtZmF0LXB3LTA3DQogICAgRmxvdyBB d2FyZSBUcmFuc3BvcnQgb2YgUHNldWRvd2lyZXMgb3ZlciBhbiBNUExTIFBhY2tldCBTd2l0Y2hl ZA0KICAgIE5ldHdvcmsgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6IE1hdHRoZXcgQm9j Y2kgKG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tKSBpcyB0aGUNCiAgICBkb2N1bWVu dCBzaGVwaGVyZA0KICAgIFRva2VuOiBBZHJpYW4gRmFycmVsDQoNCiAgbyBkcmFmdC1pZXRmLXNp ZHItcmVzY2VydHMtcHJvdmlzaW9uaW5nLTEwDQogICAgQSBQcm90b2NvbCBmb3IgUHJvdmlzaW9u aW5nIFJlc291cmNlIENlcnRpZmljYXRlcyAoUHJvcG9zZWQNCiAgICBTdGFuZGFyZCkNCiAgICBO b3RlOiBTYW5kcmEgTXVycGh5IChTYW5kcmEuTXVycGh5QHNwYXJ0YS5jb20pIGlzIHRoZSBkb2N1 bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJh ZnQtaWV0Zi1tcGxzLXJzdnAtdGUtbm8tcGhwLW9vYi1tYXBwaW5nLTA5DQogICAgTm9uIFBlbnVs dGltYXRlIEhvcCBQb3BwaW5nIEJlaGF2aW9yIGFuZCBvdXQtb2YtYmFuZCBtYXBwaW5nIGZvcg0K ICAgIFJTVlAtVEUgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAg IE5vdGU6IE1hcnRpbiBWaWdvdXJldXggKG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQu Y29tKSBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogQWRyaWFuIEZh cnJlbA0KDQogIG8gZHJhZnQtaWV0Zi15YW0tcmZjNDQwOWJpcy0wMg0KICAgIE1lc3NhZ2UgU3Vi bWlzc2lvbiBmb3IgTWFpbCAoU3RhbmRhcmQpDQogICAgTm90ZTogUyBNb29uZXNhbXkgKHNtK2ll dGZAZWxhbmRzeXMuY29tKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFBl dGUgUmVzbmljaw0KDQogIG8gZHJhZnQtaWV0Zi1waW0taGVsbG8taW50aWQtMDENCiAgICBBbiBJ bnRlcmZhY2UgSUQgSGVsbG8gT3B0aW9uIGZvciBQSU0gKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAg IE5vdGU6IE1pa2UgTWNCcmlkZSAobW1jYnJpZGVAY2lzY28uY29tKSBpcyB0aGUgZG9jdW1lbnQg c2hlcGhlcmQuDQogICAgVG9rZW46IEFkcmlhbiBGYXJyZWwNCg0KICBvIGRyYWZ0LWlldGYtbXBs cy10cC1vbi1kZW1hbmQtY3YtMDYNCiAgICBNUExTIE9uLWRlbWFuZCBDb25uZWN0aXZpdHkgVmVy aWZpY2F0aW9uIGFuZCBSb3V0ZSBUcmFjaW5nIChQcm9wb3NlZA0KICAgIFN0YW5kYXJkKQ0KICAg IE5vdGU6IExvYSBBbmRlcnNzb24gKGxvYUBwaS5udSkgaXMgdGhlIERvY3VtZW50IFNoZXBoZXJk Lg0KICAgIFRva2VuOiBBZHJpYW4gRmFycmVsDQoNCiAgbyBkcmFmdC1pZXRmLWtyYi13Zy1jbGVh ci10ZXh0LWNyZWQtMDINCiAgICBUaGUgVW5lbmNyeXB0ZWQgRm9ybSBPZiBLZXJiZXJvcyA1IEtS Qi1DUkVEIE1lc3NhZ2UgKFByb3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAgTm90ZTogU2FtIEhh cnRtYW4gKGhhcnRtYW5zLWlldGZAbWl0LmVkdSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0K ICAgIFRva2VuOiBTdGVwaGVuIEZhcnJlbGwNCg0KMi4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAg byBkcmFmdC1pZXRmLWdyb3ctZ2VvbXJ0LTA1DQogICAgTXVsdGktdGhyZWFkZWQgUm91dGluZyBU b29sa2l0IChNUlQpIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChCR1ApDQogICAgcm91dGluZyBp bmZvcm1hdGlvbiBleHBvcnQgZm9ybWF0IHdpdGggZ2VvLWxvY2F0aW9uIGV4dGVuc2lvbnMNCiAg ICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogQ2hyaXN0b3BoZXIgTW9ycm93IChjaHJp c3RvcGhlci5tb3Jyb3dAZ21haWwuY29tKSBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4N CiAgICBUb2tlbjogUm9uIEJvbmljYQ0KDQoyLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucw0KMi4y LjEgTmV3IEl0ZW1zDQoNCiAgTk9ORQ0KDQoyLjIuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05F DQoNCjMuIERvY3VtZW50IEFjdGlvbnMNCjMuMSBXRyBTdWJtaXNzaW9ucw0KMy4xLjEgTmV3IEl0 ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXY2b3BzLTNncHAtZXBzLTAzDQogICAgSVB2NiBpbiAzR1BQ IEV2b2x2ZWQgUGFja2V0IFN5c3RlbSAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBKb2VsIEph ZWdnbGkgKGpvZWxqYUBib2d1cy5jb20pLCB2Nm9wcyBjby1jaGFpciBpcyB0aGUNCiAgICBkb2N1 bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogUm9uIEJvbmljYQ0KDQogIG8gZHJhZnQtaWV0Zi1k YW5lLXVzZS1jYXNlcy0wNQ0KICAgIFVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIGZvciBETlMt YmFzZWQgQXV0aGVudGljYXRpb24gb2YgTmFtZWQNCiAgICBFbnRpdGllcyAoREFORSkgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogT25kP2VqIFN1csOvwr/CvSAob25kcmVqLnN1cnlAbmljLmN6 KSBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQuDQogICAgVG9rZW46IFN0ZXBoZW4gRmFycmVsbA0K DQozLjEuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtYm13Zy1pZ3AtZGF0YXBs YW5lLWNvbnYtbWV0aC0yMw0KICAgIEJlbmNobWFya2luZyBNZXRob2RvbG9neSBmb3IgTGluay1T dGF0ZSBJR1AgRGF0YSBQbGFuZSBSb3V0ZQ0KICAgIENvbnZlcmdlbmNlIChJbmZvcm1hdGlvbmFs KQ0KICAgIE5vdGU6IEFsIE1vcnRvbiAoYWNtb3J0b25AYXR0LmNvbSkgaXMgdGhlIHNoZXBoZXJk Lg0KICAgIFRva2VuOiBSb24gQm9uaWNhDQoNCiAgbyBkcmFmdC1pZXRmLWJtd2ctaWdwLWRhdGFw bGFuZS1jb252LXRlcm0tMjMNCiAgICBUZXJtaW5vbG9neSBmb3IgQmVuY2htYXJraW5nIExpbmst U3RhdGUgSUdQIERhdGEgUGxhbmUgUm91dGUNCiAgICBDb252ZXJnZW5jZSAoSW5mb3JtYXRpb25h bCkNCiAgICBOb3RlOiBBbCBNb3J0b24gKGFjbW9ydG9uQGF0dC5jb20pIGlzIHRoZSBzaGVwaGVy ZC4NCiAgICBUb2tlbjogUm9uIEJvbmljYQ0KDQozLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucyBW aWEgQUQNCjMuMi4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtZG9yaWEtZ2VuYXJ0LWV4cGVyaWVu Y2UtMDQNCiAgICBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIEV4cGVyaWVuY2Vz IChJbmZvcm1hdGlvbmFsKQ0KICAgIFRva2VuOiBSdXNzIEhvdXNsZXkNCg0KICBvIGRyYWZ0LXll dnN0aWZleWV2LWlvbi1yZXBvcnQtMDcNCiAgICBNb3ZpbmcgUkZDIDQ2OTMgdG8gSGlzdG9yaWMg KEluZm9ybWF0aW9uYWwpDQogICAgVG9rZW46IFJ1c3MgSG91c2xleQ0KDQozLjIuMiBSZXR1cm5p bmcgSXRlbXMNCg0KICBOT05FDQoNCjMuMyBJUlRGIGFuZCBJbmRlcGVuZGVudCBTdWJtaXNzaW9u IFN0cmVhbSBEb2N1bWVudHMNCjMuMy4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtYm91Y2FkYWly LXBwcGV4dC1wb3J0cmFuZ2Utb3B0aW9uLTA2DQogICAgSHVhd2VpIFBvcnQgUmFuZ2UgQ29uZmln dXJhdGlvbiBPcHRpb25zIGZvciBQUFAgSVBDUCAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBJ U0UgU3VibWlzc2lvbg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCjMuMy4yIFJldHVybmluZyBJ dGVtcw0KDQogIE5PTkUNCg0KMy4zLjMgRm9yIEFjdGlvbg0KDQogIG8gZHJhZnQtd2VlYi1yZXNl YXJjaC10by1pbnRlcm5ldC1zdGRzLTAyDQogICAgSG93IHRvIENvbnRyaWJ1dGUgUmVzZWFyY2gg UmVzdWx0cyB0byBJbnRlcm5ldCBTdGFuZGFyZGl6YXRpb24NCiAgICAoSW5mb3JtYXRpb25hbCkN CiAgICBOb3RlOiBJU0UgU3VibWlzc2lvbg0KICAgIFRva2VuOiBSdXNzIEhvdXNsZXkNCg0KNC4g V29ya2luZyBHcm91cCBBY3Rpb25zDQo0LjEgV0cgQ3JlYXRpb24NCjQuMS4xIFByb3Bvc2VkIGZv ciBJRVRGIFJldmlldw0KDQogIG8gSmF2YXNjcmlwdCBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlw dGlvbiAoam9zZSkNCiAgICBUb2tlbjogU2Vhbg0KDQo0LjEuMiBQcm9wb3NlZCBmb3IgQXBwcm92 YWwNCg0KICBOT05FDQoNCjQuMiBXRyBSZWNoYXJ0ZXJpbmcNCjQuMi4xIFVuZGVyIEV2YWx1YXRp b24gZm9yIElFVEYgUmV2aWV3DQoNCiAgbyBMYXllciAyIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3Jr cyAobDJ2cG4pDQogICAgVG9rZW46IFN0ZXdhcnQNCg0KICBvIFNUT1JhZ2UgTWFpbnRlbmFuY2Ug KHN0b3JtKQ0KICAgIFRva2VuOiBEYXZpZA0KDQoNCg== From jari.arkko@piuha.net Fri Aug 19 11:23:02 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55121F8B23; Fri, 19 Aug 2011 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.526 X-Spam-Level: X-Spam-Status: No, score=-101.526 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlfeOFMRbyXa; Fri, 19 Aug 2011 11:23:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8521F8B18; Fri, 19 Aug 2011 11:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7236A2CEFF; Fri, 19 Aug 2011 21:23:58 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIIXdhvCxsqO; Fri, 19 Aug 2011 21:23:58 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D9DE02CE12; Fri, 19 Aug 2011 21:23:57 +0300 (EEST) Message-ID: <4E4EAA3D.5060306@piuha.net> Date: Fri, 19 Aug 2011 21:23:57 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "int-chairs@ietf.org" , Behave Chairs , V6ops Chairs , core-chairs@tools.ietf.org, grow-chairs@tools.ietf.org, armd-chairs@tools.ietf.org, dns directorate , IAB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dns-dir] INT AD, 2012- X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 18:23:02 -0000 For your information, I have decided to NOT seek another term as INT AD. Its been a wonderful experience for me, and I'd love to continue, but after six years change is also good, for me, the IESG, and the area. And I need new challenges. I plan to do other things in the IETF, some technical work, more day job, etc. This means that we need a new person to take over after next March. Some of the best people to do that are on the To-line. Please consider whether you would like to volunteer, or if you know someone else who should volunteer. Please talk to the nomcom, and ask me or Ralph if you have any questions about the job itself. Jari From peter@denic.de Thu Aug 25 02:44:25 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A115321F8560 for ; Thu, 25 Aug 2011 02:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwIJEZD0gxIs for ; Thu, 25 Aug 2011 02:44:25 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id E106621F8562 for ; Thu, 25 Aug 2011 02:44:21 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QwWV8-000098-Gq; Thu, 25 Aug 2011 11:45:30 +0200 Received: from localhost by x27.adm.denic.de with local id 1QwWV8-0005K2-D7; Thu, 25 Aug 2011 11:45:30 +0200 Date: Thu, 25 Aug 2011 11:45:30 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20110825094530.GL25053@x27.adm.denic.de> Mail-Followup-To: IETF DNS Directorate , ondrej.sury@nic.cz, rbarnes@bbn.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: rbarnes@bbn.com, ondrej.sury@nic.cz Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 25, 2011 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 09:44:25 -0000 On Fri, Aug 19, 2011 at 09:49:23AM +0200, Romascanu, Dan (Dan) wrote: > Please find below the preliminary agenda of the 8/25 IESG telechat. Please send me your questions, comments and concerns related to the documents and WG charters on the agenda before 8/24 COB. > o draft-ietf-dane-use-cases-05 > Use Cases and Requirements for DNS-based Authentication of Named > Entities (DANE) (Informational) > Note: Ond?ej Surï¿?? (ondrej.sury@nic.cz) is the Document Shepherd. > Token: Stephen Farrell this is the only one on the list with relevance to DNS as far as i can see. The document is well written, but i have a concern regarding the repeated use of the term "domain holder" throughout the document. In the introduction it says With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain holder and not tampered with in transit. [...] where the first conclusion simply isn't true. All that DNSSEC provides is data origin authentication with the origin being the DNS zone. DNSSEC dos not help to identify the party applying or authorizing entries into that zone. Later on, section 3.3 correctly makes that distinction: By the same token, this use case puts the most power in the hands of DNS operators. Since the operator of the appropriate DNS zone has de facto control over the content and signing of the zone, he can create false DANE records that bind a malicious party's certificate to a domain. This risk is especially important to keep in mind in cases where the operator of a DNS zone is a different entity than the holder of the domain, as in DNS hosting/outsourcing arrangements, since in these cases the DNS operator might be able to make changes to a domain that are not authorized by the holder of the domain. However, it's not only a malicious operator that can interfere. Nowhere does it say that the operator has specific duties to verify or validate DANE information before entering data into the zone. Negligence or malice don't make a difference. The fact that the zone is DNSSEC signed does not change that since the only meaning of the RRSIGs is that the zone operator attests the data was present as signed. Also "domain holder" is usually understood as equivalent to a registrant, meaning someone who registered a 2nd (or 3rd, where applicable) domain name. It is not obvious how to apply this logic to nodes further down the tree. -Peter From dromasca@avaya.com Wed Aug 31 01:23:10 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C473821F8AF1; Wed, 31 Aug 2011 01:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW+zB+FNKy-f; Wed, 31 Aug 2011 01:23:10 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFEC21F8B09; Wed, 31 Aug 2011 01:23:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAHvvXU7GmAcF/2dsb2JhbABCmF2PbXeBOQcBAQEBAwEBAQ8eCi0HFwYBCA0EBAEBCwIEDAsBByYfBwEBBQQBBAESCAEZh1SZcwKcVIV1YASYUYtb X-IronPort-AV: E=Sophos;i="4.68,306,1312171200"; d="scan'208";a="204918666" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Aug 2011 04:24:31 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Aug 2011 04:20:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 10:24:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [new-work] WG Review: Javascript Object Signing and Encryption(jose) Thread-Index: AcxnMjrwaMVff4mKSfaUrnzkye64dwAhQiBQ From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: [new-work] WG Review: Javascript Object Signing and Encryption(jose) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:23:10 -0000 -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, August 30, 2011 7:30 PM To: new-work@ietf.org Subject: [new-work] WG Review: Javascript Object Signing and Encryption(jose) A new IETF working group has been proposed in the Security Area. The=20 IESG has not made any determination as yet. The following draft charter=20 was submitted, and is provided for informational purposes only. Please=20 send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,=20 September 6, 2011 =20 Javascript Object Signing and Encryption (jose) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Status: Proposed Working Group Last updated: 2011-08-18 Chairs TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: jose@ietf.org To Subscribe: Archive: Description of Working Group ---------------------------- Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used=20 for serializing and transmitting structured data over a network=20 connection. With the increased usage of JSON in protocols in the IETF=20 and elsewhere, there is now a desire to offer security services such as=20 encryption, digital signatures, and message authentication codes (MACs)=20 for data that is being carried in JSON format. Different proposals for providing such security services have already=20 been defined and implemented. This Working Group's task is to=20 standardize two security services, integrity protection (signature and=20 MAC) and encryption, in order to increase interoperability of security=20 features between protocols that use JSON. The Working Group will base=20 its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that=20 the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply JSON-structured=20 integrity protection to data, including (but not limited to) JSON data=20 structures. "Integrity protection" includes public-key digital=20 signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured=20 encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as=20 JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement=20 algorithms for the other three documents. The working group may decide to address one or more of these goals in a=20 single document, in which case the concrete milestones for=20 signing/encryption below will both be satisfied by the single document. Goals and Milestones -------------------- Jan 2012 Submit JSON object integrity document as a WG item. Jan 2012 Submit JSON object encryption document as a WG item. Jan 2012 Submit JSON key format document as a WG item. Jan 2012 Submit JSON algorithm document as a WG item. Jun 2012 Start Working Group Last Call on JSON object integrity=20 document. Jun 2012 Start Working Group Last Call on JSON object encryption=20 document. Jun 2012 Start Working Group Last Call on JSON key format document. Jun 2012 Start Working Group Last Call on JSON algorithm document. Jul 2012 Submit JSON object integrity document to IESG for=20 consideration as Standards Track document. Jul 2012 Submit JSON object encryption document to IESG for=20 consideration as Standards Track document. Jul 2012 Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 Submit JSON algorithm document to IESG for consideration as Standards Track document. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dromasca@avaya.com Wed Aug 31 01:23:55 2011 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95F921F8B2B; Wed, 31 Aug 2011 01:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sop+xYWDtKO; Wed, 31 Aug 2011 01:23:55 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id AA28421F8B1C; Wed, 31 Aug 2011 01:23:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAHvvXU6HCzI1/2dsb2JhbAA4Cphdj213gUABAQEBAwEBAQ8eCjQXBgEIDQQBAwEBCwIEDAsBByYfAwQBAQUEAQQBEggBEgeHVJlzApxUgzCCRWAEmFGLWw X-IronPort-AV: E=Sophos;i="4.68,306,1312171200"; d="scan'208";a="300823327" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Aug 2011 04:25:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Aug 2011 04:16:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 10:25:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks(l2vpn) Thread-Index: AcxnM125mid25wOTQ+emQJ3+knEbugAhBpAw From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [dns-dir] FW: [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks(l2vpn) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:23:56 -0000 -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, August 30, 2011 7:37 PM To: new-work@ietf.org Subject: [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks(l2vpn) A modified charter has been submitted for the Layer 2 Virtual Private=20 Networks (l2vpn) working group in the Routing Area of the IETF. The=20 IESG has not made any determination as yet. The modified charter is=20 provided below for informational purposes only. Please send your=20 comments to the IESG mailing list (iesg@ietf.org) by Tuesday, September=20 6, 2011. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Last updated: 2011-08-30 Current Status: Active Chairs: Nabil Bitar Giles Heron Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive:=20 http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements=20 driven by cloud computing services and data centers as they apply to=20 Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over IP or MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across a PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across a PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across a PSN. 4. IP-only L2VPN, an IP-only service over a PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but=20 also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree, a Layer-2 service defined by the MEF, which provides connectivity between one or more root nodes and one or more leaf nodes, with the restriction that leaf nodes may only communicate with root node(s) (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires.=20 Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN within the scope of the L2VPN Working Group. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multi-pathing between PEs interconnecting a Layer-2 service using an L2VPN across the PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/ active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RFC Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Oct 2011 Submit IP-only L2VPN solution documents to IESG Nov 2011 Submit OAM solutions for VPWS to IESG Nov 2011 Submit OAM solutions for VPLS to IESG Nov 2011 Submit signaling solution for multicast-optimized VPLS to IESG Nov 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2011 Submit MIB for VPLS to IESG Nov 2011 Submit MIB for VPWS to IESG Mar 2012 Submit scalability solutions for VPLS Data-Plane to IESG Mar 2012 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit E-Tree requirements/framework to IESG Jul 2012 Submit MIB for IP-only L2VPN to IESG Jul 2012 Submit OAM solutions for IP-only L2VPN to IESG Jul 2012 Submit Auto-Discovery solution for VPMS to IESG Jul 2012 Submit VPLS service convergence improvement solutions to IESG Jul 2012 Submit VPLS multi-homing solutions to IESG Jul 2012 Submit E-Tree solution to IESG Jul 2012 Submit E-VPN requirements/framework to IESG Nov 2012 Submit E-Tree OAM to IESG Dec 2012 Submit E-Tree MIB to IESG Nov 2012 Submit E-VPN solution to IESG Mar 2013 Submit E-VPN OAM to IESG Apr 2013 Submit E-VPN MIB to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work