From dromasca@avaya.com Fri Oct 2 01:36:21 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C714E3A68BB; Fri, 2 Oct 2009 01:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLulrQ3FbMOe; Fri, 2 Oct 2009 01:36:18 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 358223A67F2; Fri, 2 Oct 2009 01:36:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="175397168" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 02 Oct 2009 04:37:43 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Oct 2009 04:37:42 -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: Fri, 2 Oct 2009 10:37:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for October 8, 2009 Telechat thread-index: AcpC41mdtryjRaDpS8y5xQrmgXJWmwAVwpDw From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for October 8, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 08:36:21 -0000 Please find below the preliminary agenda of the IESG telechat on 10/8. Please send your comments, questions and concerns before 10/7 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2.1 WG Submissions 2.1.1 New Item o draft-ietf-ipsecme-ikev2-resumption-08.txt IKEv2 Session Resumption (Proposed Standard) - 1 of 7=20 Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Pasi Eronen o draft-ietf-mipshop-pfmipv6-09.txt Fast Handovers for Proxy Mobile IPv6 (Proposed Standard) - 2 of 7=20 Note: Vijay Devarapalli (vijay@wichorus.com) is the document shepherd. =20 Token: Jari Arkko o draft-ietf-pmol-sip-perf-metrics-04.txt SIP End-to-End Performance Metrics (Proposed Standard) - 3 of 7=20 Note: Vijay Gurbani is the PROTO-shepherd=20 Token: Dan Romascanu o draft-ietf-dime-diameter-cmd-iana-01.txt Updated IANA Considerations for Diameter Command Code Allocations (Proposed=20 Standard) - 4 of 7=20 Note: Victor Fajardo (vfajardo@research.telcordia.com) is the document =20 shepherd.=20 Token: Ron Bonica o draft-ietf-yam-rfc1652bis-pre-evaluation-00.txt Preliminary Evaluation of RFC 1652 for Advancement to Full Standard=20 (Standard) - 5 of 7=20 Note: This draft contains the list of changes planned by the YAM WG to move=20 RFC 1652 to Full Standard. There is no intention to publish this document=20 as an RFC, so IESG should vote on this document as if RFC 1652 is advancing=20 to Full Standard.. S Moonesamy has agreed to=20 serve as the document shepherd, but note that there is no shepherding write-up for this document.=20 Token: Alexey Melnikov o draft-ietf-mpls-tp-oam-requirements-03.txt Requirements for OAM in MPLS Transport Networks (Proposed Standard) - 6 of=20 7=20 Note: Loa Andersson (loa@pi.nu) is the document shepherd.. Note that this=20 document is a requirement document, for reasons that have. to do with referencibility by ITU-T we have opted to put it on the standards track.=20 The same decision applies to all MPLS-TP requirement. documents.=20 Token: Adrian Farrel o draft-ietf-mpls-tp-nm-req-05.txt MPLS TP Network Management Requirements (Proposed Standard) - 7 of 7 Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.. Note that this=20 document is a requirement document. For reasons that. have to do with how=20 the ITU-T can reference RFCs we have opted to put. it on the Standards =20 Track.=20 Token: Adrian Farrel 2.1.2 Returning Item o draft-ietf-tcpm-tcpsecure-12.txt Improving TCP's Robustness to Blind In-Window Attacks (Proposed Standard) -=20 1 of 2=20 Note: IESG: Please read the Document Shepherd Writeup, we need to discuss=20 the "Updates: 793" issue.=20 Token: Lars Eggert o draft-ietf-mboned-lightweight-igmpv3-mldv2-05.txt Lightweight IGMPv3 and MLDv2 Protocols (BCP) - 2 of 2=20 Token: Ron Bonica 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-simple-interdomain-scaling-analysis-08.txt Presence Interdomain Scaling Analysis for SIP/SIMPLE (Informational) - 1 of=20 10=20 Note: Ben Campbell is document shepherd=20 Token: Robert Sparks o draft-ietf-krb-wg-cross-problem-statement-04.txt Problem statement on the cross-realm operation of Kerberos (Informational)=20 - 2 of 10=20 Token: Tim Polk o draft-ietf-speermint-requirements-07.txt SPEERMINT Requirements for SIP-based Session Peering (Informational) - 3 of=20 10=20 Token: Cullen Jennings o draft-ietf-speermint-voip-consolidated-usecases-14.txt VoIP SIP Peering Use Cases (Informational) - 4 of 10=20 Token: Cullen Jennings o draft-ietf-roll-home-routing-reqs-08.txt Home Automation Routing Requirements in Low Power and Lossy Networks (Informational) - 5 of 10=20 Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd=20 Token: Adrian Farrel o draft-ietf-msec-tesla-for-alc-norm-08.txt Use of TESLA in the ALC and NORM Protocols (Experimental) - 6 of 10=20 Token: Tim Polk o draft-ietf-rtgwg-lf-conv-frmwk-06.txt A Framework for Loop-free Convergence (Informational) - 7 of 10=20 Token: Ross Callon o draft-ietf-rtgwg-ipfrr-framework-12.txt IP Fast Reroute Framework (Informational) - 8 of 10=20 Token: Ross Callon o draft-ietf-ipsecme-ikev2-ipv6-config-02.txt IPv6 Configuration in IKEv2 (Experimental) - 9 of 10=20 Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Tim Polk o draft-ietf-eai-downgraded-display-02.txt Displaying Downgraded Messages for Email Address Internationalization (Experimental) - 10 of 10=20 Note: Harald Alvestrand agreed to shepherd the document=20 Token: Alexey Melnikov 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-harkins-emu-eap-pwd-08.txt EAP Authentication Using Only A Password (Informational) - 1 of 2=20 Token: Russ Housley o draft-iana-ipv4-examples-02.txt IPv4 Address Blocks Reserved for Documentation (Informational) - 2 of 2=20 Token: Russ Housley 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-keromytis-keynote-x509-02.txt X.509 Key and Signature Encoding for the KeyNote Trust Management System=20 (Informational) - 1 of 1=20 Token: Tim Polk 3.3.2 Returning Item o draft-templin-ranger-07.txt Routing and Addressing in Next-Generation EnteRprises (RANGER)=20 (Informational) - 1 of 2=20 Token: Jari Arkko o draft-irtf-mobopts-mmcastv6-ps-08.txt Multicast Mobility in MIPv6: Problem Statement and Brief Survey=20 (Informational) - 2 of 2=20 Note: Rajeev Koodli (rajeev.koodli@gmail.com) is the document shepherd.=20 Token: Jari Arkko 3.3.3 For Action o draft-levy-sip-diversion-10.txt Diversion Indication in SIP (Historic) - 1 of 1=20 Token: Robert Sparks 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Multipath TCP (mptcp) - 1 of 1 Token: Magnus Westerlund 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 2 Token: Magnus Westerlund o Access Node Control Protocol (ancp) - 2 of 2 Token: Ralph Droms From ogud@ogud.com Fri Oct 2 04:59:06 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8733A6407 for ; Fri, 2 Oct 2009 04:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37n--vetKop4 for ; Fri, 2 Oct 2009 04:59:04 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id B1FE53A698F for ; Fri, 2 Oct 2009 04:58:45 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n92C06k7053267; Fri, 2 Oct 2009 08:00:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910021200.n92C06k7053267@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Oct 2009 07:53:44 -0400 To: "Romascanu, Dan (Dan)" From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: dns-dir@ietf.org Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for October 8, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 11:59:06 -0000 someone needs to look over these documents: speermint-requirements 00 13 01 15 02 11 speermint-voip-consolidated-usecases 00 12 06 28 07 28 08 32 08 32 08 32 09 35 10 34 Olafur At 04:37 02/10/2009, you wrote: > Please find below the preliminary agenda of the IESG telechat on 10/8. >Please send your comments, questions and concerns before 10/7 COB. > >Thanks and Regards, > >Dan > > >-----Original Message----- >From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of >IESG Secretary > > >2.1 WG Submissions >2.1.1 New Item > o draft-ietf-ipsecme-ikev2-resumption-08.txt > IKEv2 Session Resumption (Proposed Standard) - 1 of 7 > Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. > > Token: Pasi Eronen > o draft-ietf-mipshop-pfmipv6-09.txt > Fast Handovers for Proxy Mobile IPv6 (Proposed Standard) - 2 of 7 > Note: Vijay Devarapalli (vijay@wichorus.com) is the document >shepherd. > > Token: Jari Arkko > o draft-ietf-pmol-sip-perf-metrics-04.txt > SIP End-to-End Performance Metrics (Proposed Standard) - 3 of 7 > Note: Vijay Gurbani is the PROTO-shepherd > Token: Dan Romascanu > o draft-ietf-dime-diameter-cmd-iana-01.txt > Updated IANA Considerations for Diameter Command Code Allocations >(Proposed > Standard) - 4 of 7 > Note: Victor Fajardo (vfajardo@research.telcordia.com) is the >document > > shepherd. > Token: Ron Bonica > o draft-ietf-yam-rfc1652bis-pre-evaluation-00.txt > Preliminary Evaluation of RFC 1652 for Advancement to Full Standard > (Standard) - 5 of 7 > Note: This draft contains the list of changes planned by the YAM WG >to >move > RFC 1652 to Full Standard. There is no intention to publish this >document > as an RFC, so IESG should vote on this document as if RFC 1652 is >advancing > to Full Standard.. S Moonesamy has agreed >to > serve as the document shepherd, but note that there is no >shepherding > > write-up for this document. > Token: Alexey Melnikov > o draft-ietf-mpls-tp-oam-requirements-03.txt > Requirements for OAM in MPLS Transport Networks (Proposed Standard) >- >6 of > 7 > Note: Loa Andersson (loa@pi.nu) is the document shepherd.. Note that >this > document is a requirement document, for reasons that have. to do >with > > referencibility by ITU-T we have opted to put it on the standards >track. > The same decision applies to all MPLS-TP requirement. documents. > Token: Adrian Farrel > o draft-ietf-mpls-tp-nm-req-05.txt > MPLS TP Network Management Requirements (Proposed Standard) - 7 of 7 > > Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.. Note that >this > document is a requirement document. For reasons that. have to do >with >how > the ITU-T can reference RFCs we have opted to put. it on the >Standards > > Track. > Token: Adrian Farrel > >2.1.2 Returning Item > o draft-ietf-tcpm-tcpsecure-12.txt > Improving TCP's Robustness to Blind In-Window Attacks (Proposed >Standard) - > 1 of 2 > Note: IESG: Please read the Document Shepherd Writeup, we need to >discuss > the "Updates: 793" issue. > Token: Lars Eggert > o draft-ietf-mboned-lightweight-igmpv3-mldv2-05.txt > Lightweight IGMPv3 and MLDv2 Protocols (BCP) - 2 of 2 > Token: Ron Bonica > > >2.2 Individual Submissions >2.2.1 New Item >NONE >2.2.2 Returning Item >NONE > >3. Document Actions > >3.1 WG Submissions > Reviews should focus on these questions: "Is this document a >reasonable > contribution to the area of Internet engineering which it >covers? If > not, what changes would make it so?" > >3.1.1 New Item > o draft-ietf-simple-interdomain-scaling-analysis-08.txt > Presence Interdomain Scaling Analysis for SIP/SIMPLE (Informational) >- >1 of > 10 > Note: Ben Campbell is document shepherd > Token: Robert Sparks > o draft-ietf-krb-wg-cross-problem-statement-04.txt > Problem statement on the cross-realm operation of Kerberos >(Informational) > - 2 of 10 > Token: Tim Polk > o draft-ietf-speermint-requirements-07.txt > SPEERMINT Requirements for SIP-based Session Peering (Informational) >- >3 of > 10 > Token: Cullen Jennings > o draft-ietf-speermint-voip-consolidated-usecases-14.txt > VoIP SIP Peering Use Cases (Informational) - 4 of 10 > Token: Cullen Jennings > o draft-ietf-roll-home-routing-reqs-08.txt > Home Automation Routing Requirements in Low Power and Lossy Networks > > (Informational) - 5 of 10 > Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd > Token: Adrian Farrel > o draft-ietf-msec-tesla-for-alc-norm-08.txt > Use of TESLA in the ALC and NORM Protocols (Experimental) - 6 of 10 > Token: Tim Polk > o draft-ietf-rtgwg-lf-conv-frmwk-06.txt > A Framework for Loop-free Convergence (Informational) - 7 of 10 > Token: Ross Callon > o draft-ietf-rtgwg-ipfrr-framework-12.txt > IP Fast Reroute Framework (Informational) - 8 of 10 > Token: Ross Callon > o draft-ietf-ipsecme-ikev2-ipv6-config-02.txt > IPv6 Configuration in IKEv2 (Experimental) - 9 of 10 > Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. > > Token: Tim Polk > o draft-ietf-eai-downgraded-display-02.txt > Displaying Downgraded Messages for Email Address >Internationalization > > (Experimental) - 10 of 10 > Note: Harald Alvestrand agreed to shepherd the document > Token: Alexey Melnikov > >3.1.2 Returning Item >NONE > >3.2 Individual Submissions Via AD > Reviews should focus on these questions: "Is this document a >reasonable > contribution to the area of Internet engineering which it >covers? If > not, what changes would make it so?" > >3.2.1 New Item > o draft-harkins-emu-eap-pwd-08.txt > EAP Authentication Using Only A Password (Informational) - 1 of 2 > Token: Russ Housley > o draft-iana-ipv4-examples-02.txt > IPv4 Address Blocks Reserved for Documentation (Informational) - 2 >of >2 > Token: Russ Housley > >3.2.2 Returning Item >NONE >3.3 Independent Submissions Via RFC Editor > The IESG will use RFC 3932 responses: 1) The IESG has not > found any conflict between this document and IETF work; 2) The > IESG thinks that this work is related to IETF work done in WG > , but this does not prevent publishing; 3) The IESG thinks > that publication is harmful to work in WG and recommends > not publishing at this time; 4) The IESG thinks that this > document violates the IETF procedures for and should > therefore not be published without IETF review and IESG > approval; 5) The IESG thinks that this document extends an > IETF protocol in a way that requires IETF review and should > therefore not be published without IETF review and IESG >approval. > > The document shepherd must propose one of these responses in > the Data Tracker note and supply complete text in the IESG > Note portion of the write-up. The Area Director ballot positions > indicate consensus with the response proposed by the > document shepherd. > > Other matters may be recorded in comments, and the comments will > be passed on to the RFC Editor as community review of the >document. > > >3.3.1 New Item > o draft-keromytis-keynote-x509-02.txt > X.509 Key and Signature Encoding for the KeyNote Trust Management >System > (Informational) - 1 of 1 > Token: Tim Polk > >3.3.2 Returning Item > o draft-templin-ranger-07.txt > Routing and Addressing in Next-Generation EnteRprises (RANGER) > (Informational) - 1 of 2 > Token: Jari Arkko > o draft-irtf-mobopts-mmcastv6-ps-08.txt > Multicast Mobility in MIPv6: Problem Statement and Brief Survey > (Informational) - 2 of 2 > Note: Rajeev Koodli (rajeev.koodli@gmail.com) is the document >shepherd. > Token: Jari Arkko > >3.3.3 For Action > o draft-levy-sip-diversion-10.txt > Diversion Indication in SIP (Historic) - 1 of 1 > Token: Robert Sparks > >4. Working Group Actions >4.1 WG Creation >4.1.1 Proposed for IETF Review > NONE >4.1.2 Proposed for Approval > o Multipath TCP (mptcp) - 1 of 1 > Token: Magnus Westerlund >4.2 WG Rechartering >4.2.1 Under evaluation for IETF Review > NONE >4.2.2 Proposed for Approval > o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 2 > Token: Magnus Westerlund > o Access Node Control Protocol (ancp) - 2 of 2 > Token: Ralph Droms > > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir From ogud@ogud.com Sat Oct 3 11:28:33 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573AF3A698C for ; Sat, 3 Oct 2009 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tUXAoox25ju for ; Sat, 3 Oct 2009 11:28:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3C8A03A6914 for ; Sat, 3 Oct 2009 11:28:31 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n93IU19P003167 for ; Sat, 3 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sat, 3 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091003_183001_098114.ogud@ogud.com> Subject: [dns-dir] DNS Early Warn: draft-allbery-afs-srv-records-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 18:28:33 -0000 Count: 59 Network Working Group R. Allbery Internet-Draft Stanford University Intended status: Informational October 3, 2009 Expires: April 6, 2010 DNS SRV Resource Records for AFS draft-allbery-afs-srv-records-00 Abstract This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server weighting system used by AFS. It deprecates use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. Internet Draft Comments Comments are solicited. Please include the AFS Standardization mailing list at afs3-standardization@openafs.org as a recipient of any comments. From ogud@ogud.com Mon Oct 5 05:57:47 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87613A690C for ; Mon, 5 Oct 2009 05:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOUr4Mbv3zzf for ; Mon, 5 Oct 2009 05:57:47 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E3A8B3A6886 for ; Mon, 5 Oct 2009 05:57:46 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n95CxJmZ002958 for ; Mon, 5 Oct 2009 08:59:19 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910051259.n95CxJmZ002958@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Oct 2009 08:58:58 -0400 To: "Dns Directorate" From: Olafur Gudmundsson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dns-dir] Call today ? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 12:57:47 -0000 My calendar has an entry but no agenda has been circulated. Unless someone speaks up, I will assume the answer is no. Olafur From peter@denic.de Mon Oct 5 06:15:00 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129CB3A69BE for ; Mon, 5 Oct 2009 06:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.278 X-Spam-Level: X-Spam-Status: No, score=-5.278 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31zLFyB1wtPF for ; Mon, 5 Oct 2009 06:14:59 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 4B7BE3A686A for ; Mon, 5 Oct 2009 06:14:58 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MunQW-0000j9-6D; Mon, 05 Oct 2009 15:16:32 +0200 Received: from localhost by x27.adm.denic.de with local id 1MunQW-0005bd-2f; Mon, 05 Oct 2009 15:16:32 +0200 Date: Mon, 5 Oct 2009 15:16:32 +0200 From: Peter Koch To: Olafur Gudmundsson Message-ID: <20091005131632.GB21280@x27.adm.denic.de> References: <200910051259.n95CxJmZ002958@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910051259.n95CxJmZ002958@stora.ogud.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: Dns Directorate Subject: Re: [dns-dir] Call today ? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 13:15:00 -0000 On Mon, Oct 05, 2009 at 08:58:58AM -0400, Olafur Gudmundsson wrote: > > My calendar has an entry but no agenda has been circulated. > Unless someone speaks up, I will assume the answer is no. no items were raised and some of us are at the RIPE meeting in Lisbon, which provides for some collision. Can we postpone until Monday next week, taking this also as a solicitation for agenda items? Regards, Peter From narten@us.ibm.com Mon Oct 5 06:33:34 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED38A28C1C1 for ; Mon, 5 Oct 2009 06:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCuM2EiMyxSv for ; Mon, 5 Oct 2009 06:33:34 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 2BCF728C14E for ; Mon, 5 Oct 2009 06:33:34 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n95DS1Xd029415 for ; Mon, 5 Oct 2009 09:28:01 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n95DZ2X5222682 for ; Mon, 5 Oct 2009 09:35:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n95DVeZp031059 for ; Mon, 5 Oct 2009 09:31:40 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-67.mts.ibm.com [9.65.234.67]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n95DVdcl030882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Oct 2009 09:31:40 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n95DYxB3021339 for ; Mon, 5 Oct 2009 09:35:00 -0400 Message-Id: <200910051335.n95DYxB3021339@cichlid.raleigh.ibm.com> To: dns-dir@ietf.org Date: Mon, 05 Oct 2009 09:34:59 -0400 From: Thomas Narten Subject: [dns-dir] SRV registry X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 13:33:35 -0000 There are two drafts now that are looking at fixing up the SRV port registry: draft-ietf-tsvwg-iana-ports-02 draft-gudmundsson-dns-srv-iana-registry-03.txt I haven't followed discussion on the first one closely (I had been waiting for the revised version to appear, which it has now), but it is trying to be a bit grander and unify a bunch of things (something I'm not convinced makes sense). It also has some strong voices pushing it. Personally, I think it may make more sense to keep the SRV issues separate in their own document, where we can perhaps clarify some other aspects of SRV. But the authors of the tsvwg do not appear to agree with that, at least not yet. Now seems like the time to look at these two documents and figure out what should be done with the SRV registry. Thomas From ogud@ogud.com Wed Oct 7 11:28:23 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4223A69E1 for ; Wed, 7 Oct 2009 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiczURloKhCL for ; Wed, 7 Oct 2009 11:28:23 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E09B63A6976 for ; Wed, 7 Oct 2009 11:28:22 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n97IU0Wb043426 for ; Wed, 7 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Wed, 7 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091007_183001_035508.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsext-dns-tcp-requirements-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:28:23 -0000 Count: 42 DNSEXT R. Bellis Internet-Draft Nominet UK Updates: 1123, 1035 October 6, 2009 (if approved) Intended status: Standards Track Expires: April 9, 2010 DNS Transport over TCP draft-ietf-dnsext-dns-tcp-requirements-00 Abstract This document updates the requirements for the support of the TCP protocol for the transport of DNS traffic. From narten@us.ibm.com Wed Oct 7 14:54:15 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8518628C1E9 for ; Wed, 7 Oct 2009 14:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.245 X-Spam-Level: X-Spam-Status: No, score=-7.245 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGCX7D46uq8V for ; Wed, 7 Oct 2009 14:54:14 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 5584D28C200 for ; Wed, 7 Oct 2009 14:54:01 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n97LrBM1024631 for ; Wed, 7 Oct 2009 15:53:11 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n97LtVtd258848 for ; Wed, 7 Oct 2009 15:55:31 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n97LtTgP020364 for ; Wed, 7 Oct 2009 15:55:30 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-225-194.mts.ibm.com [9.65.225.194]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n97LtPQx020172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 15:55:28 -0600 Received: from cichlid (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n97LtOO4003052; Wed, 7 Oct 2009 17:55:24 -0400 Message-Id: <200910072155.n97LtOO4003052@cichlid.raleigh.ibm.com> To: Lars-Johan Liman In-reply-to: <22ab1hrpy0.fsf@zaptop.autonomica.net> References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> <20090826132745.GC6533@shinkuro.com> <05B243F724B2284986522B6ACD0504D7C083C6A7F3@EXVPMBX100-1.exc.icann.org> <22y6p3pugw.fsf@zaptop.autonomica.net> <200908282150.n7SLojkr017801@stora.ogud.com> <22ab1hrpy0.fsf@zaptop.autonomica.net> Comments: In-reply-to Lars-Johan Liman message dated "Sun, 30 Aug 2009 22:45:27 +0200." Date: Wed, 07 Oct 2009 17:55:24 -0400 From: Thomas Narten Cc: Tina Dam , dns directorate Subject: Re: [dns-dir] draft-liman-tld-names-00 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:54:15 -0000 OK, back to this one... Given where we are (ICANN meeting in 3 weeks), given the risks of lifting stones covering large ratholes (spare me!), I am now convinced that we should have a document that *very* narrowly just makes it clear that IDN TLDs are OK. Looking at the draft: > Abstract > > RFC 1123 is ambiguous regarding the specification for top level > domain (TLD) labels used in the domain name system. This document > clarifies the specification, and aligns it with current praxis, > including the use of Internationalized Domain Name (IDN) Labels in > TLD names. How about The precise syntax allowed in top-level domain name labels has been the subject to some debate. RFC 1123, for example, states that top-level domain names must be "alphabetic". This document updates the definition of allowable top-level domain names in order to support internationalized domain names (IDNs), as encoded by the IDNA protocols. This document focusses narrowly on the issue of IDNs and does not make any other changes or clarifications to existing domain name syntax rules. > > 1. Introduction and Background > > RFC 1123 [RFC1123] is ambiguous regarding the specification for top > level domain (TLD) labels used in the domain name system. There are > different interpretations which leads to problems when deciding on > new TLD names. One important aspect of this is the wish to use > internationalized domain name (IDN, RFC 3490 et. al. [RFC3490]) > labels in top level domains to facilitate use of local scripts. > > This document strives to make a new and clear definition of which > character sequences are allowed in TLD labels. > > This document is a proposal and a work in progress. How about: The precise syntax allowed in top-level domain name labels has been the subject to some debate. RFC 1123, for example, states that top-level domain names must be "alphabetic", which is interpreted as excluding the hyphen (or dash) character. This document updates the definition of allowable top-level domain names to support internationalized domain names, as encoded by the IDNA protocols [RFCXXX]. In particular, this document clarifies that ascii TLDs beginning with "xn--", as encoded by IDNA, are permissible as DNS TLD names. This document focusses narrowly on the issue of allowable ascii lables encoded by the IDNA protocols and does not (and is not intended to) make any other changes or clarifications to existing domain name syntax rules. > 1.1. Terminology > > The terminology used in this document is as defined in RFC 0952 > [RFC0952] and RFC 1035 [RFC1035]. > > 1.2. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > 2. Technical specification for Top Level Domain Labels Better: 2. Background > RFC 952 [RFC0952] gives the specification for names that may be used > for host names on the Internet. It is updated by RFC 1123 [RFC1123], > which relaxes the specification somewhat. It is somewhat unclear > wheter the relaxation is per label or per entire host name. How about: RFC 952 states (among other things) that a host 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. RFC 1123 [RFC1123] reaffirms this definition, making two additional changes 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. and However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. This last sentence implies that IDNs as encoded by IDNA (which begin with a "xn--" prefix) are not allowed as TLDs. This document explicitly updates the above rules to allow TLD ascii labels that result from the encoding of IDNs via IDNA. Do we need more than the above? Should we just say "xn--" is allowed? I'm wary of trying to define an ABNF in this document... People may start arguing.... > 3. Other Limitations on Top Level Domain Labels > > It is carefully noted that the above specification is not the only > limiting factor on TLD labels. There may be other entities than the > IETF that have influence over TLD names, and which may decide to > restrict the names further. The above technical specification is > just one limiting factor. Better: It should be noted that there are many issues that must be considered in making any changes to current restrictions on DNS labels, especially at the top level. DNS software is widely deployed, and some of that software contains embedded assumptions that may not hold if DNS names are used at the top level that differ from the older rules. For example, when TLDs longer than 3 characters became available (e.g., .info, .museum, etc.), some deployed systems did not process such DNS names properly. This document does not take the position that no problems will result when IDN TLDs are created, but does recognize that relaxing the syntax of allowed TLDs is necessary in order to allow deployment of IDNs to happen. > > 4. IANA Considerations > > This memo changes the specifications for TLD names registered by the > IANA, and the IANA is requested to change its registration process to > use the above specification. > 5. Security Considerations > > This document does not introduce any new security issues. Not necessarily true. Maybe someone will truncat TLDs during lookups, names will resolve incorrectly, and bad things can happen... Yeah, not a huge risk, perhaps, but we should say something. > It may introduce stability issues where names registered under this > new specification may interoperate badly with old software written to > enforce a strict interpretation of the old specification. However, > it is belived that such software is scarce on the Internet, and since > TLD names that do not adhere to a strict interpretation of the old > specification are already used (including IDNs) without apparent > problems, it is believed that this change of the specicification will > not create major stability problems on the Internet. Does the above make sense? Do others think this is reasonable? In any case, we need to get this one moving... Thomas From olaf@NLnetLabs.nl Thu Oct 8 02:34:27 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCAB3A6A58 for ; Thu, 8 Oct 2009 02:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1JunrUpSRWa for ; Thu, 8 Oct 2009 02:34:26 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id ED8DA3A6A56 for ; Thu, 8 Oct 2009 02:34:25 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:226:bbff:fe0e:7cc7] ([IPv6:2001:67c:64:42:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n989ZI24029908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Oct 2009 11:35:21 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) From: Olaf Kolkman Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-45--338071185; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 8 Oct 2009 10:35:19 +0100 References: <911D037AD61A14853F13047F@PST.JCK.COM> To: dns directorate , Tina Dam , Lars-Johan Liman , Thomas Narten Message-Id: <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 08 Oct 2009 11:35:22 +0200 (CEST) Cc: John Klensin Subject: [dns-dir] Fwd: TLD Names and RFC 1123 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 09:34:27 -0000 --Apple-Mail-45--338071185 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes I believe the discussion needs to move away from the directorate to a more public venue. At the risk of forwarding a message without explicit consent: Here is a parallel comment, that had hit the IAB list but I'm not sure it ended elsewhere. (Since it is purely technical I am comfortable forwarding) --Olaf Begin forwarded message: > From: John C Klensin > Date: September 9, 2009 11:26:59 PM GMT+01:00 > To: Olaf Kolkman > Cc: IAB IAB > Subject: Re: TLD Names and RFC 1123 > > > > --On Wednesday, September 09, 2009 18:47 +0200 Olaf Kolkman > wrote: > >> >> John, >> >> http://tools.ietf.org/html/draft-liman-tld-names-00 >> >> >> I am not quite sure what you mean by "1123" problem but if you >> mean disambiguating 1123, then this document is about that. > > Ok. I've looked through it and have two problems, one minor > (because, in principle, it could still be overridden) and one > major: > > Minor: There is really nothing ambiguous about the text in 1123. > The relaxation for leading digits can't possibly apply to TLDs > because the text about TLDs says "... the highest-level > component label will be alphabetic" -- no digits, no hyphens: > alphabetic. I note that, if one ignores the "IDN testbed", > nothing that ICANN has done so far violates that rule. The > current practice is still "alphabetic". > > Major: Given that changing the rule from "alphabetic" is one of > those "changing engines in flight" situations, good and > conservative design argues that we should make the minimal > change need to accommodate a real and demonstrated need. I note > that "real and demonstrated need" is considerably different from > "maybe someone would like to do this". > > That minimal change for IDNs is to allow IDNs in what the > IDNA2008 drafts call "A-label form", i.e., an > ASCII-compatible-encoding, using reversible Punycode conversion > from valid IDNs labels, with the "xn--" prefix, but requiring > that the native-character ("Unicode") form consist of letters > only. No compelling need has been shown for permitting digits > or hyphens (or other characters), in all-ASCII (non-IDN) labels, > nor for permitting those characters in the Unicode form of IDNs. > > This is not just my usual paranoia about making changes broader > than we fully understand. There is actually a case, involving > "bidirectional" Unicode strings (more or less those containing > characters from scripts written right to left), in which leading > or trailing digits can result in label migration such that the > order in which labels may appear in display format becomes > different from the order in which they are transmitted "on the > wire" or appear in native-DNS format. The problem can occur in > lower levels of the DNS as well, but, if one permits the "bad" > cases in the root, it is all over -- no amount of registry (zone > administration) discipline, even if one could count on it, would > be sufficient to prevent the label migration problem from > occurring. For those interested in a more detailed explanation > of that problem, see draft-ietf-idnabis-bidi. > > To the extent to which we care more about identifier integrity > than about the "domain names market", we need to hold the line > and support an absolutely minimal change. > > Expressed in ABNF, that minimal change would be to make the > syntax: > > tldlabel = traditional-tld-label / idn-label > traditional-tld-label = 1*63(ALPHA) > idn-label = Restricted-A-label > ; Restricted-A-label is an A-label as defined in > draft-ietf-idna-defs > ; converted from (and convertible to) a U-label that is > consistent > ; with the definition in draft-ietf-idna-defs _and_ that is > further restricted > ; to contain only Unicode characters of General Category "L". > > Note that "L" contains several subcategories. The list is > > gc ; L ; Letter # Ll | Lm | Lo | Lt | Lu > gc ; LC ; Cased_Letter # Ll | Lt | Lu > gc ; Ll ; Lowercase_Letter > gc ; Lm ; Modifier_Letter > gc ; Lo ; Other_Letter > gc ; Lt ; Titlecase_Letter > gc ; Lu ; Uppercase_Letter > > although the IDNA restriction eliminates the last two and > several of characters in the others. > > I also note, based on Dave T's comments during the retreat and > subsequently, that permitting IDN TLDs doesn't make the job of > keeping APIs that support native-UTF-8 domain names any easier. > We are far enough down this path that it may be impossible to > reverse course on that matter, but it is a major step and should > not be taken lightly, IMO. > > john > > ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-45--338071185 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDA4MDkzNTE5WjAj BgkqhkiG9w0BCQQxFgQUdE9VD7Lj8B8qvCN85jJIlutw97wwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBACzU4t6cmDrvvzWg6Z3Wz4YO9ZrnpXuGAcDk+vF9aDYKjo2+f3xAavRek9i9HUuh iIoHszASeX8p6ITRuoDk40djdjZIshlv+aKMiwKOqp4y2lufn6azThecTfIWn+xwafXoD92+jXGw ueQZDxUsjdbDroHlacuQxoXN5ATtEef0iPPqWWrgjYxyqGIBMvvQjQyouxmhuOJUJyGgpKe6J3MJ 91GCNmqDB5yB3i5XJ7e/XZTAxhTNhGoRNLBcMMBqK/Cg6AWG7516QpmibEjuMCZESG8do3JLruA0 D0I66Szl2seFFlDzy4aZLDLS+9sW0pzlu8i7KFmYMD95ood6PMMAAAAAAAA= --Apple-Mail-45--338071185-- From narten@us.ibm.com Thu Oct 8 05:46:08 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9459428C187 for ; Thu, 8 Oct 2009 05:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.313 X-Spam-Level: X-Spam-Status: No, score=-7.313 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag-MQsqSJsff for ; Thu, 8 Oct 2009 05:46:07 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 5905628C16E for ; Thu, 8 Oct 2009 05:46:07 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n98Cjex8016260 for ; Thu, 8 Oct 2009 06:45:40 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n98Cled1231466 for ; Thu, 8 Oct 2009 06:47:40 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n98CldtH018350 for ; Thu, 8 Oct 2009 06:47:39 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-232-121.mts.ibm.com [9.65.232.121]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n98Clbf6018247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2009 06:47:39 -0600 Received: from cichlid (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n98ClaFH022067; Thu, 8 Oct 2009 08:47:36 -0400 Message-Id: <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> To: Olaf Kolkman In-reply-to: <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> Comments: In-reply-to Olaf Kolkman message dated "Thu, 08 Oct 2009 10:35:19 +0100." Date: Thu, 08 Oct 2009 08:47:36 -0400 From: Thomas Narten Cc: John Klensin , Tina Dam , dns directorate Subject: Re: [dns-dir] Fwd: TLD Names and RFC 1123 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 12:46:08 -0000 > I believe the discussion needs to move away from the directorate to a > more public venue. No disagreement in principle, but I (generally) think one is better off with a revised document that addresses known issues before going for a round of public comment, and there has been already some comment on the prvious version. YMMV. > At the risk of forwarding a message without explicit consent: Here is > a parallel comment, that had hit the IAB list but I'm not sure it > ended elsewhere. (Since it is purely technical I am comfortable > forwarding) > > Ok. I've looked through it and have two problems, one minor > > (because, in principle, it could still be overridden) and one > > major: > > > > Minor: There is really nothing ambiguous about the text in 1123. Right. My suggested edits move away from that language for that reason. > > The relaxation for leading digits can't possibly apply to TLDs > > because the text about TLDs says "... the highest-level > > component label will be alphabetic" -- no digits, no hyphens: > > alphabetic. I note that, if one ignores the "IDN testbed", > > nothing that ICANN has done so far violates that rule. The > > current practice is still "alphabetic". > > > > Major: Given that changing the rule from "alphabetic" is one of > > those "changing engines in flight" situations, good and > > conservative design argues that we should make the minimal > > change need to accommodate a real and demonstrated need. I note > > that "real and demonstrated need" is considerably different from > > "maybe someone would like to do this". > > > > That minimal change for IDNs is to allow IDNs in what the > > IDNA2008 drafts call "A-label form", i.e., an > > ASCII-compatible-encoding, using reversible Punycode conversion > > from valid IDNs labels, with the "xn--" prefix, but requiring > > that the native-character ("Unicode") form consist of letters > > only. No compelling need has been shown for permitting digits > > or hyphens (or other characters), in all-ASCII (non-IDN) labels, > > nor for permitting those characters in the Unicode form of IDNs. OK. But I don't understand right off why we need to bring the Unicode form of an IDN into this. Isn't it sufficient to just say only A-Labels are allowed? > > This is not just my usual paranoia about making changes broader > > than we fully understand. There is actually a case, involving > > "bidirectional" Unicode strings (more or less those containing > > characters from scripts written right to left), in which leading > > or trailing digits can result in label migration such that the > > order in which labels may appear in display format becomes > > different from the order in which they are transmitted "on the > > wire" or appear in native-DNS format. The problem can occur in > > lower levels of the DNS as well, but, if one permits the "bad" > > cases in the root, it is all over -- no amount of registry (zone > > administration) discipline, even if one could count on it, would > > be sufficient to prevent the label migration problem from > > occurring. For those interested in a more detailed explanation > > of that problem, see draft-ietf-idnabis-bidi. This is about leading digits, which I don't think we want to propose changing in this document. And is about U-Labels, not A-Labels, Right? > > To the extent to which we care more about identifier integrity > > than about the "domain names market", we need to hold the line > > and support an absolutely minimal change. > > > > Expressed in ABNF, that minimal change would be to make the > > syntax: > > > > tldlabel = traditional-tld-label / idn-label > > traditional-tld-label = 1*63(ALPHA) > > idn-label = Restricted-A-label > > ; Restricted-A-label is an A-label as defined in > > draft-ietf-idna-defs > > ; converted from (and convertible to) a U-label that is > > consistent > > ; with the definition in draft-ietf-idna-defs _and_ that is > > further restricted > > ; to contain only Unicode characters of General Category "L". > > > > Note that "L" contains several subcategories. The list is > > > > gc ; L ; Letter # Ll | Lm | Lo | Lt | Lu > > gc ; LC ; Cased_Letter # Ll | Lt | Lu > > gc ; Ll ; Lowercase_Letter > > gc ; Lm ; Modifier_Letter > > gc ; Lo ; Other_Letter > > gc ; Lt ; Titlecase_Letter > > gc ; Lu ; Uppercase_Letter > > > > although the IDNA restriction eliminates the last two and > > several of characters in the others. wfm. > > > > I also note, based on Dave T's comments during the retreat and > > subsequently, that permitting IDN TLDs doesn't make the job of > > keeping APIs that support native-UTF-8 domain names any easier. > > We are far enough down this path that it may be impossible to > > reverse course on that matter, but it is a major step and should > > not be taken lightly, IMO. > > > > john > > > > Thomas From liman@autonomica.se Thu Oct 8 10:34:32 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27BD13A683A for ; Thu, 8 Oct 2009 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjLBHh0YBwgz for ; Thu, 8 Oct 2009 10:34:31 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 3EA293A6805 for ; Thu, 8 Oct 2009 10:34:31 -0700 (PDT) Received: from home.liman.net (2-1-3-18a.spa.sth.bostream.se [82.182.146.229]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n98HZmIo005145; Thu, 8 Oct 2009 19:35:48 +0200 (MEST) Received: from zaptop.autonomica.net ([193.0.26.95]) by home.liman.net (8.14.3/8.13.8) with ESMTP id n98HZjpA018172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Oct 2009 19:35:47 +0200 (MEST) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n98HZhBE033809; Thu, 8 Oct 2009 18:35:43 +0100 (WEST) To: Thomas Narten References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> <20090826132745.GC6533@shinkuro.com> <05B243F724B2284986522B6ACD0504D7C083C6A7F3@EXVPMBX100-1.exc.icann.org> <22y6p3pugw.fsf@zaptop.autonomica.net> <200908282150.n7SLojkr017801@stora.ogud.com> <22ab1hrpy0.fsf@zaptop.autonomica.net> <200910072155.n97LtOO4003052@cichlid.raleigh.ibm.com> From: Lars-Johan Liman Date: Thu, 08 Oct 2009 18:35:43 +0100 In-Reply-To: <200910072155.n97LtOO4003052@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Wed\, 07 Oct 2009 17\:55\:24 -0400") Message-ID: <223a5t6b68.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Tina Dam , dns directorate Subject: Re: [dns-dir] draft-liman-tld-names-00 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:34:32 -0000 narten@us.ibm.com: > OK, back to this one... I'm at the RIPE meeting. I'll try to take a look at this thread ASAP, but it may be a few hours. Also patchy connectivity. :-( Cheers, /Liman From ogud@ogud.com Thu Oct 8 11:28:21 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55873A6ABB for ; Thu, 8 Oct 2009 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCYv3V3jmogi for ; Thu, 8 Oct 2009 11:28:20 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id AEA583A6819 for ; Thu, 8 Oct 2009 11:28:20 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n98IU0mE052962 for ; Thu, 8 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 8 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091008_183001_041933.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-otis-dkim-tpa-label-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 18:28:21 -0000 Count: 12 DKIM Working Group D. Otis Internet-Draft Trend Micro Intended status: Standards Track October 7, 2009 Expires: April 10, 2010 DKIM Third-Party Authorization Label draft-otis-dkim-tpa-label-00 Abstract TPA-label is a DNS-based prefix mechanism for DKIM policy related records as a means to authorize Third-Party domains, such as mailing- lists. This mechanism allows first-party domains to autonomously authorize a range of third-party domains using scalable, individual DNS transactions. This authorization extends the scope of DKIM policy assertions as a means to supplant more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate coordination between two or more domains to synchronously set up selector/key DNS records, DNS zone delegations, or the regular exchange of public/private keys. Checking DKIM policies may occur when a From header email-address is not within the domain of a valid DKIM signature. When a Third-Party signature is found, TPA-Labels offer an efficient means for email address domains to authorize specific third-party signing domains. From ogud@ogud.com Tue Oct 13 11:30:05 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08753A657C for ; Tue, 13 Oct 2009 11:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YUON8d5wvgh for ; Tue, 13 Oct 2009 11:30:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C92403A67E9 for ; Tue, 13 Oct 2009 11:30:01 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9DIU07e096692 for ; Tue, 13 Oct 2009 14:30:02 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 13 Oct 2009 14:30:02 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091013_183002_085479.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-hoeneisen-e164-to-metadata-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:30:05 -0000 Count: 13 Network Working Group B. Hoeneisen Internet-Draft Swisscom Intended status: Standards Track Oct 12, 2009 Expires: April 15, 2010 E.164 to Metadata (E2M) Dynamic Delegation Discovery System (DDDS) Application draft-hoeneisen-e164-to-metadata-00 Abstract This document proposes a new Dynamic Delegation Discovery System (DDDS) Application to map E.164 numbers to metadata. It discusses the use of the Domain Name System (DNS) for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. From ogud@ogud.com Tue Oct 13 11:59:56 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551EA28C1DE for ; Tue, 13 Oct 2009 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRN2ZSIKsbLY for ; Tue, 13 Oct 2009 11:59:55 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7503C28C1BC for ; Tue, 13 Oct 2009 11:59:55 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9DIU2sF096704 for ; Tue, 13 Oct 2009 14:30:02 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 13 Oct 2009 14:30:02 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091013_183002_032223.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-perkins-sourceipnat-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:59:56 -0000 Count: 12 behave Working Group C. Perkins, Ed. Internet-Draft WiChorus Inc. Intended status: Standards Track October 12, 2009 Expires: April 15, 2010 Translating IPv4 to IPv6 based on source IPv4 address draft-perkins-sourceipnat-01 Abstract A method is proposed to enable communications between an IPv4-only node in today's Internet and an IPv6-only node, initiated by the IPv4-only node. The communication depends on allocation of a flow record and address triggered by a DNS query received for the target v6-only node. DNS query conventions can be agreed upon to provide a natural model for resolving IPv4 queries for IPv6-only nodes. The NAT mechanism proposed demultiplexes multiple sessions through the same dynamically allocated IP address, using flow records matching the source address of incoming packets. This is in contrast to the use of ports in NAT-PT boxes, which inhibits the support of incoming traffic towards a node behind the NAT-PT. From ogud@ogud.com Wed Oct 14 11:29:59 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E143A28C1ED for ; Wed, 14 Oct 2009 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0MHHSPEtisc for ; Wed, 14 Oct 2009 11:29:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0F09528C1E7 for ; Wed, 14 Oct 2009 11:29:58 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9EIU0Q9007379 for ; Wed, 14 Oct 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Wed, 14 Oct 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091014_183000_023108.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-kaplan-dispatch-domain-registration-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:30:00 -0000 Count: 17 DISPATCH WG H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Expires: April 13, 2010 October 13, 2009 Session Initiation Protocol (SIP) Domain Registration draft-kaplan-dispatch-domain-registration-00 Abstract This document defines a means of providing reachability information for a domain of SIP AoR's using a SIP REGISTER method transaction, and defines a SIP option-tag for indicating such. From ogud@ogud.com Thu Oct 15 11:30:01 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF35C3A690D for ; Thu, 15 Oct 2009 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnJ9mDNGtyrl for ; Thu, 15 Oct 2009 11:30:00 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id ACB2D3A6893 for ; Thu, 15 Oct 2009 11:30:00 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9FIU0hP018989 for ; Thu, 15 Oct 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 15 Oct 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091015_183000_074942.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsext-dnssec-registry-fixes-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:30:01 -0000 Count: 38 DNS Extensions Working Group S. Rose Internet-Draft NIST Intended status: Standards Track October 14, 2009 Expires: April 17, 2010 DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition draft-ietf-dnsext-dnssec-registry-fixes-00 Abstract The DNS Security Extensions (DNSSEC) has an IANA registry to allocate cryptographic algorithm suites for use in generating digital signatures over DNS data. Newly introduced cryptographic algorithms to DNSSEC mean implementors need to know which algorithms need to be implmented, which are optional, and which are obsolete. This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers to list their status for use. From ogud@ogud.com Fri Oct 16 11:29:58 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA903A68AB for ; Fri, 16 Oct 2009 11:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZPxRx0BVVZ4 for ; Fri, 16 Oct 2009 11:29:57 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 715943A67D8 for ; Fri, 16 Oct 2009 11:29:57 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9GIU0Hb029468 for ; Fri, 16 Oct 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Fri, 16 Oct 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091016_183000_005228.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-yao-dnsop-idntld-implementation-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:29:58 -0000 Count: 45 Network Working Group J. Yao Internet-Draft X. Lee Intended status: BCP CNNIC Expires: April 16, 2010 October 13, 2009 IDN TLD Variants Implementation Guideline draft-yao-dnsop-idntld-implementation-00.txt Abstract ICANN is pushing the IDN TLD into the root server. Some IDN TLD has the variants. Currently, there are two proposals to implement the IDN TLD variants in the root servers:1, implement it with the DNAME record; 2, implement it with NS record. The IDN TLD variants may be reserved or activated. If the IDN TLD variants are activated, these variants will be allocated to the same TLD manager in order to avoid the possible phishing problems. How to deal with the IDN TLD variant issue is a big challenge ahead of us. This document discusses the IDN TLD variants implementation issues related with DNAME and NS resource record way. This memo also gives a proposal about how to avoid the possible phishing problem after putting the IDN TLD variants into the root. From ogud@ogud.com Fri Oct 16 11:59:53 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E624B3A681A for ; Fri, 16 Oct 2009 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMeXeySvbQBu for ; Fri, 16 Oct 2009 11:59:53 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E57603A63D3 for ; Fri, 16 Oct 2009 11:59:52 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9GIU1UO029542 for ; Fri, 16 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Fri, 16 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091016_183001_041337.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-shin-dnsop-self-termination-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:59:54 -0000 Count: 33 DNSOP Working Group S. Shin Internet-Draft H. Lee Intended status: Informational C. Park Expires: April 19, 2010 H. Paik Korea Internet & Security Agency of Korea October 16, 2009 Self-termination Mechanism for Anycast DNS Service draft-shin-dnsop-self-termination-00 Abstract Anycast has in recent years become popular for DNS servers and widely applied to several root nams servers and to other commercial name servers. For Anycast-based DNS service reliability, this documents describes the use of self-termination mechanism in Anycast-based DNS service operation when the service becomes unavailable due to events such as hardware failures From ogud@ogud.com Fri Oct 16 11:59:54 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CE63A63D3 for ; Fri, 16 Oct 2009 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hK1OgWGPjzy for ; Fri, 16 Oct 2009 11:59:53 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 770443A6767 for ; Fri, 16 Oct 2009 11:59:53 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9GIU1pO029477 for ; Fri, 16 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Fri, 16 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091016_183001_080847.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-bellis-dns-recursive-discovery-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:59:54 -0000 Count: 45 Network Working Group R. Bellis Internet-Draft Nominet UK Intended status: Standards Track A. Bligh Expires: April 18, 2010 Silverscale Associates Ltd W. Wijngaards NLnet Labs October 15, 2009 DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA draft-bellis-dns-recursive-discovery-00 Abstract This document describes a method for a DNS client resolver to discover the IP addresses of the upstream recursive DNS resolvers and hence bypass the local DNS proxy. It also directs IANA to reserve the "LOCAL.ARPA" domain name and to create a registry for well known sub-domains of that domain name, such sub-domains being reserved for use within any network's administrative boundary. From klensin@jck.com Thu Oct 8 08:12:31 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87BE3A69C7 for ; Thu, 8 Oct 2009 08:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9l2oaT5kc1K for ; Thu, 8 Oct 2009 08:12:30 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7F2AB3A659C for ; Thu, 8 Oct 2009 08:12:30 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mvugr-000ODw-8F; Thu, 08 Oct 2009 11:14:01 -0400 Date: Thu, 08 Oct 2009 11:14:00 -0400 From: John C Klensin To: Thomas Narten , Olaf Kolkman Message-ID: <0E04F75760A950630B35F1C4@PST.JCK.COM> In-Reply-To: <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 16 Oct 2009 13:51:31 -0700 Cc: Tina Dam , dns directorate Subject: Re: [dns-dir] Fwd: TLD Names and RFC 1123 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 15:12:32 -0000 --On Thursday, October 08, 2009 08:47 -0400 Thomas Narten wrote: >... >> > That minimal change for IDNs is to allow IDNs in what the >> > IDNA2008 drafts call "A-label form", i.e., an >> > ASCII-compatible-encoding, using reversible Punycode >> > conversion from valid IDNs labels, with the "xn--" prefix, >> > but requiring that the native-character ("Unicode") form >> > consist of letters only. No compelling need has been shown >> > for permitting digits or hyphens (or other characters), in >> > all-ASCII (non-IDN) labels, nor for permitting those >> > characters in the Unicode form of IDNs. > > OK. But I don't understand right off why we need to bring the > Unicode form of an IDN into this. Isn't it sufficient to just > say only A-Labels are allowed? Thomas (and others), There are two possible ways of looking at this. One is that we are looking exclusively at the technical requirements for DNS operation, seen separately from anything else --and really pretending that nothing else exists. An extreme version of that position would suggest that there are really no restrictions that make any sense -- after all, from a narrow, DNS Operations, standpoint, the biggest argument against binary string labels in the root is that it might require updating some of the maintenance tools. I can't really recommend that, but it does have some appeal... perhaps the same appeal that the proverbial ostrich feels with its head in a secure and dark place. The other is that these restrictions have always been, at least in part, driven by human factors considerations. We don't have underscores in host names partially because of some early internationalization issues but mostly because it was pointed out that they were indistinguishable from hyphens when seen on the page or written in longhand. The original "no leading digits" rule was driven by wanting to make sure that even sloppy programming or sloppy thinking didn't confuse addresses with names. I remember a discussion, long ago and pre-DNS, about whether it would be rational to permit host names like 1X while prohibiting 1A (which could be an address in hex). Similarly, from a policy standpoint --and as you have certainly learned by now in your ICANN experience-- the fuzzy lines are much harder to hold than the hard ones. "Non-Latin-IDNs get to do this at the top level in terms of what users see, so it is unfair that I can't do it in spite of using Latin script or having only undecorated Latin characters" is lawyer-bait. "No non-letter characters, other than as needed for A-labels, in either the display or internal form of a TLD name" is very clear, very crisp, and completely non-discriminatory wrt particular languages or scripts. >> > This is not just my usual paranoia about making changes >> > broader than we fully understand. There is actually a >> > case, involving "bidirectional" Unicode strings (more or >> > less those containing characters from scripts written right >> > to left), in which leading or trailing digits can result in >> > label migration such that the order in which labels may >> > appear in display format becomes different from the order >> > in which they are transmitted "on the wire" or appear in >> > native-DNS format. The problem can occur in lower levels >> > of the DNS as well, but, if one permits the "bad" cases in >> > the root, it is all over -- no amount of registry (zone >> > administration) discipline, even if one could count on it, >> > would be sufficient to prevent the label migration problem >> > from occurring. For those interested in a more detailed >> > explanation of that problem, see draft-ietf-idnabis-bidi. > > This is about leading digits, which I don't think we want to > propose changing in this document. And is about U-Labels, not > A-Labels, Right? Yes, it is about U-labels, for which see above. It is still a relevant concern relative to perceived ambiguity in FQDNs -- a problem that is potentially no less severe than the "visually similar characters" one. And, again, in terms of crispness and clarity of rules, "no digits" is clear. "Digits anywhere but in the first position in spite of the fact that we've now got two decades of experience with leading digits in other labels" sounds like we are hair-splitting to put some groups at a disadvantage. And that, again, is lawyer-bait. >> > To the extent to which we care more about identifier >> > integrity than about the "domain names market", we need to >> > hold the line and support an absolutely minimal change. >> > >> > Expressed in ABNF, that minimal change would be to make the >> > syntax: >> > >> > tldlabel = traditional-tld-label / idn-label >> > traditional-tld-label = 1*63(ALPHA) >> > idn-label = Restricted-A-label >> > ; Restricted-A-label is an A-label as defined in >> > draft-ietf-idna-defs >> > ; converted from (and convertible to) a U-label that is >> > consistent >> > ; with the definition in draft-ietf-idna-defs _and_ that >> > is further restricted >> > ; to contain only Unicode characters of General Category >> > "L". >> > >> > Note that "L" contains several subcategories. The list is >> > >> > gc ; L ; Letter # Ll | Lm | Lo | Lt | Lu >> > gc ; LC ; Cased_Letter # Ll | Lt | Lu >> > gc ; Ll ; Lowercase_Letter >> > gc ; Lm ; Modifier_Letter >> > gc ; Lo ; Other_Letter >> > gc ; Lt ; Titlecase_Letter >> > gc ; Lu ; Uppercase_Letter >> > >> > although the IDNA restriction eliminates the last two and >> > several of characters in the others. > > wfm. Encouraging. john From ogud@ogud.com Sat Oct 17 11:30:00 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2623A686A for ; Sat, 17 Oct 2009 11:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEM2GoNHdBMN for ; Sat, 17 Oct 2009 11:29:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 448903A683C for ; Sat, 17 Oct 2009 11:29:58 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9HIU0eJ038347 for ; Sat, 17 Oct 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sat, 17 Oct 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091017_183000_088566.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-wang-dns-inconsis-ncache-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 18:30:00 -0000 Count: 24 Network Working Group Zheng Wang Internet Draft CNNIC Updates: 1035, 2308 (if approved) Intended status: Standards Track Expires: April 19, 2010 Handling of the Inconsistency of Negative Caching of DNS Queries draft-wang-dns-inconsis-ncache-00.txt Abstract The introduction of negative caching of DNS queries may make DNS resolvers more frequently exposed to the cache inconsistency. This document describes the negative caching inconsistency and gives a solution for DNS resolvers to handle it. From ogud@ogud.com Tue Oct 20 11:29:59 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E2C3A6944 for ; Tue, 20 Oct 2009 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPZqKaIYYVUH for ; Tue, 20 Oct 2009 11:29:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id EF7673A6899 for ; Tue, 20 Oct 2009 11:29:55 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU0nr013726 for ; Tue, 20 Oct 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183000_079153.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-huang-behave-pnat-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:29:59 -0000 Count: 43 Network Working Group B. Huang Internet-Draft H. Deng Intended status: Standards Track China Mobile Expires: April 21, 2010 October 18, 2009 Prefix NAT: Host based IPv6 translation draft-huang-behave-pnat-00 Abstract Host based translation such as BIA, BIS could support conventional IPv4 applications talk with IPv6 applications in the dual stack network, and BIAbis and BISbis propose to extend this two solutions support IPv6 and IPv4 only network which consequently support IPv6 applications as well. This document describes a mechanism called "PNAT" which could guarantee the IPv4 or IPv6 applications in the two hosts communicate with each other directly through host based translation technologies, or by together with a network translator such as NAT64. From ogud@ogud.com Tue Oct 20 11:46:06 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A0628C184 for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K967LHi8cW3 for ; Tue, 20 Oct 2009 11:46:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C75B728C183 for ; Tue, 20 Oct 2009 11:46:04 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU8VU014396 for ; Tue, 20 Oct 2009 14:30:08 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:08 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183008_090737.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-hildebrand-dna-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:06 -0000 Count: 13 Network Working Group J. Hildebrand Internet-Draft Cisco Intended status: Standards Track S. Turner Expires: April 22, 2010 IECA, Inc. October 19, 2009 Domain Name Assertions draft-hildebrand-dna-00 Abstract An application-level approach to asserting and proving the delegated ownership of a domain name for XMPP. From ogud@ogud.com Tue Oct 20 11:46:06 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5001F28C183 for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D2H2Sdl7VPF for ; Tue, 20 Oct 2009 11:46:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5BC3E28C0E8 for ; Tue, 20 Oct 2009 11:46:05 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU1GU013821 for ; Tue, 20 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183001_060674.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-boucadair-behave-dns64-discovery-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:06 -0000 Count: 111 Network Working Group M. Boucadair Internet-Draft E. Burgey Intended status: Standards Track France Telecom Expires: April 22, 2010 October 19, 2009 DNS64 Service Location and Discovery draft-boucadair-behave-dns64-discovery-00 Abstract This memo proposes a set of solutions for the discovery of DNS64 [I-D.ietf-behave-dns64] service. Three solution candidates are proposed: SRV RR, DHCP and RA-based. From ogud@ogud.com Tue Oct 20 11:46:06 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DF728C183 for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ISoOB6W09el for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E3A413A6939 for ; Tue, 20 Oct 2009 11:46:05 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU5ch014199 for ; Tue, 20 Oct 2009 14:30:05 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:05 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183005_048098.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-mif-current-practices-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:07 -0000 Count: 38 Internet Engineering Task Force M. Wasserman, Ed. Internet-Draft Sandstorm Enterprises Intended status: Informational October 19, 2009 Expires: April 22, 2010 Current Practices for Multiple Interface Hosts draft-ietf-mif-current-practices-00 Abstract An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. From ogud@ogud.com Tue Oct 20 11:46:07 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A25628C1A3 for ; Tue, 20 Oct 2009 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP5suEZKhks8 for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8205528C0E8 for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU3e3014026 for ; Tue, 20 Oct 2009 14:30:03 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:03 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183003_090845.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-xli-behave-dns46-for-stateless-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:07 -0000 Count: 39 Network Working Group X. Li Internet-Draft C. Bao Intended status: Informational CERNET Center/Tsinghua University Expires: April 22, 2010 October 19, 2009 DNS46 for the IPv4/IPv6 Stateless Translator draft-xli-behave-dns46-for-stateless-00 Abstract The stateless translator can support IPv6-initiated communications as well as the IPv4 initiated communications for the IPv6 hosts using IPv4-translatable addresses. The DNS support for the IPv6-initiated communication is defined in the DNS64 document. This document defines the DNS46 function for the stateless translator. From ogud@ogud.com Tue Oct 20 11:46:08 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BDA3A694F for ; Tue, 20 Oct 2009 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZAd-Fz0xPZs for ; Tue, 20 Oct 2009 11:46:07 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 14C2428C186 for ; Tue, 20 Oct 2009 11:46:06 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU6Qq014265 for ; Tue, 20 Oct 2009 14:30:06 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:06 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183006_035300.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-perkins-behave-dpinat-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:08 -0000 Count: 15 IETF Behave Working Group C. Perkins Internet-Draft WiChorus Inc. Expires: April 22, 2010 October 19, 2009 Payload-assisted Delivery for SIPNAT draft-perkins-behave-dpinat-00.txt Abstract SIPNAT has been proposed as an effective method for enabling global Internet access to IPv6-only domains. New methods have been devised for accurate delivery of packets from the global Internet into the internal domain of destinations that do not share a common address space with the majority of the global Internet. These improvements can be used to augment Source-IP NAT so that perfect accuracy can be achieved in many common cases of interest. From ogud@ogud.com Tue Oct 20 11:46:08 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFB628C1A3 for ; Tue, 20 Oct 2009 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07c5OcgMZPHr for ; Tue, 20 Oct 2009 11:46:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9792128C0E8 for ; Tue, 20 Oct 2009 11:46:07 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU2ZI013943 for ; Tue, 20 Oct 2009 14:30:03 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:03 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183003_034494.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-mif-problem-statement-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:08 -0000 Count: 15 Network Working Group M. Blanchet Ed. Internet-Draft Viagenie Intended status: Informational P. Seite Expires: April 22, 2010 France Telecom October 19, 2009 Multiple Interfaces Problem Statement draft-ietf-mif-problem-statement-00.txt Abstract A multihomed host receives node configuration information from each of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. From ogud@ogud.com Tue Oct 20 11:46:09 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709133A69A4 for ; Tue, 20 Oct 2009 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBiTdzAegv15 for ; Tue, 20 Oct 2009 11:46:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3B1AC3A694F for ; Tue, 20 Oct 2009 11:46:08 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU8aH014385 for ; Tue, 20 Oct 2009 14:30:08 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:08 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183008_005426.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-wing-v6ops-v6app-v4server-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:09 -0000 Count: 13 BEHAVE Working Group D. Wing Internet-Draft Cisco Intended status: Informational October 19, 2009 Expires: April 22, 2010 Building IPv6 Applications which Access IPv4 Servers draft-wing-v6ops-v6app-v4server-00 Abstract When an application runs on a host or network that only supports IPv6 ("IPv6-only"), it is sometimes necessary that the application communicate with IPv4 peers. When that communication involves DNS, DNS64 and a 6/4 translator works well without any changes to most applications. However, when that communication does not involve DNS, it can require additional features be configured on or programmed into the IPv6 application. This document explains why this functionality is important and describes mechanisms for applications to provide such functionality. From ogud@ogud.com Tue Oct 20 11:46:09 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57303A694F for ; Tue, 20 Oct 2009 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dejJe4ff8QY for ; Tue, 20 Oct 2009 11:46:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C692F28C19F for ; Tue, 20 Oct 2009 11:46:08 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU2SG013881 for ; Tue, 20 Oct 2009 14:30:02 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:02 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183002_002975.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-xli-behave-divi-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:09 -0000 Count: 13 Network Working Group X. Li Internet-Draft C. Bao Intended status: Informational H. Zhang Expires: April 22, 2010 CERNET Center/Tsinghua University October 19, 2009 Address-sharing stateless double IVI draft-xli-behave-divi-00 Abstract This document presents the concepts and the implementations of address-sharing stateless IVI (stateless 1:N IVI) and the address- sharing stateless double IVI (stateless 1:N dIVI). The stateless 1:N IVI keeps the features of stateless, end-to-end address transparency and bidirectional-initiated communications of the original stateless 1:1 IVI, while it can utilize the IPv4 addresses more effectively. The stateless 1:N dIVI has above features and it does not require the DNS64/DNS46 and ALG supports. From ogud@ogud.com Tue Oct 20 11:46:10 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B89028C19C for ; Tue, 20 Oct 2009 11:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq0F1faRYx4d for ; Tue, 20 Oct 2009 11:46:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6BC6C3A6939 for ; Tue, 20 Oct 2009 11:46:09 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU5q6014216 for ; Tue, 20 Oct 2009 14:30:05 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:05 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183005_092072.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-wing-behave-v4app-v6server-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:10 -0000 Count: 11 BEHAVE Working Group D. Wing Internet-Draft Cisco Intended status: Informational C. Byrne Expires: April 22, 2010 T-Mobile USA October 19, 2009 Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46) draft-wing-behave-v4app-v6server-00 Abstract Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to access IPv6 servers. This is done by using in-host NAT46 translator. When used in conjunction with an in-network NAT64, it is also possible for the IPv4 application to access an IPv4 server via an IPv6-only network. This document describes how these functions work in detail, and discusses some concerns especially around IPv4 applications accessing IPv6 servers. These concerns can be reduced by not having IPv4 applications access IPv6 servers. From ogud@ogud.com Tue Oct 20 11:46:10 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BF43A69A4 for ; Tue, 20 Oct 2009 11:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXMmiLKNouln for ; Tue, 20 Oct 2009 11:46:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0C78A28C198 for ; Tue, 20 Oct 2009 11:46:09 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU7sS014353 for ; Tue, 20 Oct 2009 14:30:07 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:07 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183007_092203.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-zhu-mobility-survey-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:11 -0000 Count: 27 Network Working Group Z. Zhu Internet-Draft UCLA Intended status: Informational R. Wakikawa Expires: April 22, 2010 TOYOTA ITC L. Zhang UCLA October 19, 2009 A Survey of Mobility Support In the Internet draft-zhu-mobility-survey-00.txt Abstract Over the last two decades many research efforts have been devoted to developing solutions for mobility support over the global Internet and resulted in a variety of proposed solutions. We conducted a survey of the previous efforts to deepen our understanding on the overall solution space of mobility support. This draft reports on our finding and identifies remaining issues in providing ubiquitous and efficient global scale mobility support. From ogud@ogud.com Tue Oct 20 11:46:11 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A162528C184 for ; Tue, 20 Oct 2009 11:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPH+7amqNJNl for ; Tue, 20 Oct 2009 11:46:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 96FFB3A6939 for ; Tue, 20 Oct 2009 11:46:10 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU8II014446 for ; Tue, 20 Oct 2009 14:30:08 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:08 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183008_096282.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ljunggren-dps-framework-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:11 -0000 Count: 58 Network Working Group F. Ljunggren Internet-Draft Kirei AB Intended status: Informational A-M. Eklund-Lowinder Expires: April 23, 2010 .SE T. Okubo VeriSign October 20, 2009 DNSSEC Signing Policy & Practice Statement Framework draft-ljunggren-dps-framework-01 Abstract This document presents a framework to assist writers of DNSSEC Signing Policy and Practice Statements such as Regulatory Authorities and Registry Managers on both the TLD and secondary level, who is operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) needs to be covered in a DNSSEC Signing Policy definition and Practice Statement. From ogud@ogud.com Tue Oct 20 11:46:12 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6913A694F for ; Tue, 20 Oct 2009 11:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK-0tReJ4HfH for ; Tue, 20 Oct 2009 11:46:11 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3E36428C19C for ; Tue, 20 Oct 2009 11:46:11 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU4jx014071 for ; Tue, 20 Oct 2009 14:30:04 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:04 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183004_050668.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-tschofenig-ecrit-rfc5222bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:12 -0000 Count: 31 ECRIT T. Hardie Internet-Draft Updates: RFC 5222, RFC 5012 A. Newton (if approved) American Registry for Internet Intended status: Standards Track Numbers Expires: April 21, 2010 H. Schulzrinne Columbia University H. Tschofenig Nokia Siemens Networks October 18, 2009 LoST: A Location-to-Service Translation Protocol draft-tschofenig-ecrit-rfc5222bis-00 Abstract This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. This document is a revision of the original LoST specification, descrbed in RFC 5222. From ogud@ogud.com Tue Oct 20 11:46:12 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0FB428C1AA for ; Tue, 20 Oct 2009 11:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPyPZMYVhfsa for ; Tue, 20 Oct 2009 11:46:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D8E593A6939 for ; Tue, 20 Oct 2009 11:46:11 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU1X9013804 for ; Tue, 20 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183001_012552.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-park-idnabis-unirr-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:13 -0000 Count: 32 IDNABIS Working Group C. Park Internet-Draft H. Paik Intended status: Informational Korea Internet & Security Agency Expires: April 19, 2010 of Korea E. Jung Anyang University X. Lee China Internet Network Information Center October 16, 2009 Unicode Resource Records of DNS Host Information for Internationalized Domain Names draft-park-idnabis-unirr-00 Abstract Although Internationalized Domain Names in Applications (IDNA) contributes the population of the Internationalized Domains, it forces human DNS managers to handle unreadable DNS records. In order to enable human managers to easily edit or modify DNS records, DNS servers should allow Unicode resource records. This document defines the formats of DNS Resource Records and a translation process that supports Unicode Resource Records without ruining the interoperability with existing DNS infrastructure. From ogud@ogud.com Tue Oct 20 11:46:13 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845CF28C195 for ; Tue, 20 Oct 2009 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwPd+2qyXBas for ; Tue, 20 Oct 2009 11:46:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 79C1928C19B for ; Tue, 20 Oct 2009 11:46:12 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU79J014315 for ; Tue, 20 Oct 2009 14:30:07 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:07 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183007_061076.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-carpenter-behave-referral-object-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:13 -0000 Count: 18 GROBJ BOF B. Carpenter, Ed. Internet-Draft Univ. of Auckland Intended status: Standards Track M. Boucadair Expires: April 23, 2010 France Telecom J. Halpern Ericsson S. Jiang Huawei Technologies Co., Ltd K. Moore Network Heretics October 20, 2009 A Generic Referral Object for Internet Entities draft-carpenter-behave-referral-object-01 Abstract The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application- independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals, a new notion of scope identifiers is introduced. From ogud@ogud.com Tue Oct 20 11:46:14 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A16B28C1A3 for ; Tue, 20 Oct 2009 11:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptr85QHspDAa for ; Tue, 20 Oct 2009 11:46:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 19B1728C159 for ; Tue, 20 Oct 2009 11:46:12 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU1Tj013832 for ; Tue, 20 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183001_011519.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-boucadair-behave-dns-a64-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:14 -0000 Count: 41 Network Working Group M. Boucadair Internet-Draft E. Burgey Intended status: Standards Track France Telecom Expires: April 22, 2010 October 19, 2009 A64: DNS Resource Record for IPv4-mapped IPv6 Address draft-boucadair-behave-dns-a64-00 Abstract In this context of IPv4-IPv6 interconnection, several solutions have been proposed. Some of these solutions require the definition of a new IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] which is used to represent an IPv4-only host in an IPv6 realms and the definition of a new mechanism called DNS64 for synthesizing a AAAA record, representing an IPv4-mapped IPv6 address in the DNS system, from the A record representing the IPv4 address of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 address, when managed by a translator, is to be considered as "fake" address in a DNS system since it is not necessarily assigned to any host's interface qualified by the associated name. This document defines a new DNS record type and query type to identify IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] from native IPv6 ones. The new record type and query type aim at helping the remote party to enforce its policies and avoid NAT64 boxes when possible. Native addresses are to be preferred. From ogud@ogud.com Tue Oct 20 11:46:14 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BC228C19B for ; Tue, 20 Oct 2009 11:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JULPDn++lGzD for ; Tue, 20 Oct 2009 11:46:14 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BE21E28C195 for ; Tue, 20 Oct 2009 11:46:13 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU6CB014236 for ; Tue, 20 Oct 2009 14:30:06 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:06 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183006_059105.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-cui-softwire-pet64-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:14 -0000 Count: 48 Network Working Group Y. Cui Internet-Draft M. Xu Intended status: Standards Track S. Wang Expires: April 4, 2010 X. Li J. Wu Tsinghua University C. Metz Cisco systems Oct. 2009 PET for IPv6 to IPv4 communication draft-cui-softwire-pet64-00.txt Abstract This draft offers a solution using PET for the scenario that an IPv6- only client initiates a communication to an IPv4-only server through IPv6 backbone. In this communication scenario,translation is needed. However, translation work has requirements on the performance (hardware or software) of PET and the size of network that the PET is charge for. This draft introduces the concept of translation preference to express the PET's willing of performing translation according to some policies the network administrators constitute. Through exchanging the Translation preference among PETs, PET framework can decide which PET should act as a translator. In addition, this draft also gives how the PET collaborates with DNS to solve the IPv6-to-IPv4 communication problem. From ogud@ogud.com Tue Oct 20 11:46:15 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879D128C1A0 for ; Tue, 20 Oct 2009 11:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QWzSLxoRmZ3 for ; Tue, 20 Oct 2009 11:46:14 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6EDDE28C159 for ; Tue, 20 Oct 2009 11:46:14 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU2pO013855 for ; Tue, 20 Oct 2009 14:30:02 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:02 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183002_008596.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-zhang-hip-investigation-proxy-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:15 -0000 Count: 60 Network working group Dacheng Zhang Internet Draft Xiaohu Xu Intended status: Experimental Huawei Technologies Co.,Ltd Created: October 19, 2009 Jiankang Yao Expires: April 2010 CNNIC Investigation in HIP Proxies draft-zhang-hip-investigation-proxy-00 Abstract HIP proxies play an important role in the transition from the current Internet architecture to the HIP architecture. The major function of HIP proxies is to make up legacy (or Non-HIP) hosts as HIP hosts and enable them to communicate with HIP hosts without upgrading their protocol stacks. In this document, the legacy hosts served by proxies is referred to as the Made-up Legacy (ML) hosts. Currently, various design solutions of HIP proxies have been proposed for different working circumstances, and the effectiveness of these solutions can be influenced by various factors (e.g., the information of HIP hosts maintained in DNS servers, the position where a proxy is located, etc.). In this document, we attempt to investigate these solutions in detail and compare their performance in different scenarios. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. From ogud@ogud.com Tue Oct 20 11:46:16 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463E228C1A0 for ; Tue, 20 Oct 2009 11:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zylue+PZ8B0Q for ; Tue, 20 Oct 2009 11:46:15 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 15F7A28C195 for ; Tue, 20 Oct 2009 11:46:14 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU4Mm014051 for ; Tue, 20 Oct 2009 14:30:04 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:04 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183004_055462.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-huang-behave-rfc2767bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:16 -0000 Count: 13 Behave B. Huang Internet-Draft H. Deng Obsoletes: 2767 (if approved) China Mobile Intended status: Experimental T. Savolainen Expires: April 21, 2010 Nokia October 18, 2009 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) draft-huang-behave-rfc2767bis-00 Abstract This document describes the "Bump-In-the-Stack" (BIS) host based protocol translation mechanism that allows applications supporting only one IP address family to communicate with peers that are reachable or supporting only the other address family. Furthermore, this technology avoids need for unnecessary double protocol translation in the case where destination is dual-stack enabled. This specification addresses scenarios where a host is provided dual stack, IPv6 only or IPv4 only network connectivity. In the dual stack network case, single address family applications in the host will communicate directly with other hosts reachable with the same address family. In the case of IPv6 only network or IPv6 only destination, IPv4-originated communications have to be be translated into IPv6. IPv6 communications may have to translated similarly to IPv4. In the scenario of single address family access network, but dual-stack destination, network based translation is always avoided. Technically, the BIS-enabled host resolves both IPv4 and IPv6 addresses of the destination and behaves according to received responses. Acknowledgement of previous work This document is an update to and directly derivative from Kazuaki TSUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's [RFC2767], which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations.The original document was a product of the NGTRANS working group. The changes in this document reflect three components: 1. Supporting IPv6 only network connections 2. Supporting IPv4 only network connections 3. Supporting Well Known Prefix From ogud@ogud.com Tue Oct 20 11:46:17 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FFD28C1A3 for ; Tue, 20 Oct 2009 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zIMeBqrMZVe for ; Tue, 20 Oct 2009 11:46:16 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D4D5128C159 for ; Tue, 20 Oct 2009 11:46:15 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9KIU3Zw014043 for ; Tue, 20 Oct 2009 14:30:03 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 20 Oct 2009 14:30:03 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091020_183003_011392.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-huang-behave-rfc3338bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:17 -0000 Count: 15 Behave B. Huang Internet-Draft H. Deng Obsoletes: 3338 (if approved) China Mobile Intended status: Experimental T. Savolainen Expires: April 22, 2010 Nokia October 19, 2009 Dual Stack Hosts Using "Bump-in-the-API" (BIA) draft-huang-behave-rfc3338bis-00 Abstract This document describes the "Bump-In-the-API" (BIA) host based protocol translation mechanism that allows applications supporting only one IP address family to communicate with peers that are reachable or supporting only the other address family. This specification addresses scenarios where a host is provided dual stack, IPv6 only or IPv4 only network connectivity. In the dual stack network case, single address family applications in the host will communicate directly with other hosts using the same address family. In the case of IPv6 only network or IPv6 only destination, IPv4- originated communications have to be be translated into IPv6. IPv6 communications may have to translated similarly to IPv4. Technically, the BIS-enabled host resolves both IPv4 and IPv6 addresses of the destination and behaves according to received responses. Acknowledgement of previous work This document is an update to and directly derivative from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's [RFC3338], which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations.The original document was a product of the NGTRANS working group. The changes in this document reflect three components: 1. Supporting IPv6 only network connections 2. Supporting IPv4 only network connections 3. Supporting Well Known Prefix 4. Removing Applicability and Disclaimer The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation. From liman@autonomica.se Mon Oct 26 07:30:54 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B863A67A3 for ; Mon, 26 Oct 2009 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX8jvaGH-Pzc for ; Mon, 26 Oct 2009 07:30:52 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id DEDCE3A677C for ; Mon, 26 Oct 2009 07:30:48 -0700 (PDT) Received: from home.liman.net (2-1-3-18a.spa.sth.bostream.se [82.182.146.229]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9QETAdR018514; Mon, 26 Oct 2009 15:29:10 +0100 (MET) Received: from zaptop.autonomica.net ([203.229.181.215]) by home.liman.net (8.14.3/8.13.8) with ESMTP id n9QET2L3005791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Oct 2009 15:29:07 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n9QESsDL092106; Mon, 26 Oct 2009 23:28:54 +0900 (KST) To: Thomas Narten , John Klensin References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> From: Lars-Johan Liman Date: Mon, 26 Oct 2009 23:28:54 +0900 In-Reply-To: <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Thu\, 08 Oct 2009 08\:47\:36 -0400") Message-ID: <22iqe2b55l.fsf_-_@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Olaf Kolkman , Tina Dam , dns directorate Subject: [dns-dir] TLD Names - new draft. X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:30:54 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Friends, I realize that the chances that you'll see this in time are minimal, but if you do, and have critical comments before I submit it, let me know. Else I'll send it in before the deadline later (your) today. I've incorporated most of Tomas's coments, and I must say that I follow John's reasoning all the way. We _don't_ want jumping digits in the TLD label (nor anywhere else, but that's a different problem). So, I've tried to merge the two sets of comments. Right now the text is fairly complicated and refers to a couple of internet drafts - references that need to be cleared up before publication. I'm hesitant to duplicate text so references is probably the way to go, but I don't have the respective I-Ds in front of me, so right now I'll have to trust John that they contain the relevant information. Thomas, my cell phone number is +46-708-540666, should you need it. (For the rest of you: Please note that I'm at the ICANN meeting in Korea, so my current TZ=3D+0900.) Cheers, /Liman #---------------------------------------------------------------------- # ** WE'VE MOVED **: New address: Franz=E9ngatan 5, SE-112 51 Stockholm #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail/SIP/Jabber: liman@autonomica.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Autonomica AB, Stockholm ! http://www.autonomica.se/ #---------------------------------------------------------------------- --=-=-= Content-Disposition: inline; filename=draft-liman-tld-names-01.txt Individual submission L-J. Liman Internet-Draft Autonomica Intended status: Informational October 26, 2009 Expires: April 29, 2010 Top Level Domain Name Specification draft-liman-tld-names-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Liman Expires April 29, 2010 [Page 1] Internet-Draft Top Level Domain Name Specification October 2009 Abstract The precise syntax allowed in top-level domain name labels has been the subject to some debate. RFC 1123, for example, makes the statement that top-level domain names are "alphabetic". This document updates the definition of allowable top-level domain names in order to support internationalized domain names (IDNs), as encoded by the IDNA protocols. This document focuses narrowly on the issue of IDNs and does not make any other changes or clarifications to existing domain name syntax rules. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Other Limitations on Top Level Domain Labels . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 11 B.1. draft-liman-tld-named-01 . . . . . . . . . . . . . . . . . 11 B.2. draft-liman-tld-named-00 . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Liman Expires April 29, 2010 [Page 2] Internet-Draft Top Level Domain Name Specification October 2009 1. Introduction The precise syntax allowed in top-level domain (TLD) name labels has been the subject to some debate. RFC 1123 [RFC1123], for example, states that TLD names must be "alphabetic", which is interpreted as excluding the hyphen (or dash) character. This document updates the definition of allowable top-level domain names to support internationalized domain names that consist of Unicode letters, as encoded by the IDNA protocols [RFCXXX]. In particular, this document clarifies that ASCII TLDs beginning with "xn--", as encoded by IDNA, are permissible as DNS TLD names as long as they are made from Unicode letters. This document focuses narrowly on the issue of allowable ASCII labels encoded by the IDNA protocols and does not (and is not intended to) make any other changes or clarifications to existing domain name syntax rules. 1.1. Terminology The terminology used in this document is as defined in RFC 0952 [RFC0952] and RFC 1035 [RFC1035]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Liman Expires April 29, 2010 [Page 3] Internet-Draft Top Level Domain Name Specification October 2009 2. Background RFC 0952 [RFC0952] states (among other things) that a host 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. RFC 1123 [RFC1123] reaffirms this definition, making two additional changes 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. and However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. The restrictions on host names and specifically TLD names have always been, at least in part, driven by human factors considerations. Underscores in host names are avoided because they are indistinguishable from hyphens when seen on a page or written in longhand, and to some extent because of early internationalization issues. The original "no leading digits" rule was driven by wanting to make sure that even imprecise programming or human thought errors didn't confuse addresses with names. The wish to express TLD names in other scripts than Latin makes it necessary to relax the the rules for TLD names. However, the old motivations for keeping the TLD names alphabetical still hold, and furthermore, certain characteristics of some IDN names with digits in them make them unsuitable as DNS labels. The problem is referred to as "jumping digits", and is described in draft-ietf-idnabis-bidi. In order to keep changes to existing specifications to a minimum but to still allow for IDN TLD names, this document hereby changes the existing specification to allow for IDN TLD names in the "A-label Liman Expires April 29, 2010 [Page 4] Internet-Draft Top Level Domain Name Specification October 2009 form" as specified by the IDNA-2008 specifications, i.e., an ASCII- compatible-encoding, using reversible Punycode conversion from valid IDNs labels, with IDN A-label prefix (which, as of this writing, is "xn--"), but requiring that the native-character ("Unicode") form consist of letters only. Hence, the ABNF expression that matches a valid TLD label is as follows: tldlabel = 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 Restricted-A-label is an A-label as defined in draft-ietf-idna-defs converted from (and convertible to) a U-label that is consistent with the definition in draft-ietf-idna-defs and that is further restricted to contain only Unicode characters of General Category "L". Note that "L" contains several sub-categories. The list is: Foo: ; Letter L = Ll / Lm / Lo / Lt / Lu Ll = Lowercase-Letter Lm = Modifier-Letter Lo = Other-Letter Lt = Titlecase-Letter Lu = Uppercase-Letter although the IDNA restriction eliminates the last two and several of characters in the others. This new specification reflects current practice in registration of TLD names by the IANA, and allows for IDNs. Liman Expires April 29, 2010 [Page 5] Internet-Draft Top Level Domain Name Specification October 2009 3. Other Limitations on Top Level Domain Labels It should be noted that there are many issues that must be considered in making any changes to current restrictions on DNS labels, especially at the top level. DNS software is widely deployed, and some of that software contains embedded assumptions that may not hold if DNS names are used at the top level that differ from the older rules. For example, when TLDs longer than 3 characters became available (e.g., .info, .museum, etc.), some deployed systems did not process such DNS names properly. This document does not take the position that no problems will result when IDN TLDs are created, but does recognize that relaxing the syntax of allowed TLDs is necessary in order to allow deployment of IDNs to happen. It is also carefully noted that the above specification is not the only limiting factor on TLD labels. There may be other entities than the IETF that have influence over TLD names, and which may decide to restrict the names further. The above technical specification is just one limiting factor. Liman Expires April 29, 2010 [Page 6] Internet-Draft Top Level Domain Name Specification October 2009 4. IANA Considerations This memo changes the specifications for TLD names registered by the IANA, and the IANA is requested to change its registration process to use the above specification. Liman Expires April 29, 2010 [Page 7] Internet-Draft Top Level Domain Name Specification October 2009 5. Security Considerations This document is believed to have limited security consequences. It may introduce stability issues where names registered under this new specification may inter-operate badly with old software written to enforce a strict interpretation of the old specification. This might also open up attack vectors (e.g. form names being truncated). However, it is believed that such software is scarce on the Internet, and since TLD names that do not adhere to a strict interpretation of the old specification are already used (including test IDNs) without apparent problems, it is believed that this change of the specification will not create major stability or security problems on the Internet. Liman Expires April 29, 2010 [Page 8] Internet-Draft Top Level Domain Name Specification October 2009 6. References 6.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985. Liman Expires April 29, 2010 [Page 9] Internet-Draft Top Level Domain Name Specification October 2009 Appendix A. To Do 1. Clean up references. Check situation with references to Internet Drafts. Are they/will they be published as RFCs before this draft? 2. Verify quotations. Liman Expires April 29, 2010 [Page 10] Internet-Draft Top Level Domain Name Specification October 2009 Appendix B. Change History B.1. draft-liman-tld-named-01 Substantial comments and improvements supplied by Thomas Narten and John Klensin. Decided to go for a minimal change approach. Also noted that U-labels have to be letters due to jumping digit problem. Rewritten major parts. B.2. draft-liman-tld-named-00 First cut. Prompted by Olafur Gudmundsson and Tina Dam. Liman Expires April 29, 2010 [Page 11] Internet-Draft Top Level Domain Name Specification October 2009 Author's Address Lars-Johan Liman Autonomica AB Franzengatan 5 SE-112 51 Stockholm Sweden Email: liman@autonomica.se URI: http://www.autonomica.se/ Liman Expires April 29, 2010 [Page 12] --=-=-=-- From ogud@ogud.com Mon Oct 26 08:10:35 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76E128C0FF for ; Mon, 26 Oct 2009 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGmfPfCmpCOL for ; Mon, 26 Oct 2009 08:10:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 1462728C0F8 for ; Mon, 26 Oct 2009 08:10:32 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9QFAHWN071215; Mon, 26 Oct 2009 11:10:17 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910261510.n9QFAHWN071215@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 11:10:09 -0400 To: Lars-Johan Liman , Thomas Narten , John Klensin From: Olafur Gudmundsson In-Reply-To: <22iqe2b55l.fsf_-_@zaptop.autonomica.net> References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> <22iqe2b55l.fsf_-_@zaptop.autonomica.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: Olaf Kolkman , Tina Dam , dns directorate Subject: Re: [dns-dir] TLD Names - new draft. X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:10:35 -0000 I read this over and I think it is safe for you to post. Olafur At 10:28 26/10/2009, Lars-Johan Liman wrote: >Friends, > >I realize that the chances that you'll see this in time are minimal, >but if you do, and have critical comments before I submit it, let me >know. Else I'll send it in before the deadline later (your) today. > >I've incorporated most of Tomas's coments, and I must say that I >follow John's reasoning all the way. We _don't_ want jumping digits in >the TLD label (nor anywhere else, but that's a different problem). > >So, I've tried to merge the two sets of comments. Right now the text >is fairly complicated and refers to a couple of internet drafts - >references that need to be cleared up before publication. I'm hesitant >to duplicate text so references is probably the way to go, but I don't >have the respective I-Ds in front of me, so right now I'll have to >trust John that they contain the relevant information. > >Thomas, my cell phone number is +46-708-540666, should you need it. >(For the rest of you: Please note that I'm at the ICANN meeting in >Korea, so my current TZ=3D+0900.) > > Cheers, > /Liman >#---------------------------------------------------------------------- ># ** WE'VE MOVED **: New address: Franz=E9ngatan 5, SE-112 51 Stockholm >#---------------------------------------------------------------------- ># Lars-Johan Liman, M.Sc. ! E-mail/SIP/Jabber: liman@autonomica.se ># Senior Systems Specialist ! Tel: +46 8 - 562 860 12 ># Autonomica AB, Stockholm ! http://www.autonomica.se/ >#---------------------------------------------------------------------- > > > > > >Individual submission L-J. Liman >Internet-Draft Autonomica >Intended status: Informational October 26, 2009 >Expires: April 29, 2010 > > > Top Level Domain Name Specification > draft-liman-tld-names-01 > >Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 29, 2010. > >Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents in effect on the date of > publication of this document (http://trustee.ietf.org/license-info). > Please review these documents carefully, as they describe your rights > and restrictions with respect to this document. > > > > > > > > > >Liman Expires April 29, 2010 [Page 1] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >Abstract > > The precise syntax allowed in top-level domain name labels has been > the subject to some debate. RFC 1123, for example, makes the > statement that top-level domain names are "alphabetic". This > document updates the definition of allowable top-level domain names > in order to support internationalized domain names (IDNs), as encoded > by the IDNA protocols. This document focuses narrowly on the issue > of IDNs and does not make any other changes or clarifications to > existing domain name syntax rules. > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 > 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Other Limitations on Top Level Domain Labels . . . . . . . . . 6 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 > 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 > Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 10 > Appendix B. Change History . . . . . . . . . . . . . . . . . . . 11 > B.1. draft-liman-tld-named-01 . . . . . . . . . . . . . . . . . 11 > B.2. draft-liman-tld-named-00 . . . . . . . . . . . . . . . . . 11 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 2] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >1. Introduction > > The precise syntax allowed in top-level domain (TLD) name labels has > been the subject to some debate. RFC 1123 [RFC1123], for example, > states that TLD names must be "alphabetic", which is interpreted as > excluding the hyphen (or dash) character. This document updates the > definition of allowable top-level domain names to support > internationalized domain names that consist of Unicode letters, as > encoded by the IDNA protocols [RFCXXX]. In particular, this document > clarifies that ASCII TLDs beginning with "xn--", as encoded by IDNA, > are permissible as DNS TLD names as long as they are made from > Unicode letters. This document focuses narrowly on the issue of > allowable ASCII labels encoded by the IDNA protocols and does not > (and is not intended to) make any other changes or clarifications to > existing domain name syntax rules. > >1.1. Terminology > > The terminology used in this document is as defined in RFC 0952 > [RFC0952] and RFC 1035 [RFC1035]. > >1.2. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 3] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >2. Background > > RFC 0952 [RFC0952] states (among other things) that a host 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. > > RFC 1123 [RFC1123] reaffirms this definition, making two additional > changes 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. > > and > > However, a valid host name can never have the dotted-decimal form > #.#.#.#, since at least the highest-level component label will be > alphabetic. > > The restrictions on host names and specifically TLD names have always > been, at least in part, driven by human factors considerations. > Underscores in host names are avoided because they are > indistinguishable from hyphens when seen on a page or written in > longhand, and to some extent because of early internationalization > issues. The original "no leading digits" rule was driven by wanting > to make sure that even imprecise programming or human thought errors > didn't confuse addresses with names. > > The wish to express TLD names in other scripts than Latin makes it > necessary to relax the the rules for TLD names. However, the old > motivations for keeping the TLD names alphabetical still hold, and > furthermore, certain characteristics of some IDN names with digits in > them make them unsuitable as DNS labels. The problem is referred to > as "jumping digits", and is described in draft-ietf-idnabis-bidi. > > In order to keep changes to existing specifications to a minimum but > to still allow for IDN TLD names, this document hereby changes the > existing specification to allow for IDN TLD names in the "A-label > > > >Liman Expires April 29, 2010 [Page 4] > >Internet-Draft Top Level Domain Name Specification October 2009 > > > form" as specified by the IDNA-2008 specifications, i.e., an ASCII- > compatible-encoding, using reversible Punycode conversion from valid > IDNs labels, with IDN A-label prefix (which, as of this writing, is > "xn--"), but requiring that the native-character ("Unicode") form > consist of letters only. > > Hence, the ABNF expression that matches a valid TLD label is as > follows: > > > tldlabel =3D traditional-tld-label / idn-label > > traditional-tld-label =3D 1*63(ALPHA) > > idn-label =3D Restricted-A-label > > ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z > > > Restricted-A-label is an A-label as defined in draft-ietf-idna-defs > converted from (and convertible to) a U-label that is consistent with > the definition in draft-ietf-idna-defs and that is further restricted > to contain only Unicode characters of General Category "L". Note > that "L" contains several sub-categories. The list is: > > Foo: > > > ; Letter > L =3D Ll / Lm / Lo / Lt / Lu > > Ll =3D Lowercase-Letter > > Lm =3D Modifier-Letter > > Lo =3D Other-Letter > > Lt =3D Titlecase-Letter > > Lu =3D Uppercase-Letter > > > although the IDNA restriction eliminates the last two and several of > characters in the others. > > This new specification reflects current practice in registration of > TLD names by the IANA, and allows for IDNs. > > > > >Liman Expires April 29, 2010 [Page 5] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >3. Other Limitations on Top Level Domain Labels > > It should be noted that there are many issues that must be considered > in making any changes to current restrictions on DNS labels, > especially at the top level. DNS software is widely deployed, and > some of that software contains embedded assumptions that may not hold > if DNS names are used at the top level that differ from the older > rules. For example, when TLDs longer than 3 characters became > available (e.g., .info, .museum, etc.), some deployed systems did not > process such DNS names properly. This document does not take the > position that no problems will result when IDN TLDs are created, but > does recognize that relaxing the syntax of allowed TLDs is necessary > in order to allow deployment of IDNs to happen. > > It is also carefully noted that the above specification is not the > only limiting factor on TLD labels. There may be other entities than > the IETF that have influence over TLD names, and which may decide to > restrict the names further. The above technical specification is > just one limiting factor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 6] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >4. IANA Considerations > > This memo changes the specifications for TLD names registered by the > IANA, and the IANA is requested to change its registration process to > use the above specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 7] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >5. Security Considerations > > This document is believed to have limited security consequences. > > It may introduce stability issues where names registered under this > new specification may inter-operate badly with old software written > to enforce a strict interpretation of the old specification. This > might also open up attack vectors (e.g. form names being truncated). > However, it is believed that such software is scarce on the Internet, > and since TLD names that do not adhere to a strict interpretation of > the old specification are already used (including test IDNs) without > apparent problems, it is believed that this change of the > specification will not create major stability or security problems on > the Internet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 8] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >6. References > >6.1. Normative References > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [RFC1123] Braden, R., "Requirements for Internet Hosts - Application > and Support", STD 3, RFC 1123, October 1989. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > >6.2. Informative References > > [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet > host table specification", RFC 952, October 1985. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 9] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >Appendix A. To Do > > 1. Clean up references. Check situation with references to Internet > Drafts. Are they/will they be published as RFCs before this > draft? > > 2. Verify quotations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 10] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >Appendix B. Change History > >B.1. draft-liman-tld-named-01 > > Substantial comments and improvements supplied by Thomas Narten and > John Klensin. Decided to go for a minimal change approach. Also > noted that U-labels have to be letters due to jumping digit problem. > Rewritten major parts. > >B.2. draft-liman-tld-named-00 > > First cut. Prompted by Olafur Gudmundsson and Tina Dam. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 11] > >Internet-Draft Top Level Domain Name Specification October 2009 > > >Author's Address > > Lars-Johan Liman > Autonomica AB > Franzengatan 5 > SE-112 51 Stockholm > Sweden > > Email: liman@autonomica.se > URI: http://www.autonomica.se/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Liman Expires April 29, 2010 [Page 12] > > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir From klensin@jck.com Mon Oct 26 09:05:24 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E093A6ACE for ; Mon, 26 Oct 2009 09:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ajuCZK8bzb8 for ; Mon, 26 Oct 2009 09:05:23 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D7D8D3A6AC3 for ; Mon, 26 Oct 2009 09:05:20 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1N2S4O-000Bj0-UV; Mon, 26 Oct 2009 12:05:21 -0400 Date: Mon, 26 Oct 2009 12:05:19 -0400 From: John C Klensin To: Lars-Johan Liman Message-ID: <6038E580C7975FBD688FB668@PST.JCK.COM> In-Reply-To: <22iqe2b55l.fsf_-_@zaptop.autonomica.net> References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> <22iqe2b55l.fsf_-_@zaptop.autonomica.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Thomas Narten , Olaf Kolkman , Tina Dam , dns directorate , Cary Karp Subject: Re: [dns-dir] TLD Names - new draft. X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:05:24 -0000 --On Monday, October 26, 2009 23:28 +0900 Lars-Johan Liman wrote: > Friends, > > I realize that the chances that you'll see this in time are > minimal, but if you do, and have critical comments before I > submit it, let me know. Else I'll send it in before the > deadline later (your) today. >... > So, I've tried to merge the two sets of comments. Right now > the text is fairly complicated and refers to a couple of > internet drafts - references that need to be cleared up before > publication. I'm hesitant to duplicate text so references is > probably the way to go, but I don't have the respective I-Ds > in front of me, so right now I'll have to trust John that they > contain the relevant information. Hi. I've skimmed this -- no time to read it carefully. A few things that might be useful to incorporate/patch if you have time. (1) draft-ietf-idnabis-bidi does not use the term "jumping digits". The discussion that you want does occur in Section 5 of that document. FWIW, the co-authors of that document are Harald and Cary Karp, both of whom are in Seoul. I imagine that Harald is swamped in Board things, but Cary might possibly have some time to help you tune that part of the document (I've taken the liberty of copying him on this note as a heads-up that I've volunteered him). There is, incidentally, an additional reason for avoiding digits, but I don't have time to write it up right now. Bug me in Hiroshima and, if I forget, mention Input Method Editors and localization. (2) The "A-label form" is specified in draft-ietf-idnabis-defs (which references the other documents as needed). (3) Editorial: on the top of page 5, you have "compatible-encoding, using reversible Punycode conversion from valid IDNs labels, with IDN A-label prefix (which, as of this writing, is..." s/valid IDNs labels/valid IDN labels/ (4) Editorial (next paragraph on Page 5 and the ABNF for "L"): Foo: ; Letter L = Ll / Lm / Lo / Lt / Lu Ll = Lowercase-Letter Lm = Modifier-Letter s/Foo:// (5) "the IDNA restriction". The text now reads... although the IDNA restriction eliminates the last two and several of characters in the others. try something like: although IDNA prohibits (categorizes as DISALLOWED) all characters in the last two categories and several of the characters that fall into the other categories. (6) The IDNA2008 drafts have completed IETF Last Call and new drafts have been posted to reflect the Last Call comments (the most recent set a few hours ago). So, while I don't know Lisa's plans or schedule, there is reason to hope that the documents will be under final IESG consideration before or during Hiroshima. In other words, there are good odds that they will, indeed, be published before you can get this draft approved and published. I will send you separately a small file containing the XML forms of the elements for the IDNA2008 documents in case it would help you get better refs into the document. john From ogud@ogud.com Mon Oct 26 11:29:54 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2723A68A6 for ; Mon, 26 Oct 2009 11:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVKdSYfY19dr for ; Mon, 26 Oct 2009 11:29:53 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 563F33A687E for ; Mon, 26 Oct 2009 11:29:53 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9QIU1pw074367 for ; Mon, 26 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 26 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091026_183001_031198.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-zhang-hip-hi-revocation-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:29:54 -0000 Count: 11 Network working group Dacheng Zhang Internet Draft Huawei Technologies Co.,Ltd Category: Informational Dmitriy Kuptsov Created: October 26, 2009 Helsinki Institute for Information Technology Expires: April 2010 Sean Shen CNNIC Host Identifier Revocation in HIP draft-zhang-hip-hi-revocation-01 Abstract This document mainly analyzes the key revocation issue with host identities (HIs) in the Host Identity Protocol (HIP), which has not attracted enough attention from the HIP community yet. As a key functionality of key management mechanisms, key revocation is critical for security systems especially which are expected to operate for a long period. Apart from that, this document also discusses the potential challenges that the designers of HI revocation mechanisms have to encounter and propose candidate solutions. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. From narten@us.ibm.com Mon Oct 26 14:08:38 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336983A6B23 for ; Mon, 26 Oct 2009 14:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7xM8WluBXNS for ; Mon, 26 Oct 2009 14:08:37 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 6A2B93A6B08 for ; Mon, 26 Oct 2009 14:08:37 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9QL4JK8016488 for ; Mon, 26 Oct 2009 15:04:19 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9QL8X5r096468 for ; Mon, 26 Oct 2009 15:08:39 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9QF7m6m003692 for ; Mon, 26 Oct 2009 09:07:48 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-247-236.mts.ibm.com [9.65.247.236]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9QF7jhZ003358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 09:07:47 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n9QL8HK7005046; Tue, 27 Oct 2009 06:08:18 +0900 Message-Id: <200910262108.n9QL8HK7005046@cichlid.raleigh.ibm.com> To: Lars-Johan Liman In-reply-to: <22iqe2b55l.fsf_-_@zaptop.autonomica.net> References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> <22iqe2b55l.fsf_-_@zaptop.autonomica.net> Comments: In-reply-to Lars-Johan Liman message dated "Mon, 26 Oct 2009 23:28:54 +0900." Date: Tue, 27 Oct 2009 06:08:16 +0900 From: Thomas Narten Cc: Olaf Kolkman , Tina Dam , John Klensin , dns directorate Subject: Re: [dns-dir] TLD Names - new draft. X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:08:38 -0000 Hi Liman. Thanks for getting to this! I did a quick read and also think it's good to go for this round. Thomas From liman@autonomica.se Mon Oct 26 16:43:01 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79293A69D1 for ; Mon, 26 Oct 2009 16:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwB6e5lIiJ1Z for ; Mon, 26 Oct 2009 16:43:01 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id B43B33A69BF for ; Mon, 26 Oct 2009 16:43:00 -0700 (PDT) Received: from home.liman.net (2-1-3-18a.spa.sth.bostream.se [82.182.146.229]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n9QNgliV011317; Tue, 27 Oct 2009 00:42:47 +0100 (MET) Received: from zaptop.autonomica.net ([203.229.181.215]) by home.liman.net (8.14.3/8.13.8) with ESMTP id n9QNgcwa005348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Oct 2009 00:42:43 +0100 (MET) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n9QNga8q095870; Tue, 27 Oct 2009 08:42:36 +0900 (KST) To: Thomas Narten References: <911D037AD61A14853F13047F@PST.JCK.COM> <984B5913-6DBF-40C5-94DE-28FBE2EA1A52@NLnetLabs.nl> <200910081247.n98ClaFH022067@cichlid.raleigh.ibm.com> <22iqe2b55l.fsf_-_@zaptop.autonomica.net> <200910262108.n9QL8HK7005046@cichlid.raleigh.ibm.com> From: Lars-Johan Liman Date: Tue, 27 Oct 2009 08:42:36 +0900 In-Reply-To: <200910262108.n9QL8HK7005046@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Tue\, 27 Oct 2009 06\:08\:16 +0900") Message-ID: <22eiop7mdv.fsf@zaptop.autonomica.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Olaf Kolkman , Tina Dam , John Klensin , dns directorate Subject: Re: [dns-dir] TLD Names - new draft. X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 23:43:02 -0000 narten@us.ibm.com: > Hi Liman. > Thanks for getting to this! I did a quick read and also think it's > good to go for this round. OK. It's out there now. Cheers, /Liman From ogud@ogud.com Tue Oct 27 11:29:52 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310FF3A68B7 for ; Tue, 27 Oct 2009 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7xM7i41U8u2 for ; Tue, 27 Oct 2009 11:29:51 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 51B323A6899 for ; Tue, 27 Oct 2009 11:29:51 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9RIU36W087549 for ; Tue, 27 Oct 2009 14:30:03 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 27 Oct 2009 14:30:03 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091027_183003_098186.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-liman-tld-names-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:29:52 -0000 Count: 12 Individual submission L-J. Liman Internet-Draft Autonomica Intended status: Informational October 26, 2009 Expires: April 29, 2010 Top Level Domain Name Specification draft-liman-tld-names-01 Abstract The precise syntax allowed in top-level domain name labels has been the subject to some debate. RFC 1123, for example, makes the statement that top-level domain names are "alphabetic". This document updates the definition of allowable top-level domain names in order to support internationalized domain names (IDNs), as encoded by the IDNA protocols. This document focuses narrowly on the issue of IDNs and does not make any other changes or clarifications to existing domain name syntax rules. From ogud@ogud.com Tue Oct 27 11:46:00 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DF43A69A1 for ; Tue, 27 Oct 2009 11:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RpKZHpdtCSq for ; Tue, 27 Oct 2009 11:45:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5CB563A63EC for ; Tue, 27 Oct 2009 11:45:58 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9RIU0MY087181 for ; Tue, 27 Oct 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 27 Oct 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091027_183001_042025.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-venaas-behave-v4v6mc-framework-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:46:00 -0000 Count: 20 Network Working Group S. Venaas Internet-Draft cisco Systems Intended status: Informational X. Li Expires: April 27, 2010 C. Bao CERNET Center/Tsinghua University October 24, 2009 Framework for IPv4/IPv6 Multicast Translation draft-venaas-behave-v4v6mc-framework-01.txt Abstract This draft describes how IPv4/IPv6 multicast translation may be used in various scenarios and attempts to be a framework for possible solutions. This can be seen as a companion document to the draft "Framework for IPv4/IPv6 translation" by Baker et al. When considering scenarios and solutions for unicast translation, one should also see how they may be extended to provide multicast translation. From ogud@ogud.com Tue Oct 27 11:46:00 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3D03A63EC for ; Tue, 27 Oct 2009 11:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AMKdnhF3D+I for ; Tue, 27 Oct 2009 11:46:00 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DE5AA3A699E for ; Tue, 27 Oct 2009 11:45:59 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9RIU2gg087374 for ; Tue, 27 Oct 2009 14:30:02 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 27 Oct 2009 14:30:02 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20091027_183002_078555.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-kiesel-alto-3pdisc-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:46:00 -0000 Count: 23 ALTO S. Kiesel Internet-Draft NEC Europe Ltd. Intended status: Informational M. Tomsu Expires: April 29, 2010 Alcatel-Lucent Bell Labs October 26, 2009 Third-party ALTO server discovery draft-kiesel-alto-3pdisc-01 Abstract The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This document describes why a third-party ALTO server discovery mechanism is required for an important class of applications, namely tracker-based P2P applications. Several solution approaches are classified and evaluated. The conclusion is that further work is required to standardize a protocol and procedures that follow one specific approach. From ogud@ogud.com Tue Oct 27 15:36:40 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9453A680A for ; Tue, 27 Oct 2009 15:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoGWZGq8Bd2w for ; Tue, 27 Oct 2009 15:36:39 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A74463A677C for ; Tue, 27 Oct 2009 15:36:39 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9RMap0b089911 for ; Tue, 27 Oct 2009 18:36:52 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910272236.n9RMap0b089911@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Oct 2009 18:36:01 -0400 To: "Dns Directorate" From: Olafur Gudmundsson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] Meeting in Hiroshima ? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:36:40 -0000 Are we planning Thursday evening or some other time? I need to make sure this does not conflict with a high priority BOF (soccer) Olafur From dromasca@avaya.com Wed Oct 28 03:23:53 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763883A67B6; Wed, 28 Oct 2009 03:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuSfkD9T546d; Wed, 28 Oct 2009 03:23:52 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 51E893A67E4; Wed, 28 Oct 2009 03:23:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,639,1249272000"; d="scan'208";a="188387272" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Oct 2009 06:24:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Oct 2009 06:24:02 -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, 28 Oct 2009 11:24:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Internet Area Working Group (intarea) Thread-Index: AcpXQCyqEqEa1DuBTXyoIcEMmOi3eQAeIoPw From: "Romascanu, Dan (Dan)" To: , , , Subject: [dns-dir] FW: WG Review: Internet Area Working Group (intarea) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:23:53 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, October 27, 2009 10:00 PM To: new-work@ietf.org Subject: WG Review: Internet Area Working Group (intarea)=20 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Internet Area Working Group (intarea) --------------------------------------------------- Current Status: Proposed Working Group Last modified: 2009-10-22 Chairs: TBD Internet Area (int) Directors: Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Ralph Droms Mailing Lists: General Discussion: int-area@ietf.org Subscribe online at: https://www.ietf.org/mailman/listinfo/int-area Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Milestones: Dec 2009 Submission of IPID document to the IESG as PS Mar 2010 Submission of tunneling issues document to the IESG as Info From dromasca@avaya.com Wed Oct 28 03:25:15 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B1D3A6889; Wed, 28 Oct 2009 03:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf3KtvHBoKGO; Wed, 28 Oct 2009 03:25:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2CBEA3A6875; Wed, 28 Oct 2009 03:25:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,639,1249272000"; d="scan'208";a="161579895" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Oct 2009 06:25:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2009 06:25:10 -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, 28 Oct 2009 11:24:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Handover Keying (hokey) Thread-Index: AcpXSI4gdwuwlXVZRzCWaWO5/ULIAgAcD0kQ From: "Romascanu, Dan (Dan)" To: , , , , , Subject: [dns-dir] FW: WG Review: Recharter of Handover Keying (hokey) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:25:15 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, October 27, 2009 11:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of Handover Keying (hokey)=20 A modified charter has been submitted for the Handover Keying (hokey) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Handover Keying (hokey) ------------------------ Last Modified: 2009-10-19 Chair(s): Glen Zorn Tina Tsou (Ting ZOU) =20 Security Area Director(s): Tim Polk Pasi Eronen =20 Security Area Advisor: Tim Polk =20 Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication" or "early authentication". All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in RFC 4962 and RFC 5247. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) Not require changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. Goals and Milestones: Nov 2009 First draft on Local Domain Name Discovery for ERP Nov 2009 First draft on Early Authentication solutions Mar 2010 First draft on Hokey architecture Mar 2010 First draft on NAS-Authenticator Interaction Jul 2010 First draft on revision of RFC 5296 Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 Submit the Early Authentication solutions draft to IESG Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 Submit the Hokey architecture draft to IESG Nov 2011 Submit the revision of RFC 5296 to IESG Mar 2012 Re-charter or shut down WG