From peter@denic.de Mon Aug 3 03:36: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 E6AC83A6A36 for ; Mon, 3 Aug 2009 03:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.916 X-Spam-Level: X-Spam-Status: No, score=-6.916 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, 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 LDBhMSaCTg6a for ; Mon, 3 Aug 2009 03:36:07 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 23D073A6A13 for ; Mon, 3 Aug 2009 03:36:06 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MXutf-0002BB-KA; Mon, 03 Aug 2009 12:36:03 +0200 Received: from localhost by x27.adm.denic.de with local id 1MXutf-0001Um-Gl; Mon, 03 Aug 2009 12:36:03 +0200 Date: Mon, 3 Aug 2009 12:36:03 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20090803103603.GF1362@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [dns-dir] Rescheduling DNS-Dir conf call 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, 03 Aug 2009 10:36:08 -0000 Dear DNS Directorate Members, since today is the first Monday of the month, there would be a regular DNS Directorate conf call. However, even though we didn't succeed to find a "quiet" place during Thursday's event, it is probably too close to the recent face to face meeting. I'd like to suggest we re-schedule to Monday, 17 August 2009 1400 UTC Please let me know suggestions for agenda items by next Monday. Thanks! Best regards, Peter From ajs@shinkuro.com Wed Aug 5 01:59:39 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 2D26128C3AA for ; Wed, 5 Aug 2009 01:59:39 -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 4CAO8mxXJuKb for ; Wed, 5 Aug 2009 01:59:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id DF8F53A6B45 for ; Wed, 5 Aug 2009 01:59:35 -0700 (PDT) Received: from crankycanuck.ca (unknown [59.163.69.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3037C2FE8FD3 for ; Wed, 5 Aug 2009 08:59:10 +0000 (UTC) Date: Wed, 5 Aug 2009 04:59:07 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090805085906.GB7528@shinkuro.com> References: <20090803103603.GF1362@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090803103603.GF1362@x27.adm.denic.de> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 05 Aug 2009 08:59:39 -0000 I can make this. I don't have anything for the agenda. On Mon, Aug 03, 2009 at 12:36:03PM +0200, Peter Koch wrote: > Dear DNS Directorate Members, > > since today is the first Monday of the month, there would be a regular > DNS Directorate conf call. However, even though we didn't succeed to find a > "quiet" place during Thursday's event, it is probably too close to the recent > face to face meeting. I'd like to suggest we re-schedule to > > Monday, 17 August 2009 1400 UTC > > Please let me know suggestions for agenda items by next Monday. Thanks! > > Best regards, > Peter > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dromasca@avaya.com Wed Aug 5 02:01: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 135C23A707A for ; Wed, 5 Aug 2009 02:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 FbanVJkg9+jQ for ; Wed, 5 Aug 2009 02:01:31 -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 185583A6B45 for ; Wed, 5 Aug 2009 02:01:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,327,1246852800"; d="scan'208";a="169246100" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 05 Aug 2009 05:01:33 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Aug 2009 05:01:32 -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, 5 Aug 2009 11:00:58 +0200 Message-ID: In-Reply-To: <20090805085906.GB7528@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Rescheduling DNS-Dir conf call thread-index: AcoVqx6tz+E/yk6bQc6xSLAfcCDTNAAABUtQ References: <20090803103603.GF1362@x27.adm.denic.de> <20090805085906.GB7528@shinkuro.com> From: "Romascanu, Dan (Dan)" To: "Andrew Sullivan" , Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 05 Aug 2009 09:01:32 -0000 I will be on vacation on 8/17.=20 Regards, Dan =20 > -----Original Message----- > From: dns-dir-bounces@ietf.org=20 > [mailto:dns-dir-bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Wednesday, August 05, 2009 11:59 AM > To: dns-dir@ietf.org > Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call >=20 > I can make this. I don't have anything for the agenda. >=20 > On Mon, Aug 03, 2009 at 12:36:03PM +0200, Peter Koch wrote: > > Dear DNS Directorate Members, > >=20 > > since today is the first Monday of the month, there would=20 > be a regular=20 > > DNS Directorate conf call. However, even though we didn't=20 > succeed to=20 > > find a "quiet" place during Thursday's event, it is=20 > probably too close=20 > > to the recent face to face meeting. I'd like to suggest we=20 > > re-schedule to > >=20 > > Monday, 17 August 2009 1400 UTC > >=20 > > Please let me know suggestions for agenda items by next=20 > Monday. Thanks! > >=20 > > Best regards, > > Peter > > _______________________________________________ > > dns-dir mailing list > > dns-dir@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-dir >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir >=20 From jlentini@netapp.com Wed Aug 5 07:50: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 E68D33A694F; Wed, 5 Aug 2009 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 cNLcqpDIvv45; Wed, 5 Aug 2009 07:50:07 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 2BA5828C502; Wed, 5 Aug 2009 07:49:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,329,1246863600"; d="scan'208";a="218742160" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Aug 2009 07:49:51 -0700 Received: from jlentini-linux.nane.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n75EnoUt006414; Wed, 5 Aug 2009 07:49:50 -0700 (PDT) Date: Wed, 5 Aug 2009 10:49:48 -0400 (EDT) From: James Lentini X-X-Sender: jlentini@jlentini-linux.nane.netapp.com To: dns-dir@ietf.org Message-ID: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 06 Aug 2009 02:32:58 -0700 Cc: Craig Everhart , nfsv4@ietf.org, Lars Eggert Subject: [dns-dir] Request for review of NFSv4 DNS SRV 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: Wed, 05 Aug 2009 14:50:08 -0000 Hello, At the NFSv4 WG meeting last week, Lars directed us to obtain a review of http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt by the DNS Directorate. This draft along with the NFSv4 WG drafts "Requirements for Federated File Systems", "NSDB Protocol for Federated Filesystems", and "Administration Protocol for Federated Filesystems" define FedFS, a system for creating a federated namespaces across NFSv4 servers. A WG last call on these drafts is scheduled for October. We look forward to your feedback on our use of DNS in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01. -james -- James Lentini | NetApp | 781-768-5359 | jlentini@netapp.com From dromasca@avaya.com Thu Aug 6 02:35:57 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 DC2103A6859 for ; Thu, 6 Aug 2009 02:35:57 -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 4erUC5x0uTjP for ; Thu, 6 Aug 2009 02:35:57 -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 2D9A93A690E for ; Thu, 6 Aug 2009 02:35:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,332,1246852800"; d="scan'208";a="179197480" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Aug 2009 05:36:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Aug 2009 05:35:59 -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: Thu, 6 Aug 2009 11:35:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for subscription to dns-dir thread-index: AcoWeUHDd1onhHnnS7SzKeX+0zuN+Q== From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] Request for subscription to dns-dir 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, 06 Aug 2009 09:35:57 -0000 We have a request to subscribe to the DNS-DIR mail list pending from James Lentini. As far as I understand this list is restricted to directorate members. Did anybody discuss with James about becoming a member of DNS-DIR?=20 Thanks and Regards, Dan From dromasca@avaya.com Fri Aug 7 02:37: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 91F3D28C0EC; Fri, 7 Aug 2009 02:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 tgFa0gGi46ZT; Fri, 7 Aug 2009 02:37:22 -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 60C8E28C147; Fri, 7 Aug 2009 02:37:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,341,1246852800"; d="scan'208";a="179319332" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Aug 2009 05:37:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 07 Aug 2009 05:37:24 -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, 7 Aug 2009 11:37:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for August 13, 2009 Telechat thread-index: AcoW5p+XfxQA88oGQnq1/FMZJbkC9AAW4gaA From: "Romascanu, Dan (Dan)" To: , , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for August 13, 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, 07 Aug 2009 09:37:23 -0000 Please find below the preliminary agenda of the 8/13 IESG telechat. Please send your comments, questions, and concerns before 8/12 COB.=20 Thanks and Regards, Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-rmt-bb-lct-revised-10.txt Layered Coding Transport (LCT) Building Block (Proposed Standard) - 1 of 12=20 Token: Magnus Westerlund o draft-ietf-sieve-mime-loop-09.txt Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement=20 and Enclosure (Proposed Standard) - 2 of 12=20 Note: Alexey Melnikov is the document=20 shepherd for this document.=20 Token: Lisa Dusseault o draft-ietf-mpls-ldp-end-of-lib-03.txt LDP End-of-LIB (Proposed Standard) - 3 of 12=20 Note: Proto write-up has been revised. Make sure to use new version. Token: Adrian Farrel o draft-ietf-netconf-partial-lock-09.txt Partial Lock RPC for NETCONF (Proposed Standard) - 4 of 12=20 Token: Dan Romascanu o draft-ietf-nea-pa-tnc-04.txt PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC (Proposed=20 Standard) - 5 of 12=20 Token: Tim Polk o draft-ietf-nea-pb-tnc-04.txt PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC (Proposed Standard) - 6 of 12=20 Token: Tim Polk o draft-ietf-dime-diameter-qos-11.txt Diameter Quality of Service Application (Proposed Standard) - 7 of 12 Note: Victor Fajardo [vfajardo@tari.toshiba.com] is the document shepherd=20 for this document.=20 Token: Dan Romascanu o draft-ietf-opsawg-syslog-snmp-04.txt Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG=20 Messages (Proposed Standard) - 8 of 12=20 Note: Scott Bradner (sob@harvard.edu) is the document shepherd.=20 Token: Dan Romascanu o draft-ietf-opsawg-syslog-msg-mib-05.txt Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (Proposed Standard) - 9 of=20 12=20 Note: Scott Bradner (sob@harvard.edu) is the document shepherd.=20 Token: Dan Romascanu o draft-ietf-l3vpn-as4octet-ext-community-03.txt Four-octet AS Specific BGP Extended Community (Proposed Standard) - 10 of=20 12=20 Token: Ross Callon o draft-ietf-mpls-tp-requirements-09.txt MPLS-TP Requirements (Proposed Standard) - 11 of 12=20 Note: Loa Andersson (loa@pi.nu) is the document shepherd.=20 Token: Adrian Farrel o draft-ietf-l3vpn-v6-ext-communities-02.txt IPv6 Address Specific BGP Extended Communities Attribute (Proposed=20 Standard) - 12 of 12=20 Token: Ross Callon 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-iana-rfc3330bis-07.txt Special Use IPv4 Addresses (BCP) - 1 of 2=20 Token: Russ Housley o draft-freed-sieve-in-xml-05.txt Sieve Email Filtering: Sieves and display directives in XML (Proposed Standard) - 2 of 2=20 Note: Cyrus Daboo is the document shepherd. This=20 is a Sieve WG document, despite the name..=20 Token: Lisa Dusseault 2.2.2 Returning Item o draft-housley-iesg-rfc3932bis-07.txt IESG Procedures for Handling of Independent and IRTF Stream Submissions=20 (BCP) - 1 of 2=20 Note: There is no document shepherd=20 Token: Jari Arkko o draft-dusseault-impl-reports-04.txt Guidance on Interoperation and Implementation Reports for Advancement to=20 Draft Standard (BCP) - 2 of 2=20 Token: Tim Polk 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-behave-nat-behavior-discovery-07.txt NAT Behavior Discovery Using STUN (Experimental) - 1 of 3=20 Token: Magnus Westerlund o draft-ietf-ipfix-export-per-sctp-stream-03.txt IPFIX Export per SCTP Stream (Informational) - 2 of 3=20 Token: Dan Romascanu o draft-ietf-pwe3-mpls-transport-04.txt Application of Ethernet Pseudowires to MPLS Transport Networks=20 (Informational) - 3 of 3=20 Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document =20 shepherd=20 Token: Ralph Droms 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-iana-special-ipv4-registry-01.txt IANA IPv4 Special Purpose Address Registry (Informational) - 1 of 1=20 Token: Russ Housley 3.2.2 Returning Item o draft-housley-tls-authz-extns-07.txt Transport Layer Security (TLS) Authorization Extensions (Experimental) - 1=20 of 1=20 Token: Tim Polk 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 NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Mobility for IPv4 (mip4) - 1 of 1 Token: Jari Arkko From ogud@ogud.com Sat Aug 15 11:30:03 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 73CB03A6E7C for ; Sat, 15 Aug 2009 11:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 DGv2H3odyKYA for ; Sat, 15 Aug 2009 11:30:02 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9EA723A6963 for ; Sat, 15 Aug 2009 11:29: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 n7FIU1N3047888 for ; Sat, 15 Aug 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sat, 15 Aug 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: <20090815_183001_077941.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-barwood-dnsext-edns-page-option-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, 15 Aug 2009 18:30:03 -0000 Count: 19 DNS Extensions Working Group G. Barwood Internet-Draft Intended status: Standards track 15 August 2009 Expires: February 2010 EDNS Page Option draft-barwood-dnsext-edns-page-option-00 Abstract Describes an EDNS option to allow large DNS responses to be sent using small UDP packets. From erik.nordmark@sun.com Sun Aug 16 20:31: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 C09B73A6956 for ; Sun, 16 Aug 2009 20:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.807 X-Spam-Level: X-Spam-Status: No, score=-4.807 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, 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 bBcZzVv9leDS for ; Sun, 16 Aug 2009 20:31:58 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 102F23A6932 for ; Sun, 16 Aug 2009 20:31:57 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7H3Vw0Q027968; Mon, 17 Aug 2009 03:31:58 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7H3VqFs484537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 20:31:58 -0700 (PDT) Message-ID: <4A88CF28.8050403@sun.com> Date: Sun, 16 Aug 2009 20:31:52 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090623) MIME-Version: 1.0 To: Peter Koch References: <20090803103603.GF1362@x27.adm.denic.de> In-Reply-To: <20090803103603.GF1362@x27.adm.denic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DNS Directorate Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 17 Aug 2009 03:31:58 -0000 Peter Koch wrote: > Dear DNS Directorate Members, > > since today is the first Monday of the month, there would be a regular > DNS Directorate conf call. However, even though we didn't succeed to find a > "quiet" place during Thursday's event, it is probably too close to the recent > face to face meeting. I'd like to suggest we re-schedule to > > Monday, 17 August 2009 1400 UTC > > Please let me know suggestions for agenda items by next Monday. Thanks! Are we having a call tomorrow? I haven't seen any agenda. Erik From roy@dnss.ec Mon Aug 17 02:01:02 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 A51AF28C17D for ; Mon, 17 Aug 2009 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_40=-0.185, HELO_EQ_SE=0.35, MANGLED_FREE=2.3] 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 j3zTWk+0734B for ; Mon, 17 Aug 2009 02:01:02 -0700 (PDT) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id E6E1628C193 for ; Mon, 17 Aug 2009 02:01:01 -0700 (PDT) Received: from [127.0.0.1] (a82-94-105-58.adsl.xs4all.nl [82.94.105.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id 85E1B2DADB for ; Mon, 17 Aug 2009 11:01:04 +0200 (MEST) Message-Id: From: Roy Arends To: IETF DNS Directorate Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 11:01:03 +0200 X-Mailer: Apple Mail (2.936) Subject: [dns-dir] 2009-08-17 1400-UTC DNS Directorate conf call logistics 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, 17 Aug 2009 09:01:02 -0000 Hi all, Apologies for the late announcement. Please use the following for todays DNS-DIR conference call at 1400 UTC. US (east) +1 7183541169 US (west) +1 4089616553 NL +31 202013852 UK +44 2078193600 FR +33 171230055 SE +46 858536827 CA 18667425608 FI +358 969379595 DE +49 6950070811 IL (toll free) 1809435186 Conference Code: 4227104 Kind regards, Roy Arends Nominet UK From rdroms@cisco.com Mon Aug 17 03:21: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 A4F613A6D19 for ; Mon, 17 Aug 2009 03:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.294 X-Spam-Level: X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599, MANGLED_FREE=2.3, 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 LITOo8GW17aS for ; Mon, 17 Aug 2009 03:21:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8D8503A6C6D for ; Mon, 17 Aug 2009 03:21:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACfMiEpAZnmf/2dsb2JhbAC9JIgtjnMFgisBEIFdihs X-IronPort-AV: E=Sophos;i="4.43,395,1246838400"; d="scan'208";a="54360345" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2009 10:21:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7HALal4032676; Mon, 17 Aug 2009 06:21:36 -0400 Received: from bxb-rdroms-8714.cisco.com (bxb-rdroms-8714.cisco.com [10.98.10.85]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7HALUTI011807; Mon, 17 Aug 2009 10:21:35 GMT Message-Id: <97C11525-A0A7-47A7-8FFF-228CA1320140@cisco.com> From: Ralph Droms To: Roy Arends In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 17 Aug 2009 06:21:25 -0400 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=741; t=1250504496; x=1251368496; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dns-dir]=202009-08-17=201400-UTC=20DNS =20Directorate=20conf=20call=20logistics |Sender:=20 |To:=20Roy=20Arends=20; bh=9rbEuUjAJ3JREFbfn7RO4qt2PiQ/SC9c2kXeWOSYs9Q=; b=ajmZd7sXgW6qCylocdiAB65xV0Xjz9FLwI+enGaFSfQzhRv0lsqkWQnC3k mPmL1fmvtGZvORZFtlI/r9lXy3V7tSuw/vjPCGoTyZ58+Z7BVB1dxZFhjAdB WOmSuT2TU+; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF DNS Directorate Subject: Re: [dns-dir] 2009-08-17 1400-UTC DNS Directorate conf call logistics 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, 17 Aug 2009 10:21:32 -0000 I have a conflict at 1400 UTC today and won't be able to join the call. - Ralph On Aug 17, 2009, at 5:01 AM 8/17/09, Roy Arends wrote: > Hi all, > > Apologies for the late announcement. > > Please use the following for todays DNS-DIR conference call at 1400 > UTC. > > US (east) +1 7183541169 > US (west) +1 4089616553 > NL +31 202013852 > UK +44 2078193600 > FR +33 171230055 > SE +46 858536827 > CA 18667425608 > FI +358 969379595 > DE +49 6950070811 > IL (toll free) 1809435186 > > Conference Code: 4227104 > > Kind regards, > > Roy Arends > Nominet UK > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From peter@denic.de Mon Aug 17 06:28: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 0C0B23A6BAB for ; Mon, 17 Aug 2009 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, MANGLED_FREE=2.3, 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 GfifSWvTbWBV for ; Mon, 17 Aug 2009 06:28:23 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 3EAB43A6A05 for ; Mon, 17 Aug 2009 06:28:23 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Md2G8-0005lT-07; Mon, 17 Aug 2009 15:28:24 +0200 Received: from localhost by x27.adm.denic.de with local id 1Md2G7-0004w3-ST; Mon, 17 Aug 2009 15:28:23 +0200 Date: Mon, 17 Aug 2009 15:28:23 +0200 From: Peter Koch To: Erik Nordmark Message-ID: <20090817132823.GB16825@x27.adm.denic.de> References: <20090803103603.GF1362@x27.adm.denic.de> <4A88CF28.8050403@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A88CF28.8050403@sun.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: IETF DNS Directorate Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 17 Aug 2009 13:28:24 -0000 On Sun, Aug 16, 2009 at 08:31:52PM -0700, Erik Nordmark wrote: > Are we having a call tomorrow? > I haven't seen any agenda. for now I'd only have 0) Adminstrivia 1) IETF 75 review - new DNS drafts? - DNS Dir review requested SIP UA config I'd suggest we try this as a starter. Here's the call data as circulated by Roy (thanks, Roy+Nominet!) US (east) +1 7183541169 US (west) +1 4089616553 NL +31 202013852 UK +44 2078193600 FR +33 171230055 SE +46 858536827 CA 18667425608 FI +358 969379595 DE +49 6950070811 IL (toll free) 1809435186 Conference Code: 4227104 -Peter From ajs@shinkuro.com Mon Aug 17 06:48:20 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 D4BEC3A6EC5 for ; Mon, 17 Aug 2009 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_FREE=2.3] 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 QTYFPoyVPjFB for ; Mon, 17 Aug 2009 06:48:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2D6CD3A6B7F for ; Mon, 17 Aug 2009 06:48:20 -0700 (PDT) Received: from [192.168.1.3] (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 763502FE8ED5; Mon, 17 Aug 2009 13:48:24 +0000 (UTC) From: Andrew Sullivan To: Peter Koch In-Reply-To: <20090817132823.GB16825@x27.adm.denic.de> X-Mailer: iPhone Mail (7A400) References: <20090803103603.GF1362@x27.adm.denic.de> <4A88CF28.8050403@sun.com> <20090817132823.GB16825@x27.adm.denic.de> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A400) Date: Mon, 17 Aug 2009 09:47:34 -0400 Cc: IETF DNS Directorate Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 17 Aug 2009 13:48:20 -0000 I've had a sudden conflict & will probably be late. Andrew Sullivan ajs@shinkuro.com On 2009-08-17, at 9:28, Peter Koch wrote: > On Sun, Aug 16, 2009 at 08:31:52PM -0700, Erik Nordmark wrote: > >> Are we having a call tomorrow? >> I haven't seen any agenda. > > for now I'd only have > > 0) Adminstrivia > 1) IETF 75 review > - new DNS drafts? > - DNS Dir review requested > SIP UA config > > I'd suggest we try this as a starter. > > Here's the call data as circulated by Roy (thanks, Roy+Nominet!) > US (east) +1 7183541169 > US (west) +1 4089616553 > NL +31 202013852 > UK +44 2078193600 > FR +33 171230055 > SE +46 858536827 > CA 18667425608 > FI +358 969379595 > DE +49 6950070811 > IL (toll free) 1809435186 > > Conference Code: 4227104 > > -Peter > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From ajs@shinkuro.com Mon Aug 17 07:30: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 B752C3A6B13 for ; Mon, 17 Aug 2009 07:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 wv8+xi5BAr8X for ; Mon, 17 Aug 2009 07:30:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 04FC03A672E for ; Mon, 17 Aug 2009 07:30:35 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 436D62FE8ED5 for ; Mon, 17 Aug 2009 14:30:39 +0000 (UTC) Date: Mon, 17 Aug 2009 10:30:34 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090817143034.GA1947@shinkuro.com> References: <20090803103603.GF1362@x27.adm.denic.de> <4A88CF28.8050403@sun.com> <20090817132823.GB16825@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 17 Aug 2009 14:30:35 -0000 On Mon, Aug 17, 2009 at 09:47:34AM -0400, Andrew Sullivan wrote: > I've had a sudden conflict & will probably be late. Or not make it at all, I gather, since there was only music when I dialled in. Apologies all. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From peter@denic.de Mon Aug 17 07:37: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 397733A6EEC for ; Mon, 17 Aug 2009 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, 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 vUxTreKsFecf for ; Mon, 17 Aug 2009 07:37:53 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 572793A6EDF for ; Mon, 17 Aug 2009 07:37:53 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Md3LQ-0006X2-UO; Mon, 17 Aug 2009 16:37:56 +0200 Received: from localhost by x27.adm.denic.de with local id 1Md3LQ-0005Tt-QW; Mon, 17 Aug 2009 16:37:56 +0200 Date: Mon, 17 Aug 2009 16:37:56 +0200 From: Peter Koch To: Andrew Sullivan Message-ID: <20090817143756.GA20904@x27.adm.denic.de> References: <20090803103603.GF1362@x27.adm.denic.de> <4A88CF28.8050403@sun.com> <20090817132823.GB16825@x27.adm.denic.de> <20090817143034.GA1947@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090817143034.GA1947@shinkuro.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: dns-dir@ietf.org Subject: Re: [dns-dir] Rescheduling DNS-Dir conf call 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, 17 Aug 2009 14:37:54 -0000 On Mon, Aug 17, 2009 at 10:30:34AM -0400, Andrew Sullivan wrote: > On Mon, Aug 17, 2009 at 09:47:34AM -0400, Andrew Sullivan wrote: > > I've had a sudden conflict & will probably be late. > > Or not make it at all, I gather, since there was only music when I > dialled in. Apologies all. Erik and me decided to adjourn at around 14:15 UTC There were no issues on the agenda that called for immediate attention, but we might want to collect the DNS related "new" issues from the Stockholm IETF nonetheless. We have three regular calls before IETF76: 2009-09-07 2009-10-05 (may conflict with RIPE59 for some) 2009-11-02 2009-11-12 IETF Thursday Dinner -Peter From narten@us.ibm.com Tue Aug 18 12:54:41 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 E98643A6C34; Tue, 18 Aug 2009 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 xPTixHsYZW5x; Tue, 18 Aug 2009 12:54:40 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 4D7973A6C76; Tue, 18 Aug 2009 12:54:40 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7IJkiLA019246; Tue, 18 Aug 2009 15:46:44 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7IJsi46255190; Tue, 18 Aug 2009 15:54:44 -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 n7IJpopM027944; Tue, 18 Aug 2009 15:51:50 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-128-186.mts.ibm.com [9.76.128.186]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7IJpaGl027132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 15:51:46 -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 n7IJsR8j032723; Tue, 18 Aug 2009 15:54:28 -0400 Message-Id: <200908181954.n7IJsR8j032723@cichlid.raleigh.ibm.com> To: James Lentini In-reply-to: References: Comments: In-reply-to James Lentini message dated "Wed, 05 Aug 2009 10:49:48 -0400." Date: Tue, 18 Aug 2009 15:54:27 -0400 From: Thomas Narten Cc: Craig Everhart , dns-dir@ietf.org, Lars Eggert , nfsv4@ietf.org Subject: Re: [dns-dir] Request for review of NFSv4 DNS SRV 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: Tue, 18 Aug 2009 19:54:42 -0000 Here are my review comments on this document. I am also not subscribed to the nfsv4 list, so please cc me in responses. Note: I'm reviewing this mostly from a DNS perspective and what little I know about NFS goes pretty far back. So some of my questions/concerns may stem from a lack of understanding of NFSv4. > [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 > Migration/Replication", October 2005, internet-drafts/draft-noveck-nfsv4-migrep-00.txt>. This reference seems pretty important to this document. Yet the document is 4 years old and expired. What is the status of it? Does it make sense to advance this document without the reference? Or has it been replaced by a newer document? > 3.1. Deployment of the Resource Record > > As with any DNS resource, any server installation needs to concern > itself with the likely loads and effects of the presence of the > resource record. The answers to requests for RRs might differ > depending on what the server can tell about the client. For example, > some RRs might be returned only to those clients inside some network > perimeter (to provide an intranet service) and requests from other > clients might be denied. As the RR directs the clients to ask for > service from a given set of servers, the administrator should ensure > that the identified servers can handle the expected load. > Fortunately, the definition of the DNS SRV resource record offers a > mechanism to distribute the load to multiple servers within a > priority ordering. The above makes me a little nervous, but maybe I'm missreading the intention. From a DNS point of view, it is generally frowned upon to return differing answers to a DNS query depending on criteria (like the above). (I know there are DNS load balancers that do that, but they only work if one disables DNS caching, etc.). Besides, the above doesn't really buy you much. Isn't the better place to perform access control on the server itself when a client attempts to contact it? Is that what you really mean to happen above? > 4. Integration with Use of NFS Version 4 > > There are at least two remaining questions: whether this DNS SRV > record evaluation is done in the NFS server or client, and also how > the domain names of the organizations are passed to client or server. > A third question is how this might produce a uniform global file name > space, and what prefix should be used for such file names. I don't get the first question. SRV processing is always done by the client (the requestor). The NFS server does nothing... The DNS server does respond to the DNS queries, but the NFS server is not involved in that.... Also, what does the last sentence (referring to "what prefix should be used") mean? > This specification anticipates that these SRV records will most > commonly be used to define the second directory level in an inter- > organizational file name space. This directory will be populated > with domain names pointing to the file systems published for use > under those domain names. Thus, the root directory for the file > system published by example.net will effectively be mounted > underneath the example.net name in a second-level directory. I don't really understand this part at all. The SRV resolution will convert an SRV into a machine name (and eventually an address) and port number. That is what the client contacts. But you are talking about "mounting". What exactly does the client pass to the server in the mount request? Doesn't that need to be specified here? I also don't understand what "second-level directory" means or why anything needs to be said. (This probably just reflects my ignorance about NFS mounts.) What does it mean to populate a directory with DNS names? > Thus, the root directory for the file system published by > example.net will effectively be mounted underneath the > example.net name in a second-level directory. Going back to your example, the SRVs point to nfs2ex.example.net. So it doesn't seem right to say (above) "will effectively be mounted underneath the example.net name..." I don't understand what you are trying to say here. > 4.1. Globally-useful names: conventional mount point > > For the inter-organizational name space to be a global name space, it > is useful for its mount point in local systems to be uniform as well. > The name /nfs4/ SHOULD be used so that names on one machine will be > directly usable on any machine. Thus, the example.net published file > system would be accessible as > > /nfs4/example.net/ > > on any client. Using this convention, "/nfs4/" is a mount for a > special file system that is populated with the results of SRV record > lookups. I don't understand the above at all. Are you getting into NFS implementation details that are uniform and well known? Does NFS have a well-known name space where /nfs4/foo.com/ would have the second component recognized to be a a DNS name? Where is this specified? > One extension of this rule that we might choose to inherit from AFS, > though, is to give a special meaning to the domain name of an > organization preceded by a period ("."). It might be reasonable to > have names mounting the filesystem for a period-prefixed domain name > (e.g., ".example.net") attempt to mount only a read-write instance of > that organization's root filesystem, rather than permitting the use > of read-only instances of that filesystem. Thus, Seems like a bad idea.. You are using non compliant DNS names... > 4.3. File system integration issues > > The result of the DNS search SHOULD appear as a (pseudo-)directory in > the client name space, cached for a time no longer than the RR's TTL. > A further refinement is advisable, and SHOULD be deployed: that only > fully-qualified domain names appear as directories. That is, in many The above seems at odds with the documents earlier support for using short TTLs in order to return client-specific results. And, when the TTL expires, what is supposed to happen? > environments, DNS names may be abbreviated from their fully-qualified > form. In such circumstances, multiple names might be given to file > system code that all resolve to the same DNS SRV RRs. The > abbreviated form SHOULD be represented in the client's name space > cache as a symbolic link, pointing to the fully-qualified name, case- > canonicalized when appropriate. This seem like it would be hard for clients to implement, since the DNS algorithm (which may append various names as part of trying to resolve the query) are not done by the client directly, but as part of more generic DNS routines. Is this really feasible to implement? And how is the above problem worse with SRV records than it is today when the DNS name of the server is given? Is the "name space cache" something very specific to NFS? > This will allow pathnames obtained > with, say, getcwd() to include the DNS name that is most likely to be > usable outside the scope of any particular DNS abbreviation > convention. > 5. Where is this integration carried out? > > Another consideration is what agent should be responsible for > interpreting the SRV records. It could be done just as well by the > client or by the server, though we expect that most clients will > include this function themselves. Using something like Automounter I am very worried that this documen seems to have some pretty basic misconceptions about DNS/SRVs. NFS servers DO NOT interpret SRV records... only clients do that... Thomas From Nicolas.Williams@sun.com Tue Aug 18 14:14:30 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 5577E3A6B37; Tue, 18 Aug 2009 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ipwqVRMCUWyM; Tue, 18 Aug 2009 14:14:28 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 916BC28C3AC; Tue, 18 Aug 2009 14:14:14 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7ILEBAG015219; Tue, 18 Aug 2009 21:14:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7ILEBNC065273; Tue, 18 Aug 2009 15:14:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7IL3Qq6003665; Tue, 18 Aug 2009 16:03:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7IL3Pp8003664; Tue, 18 Aug 2009 16:03:25 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 18 Aug 2009 16:03:25 -0500 From: Nicolas Williams To: Thomas Narten Message-ID: <20090818210325.GT1043@Sun.COM> References: <200908181954.n7IJsR8j032723@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908181954.n7IJsR8j032723@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.7i X-Mailman-Approved-At: Wed, 19 Aug 2009 21:30:24 -0700 Cc: James Lentini , dns-dir@ietf.org, nfsv4@ietf.org Subject: Re: [dns-dir] [nfsv4] Request for review of NFSv4 DNS SRV 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: Tue, 18 Aug 2009 21:14:30 -0000 On Tue, Aug 18, 2009 at 03:54:27PM -0400, Thomas Narten wrote: > > [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 > > Migration/Replication", October 2005, > internet-drafts/draft-noveck-nfsv4-migrep-00.txt>. > > This reference seems pretty important to this document. Yet the > document is 4 years old and expired. What is the status of it? Does it > make sense to advance this document without the reference? Or has it > been replaced by a newer document? It's informational. The referral mechanism in NFSv4 was originally conceived as a way to indicate to clients that a filesystem migrated to a different location, and later it was recognized that this mechanism could be used to form a "global namespace", quite independently of migration and replication. > > 3.1. Deployment of the Resource Record > > > > As with any DNS resource, any server installation needs to concern > > itself with the likely loads and effects of the presence of the > > resource record. The answers to requests for RRs might differ > > depending on what the server can tell about the client. For example, > > some RRs might be returned only to those clients inside some network > > perimeter (to provide an intranet service) and requests from other > > clients might be denied. [...] > > The above makes me a little nervous, but maybe I'm missreading the > intention. From a DNS point of view, it is generally frowned upon to > return differing answers to a DNS query depending on criteria (like > the above). (I know there are DNS load balancers that do that, but > they only work if one disables DNS caching, etc.). Well, people do tend to keep fake DNS roots inside their perimeters, with different zone file contents inside and outside. I agree with you that this I-D should really not mention that. For load balancing the SRV RR weight and priority RDATA fields should suffice. > Besides, the above doesn't really buy you much. Isn't the better place > to perform access control on the server itself when a client attempts > to contact it? I didn't read that text as being about access control at all, but about separating "inside" and "outside" namespaces, infrastructures. But I agree that it seems completely out of place. > > 4. Integration with Use of NFS Version 4 > > > > There are at least two remaining questions: whether this DNS SRV > > record evaluation is done in the NFS server or client, and also how > > the domain names of the organizations are passed to client or server. > > A third question is how this might produce a uniform global file name > > space, and what prefix should be used for such file names. > > I don't get the first question. SRV processing is always done by the > client (the requestor). The NFS server does nothing... The DNS server > does respond to the DNS queries, but the NFS server is not involved in > that.... I think the idea is that servers could dynamically generate NFSv4 referrals on the basis of these SRV RRs. Consider this example: - client A mounts B:/foo on /bar - B:/foo/ is a "magic" directory in that all names looked up in it are treated as domainnames, their corresponding SRV RRs are looked up, and, if found, referrals are instantiated with those domainnames as their name. So when the client looks for /bar/baz.example/a/b/c the _nfs4._tcp.baz.example SRV RR is looked up by the _server_. Clients could also implement a similar magic directory, in which case it's the _clients_ that do the SRV RR lookup. (If you've ever used a /net/ automounter path on a Unix-like system then you know what I mean by "magic". In the /net/ case the automounter interprets all names looked up in it as hostnames, and tries to mount :/ on /net/. The same thing would happen here, only with names interpreted as domain names and resolved to server names via the _nfs4 SRV RR. In the Windows world the closest equivalent to /net/ would be UNCs.) > Also, what does the last sentence (referring to "what prefix should be > used") mean? I believe it refers to the /net/ automounter path. On Unix-like systems it is quite common that /net/ is as described above. Now, where should the new magic directory get mounted? On /domain/? /dom/?? It's a local matter. Therefore this I-D has little business specifying it, but since we're going to want to converge on a common convention, it does make sense to make a recommendation (in this case /nfs4/). I'm not sure that I really like /nfs4/ for this -- as a user I really could care less what protocol is being used to get to some file... But I don't really have a better recommendation either. > > This specification anticipates that these SRV records will most > > commonly be used to define the second directory level in an inter- > > organizational file name space. This directory will be populated > > with domain names pointing to the file systems published for use > > under those domain names. Thus, the root directory for the file > > system published by example.net will effectively be mounted > > underneath the example.net name in a second-level directory. > > I don't really understand this part at all. The SRV resolution will > convert an SRV into a machine name (and eventually an address) and > port number. That is what the client contacts. But you are talking > about "mounting". What exactly does the client pass to the server in > the mount request? Doesn't that need to be specified here? There's no "mount request". > I also don't understand what "second-level directory" means or why > anything needs to be said. (This probably just reflects my ignorance > about NFS mounts.) What does it mean to populate a directory with DNS > names? I *think* they mean that /nfs4/example.net/foo/ will really map to "the filesystem at foo.example.net". But frankly, I find that text confusing too. > > Thus, the root directory for the file system published by > > example.net will effectively be mounted underneath the > > example.net name in a second-level directory. > > Going back to your example, the SRVs point to nfs2ex.example.net. So > it doesn't seem right to say (above) "will effectively be mounted > underneath the example.net name..." I don't understand what you are > trying to say here. I think they mean to say that a server for example.net named, say, foo, will be accessible as /nfs4/example.net/foo -- /nfs4/example.net/ being a magic /net/-like filesystem containing only referrals. The key issue here though is this: say you lookup the _nfs4._tcp SRV RR for example.net and find a list of servers, now, what path from any one of those fileservers should be mounted on /nfs4/example.net?? In the /net/ case the answer to that question is always "/". I.e., /net/foo.example.net/ should be a mount of foo.example.net:/ Section 4.2 is explicit about this: use "the pseudo-root" (meaning "the root FH"). I don't think that's a great answer for this new magic mount, but the SRV RR has no way to tell us what that path should be, so we must pick one. I see the quoted text as getting to that issue in a round-about way, but without actually giving us an answer. I really don't see how the servers for example.net can have two roots: one for clients arriving via an SRV RR lookup, and one for clients arriving as usual. > > 4.1. Globally-useful names: conventional mount point > > > > For the inter-organizational name space to be a global name space, it > > is useful for its mount point in local systems to be uniform as well. > > The name /nfs4/ SHOULD be used so that names on one machine will be > > directly usable on any machine. Thus, the example.net published file > > system would be accessible as > > > > /nfs4/example.net/ > > > > on any client. Using this convention, "/nfs4/" is a mount for a > > special file system that is populated with the results of SRV record > > lookups. > > I don't understand the above at all. Are you getting into NFS > implementation details that are uniform and well known? Does NFS have > a well-known name space where /nfs4/foo.com/ would have the second > component recognized to be a a DNS name? Where is this specified? See above. > > One extension of this rule that we might choose to inherit from AFS, > > though, is to give a special meaning to the domain name of an > > organization preceded by a period ("."). It might be reasonable to > > have names mounting the filesystem for a period-prefixed domain name > > (e.g., ".example.net") attempt to mount only a read-write instance of > > that organization's root filesystem, rather than permitting the use > > of read-only instances of that filesystem. Thus, > > Seems like a bad idea.. You are using non compliant DNS names... I agree. I don't understand the paragraph immediately preceding the one you quote. I think the issue here is that a referral can point to more than one server, so what to do if one is writeable and the others are not? But it gets worse than that: the referral data in the NFSv4 protocol doesn't tell you which is writeable, so to find out the client would have to go test each one. But it gets worse: in NFSv4.0 (RFC3530) there's no way to find out if a filesystem is read-only without actually attempting a write! So, IMO the paragraph immediately preceding the one you quote is wrong. The one you quote is inadvisable, IMO. What should happen is that the client should assume the mount is read-write *if* there's a single location, else the client should assume read-write *if* the client is willing to retry writes against each location until one succeeds, else the client should assume read-only. (The I-D could provide a lot more background, including an *informative* copy of the fs_locations XDR, so that readers who are not familiar with NFSv4 can recognize some of these issues more easily.) > > 4.3. File system integration issues > > > > The result of the DNS search SHOULD appear as a (pseudo-)directory in > > the client name space, cached for a time no longer than the RR's TTL. > > A further refinement is advisable, and SHOULD be deployed: that only > > fully-qualified domain names appear as directories. That is, in many > > The above seems at odds with the documents earlier support for using > short TTLs in order to return client-specific results. And, when the > TTL expires, what is supposed to happen? The path should be unmounted. If the path is busy and can't easily be unmounted then the client should be free to leave it as is and say "oh well". (This happens today in the case of /net/.) > > environments, DNS names may be abbreviated from their fully-qualified > > form. In such circumstances, multiple names might be given to file > > system code that all resolve to the same DNS SRV RRs. The > > abbreviated form SHOULD be represented in the client's name space > > cache as a symbolic link, pointing to the fully-qualified name, case- > > canonicalized when appropriate. > > This seem like it would be hard for clients to implement, since the > DNS algorithm (which may append various names as part of trying to > resolve the query) are not done by the client directly, but as part of > more generic DNS routines. Is this really feasible to implement? IMO this is really referring to the resolver "search" features. I see no reason why it should be difficult to use a resolver search in this context. > And how is the above problem worse with SRV records than it is today > when the DNS name of the server is given? IMO it's not *unless* the client can't cope with mounting the same resource in multiple places on the client-side namespace. But I don't think that's an issue nowadays. > Is the "name space cache" something very specific to NFS? No, it's a local issue (though I don't know where "cache" comes from here). Gathering recommendations for _local_ behavior should be in a separate section would be a good idea. And they should be as OS-agnostic as possible, though even then, POSIX-specific recommendations are a good idea. (And what about Windows? I dunno. Something like network neighborhood needs to be added that knows about this scheme. But we can hardly tell MSFT what to do, whereas in the POSIX case it's much more likely that vendors will follow these recommendations.) > > This will allow pathnames obtained > > with, say, getcwd() to include the DNS name that is most likely to be > > usable outside the scope of any particular DNS abbreviation > > convention. > > > > 5. Where is this integration carried out? > > > > Another consideration is what agent should be responsible for > > interpreting the SRV records. It could be done just as well by the > > client or by the server, though we expect that most clients will > > include this function themselves. Using something like Automounter > > I am very worried that this documen seems to have some pretty basic > misconceptions about DNS/SRVs. NFS servers DO NOT interpret SRV > records... only clients do that... See above. I can certainly see both, clients and servers doing it. I think it's best for clients to do it exclusively, but consider older clients: they won't know how, therefore it'd be useful to have servers that export a "magic" (automounter) directory where the servers do what the client should be doing. IMO the I-D needs wordsmithing. The DNS-based _mechanism_ described is fine, though it has shortcomings: - no way to specify a path - no way to specify read-only vs. read-write (but this is really a local issue) - no way to specify other local options that would nonetheless be very convenient to be able to specify centrally These shortcomings can be dealt with easily enough. Path? -> /. Read-write? -> guess read-write and if you fail, return a suitable error to the app. Other local options? -> use suitable defaults. Nico -- From Craig.Everhart@netapp.com Tue Aug 18 14:47:30 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 2CD2A28C361; Tue, 18 Aug 2009 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 elnsYEipeEzC; Tue, 18 Aug 2009 14:47:28 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 919CA28C206; Tue, 18 Aug 2009 14:47:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,404,1246863600"; d="scan'208";a="227099714" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 18 Aug 2009 14:46:10 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n7ILkA0a016549; Tue, 18 Aug 2009 14:46:10 -0700 (PDT) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 14:46:10 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 17:46:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 17:46:08 -0400 Message-ID: In-Reply-To: <200908181954.n7IJsR8j032723@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Request for review of NFSv4 DNS SRV draft Thread-Index: AcogPcFS7/d88m53QOaoTAcwm03IrwACFdTQ References: <200908181954.n7IJsR8j032723@cichlid.raleigh.ibm.com> From: "Everhart, Craig" To: "Thomas Narten" , "Lentini, James" X-OriginalArrivalTime: 18 Aug 2009 21:46:08.0938 (UTC) FILETIME=[4BC6F0A0:01CA204D] X-Mailman-Approved-At: Wed, 19 Aug 2009 21:30:24 -0700 Cc: dns-dir@ietf.org, Lars Eggert , nfsv4@ietf.org Subject: Re: [dns-dir] Request for review of NFSv4 DNS SRV 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: Tue, 18 Aug 2009 21:47:30 -0000 Thanks for the review, Thomas. My responses are interspersed. > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > Sent: Tuesday, August 18, 2009 3:54 PM > To: Lentini, James > Cc: dns-dir@ietf.org; Everhart, Craig; nfsv4@ietf.org; Lars Eggert > Subject: Re: [dns-dir] Request for review of NFSv4 DNS SRV draft >=20 > Here are my review comments on this document. I am also not=20 > subscribed to the nfsv4 list, so please cc me in responses. >=20 > Note: I'm reviewing this mostly from a DNS perspective and=20 > what little I know about NFS goes pretty far back. So some of=20 > my questions/concerns may stem from a lack of understanding of NFSv4. >=20 > > [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 > > Migration/Replication", October 2005,=20 > > internet-drafts/draft-noveck-nfsv4-migrep-00.txt>. >=20 > This reference seems pretty important to this document. Yet=20 > the document is 4 years old and expired. What is the status=20 > of it? Does it make sense to advance this document without=20 > the reference? Or has it been replaced by a newer document? The NFS4.1 draft, draft-ietf-nfsv4-minorversion1-29, describes replacement functionality. It is in the RFC Ed queue. =20 > > 3.1. Deployment of the Resource Record > >=20 > > As with any DNS resource, any server installation needs=20 > to concern > > itself with the likely loads and effects of the presence of the > > resource record. The answers to requests for RRs might differ > > depending on what the server can tell about the client. =20 > For example, > > some RRs might be returned only to those clients inside=20 > some network > > perimeter (to provide an intranet service) and requests=20 > from other > > clients might be denied. As the RR directs the clients=20 > to ask for > > service from a given set of servers, the administrator=20 > should ensure > > that the identified servers can handle the expected load. > > Fortunately, the definition of the DNS SRV resource=20 > record offers a > > mechanism to distribute the load to multiple servers within a > > priority ordering. >=20 > The above makes me a little nervous, but maybe I'm=20 > missreading the intention. From a DNS point of view, it is=20 > generally frowned upon to return differing answers to a DNS=20 > query depending on criteria (like the above). (I know there=20 > are DNS load balancers that do that, but they only work if=20 > one disables DNS caching, etc.). >=20 > Besides, the above doesn't really buy you much. Isn't the=20 > better place to perform access control on the server itself=20 > when a client attempts to contact it? >=20 > Is that what you really mean to happen above? I'm happy to take the operational advice about DNS. Probably the better answer is to defer to the definition of the SRV record as a mechanism for load balancing. I totally expect that the file servers will perform their own access control; that isn't really what I was concerned about, though. > > 4. Integration with Use of NFS Version 4 > >=20 > > There are at least two remaining questions: whether this DNS SRV > > record evaluation is done in the NFS server or client,=20 > and also how > > the domain names of the organizations are passed to=20 > client or server. > > A third question is how this might produce a uniform=20 > global file name > > space, and what prefix should be used for such file names. >=20 > I don't get the first question. SRV processing is always done=20 > by the client (the requestor). The NFS server does nothing...=20 > The DNS server > does respond to the DNS queries, but the NFS server is=20 > not involved in > that.... Actually, I'm arguing that the NFS server could, architecturally, be the DNS client here. The functionality being described could be implemented by an NFS server. The semantics of the SRV record could be captured in an NFS4/NFS4.1 referral. Even if most of the NFSv4 list currently thinks that the right implementation to use is the client-based one, I feel that it's sensible to describe the NFS-server-based one. Given that it makes semantic sense, is this not appropriate? =20 > Also, what does the last sentence (referring to "what prefix should be > used") mean? The question is what's described below: basically, whether one wants to have a convention for what amounts to the mount point for the directory whose contents are given by all the SRV records. =20 > > This specification anticipates that these SRV records will most > > commonly be used to define the second directory level in=20 > an inter- > > organizational file name space. This directory will be populated > > with domain names pointing to the file systems published for use > > under those domain names. Thus, the root directory for the file > > system published by example.net will effectively be mounted > > underneath the example.net name in a second-level directory. >=20 > I don't really understand this part at all. The SRV=20 > resolution will convert an SRV into a machine name (and=20 > eventually an address) and port number. That is what the=20 > client contacts. But you are talking about "mounting". What=20 > exactly does the client pass to the server in the mount=20 > request? Doesn't that need to be specified here?=20 Yes, and every NFSv4 server exports a root file system, which is what I expect the clients would mount. =20 > I also don't understand what "second-level directory" means=20 > or why anything needs to be said. (This probably just=20 > reflects my ignorance about NFS mounts.) What does it mean to=20 > populate a directory with DNS names?=20 I guess I'm not being clear. Let's talk about the client-based implementation of this, as opposed to the server-based one. I'm proposing a scheme where, on the NFSv4 client, there's a special directory under the client's root directory. Suppose that directory is called "/nfs4". Then, under this special directory, whenever some application does a lookup for a domain name, like "/nfs4/mit.edu", the NFSv4 client asks DNS for the corresponding SRV record for that domain--in this case, _nfsv4.mit.edu. This DNS lookup produces a list of SRV RRs, and I'm trying to describe the process by which those SRV RRs can be interpreted as mounts of file systems on NFSv4 servers. So our NFS client carries out the indicated server mount, using "/nfs4/mit.edu" as the place in the client's name space where that server (those servers) are mounted. If subsequent applications do lookups for other domain names under /nfs4/, that local directory (the /nfs4/ one) will appear to be populated with the domain names that have been looked up. > > Thus, the root directory for the file system published by > > example.net will effectively be mounted underneath the > > example.net name in a second-level directory. >=20 > Going back to your example, the SRVs point to=20 > nfs2ex.example.net. So it doesn't seem right to say (above)=20 > "will effectively be mounted underneath the example.net=20 > name..." I don't understand what you are trying to say here. Right. The NFS client does an auto-mount of the given file server(s) in the machine's local name space, as /nfs4/example.net. > > 4.1. Globally-useful names: conventional mount point > >=20 > > For the inter-organizational name space to be a global=20 > name space, it > > is useful for its mount point in local systems to be=20 > uniform as well. > > The name /nfs4/ SHOULD be used so that names on one=20 > machine will be > > directly usable on any machine. Thus, the example.net=20 > published file > > system would be accessible as > >=20 > > /nfs4/example.net/ > >=20 > > on any client. Using this convention, "/nfs4/" is a mount for a > > special file system that is populated with the results=20 > of SRV record > > lookups. >=20 > I don't understand the above at all. Are you getting into NFS=20 > implementation details that are uniform and well known? Does=20 > NFS have a well-known name space where /nfs4/foo.com/ would=20 > have the second component recognized to be a a DNS name?=20 > Where is this specified? This draft is proposing that /nfs4/ be used conventionally, and it proposes that there be a well-known name space such as you describe. All that the above paragraph is trying to describe is the name of that conventional mount point, proposing the "nfs4" name for it. > > One extension of this rule that we might choose to=20 > inherit from AFS, > > though, is to give a special meaning to the domain name of an > > organization preceded by a period ("."). It might be=20 > reasonable to > > have names mounting the filesystem for a period-prefixed=20 > domain name > > (e.g., ".example.net") attempt to mount only a=20 > read-write instance of > > that organization's root filesystem, rather than=20 > permitting the use > > of read-only instances of that filesystem. Thus, >=20 > Seems like a bad idea.. You are using non compliant DNS names... It's true that ".example.net" is not a legal DNS name. My expectation, perhaps not well-spelled-out, is that the agent interpreting ".example.net" (the NFS client, commonly) would strip off the leading "." and proceed as before to obtain the SRV records from DNS for the "example.net" name. Subsequent processing of the servers so indicated might show that some servers were read-only, and if so, they should not be mounted by such a request. =20 > > 4.3. File system integration issues > >=20 > > The result of the DNS search SHOULD appear as a=20 > (pseudo-)directory in > > the client name space, cached for a time no longer than=20 > the RR's TTL. > > A further refinement is advisable, and SHOULD be=20 > deployed: that only > > fully-qualified domain names appear as directories. That is, in=20 > > many >=20 > The above seems at odds with the documents earlier support=20 > for using short TTLs in order to return client-specific=20 > results. And, when the TTL expires, what is supposed to happen? This is an inconsistency. I should not have suggested any short TTL values earlier. =20 > > environments, DNS names may be abbreviated from their=20 > fully-qualified > > form. In such circumstances, multiple names might be=20 > given to file > > system code that all resolve to the same DNS SRV RRs. The > > abbreviated form SHOULD be represented in the client's name space > > cache as a symbolic link, pointing to the=20 > fully-qualified name, case- > > canonicalized when appropriate. >=20 > This seem like it would be hard for clients to implement,=20 > since the DNS algorithm (which may append various names as=20 > part of trying to resolve the query) are not done by the=20 > client directly, but as part of more generic DNS routines. Is=20 > this really feasible to implement? I remember doing this some years ago. In the layer I had to deal with, it was totally possible, if not obvious. If that's no longer true, perhaps the SHOULD will put its featherweight on the scale of making it possible again. =20 > And how is the above problem worse with SRV records than it=20 > is today when the DNS name of the server is given? >=20 > Is the "name space cache" something very specific to NFS? I was thinking of a "name space cache" specifically in the NFS client, so that the content fetched from DNS would be cached. The alternative seems to be that the interpretation of every pathname would require a DNS lookup/reply. Even if this is a local operation, in most implementations it would require a trip from kernel to userspace and back, which is a substantial penalty. This speaks to how the DNS result might be represented in-kernel. > > This will allow pathnames obtained > > with, say, getcwd() to include the DNS name that is most=20 > likely to be > > usable outside the scope of any particular DNS abbreviation > > convention. >=20 >=20 > > 5. Where is this integration carried out? > >=20 > > Another consideration is what agent should be responsible for > > interpreting the SRV records. It could be done just as=20 > well by the > > client or by the server, though we expect that most clients will > > include this function themselves. Using something like=20 > Automounter >=20 > I am very worried that this documen seems to have some pretty=20 > basic misconceptions about DNS/SRVs. NFS servers DO NOT=20 > interpret SRV records... only clients do that... As I say, one obvious use for this convention is that an NFS client could consult the DNS client. Architecturally, though, it would be perfectly possible for an NFS server to use this convention. The convention I'm advocating is that admins wishing to publish file servers for a domain name should be able to do so by publishing suitable SRV records in that domain. Those SRV records could then be interpreted by either the NFS-client-based scheme or by the NFS-server-based one, in principle. =20 > Thomas >=20 Craig From Nicolas.Williams@Sun.COM Tue Aug 18 15:35: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 5E6723A6ADB; Tue, 18 Aug 2009 15:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 xyHz8ELcsKLP; Tue, 18 Aug 2009 15:35:39 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 872373A6AD4; Tue, 18 Aug 2009 15:35:39 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IM3bDS009530; Tue, 18 Aug 2009 22:03:37 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IM3aS3062862; Tue, 18 Aug 2009 16:03:37 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7ILqree003701; Tue, 18 Aug 2009 16:52:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7ILqrfR003700; Tue, 18 Aug 2009 16:52:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 18 Aug 2009 16:52:53 -0500 From: Nicolas Williams To: James Lentini Message-ID: <20090818215253.GV1043@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Mailman-Approved-At: Wed, 19 Aug 2009 21:30:24 -0700 Cc: dns-dir@ietf.org, nfsv4@ietf.org Subject: Re: [dns-dir] [nfsv4] Request for review of NFSv4 DNS SRV 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: Tue, 18 Aug 2009 22:35:40 -0000 On Wed, Aug 05, 2009 at 10:49:48AM -0400, James Lentini wrote: > http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt My advice: - remove all references to internal and external DNS; these are not necessary - collect all recommendations for purely local behavior into a separate section/subsection: X. Local Behavior Recommendations X.1. Local Behavior Recommendations for POSIX This includes: - the name of the mount point on clients for a /net/-like automount - local options like "ro" (read-only), "intr" (interruptible), ... - obtain consensus on where on the client to mount a domain-based "automount map" /nfs4 seems odd. Why not /nfs4dom, or some such. Why should one think that /nfs4 is not an NFSv4-specific variant of /net? Why do users need an NFSv4-specific mountpoint here? Shouldn't there also be a protocol-agnostic mountpoint? - obtain consensus on whether clients should mount the root FH for each root server, or some other path. I strongly recommend something like /.nfs4-globalnamespace-root (POSIX allows for special . files/dirs in the root of any filesystem), or some such. - work out a suitable read-only/read-write option setting Possible schemes: a) Assume read-only for all namespace roots. (They're very likely to be read-onlyanyways.) b) Assume read-write and pass on any NFS4ERR_ROFS as EROFS. c) Heuristic: - if there's only one root location -> assume read-write; if the server returns NFS4ERR_ROFS then mark the mount as read-only - if there's more than one root location and if the client is willing to re-do LOOKUPs/OPENs (as during recovery) on NFS4ERR_ROFS -> assume read-write; if all servers return NFS4ERR_ROFS then mark the mount as read-only - if there's more than one root location and the client is not willing to do as above -> mark the mount as read-only - recommend that clients do the SRV lookups, but allow (MAY) servers to export filesystems where names are interpreted as domainnames and which result in referrals to those domainnames' namespace root locations. Nico -- From Craig.Everhart@netapp.com Wed Aug 19 07:01: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 B28F73A6A8E; Wed, 19 Aug 2009 07:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 L9kSGsf5knsz; Wed, 19 Aug 2009 07:01:51 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 6E62A3A67EA; Wed, 19 Aug 2009 07:01:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,408,1246863600"; d="scan'208";a="227497261" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 19 Aug 2009 07:01:41 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n7JE1fGP005355; Wed, 19 Aug 2009 07:01:41 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 07:01:41 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:01:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 10:01:39 -0400 Message-ID: In-Reply-To: <20090818210325.GT1043@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] [dns-dir] Request for review of NFSv4 DNS SRV draft Thread-Index: AcogSO4bsukmjQOqQEe4w+KX/TpcMgAiPQBw References: <200908181954.n7IJsR8j032723@cichlid.raleigh.ibm.com> <20090818210325.GT1043@Sun.COM> From: "Everhart, Craig" To: "Nicolas Williams" , "Thomas Narten" X-OriginalArrivalTime: 19 Aug 2009 14:01:40.0440 (UTC) FILETIME=[93455D80:01CA20D5] X-Mailman-Approved-At: Wed, 19 Aug 2009 21:30:24 -0700 Cc: dns-dir@ietf.org, nfsv4@ietf.org Subject: Re: [dns-dir] [nfsv4] Request for review of NFSv4 DNS SRV 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: Wed, 19 Aug 2009 14:01:52 -0000 > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Tuesday, August 18, 2009 5:03 PM > To: Thomas Narten >=20 ... > > > 3.1. Deployment of the Resource Record > > >=20 > > > As with any DNS resource, any server installation=20 > needs to concern > > > itself with the likely loads and effects of the presence of the > > > resource record. The answers to requests for RRs might differ > > > depending on what the server can tell about the=20 > client. For example, > > > some RRs might be returned only to those clients=20 > inside some network > > > perimeter (to provide an intranet service) and=20 > requests from other > > > clients might be denied. [...] > >=20 > > The above makes me a little nervous, but maybe I'm missreading the=20 > > intention. From a DNS point of view, it is generally=20 > frowned upon to=20 > > return differing answers to a DNS query depending on criteria (like=20 > > the above). (I know there are DNS load balancers that do that, but=20 > > they only work if one disables DNS caching, etc.). >=20 > Well, people do tend to keep fake DNS roots inside their=20 > perimeters, with different zone file contents inside and=20 > outside. I agree with you that this I-D should really not=20 > mention that. For load balancing the SRV RR weight and=20 > priority RDATA fields should suffice. Agreed. =20 ... > > I also don't understand what "second-level directory" means or why=20 > > anything needs to be said. (This probably just reflects my=20 > ignorance=20 > > about NFS mounts.) What does it mean to populate a=20 > directory with DNS=20 > > names? >=20 > I *think* they mean that /nfs4/example.net/foo/ will really=20 > map to "the filesystem at foo.example.net". But frankly, I=20 > find that text confusing too. OK, it must really be confusing. "[S]econd-level directory" is just meant as the suggested /nfs4/ directory name on the NFS client, where the "magic" automount-like mounts would appear. It doesn't mean what Nico interprets it as. The only thing that appears *under* the /nfs4/example.net/ directory, or mount, or name, is a reflection of what's on a file server. So the only way /nfs4/example.net/foo/ appears is if there's a "/foo" exported from the file server(s) pointed to by the SRV records for "example.net". > > > Thus, the root directory for the file system published by > > > example.net will effectively be mounted underneath the > > > example.net name in a second-level directory. > >=20 > > Going back to your example, the SRVs point to=20 > nfs2ex.example.net. So=20 > > it doesn't seem right to say (above) "will effectively be mounted=20 > > underneath the example.net name..." I don't understand what you are=20 > > trying to say here. >=20 > I think they mean to say that a server for example.net named,=20 > say, foo, will be accessible as /nfs4/example.net/foo --=20 > /nfs4/example.net/ being a magic /net/-like filesystem=20 > containing only referrals. >=20 > The key issue here though is this: say you lookup the=20 > _nfs4._tcp SRV RR for example.net and find a list of servers,=20 > now, what path from any one of those fileservers should be=20 > mounted on /nfs4/example.net?? >=20 > In the /net/ case the answer to that question is always "/". =20 > I.e., /net/foo.example.net/ should be a mount of foo.example.net:/ >=20 > Section 4.2 is explicit about this: use "the pseudo-root"=20 > (meaning "the root FH"). I don't think that's a great answer=20 > for this new magic mount, but the SRV RR has no way to tell=20 > us what that path should be, so we must pick one. >=20 > I see the quoted text as getting to that issue in a=20 > round-about way, but without actually giving us an answer. I=20 > really don't see how the servers for example.net can have two=20 > roots: one for clients arriving via an SRV RR lookup, and one=20 > for clients arriving as usual. I agree. If you go to any of the servers (named in SRV) for example.net and mount their "/", you should get the same thing as if you had asked your NFS client to interpret the pathname /nfs4/example.net/. =20 > > > One extension of this rule that we might choose to=20 > inherit from AFS, > > > though, is to give a special meaning to the domain name of an > > > organization preceded by a period ("."). It might be=20 > reasonable to > > > have names mounting the filesystem for a=20 > period-prefixed domain name > > > (e.g., ".example.net") attempt to mount only a=20 > read-write instance of > > > that organization's root filesystem, rather than=20 > permitting the use > > > of read-only instances of that filesystem. Thus, > >=20 > > Seems like a bad idea.. You are using non compliant DNS names... >=20 > I agree. I don't understand the paragraph immediately=20 > preceding the one you quote. >=20 > I think the issue here is that a referral can point to more=20 > than one server, so what to do if one is writeable and the=20 > others are not? But it gets worse than that: the referral=20 > data in the NFSv4 protocol doesn't tell you which is=20 > writeable, so to find out the client would have to go test each one. >=20 > But it gets worse: in NFSv4.0 (RFC3530) there's no way to=20 > find out if a filesystem is read-only without actually=20 > attempting a write! >=20 > So, IMO the paragraph immediately preceding the one you quote=20 > is wrong. > The one you quote is inadvisable, IMO. This isn't a central feature of the draft, but a bell/whistle. It could go without leaving a mark. But it's a handy kind of thing for actually *using* a system where some filesystem instances are readonly and some are read-write. =20 > What should happen is that the client should assume the mount=20 > is read-write *if* there's a single location, else the client=20 > should assume read-write *if* the client is willing to retry=20 > writes against each location until one succeeds, else the=20 > client should assume read-only. I buy the first half. I don't buy the second half. What if some of the R/O instances are out-of-date with respect to the R/W, even if they will eventually converge? Then you have updates arriving at a file server where the update is based on a potentially stale copy of the data. Think "echo 'foo' >> /etc/passwd". =20 > (The I-D could provide a lot more background, including an=20 > *informative* copy of the fs_locations XDR, so that readers=20 > who are not familiar with > NFSv4 can recognize some of these issues more easily.) (Sure, though I don't want to break with IETF tradition here.) =20 > > > 4.3. File system integration issues > > >=20 > > > The result of the DNS search SHOULD appear as a=20 > (pseudo-)directory in > > > the client name space, cached for a time no longer=20 > than the RR's TTL. > > > A further refinement is advisable, and SHOULD be=20 > deployed: that only > > > fully-qualified domain names appear as directories. =20 > That is, in=20 > > > many > >=20 > > The above seems at odds with the documents earlier support=20 > for using=20 > > short TTLs in order to return client-specific results. And,=20 > when the=20 > > TTL expires, what is supposed to happen? >=20 > The path should be unmounted. If the path is busy and can't=20 > easily be unmounted then the client should be free to leave=20 > it as is and say "oh well". (This happens today in the case=20 > of /net/.) OK, this sort of thing needs more clarity: noted. Certainly the path could be un-pseudo-mounted if it's idle. If it's busy, probably the (NFS) client is best off leaving it there for a while. But this section was insufficiently qualified; it's supposed to apply to idle pseudo-mounts. =20 > > > environments, DNS names may be abbreviated from their=20 > fully-qualified > > > form. In such circumstances, multiple names might be=20 > given to file > > > system code that all resolve to the same DNS SRV RRs. The > > > abbreviated form SHOULD be represented in the client's=20 > name space > > > cache as a symbolic link, pointing to the=20 > fully-qualified name, case- > > > canonicalized when appropriate. > >=20 ... > > Is the "name space cache" something very specific to NFS? >=20 > No, it's a local issue (though I don't know where "cache"=20 > comes from here). I'm just talking about the collection of pseudo-mounts under /nfs4/, which works like a cache of the SRV records. =20 > Gathering recommendations for _local_ behavior should be in a=20 > separate section would be a good idea. And they should be as=20 > OS-agnostic as possible, though even then, POSIX-specific=20 > recommendations are a good idea. (And what about Windows? I=20 > dunno. Something like network neighborhood needs to be added=20 > that knows about this scheme. But we can hardly tell MSFT=20 > what to do, whereas in the POSIX case it's much more likely=20 > that vendors will follow these recommendations.) Not a bad idea. Certainly the location for the nest of pseudo-mounts is local. I'm not so sure about the suggested behavior of an NFS client with respect to, say, the TTL of the SRV RRs; that doesn't feel entirely local. =20 ... > Nico Craig From pk@DENIC.DE Thu Aug 20 11:01:51 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 3BC3F3A6B87 for ; Thu, 20 Aug 2009 11:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, 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 QPQJXZrVzcCl for ; Thu, 20 Aug 2009 11:01:50 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 5F4103A6AFE for ; Thu, 20 Aug 2009 11:01:50 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.126]) by office.denic.de with esmtp id 1MeBxS-0002mH-KL; Thu, 20 Aug 2009 20:01:54 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 823B551EE89; Thu, 20 Aug 2009 20:01:54 +0200 (CEST) Date: Thu, 20 Aug 2009 20:01:54 +0200 From: Peter Koch To: dns-dir@ietf.org Message-ID: <20090820180154.GG13476@unknown.office.denic.de> Mail-Followup-To: dns-dir@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [dns-dir] [alexey.melnikov@isode.com: Additional reviews of draft-daboo-srv-email-02.txt needed] 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, 20 Aug 2009 18:01:51 -0000 is another attempt to do service discovery in the plain old forward DNS ... -Peter ----- Forwarded message from Alexey Melnikov ----- From: Alexey Melnikov To: apps-discuss@ietf.org Subject: Additional reviews of draft-daboo-srv-email-02.txt needed Date: Thu, 20 Aug 2009 11:42:50 +0100 Delivered-To: apps-discuss@core3.amsl.com X-SMTP-Protocol-Errors: NORDNS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Mailman-Version: 2.1.9 List-Id: General discussion of application-layer protocols Hi, I've just initiated IETF LC for this document. The document describes how DNS SRV records can be used for email client autodiscovery of IMAP/POP servers. I would like to solicit additional reviews of the document. Thanks, Alexey _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From dromasca@avaya.com Fri Aug 21 02:37: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 14EB33A6D2D; Fri, 21 Aug 2009 02:37:05 -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 yXXG2+JBv76A; Fri, 21 Aug 2009 02:37:04 -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 CC1613A6A5C; Fri, 21 Aug 2009 02:37:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,249,1249272000"; d="scan'208";a="180765485" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Aug 2009 05:37:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Aug 2009 05:37:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 11:37:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for August 27, 2009 Telechat Thread-Index: Acoh5UEhmpmJ622HQjGgec4D3VUWVgAXJnrQ From: "Romascanu, Dan (Dan)" To: , , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for August 27, 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, 21 Aug 2009 09:37:05 -0000 Please find below the preliminary agenda and package for the 8/27 telechat. Please let me know before 8/26 COB if there are any questions, comments or concerns.=20 Thanks and Regards, Dan =20 -----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-simple-xcap-diff-13.txt An Extensible Markup Language (XML) Document Format for Indicating A Change=20 in XML Configuration Access Protocol (XCAP) Resources (Proposed Standard) -=20 1 of 7=20 Note: Ben Campbell is taking over as the document Shepherd=20 Token: Robert Sparks o draft-ietf-ippm-multimetrics-11.txt IP Performance Metrics (IPPM) for spatial and multicast (Proposed Standard)=20 - 2 of 7=20 Note: The document shepherd is Matt Zekauskas (matt@internet2.edu).=20 Token: Lars Eggert o draft-ietf-ospf-hmac-sha-06.txt OSPFv2 HMAC-SHA Cryptographic Authentication (Proposed Standard) - 3 of 7=20 Token: Ross Callon o draft-ietf-opsawg-syslog-alarm-02.txt Alarms in SYSLOG (Proposed Standard) - 4 of 7=20 Note: Scott Bradner (sob@harvard.edu) is the document shepherd.=20 Token: Dan Romascanu o draft-ietf-mext-binding-revocation-10.txt Binding Revocation for IPv6 Mobility (Proposed Standard) - 5 of 7=20 Note: Julien Laganier (julien.laganier.ietf@googlemail.com) is the document=20 shepherd.=20 Token: Jari Arkko o draft-ietf-vcarddav-webdav-mkcol-06.txt Extended MKCOL for WebDAV (Proposed Standard) - 6 of 7=20 Note: Julian Reschke agreed to=20 shepherd the document.=20 Token: Alexey Melnikov o draft-ietf-ntp-dhcpv6-ntp-opt-04.txt Network Time Protocol (NTP) Server Option for DHCPv6 (Proposed Standard) -=20 7 of 7=20 Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.=20 Token: Ralph Droms 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item o draft-green-secsh-ecc-08.txt Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer=20 (Proposed Standard) - 1 of 2=20 Note: Jeffrey Hutzelman (jhutz@cmu.edu) is document shepherd.=20 Token: Tim Polk o draft-housley-iesg-rfc3932bis-08.txt IESG Procedures for Handling of Independent and IRTF Stream Submissions=20 (BCP) - 2 of 2=20 Note: There is no document shepherd=20 Token: Jari Arkko 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-behave-nat-behavior-discovery-07.txt NAT Behavior Discovery Using STUN (Experimental) - 1 of 4=20 Token: Magnus Westerlund o draft-ietf-bmwg-mpls-forwarding-meth-05.txt MPLS Forwarding Benchmarking Methodology for IP Flows (Informational) - 2=20 of 4=20 Token: Ron Bonica o draft-ietf-mext-aero-reqs-04.txt Network Mobility Route Optimization Requirements for Operational Use in=20 Aeronautics and Space Exploration Mobile Networks (Informational) - 3 of 4=20 Note: Document Shepherd is Marcelo Bagnulo Braun =20 Token: Jari Arkko o draft-ietf-pwe3-mpls-transport-04.txt Application of Ethernet Pseudowires to MPLS Transport Networks=20 (Informational) - 4 of 4=20 Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document =20 shepherd=20 Token: Ralph Droms 3.1.2 Returning Item o draft-ietf-ospf-manet-or-02.txt Extensions to OSPF to Support Mobile Ad Hoc Networking (Experimental) - 1=20 of 1=20 Token: Ross Callon 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 NONE 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 NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Multicast Mobility (multimob) - 1 of 1 Token: Jari Arkko 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Internationalized Domain Names in Applications, Revised (idnabis) - 1 of 2 Token: Lisa Dusseault o DNS Extensions (dnsext) - 2 of 2 Token: Ralph Droms From narten@us.ibm.com Fri Aug 21 11:01: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 ABAAA3A6B40; Fri, 21 Aug 2009 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 iVqiEErZdII6; Fri, 21 Aug 2009 11:01:46 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id D45C128C1C2; Fri, 21 Aug 2009 11:01:46 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LHvD3n012691; Fri, 21 Aug 2009 11:57:13 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LI1haW212062; Fri, 21 Aug 2009 12:01:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LI1hAQ003210; Fri, 21 Aug 2009 12:01:43 -0600 Received: from cichlid.raleigh.ibm.com (dyn455718.raleigh.ibm.com [9.37.211.137]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LI1fFZ003036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 12:01:42 -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 n7LI1fYL006065; Fri, 21 Aug 2009 14:01:41 -0400 Message-Id: <200908211801.n7LI1fYL006065@cichlid.raleigh.ibm.com> To: Nicolas Williams In-reply-to: <20090818215253.GV1043@Sun.COM> References: <20090818215253.GV1043@Sun.COM> Comments: In-reply-to Nicolas Williams message dated "Tue, 18 Aug 2009 16:52:53 -0500." Date: Fri, 21 Aug 2009 14:01:41 -0400 From: Thomas Narten Cc: James Lentini , dns-dir@ietf.org, nfsv4@ietf.org Subject: Re: [dns-dir] [nfsv4] Request for review of NFSv4 DNS SRV 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: Fri, 21 Aug 2009 18:01:47 -0000 I'm not going to respond in detail to the thread, because most of the followup is NFS-specific. That said, I think: Nicolas Williams writes: > My advice: seems generally on the right track. I see now that a lot of my confusion has to do with the document not being clear about what is purely NFS business vs. what is the DNS SRV behavior. It would be good to more clearly separate these two aspects. For example, you really only need to describe the DNS client behavior w.r.t. to SRV. Whether this is done on an NFS client or NFS server depends on the context, but from the perspective of DNS, when doing SRV processing, the entity is a DNS "client", even if it is an NFS *server* doing the processing. *This* document presumably only needs to be specifying aspects of SRV lookup behavior. Also, the talk about read/write and trying various alternative servers to find one that is writable seems fundamentally like a Bad Idea to mix up with SRV processing. For one thing, a basic definition of SRV is that all entities that are returned via an SRV lookup provide exactly the same service. One should not be trying various ones looking for a "different" service. If you want to distinguish read only from read-write directories, the proper way would be to give them different service names (I would think). Thomas From Nicolas.Williams@sun.com Fri Aug 21 11:18:42 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 25C6128C17F; Fri, 21 Aug 2009 11:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 pgBQf6HoH20w; Fri, 21 Aug 2009 11:18:41 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 476153A6E09; Fri, 21 Aug 2009 11:18:41 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7LIIkro005007; Fri, 21 Aug 2009 18:18:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7LIIktp063727; Fri, 21 Aug 2009 12:18:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7LI82C4006101; Fri, 21 Aug 2009 13:08:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7LI81Fd006100; Fri, 21 Aug 2009 13:08:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 21 Aug 2009 13:08:01 -0500 From: Nicolas Williams To: Thomas Narten Message-ID: <20090821180801.GH1043@Sun.COM> References: <20090818215253.GV1043@Sun.COM> <200908211801.n7LI1fYL006065@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908211801.n7LI1fYL006065@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.7i Cc: dns-dir@ietf.org, nfsv4@ietf.org Subject: Re: [dns-dir] [nfsv4] Request for review of NFSv4 DNS SRV 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: Fri, 21 Aug 2009 18:18:42 -0000 On Fri, Aug 21, 2009 at 02:01:41PM -0400, Thomas Narten wrote: > I see now that a lot of my confusion has to do with the document not > being clear about what is purely NFS business vs. what is the DNS SRV > behavior. It would be good to more clearly separate these two aspects. > > For example, you really only need to describe the DNS client behavior > w.r.t. to SRV. Whether this is done on an NFS client or NFS server > depends on the context, but from the perspective of DNS, when doing > SRV processing, the entity is a DNS "client", even if it is an NFS > *server* doing the processing. *This* document presumably only needs > to be specifying aspects of SRV lookup behavior. +1 > Also, the talk about read/write and trying various alternative servers > to find one that is writable seems fundamentally like a Bad Idea to > mix up with SRV processing. For one thing, a basic definition of SRV > is that all entities that are returned via an SRV lookup provide > exactly the same service. One should not be trying various ones > looking for a "different" service. > > If you want to distinguish read only from read-write directories, the > proper way would be to give them different service names (I would > think). Ah, very good point. Yes, so let's have _two_ SRV RR names: - _nfs4._tcp.@ORIGIN for read-only domain namespace roots - _write._nfs4._tcp.@ORIGIN for read-write domain namespace roots Also, the "nfs4" in the service name is a bit misleading. Perhaps we should have it be: - _nfs4._domainroot._tcp.@ORIGIN for read-only domain namespace roots - _write. _nfs4._domainroot._tcp.@ORIGIN for read-write ... roots I.e., we should clearly separate "domain namespace distributed filesystem root" from "distributed filesystem protocol". That way we could regularize CIFS, AFS, NFS, Lustre, ... domain root SRV RR naming. (Yes, I am aware of the existing AFSDB RR type.) Nico -- From narten@us.ibm.com Tue Aug 25 09:02:03 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 611D93A6784 for ; Tue, 25 Aug 2009 09:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.052 X-Spam-Level: X-Spam-Status: No, score=-7.052 tagged_above=-999 required=5 tests=[AWL=1.547, 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 FJLcZ1DTe6WQ for ; Tue, 25 Aug 2009 09:02:02 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 75D1B28C4B4 for ; Tue, 25 Aug 2009 09:02:01 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7PFrd9J009824 for ; Tue, 25 Aug 2009 11:53:39 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7PG1pns136854 for ; Tue, 25 Aug 2009 12:01:51 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7PG1oPQ008041 for ; Tue, 25 Aug 2009 12:01:51 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-227-67.mts.ibm.com [9.65.227.67]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7PG1ndx007966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2009 12:01:50 -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 n7PG1lKO016004; Tue, 25 Aug 2009 12:01:48 -0400 Message-Id: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> To: liman@autonomica.se Date: Tue, 25 Aug 2009 12:01:47 -0400 From: Thomas Narten Cc: Tina Dam , dns directorate Subject: [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: Tue, 25 Aug 2009 16:02:03 -0000 Hi All. Tina Dam has asked me to try and move this document along. ICANN thinks they need it as an RFC before they launch IDNs. It appears to have been sitting since March... In reviewing this document, I think it would benefit from some edits that make it more clear what this document is trying to solve and what it is not. (Just saying "clears up ambiguities" isn't direct enough, IMO.) Even in going back and reviewing the mail thread on dnsop in March, I'm not entirely clear what this document is trying to fix. Also, there is much confusion (FUD?) in this space, and I think this document would be a fine place to do away with some of this. Some random thoughts (which may not be right). I think this document cannot say that TLDs MUST be 2 characters long. What is the technical basis for such a recommendation? My understanding is that the main motivation for such a rule is to avoid user confusion and avoid having a single typo change TLD 'a' to some other TLD and then cause lookup from the wrong site. That is a fine concern, but we have single letter labels below TLDs, so how big a problem this is is open for debate. I think it would be fine to state something like that, but leave it to ICANN to decide. Unless someone can point me to a real technical argument. Right now, the document just says it MUST be 2 characters, with no supporting reasoning. I think this document should go review the history a bit, the various confusions (DNS vs. host name), note that we don't ever want any DNS name to be confused with something that inet_pton() would convert, etc. And so forth. Thoughts? Can someone here restate what (if any) issues exist with moving this document forward? And should it be a WG document rather than an individual submission? Thomas From ajs@shinkuro.com Tue Aug 25 20:07:20 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 8D2653A6FA4 for ; Tue, 25 Aug 2009 20:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 f5fkmSqglj3E for ; Tue, 25 Aug 2009 20:07:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id AEB5C28C347 for ; Tue, 25 Aug 2009 20:07:16 -0700 (PDT) Received: from crankycanuck.ca (72-255-94-185.client.stsn.net [72.255.94.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6063A2FE8CBB; Wed, 26 Aug 2009 03:07:17 +0000 (UTC) Date: Tue, 25 Aug 2009 23:07:13 -0400 From: Andrew Sullivan To: Thomas Narten Message-ID: <20090826030713.GD5405@shinkuro.com> References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 26 Aug 2009 03:07:20 -0000 I don't want to speak for Lars Liman, who has done all the work here. This is just my perspective, from what I remember. On Tue, Aug 25, 2009 at 12:01:47PM -0400, Thomas Narten wrote: > In reviewing this document, I think it would benefit from some edits > that make it more clear what this document is trying to solve and what > it is not. (Just saying "clears up ambiguities" isn't direct enough, > IMO.) The goal so far has been, I thought, to do the absolute bare minimum necessary to change the "alphabetic only" rule, and do nothing more. Partly, this is a defensive measure against certain parties who warned they'd kick and scream if anything more than that were done. > Even in going back and reviewing the mail thread on dnsop in March, > I'm not entirely clear what this document is trying to fix. It was supposed to be an extremely focusssed, narrow fix of exactly the provision in RFC 1123, §2.1, that says "the highest-level component label will be alphabetic." The idea was to get out the door something that solved exactly the problem standing in the way of A-labels in the top level, but nothing more. > Also, > there is much confusion (FUD?) in this space, and I think this > document would be a fine place to do away with some of this. See the "nothing more", above. I'm not opposed to tilting at that particular windmill on principle, but if we're going to do something for the short term, this isn't the way to do it. > I think this document cannot say that TLDs MUST be 2 characters > long. What is the technical basis for such a recommendation? Well, _at least_ 2 characters long. The sole justification for this is that it's ever been thus, and we don't want to change that without pretty good evidence that it will do no harm. This is not a "justify the limitation", it's a "justify the change" space. At least that's been the aim > understanding is that the main motivation for such a rule is to avoid > user confusion and avoid having a single typo change TLD 'a' to some > other TLD and then cause lookup from the wrong site. No, the motivation is that there's never been a single-character TLD, and therefore adding one could break some hard coded assumptions. Adding >3-character TLDs sure did, and there already _were_ some of those. > I think this document should go review the history a bit, the various > confusions (DNS vs. host name), note that we don't ever want any DNS > name to be confused with something that inet_pton() would convert, > etc. And so forth. I think that would be an excellent project after we got this draft out the door, because anything that involves (1) the history of the DNS or (2) anything but the most cosmetic, trivial, or obviously right alterations to the rules risks going into IETF DoS hell. To trot out my favourite personal example, the reverse-mapping-considerations draft that went to DNSOP WGLC said very little more substantive than, "Some people like the reverse tree. You should maintain it for your site. Or, not, if you don't want to. Also, if you use the reverse tree, don't rely on it too much. But use it if you want." Even this apparently bland claim was unable to make it past the WG, and died. I suspect that if a draft came to the DNS community that said, "DNS exists and (A or not-A)," there would be someone at the mic ready to complain. If we want to make progress, let's make it in small increments. > Can someone here restate what (if any) issues exist with moving this > document forward? And should it be a WG document rather than an > individual submission? It should become a WG item, yes. It seems to be an operational rule about content of the root zone, so it belongs in DNSOP (but DNSEXT is willing to take it if the DNSOP Chairs want us to. Careful what you wish for: we just sent our AD the request to get our new charter out, and this sure ain't on it). I expect that, as with most DNS documents, the main problem is author's time. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From narten@us.ibm.com Wed Aug 26 06:08: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 AA4CE3A67F9 for ; Wed, 26 Aug 2009 06:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.163 X-Spam-Level: X-Spam-Status: No, score=-5.163 tagged_above=-999 required=5 tests=[AWL=-0.564, 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 czW9XlozrHkB for ; Wed, 26 Aug 2009 06:08:33 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 16E9828C11F for ; Wed, 26 Aug 2009 06:07:53 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7QCR4uZ002990 for ; Wed, 26 Aug 2009 06:27:04 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7QCVrKs097254 for ; Wed, 26 Aug 2009 06:31:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7QCVr2t022345 for ; Wed, 26 Aug 2009 06:31:53 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-217-45.mts.ibm.com [9.65.217.45]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7QCVpXd022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Aug 2009 06:31:52 -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 n7QCVo3D015951 for ; Wed, 26 Aug 2009 08:31:51 -0400 Message-Id: <200908261231.n7QCVo3D015951@cichlid.raleigh.ibm.com> To: dns directorate Date: Wed, 26 Aug 2009 08:31:50 -0400 From: Thomas Narten Subject: [dns-dir] On Single-letter TLD names 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, 26 Aug 2009 13:08:33 -0000 Klensin says: http://www.alvestrand.no/pipermail/idna-update/2008-July/002271.html Thomas From narten@us.ibm.com Wed Aug 26 06:24:57 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 590413A6A32 for ; Wed, 26 Aug 2009 06:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 27dAZGqwAlE6 for ; Wed, 26 Aug 2009 06:24:56 -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 224F128B56A for ; Wed, 26 Aug 2009 06:24:56 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7QCQEuT022781 for ; Wed, 26 Aug 2009 06:26:14 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7QCSErB227176 for ; Wed, 26 Aug 2009 06:28:14 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7QCSEu4011656 for ; Wed, 26 Aug 2009 06:28:14 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-217-45.mts.ibm.com [9.65.217.45]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7QCSC0Z011621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 06:28:13 -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 n7QCS8OF014747; Wed, 26 Aug 2009 08:28:09 -0400 Message-Id: <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> To: Andrew Sullivan In-reply-to: <20090826030713.GD5405@shinkuro.com> References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> Comments: In-reply-to Andrew Sullivan message dated "Tue, 25 Aug 2009 23:07:13 -0400." Date: Wed, 26 Aug 2009 08:28:08 -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, 26 Aug 2009 13:24:57 -0000 Hi Andrew. Thanks for your comments... Andrew Sullivan writes: > I don't want to speak for Lars Liman, who has done all the work here. > This is just my perspective, from what I remember. Fair enough! > On Tue, Aug 25, 2009 at 12:01:47PM -0400, Thomas Narten wrote: > > In reviewing this document, I think it would benefit from some edits > > that make it more clear what this document is trying to solve and what > > it is not. (Just saying "clears up ambiguities" isn't direct enough, > > IMO.) > The goal so far has been, I thought, to do the absolute bare minimum > necessary to change the "alphabetic only" rule, and do nothing more. I can understand this, and would also support it. That said, the document should come out and say that. You have to read between the lines to understand what the new proposed syntax is actually changing, and why that needs to be done. > Partly, this is a defensive measure against certain parties who warned > they'd kick and scream if anything more than that were done. Right. Can you (or anyone) state what some of these other areas are? I may well not be inclined to go there either, so we may be in violent agreement... > > Even in going back and reviewing the mail thread on dnsop in March, > > I'm not entirely clear what this document is trying to fix. > It was supposed to be an extremely focusssed, narrow fix of exactly > the provision in RFC 1123, §2.1, that says "the highest-level > component label will be alphabetic." The idea was to get out the door > something that solved exactly the problem standing in the way of > A-labels in the top level, but nothing more. OK. > > Also, > > there is much confusion (FUD?) in this space, and I think this > > document would be a fine place to do away with some of this. > See the "nothing more", above. I'm not opposed to tilting at that > particular windmill on principle, but if we're going to do something > for the short term, this isn't the way to do it. > > > I think this document cannot say that TLDs MUST be 2 characters > > long. What is the technical basis for such a recommendation? > Well, _at least_ 2 characters long. The sole justification for this > is that it's ever been thus, and we don't want to change that without > pretty good evidence that it will do no harm. This is not a "justify > the limitation", it's a "justify the change" space. At least that's > been the aim Then let's document this and move on. I agree it's a possible concern. But talking with Klensin in particular about the history of single letter TLDs, my understanding is that the real motivation for not allowing them is about confusion. Let me dig up a note on this and forward separately. > > understanding is that the main motivation for such a rule is to avoid > > user confusion and avoid having a single typo change TLD 'a' to some > > other TLD and then cause lookup from the wrong site. > No, the motivation is that there's never been a single-character TLD, > and therefore adding one could break some hard coded assumptions. > Adding >3-character TLDs sure did, and there already _were_ some of > those. Right. But then we should document the concern, and not necessarily say MUST or MUST NOT. At least not a blanket statement without explaining what must be done first (e.g., first survey deployed software to find out how significant the concern actually is in practice, etc.). > > I think this document should go review the history a bit, the various > > confusions (DNS vs. host name), note that we don't ever want any DNS > > name to be confused with something that inet_pton() would convert, > > etc. And so forth. > I think that would be an excellent project after we got this draft out > the door, because anything that involves (1) the history of the DNS or > (2) anything but the most cosmetic, trivial, or obviously right > alterations to the rules risks going into IETF DoS hell. To trot out > my favourite personal example, the reverse-mapping-considerations > draft that went to DNSOP WGLC said very little more substantive than, > "Some people like the reverse tree. You should maintain it for your > site. Or, not, if you don't want to. Also, if you use the reverse > tree, don't rely on it too much. But use it if you want." Even this > apparently bland claim was unable to make it past the WG, and died. I > suspect that if a draft came to the DNS community that said, "DNS > exists and (A or not-A)," there would be someone at the mic ready to > complain. If we want to make progress, let's make it in small > increments. I don't see the reverse tree analogy the same. But anyway, this concern would be better discussed in the context of specific proposed changes/text that would allow us to evaluate specific items on their merits. > > Can someone here restate what (if any) issues exist with moving this > > document forward? And should it be a WG document rather than an > > individual submission? > It should become a WG item, yes. It seems to be an operational rule > about content of the root zone, so it belongs in DNSOP (but DNSEXT is > willing to take it if the DNSOP Chairs want us to. Careful what you > wish for: we just sent our AD the request to get our new charter out, > and this sure ain't on it). I expect that, as with most DNS > documents, the main problem is author's time. Yeah. It straddles the two WGs. Probably dnsop, as this isn't changing what the protocol allows, just the operational practices around what is advisable about TLD labels. Then again, the original DNS specs is where the current language is... Thomas From ajs@shinkuro.com Wed Aug 26 06:29: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 CAD2F3A6902 for ; Wed, 26 Aug 2009 06:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=2.872, 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 JoAI8bfrv3BJ for ; Wed, 26 Aug 2009 06:29:01 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 060333A67B1 for ; Wed, 26 Aug 2009 06:29:01 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2BD5C2FE8CBB; Wed, 26 Aug 2009 13:27:47 +0000 (UTC) Date: Wed, 26 Aug 2009 09:27:45 -0400 From: Andrew Sullivan To: Thomas Narten Message-ID: <20090826132745.GC6533@shinkuro.com> References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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, 26 Aug 2009 13:29:01 -0000 On Wed, Aug 26, 2009 at 08:28:08AM -0400, Thomas Narten wrote: > > Partly, this is a defensive measure against certain parties who warned > > they'd kick and scream if anything more than that were done. > > Right. Can you (or anyone) state what some of these other areas are? I > may well not be inclined to go there either, so we may be in violent > agreement... One of them is, in fact, allowing single-letter TLDs. Another is allowing TLDs that start with a number. Really, the feedback I got (and it was from one of the people who often appears on IETF BINGO cards, if that helps you narrow it down) was that we should do nothing more than adjust the rule _exactly_ enough to allow A-labels to be inserted in the root zone, and no more, or we'd face a nasty slog of a fight. The real motivation for that might well be as a proxy for a policy argument that the individual doesn't want to have, but the argument presented was on the basis of conservatism with what changes one would allow in the root zone, because of its sensitivity. My _personal_ preference is probably more aligned with yours: I think we should merely require that no TLD be confusable with either an octet or a numeric address, because otherwise there's no automatic way to tell whether something is an address or a name; in practice this means "never starts with a number" and that's probably it. To me, anything more is policy. But we got into this mess because 1123 appears to have conflated policy and protocol (or at least, some have interpreted it that way), and therefore I can at least follow the argument that the technically correct thing to do is to leave as much unchanged as practical. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From liman@autonomica.se Fri Aug 28 12:58: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 6F2CD3A6900 for ; Fri, 28 Aug 2009 12:58: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 nTn9X4UWag98 for ; Fri, 28 Aug 2009 12:58:53 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 871733A6C6B for ; Fri, 28 Aug 2009 12:58: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 n7SJwUWs024852; Fri, 28 Aug 2009 21:58:30 +0200 (MEST) Received: from zaptop.autonomica.net (zaptop.autonomica.net [172.22.1.108]) by home.liman.net (8.14.3/8.14.3) with ESMTP id n7SJwR5s025033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2009 21:58:29 +0200 (MEST) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n7SJwLwj021540; Fri, 28 Aug 2009 21:58:21 +0200 (CEST) To: Thomas Narten References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> From: Lars-Johan Liman Date: Fri, 28 Aug 2009 21:58:21 +0200 In-Reply-To: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Tue\, 25 Aug 2009 12\:01\:47 -0400") Message-ID: <22ljl3r9r6.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: Fri, 28 Aug 2009 19:58:54 -0000 narten@us.ibm.com: > Hi All. Hi. I _am_ still alive, despite rumours of the opposite ... I am, however, beginning to understand how submarine captains relate to the world ... > Tina Dam has asked me to try and move this document along. ICANN > thinks they need it as an RFC before they launch IDNs. It appears to > have been sitting since March... Mea culpa. > In reviewing this document, I think it would benefit from some edits > that make it more clear what this document is trying to solve and > what it is not. (Just saying "clears up ambiguities" isn't direct > enough, IMO.) > Even in going back and reviewing the mail thread on dnsop in March, > I'm not entirely clear what this document is trying to fix. Also, > there is much confusion (FUD?) in this space, and I think this > document would be a fine place to do away with some of this. My defence for writing the document in the style it has, is that I wanted to start out with a very strict and limited definition, with the goal of opening it up just the right amount to satisfy "general consensus", and any technical specifications that we need to meet. By being strict, I also _wanted_ to provo^H^H^H^H^H engourage discussion, so that there would be statements to look at when I/we needed to decide what the consensus was. If you try to get it right from the start, fewer people will speak their mind, and there will be less data (fewer "votes") when the consensus is polled. (Limping English here, sorry.) So, you (or anyone else) don't have to be shy to express disagreement - that's what I wanted to encourage with the -00 version, and that's what I hoped for. > Some random thoughts (which may not be right). > I think this document cannot say that TLDs MUST be 2 characters > long. What is the technical basis for such a recommendation? My > understanding is that the main motivation for such a rule is to avoid > user confusion and avoid having a single typo change TLD 'a' to some > other TLD and then cause lookup from the wrong site. That is a fine > concern, but we have single letter labels below TLDs, so how big a > problem this is is open for debate. I think it would be fine to state > something like that, but leave it to ICANN to decide. Unless someone > can point me to a real technical argument. Right now, the document > just says it MUST be 2 characters, with no supporting reasoning. Typical provocation on my part. I wanted people to scream exactly in the way you do, and now I have one more ballot in my consensus building tool box. Thank you! :-) My personal take is that an RFC should say precious little about what names can go in there, as long as they adhere to the technical specifications for DNS labels. The only strong feeling I have, is that I would like to keep the rule that they cannot be digits only. If you allow for digits only, you can construct domain names that look like 10.2.3.4 (with "4" being the TLD), and it is obviously impossible for software to know whether that is a domain name or a literal IPv4 address. By disallowing digits only, we make sure that that cannot happen. I believe there is a rule (or folklore) that requires that "not the entire domain name be make up from digits", but that rule is impossible to enforce (DNS layering violation! ;-), but by imposing a simpler rule on the root, we can avoid the problem. I also believe that the general idea of "starting out strict" is the right way to go. It is always easier to open up more in the future, then to try to impose stricter limitations at a later stage. However, the strictness can be applied for different reasons, and by different bodies. I.e., I can live with a system where this document is fairly permitting, but where a policy document (by ICANN?) sets a more limited policy, for reasons that are not necessarily strictly technical. I can, however, foresee that that might be difficult to defend to some parts of the "general public". If we can find technical motivations for keeping things strict, I think that will be easier to defend, thereby taking some pressure off ICANN and Tina. > I think this document should go review the history a bit, the various > confusions (DNS vs. host name), note that we don't ever want any DNS > name to be confused with something that inet_pton() would convert, > etc. And so forth. Where is the history to be found? There is oral folklore out there, but I would appreciate pointers to more solid documents. I believe one of the problems, and reasons for writing this document, is that there are too few solid documents out there. > Thoughts? > Can someone here restate what (if any) issues exist with moving this > document forward? And should it be a WG document rather than an > individual submission? Some issues were raised at the DNSOP meeting in SFO. I was presenting at the time, so I hope there are some notes, either in the minutes from the meeting, and/or in the jabber logs. I would like those issues to be at least looked at, so that I/we make sure that we don't miss anything critical. There are, AFAIK, no formal resons to not forward this document, but it is too raw as it stands. (More comments in follow-ups.) Cheers, /Liman From liman@autonomica.se Fri Aug 28 13:09:39 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 E3C063A6BAD for ; Fri, 28 Aug 2009 13:09:39 -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 PI7EV4dew19O for ; Fri, 28 Aug 2009 13:09:39 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id B03DC3A6D9A for ; Fri, 28 Aug 2009 13:09:38 -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 n7SK9Jjp015571; Fri, 28 Aug 2009 22:09:19 +0200 (MEST) Received: from zaptop.autonomica.net (zaptop.autonomica.net [172.22.1.108]) by home.liman.net (8.14.3/8.14.3) with ESMTP id n7SK9HbO019513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2009 22:09:18 +0200 (MEST) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n7SK9Ej1021588; Fri, 28 Aug 2009 22:09:14 +0200 (CEST) To: Andrew Sullivan References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> <20090826132745.GC6533@shinkuro.com> From: Lars-Johan Liman Date: Fri, 28 Aug 2009 22:09:14 +0200 In-Reply-To: <20090826132745.GC6533@shinkuro.com> (Andrew Sullivan's message of "Wed\, 26 Aug 2009 09\:27\:45 -0400") Message-ID: <22ab1jr991.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: Thomas Narten , 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: Fri, 28 Aug 2009 20:09:40 -0000 ajs@shinkuro.com: > One of them is, in fact, allowing single-letter TLDs. Another is > allowing TLDs that start with a number. Really, the feedback I got > (and it was from one of the people who often appears on IETF BINGO > cards, if that helps you narrow it down) was that we should do nothing > more than adjust the rule _exactly_ enough to allow A-labels to be > inserted in the root zone, and no more, or we'd face a nasty slog of a > fight. The real motivation for that might well be as a proxy for a > policy argument that the individual doesn't want to have, but the > argument presented was on the basis of conservatism with what changes > one would allow in the root zone, because of its sensitivity. Well, I see one of the problems being that it is not quite cast in stone what the current rules allow for. There are so many stones, and the runes describe the problem from different angles, so it's not easy to deduct what the current rules are. That situation is also a reason to write a document like this one, so that there would be one document, which (hopefully) unambiguously defines what ther rules are. No more (RFC 1035 + RFC 1123 - RFC 1597) * 20 years of experience. > My _personal_ preference is probably more aligned with yours: I think > we should merely require that no TLD be confusable with either an > octet or a numeric address, because otherwise there's no automatic way > to tell whether something is an address or a name; in practice this > means "never starts with a number" and that's probably it. Umm, as per my previous message, isn't "not all digits" sufficient to reach that goal? Is "10.1.2.3com" too risky? > To me, anything more is policy. Amen! > But we got into this mess because 1123 appears to have conflated > policy and protocol (or at least, some have interpreted it that > way), and therefore I can at least follow the argument that the > technically correct thing to do is to leave as much unchanged as > practical. You put it so well. Thank you. The problem is just defining what we don't want to change, i.e., the starting point. ;-) Cheers, /Liman From liman@autonomica.se Fri Aug 28 13:14: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 1A1CD3A6A07 for ; Fri, 28 Aug 2009 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-1.620, BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_LWSHORTT=1.24] 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 iUaS8-mteEUD for ; Fri, 28 Aug 2009 13:14:11 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 139AD3A693F for ; Fri, 28 Aug 2009 13:14:10 -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 n7SKDtHf017857; Fri, 28 Aug 2009 22:13:55 +0200 (MEST) Received: from zaptop.autonomica.net (zaptop.autonomica.net [172.22.1.108]) by home.liman.net (8.14.3/8.14.3) with ESMTP id n7SKDsYb011193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2009 22:13:54 +0200 (MEST) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n7SKDpHw021604; Fri, 28 Aug 2009 22:13:51 +0200 (CEST) To: Tina Dam 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> From: Lars-Johan Liman Date: Fri, 28 Aug 2009 22:13:51 +0200 In-Reply-To: <05B243F724B2284986522B6ACD0504D7C083C6A7F3@EXVPMBX100-1.exc.icann.org> (Tina Dam's message of "Thu\, 27 Aug 2009 10\:08\:29 -0700") Message-ID: <22y6p3pugw.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: Thomas Narten , 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: Fri, 28 Aug 2009 20:14:12 -0000 tina.dam@icann.org: > All, just catching up on this note. A few comments: > 1) I agree that we should do this as minimal as possible, and goal is > to allow A-label TLDs. At least that is the short term goal. > 2) on the digit concern, I previously agreed with the authors that > this did not belong in the RFC but instead should be controlled by > ICANN. Currently ICANN does not allow leading or trailing digits in > TLDs. It does not really matter to me where that rule sits, as long as > it is observed. The reason for the ICANN requirement was not "just" > the confusability with octets or numeric addresses but also due to the > results we see with leading trailing digits in a right-to-left > environment. Because this is a new area it was thought that we better > be conservative and restrict it completely. That is indeed a valid remark, IMO. This should be documented in the draft, and that makes the motivation for such a rule even stronger. > Also, please let me know what I can help with to get this finalized. I > do believe it is necessary in order for ICANN not to be in violation > of the RFC when launching IDN TLDs. I still haven't heard any voices from the DNSOP chairs. I suppose they are busy building a solid case defending how to make this document _not_ end up on their table ... (Hi, Peter and Rob! ;-). Cheers, /Liman From ogud@ogud.com Fri Aug 28 14:50:44 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 73A833A6985 for ; Fri, 28 Aug 2009 14:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 DSMVR3Qlkxvd for ; Fri, 28 Aug 2009 14:50:43 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9549D3A67E1 for ; Fri, 28 Aug 2009 14:50:43 -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 n7SLojkr017801; Fri, 28 Aug 2009 17:50:45 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200908282150.n7SLojkr017801@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Aug 2009 17:50:10 -0400 To: Lars-Johan Liman From: Olafur Gudmundsson In-Reply-To: <22y6p3pugw.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> 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: Thomas Narten , 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: Fri, 28 Aug 2009 21:50:44 -0000 At 11:45 28/08/2009, Lars-Johan Liman wrote: >I still haven't heard any voices from the DNSOP chairs. I suppose they >are busy building a solid case defending how to make this document >_not_ end up on their table ... (Hi, Peter and Rob! ;-). I will suggest we do not send this to any working group but that one or more of our AD's sponsor this to be an BCP. Any takers ? Olafur From tina.dam@icann.org Thu Aug 27 10:09:04 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 62F8528C2AC for ; Thu, 27 Aug 2009 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 H364ZCTdKRBC for ; Thu, 27 Aug 2009 10:09:03 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id E842128C246 for ; Thu, 27 Aug 2009 10:08:51 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 27 Aug 2009 10:08:59 -0700 From: Tina Dam To: Andrew Sullivan , Thomas Narten Date: Thu, 27 Aug 2009 10:08:29 -0700 Thread-Topic: [dns-dir] draft-liman-tld-names-00 Thread-Index: AcomUQ2At3k9o2s0StqA0ZZqcAzGLgA5zIYQ Message-ID: <05B243F724B2284986522B6ACD0504D7C083C6A7F3@EXVPMBX100-1.exc.icann.org> References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> <20090826132745.GC6533@shinkuro.com> In-Reply-To: <20090826132745.GC6533@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 29 Aug 2009 11:56:16 -0700 Cc: 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, 27 Aug 2009 17:09:04 -0000 All, just catching up on this note. A few comments: 1) I agree that we should do this as minimal as possible, and goal is to al= low A-label TLDs. 2) on the digit concern, I previously agreed with the authors that this did= not belong in the RFC but instead should be controlled by ICANN. Currently= ICANN does not allow leading or trailing digits in TLDs. It does not reall= y matter to me where that rule sits, as long as it is observed. The reason = for the ICANN requirement was not "just" the confusability with octets or n= umeric addresses but also due to the results we see with leading trailing d= igits in a right-to-left environment. Because this is a new area it was tho= ught that we better be conservative and restrict it completely. Also, please let me know what I can help with to get this finalized. I do b= elieve it is necessary in order for ICANN not to be in violation of the RFC= when launching IDN TLDs.=20 Tina > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com] > Sent: Wednesday, August 26, 2009 6:28 AM > To: Thomas Narten > Cc: liman@autonomica.se; Tina Dam; dns directorate > Subject: Re: [dns-dir] draft-liman-tld-names-00 >=20 > On Wed, Aug 26, 2009 at 08:28:08AM -0400, Thomas Narten wrote: >=20 > > > Partly, this is a defensive measure against certain parties who > warned > > > they'd kick and scream if anything more than that were done. > > > > Right. Can you (or anyone) state what some of these other areas are? > I > > may well not be inclined to go there either, so we may be in violent > > agreement... >=20 > One of them is, in fact, allowing single-letter TLDs. Another is > allowing TLDs that start with a number. Really, the feedback I got > (and it was from one of the people who often appears on IETF BINGO > cards, if that helps you narrow it down) was that we should do nothing > more than adjust the rule _exactly_ enough to allow A-labels to be > inserted in the root zone, and no more, or we'd face a nasty slog of a > fight. The real motivation for that might well be as a proxy for a > policy argument that the individual doesn't want to have, but the > argument presented was on the basis of conservatism with what changes > one would allow in the root zone, because of its sensitivity. >=20 > My _personal_ preference is probably more aligned with yours: I think > we should merely require that no TLD be confusable with either an > octet or a numeric address, because otherwise there's no automatic way > to tell whether something is an address or a name; in practice this > means "never starts with a number" and that's probably it. To me, > anything more is policy. But we got into this mess because 1123 > appears to have conflated policy and protocol (or at least, some have > interpreted it that way), and therefore I can at least follow the > argument that the technically correct thing to do is to leave as much > unchanged as practical. >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. From peter@denic.de Sun Aug 30 12:59:50 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 95DBE3A6BC0 for ; Sun, 30 Aug 2009 12:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 6sbo8W16Rs+l for ; Sun, 30 Aug 2009 12:59:49 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 63B643A69A5 for ; Sun, 30 Aug 2009 12:59:46 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MhqZ5-0007v7-2u; Sun, 30 Aug 2009 21:59:51 +0200 Received: from localhost by x27.adm.denic.de with local id 1MhqZ4-0003Li-VC; Sun, 30 Aug 2009 21:59:51 +0200 Date: Sun, 30 Aug 2009 21:59:50 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20090830195950.GE30426@x27.adm.denic.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22y6p3pugw.fsf@zaptop.autonomica.net> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: Tina Dam 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: Sun, 30 Aug 2009 19:59:50 -0000 On Fri, Aug 28, 2009 at 10:13:51PM +0200, Lars-Johan Liman wrote: > tina.dam@icann.org: > > All, just catching up on this note. A few comments: > > > 1) I agree that we should do this as minimal as possible, and goal is > > to allow A-label TLDs. > > At least that is the short term goal. Not sure we should actually be so narrowly focussed since it looks like "lip service" on a protocol level. From an IETF point of view I'd say we somehow found that the phrase "will be alphabetic" appears to be ambiguous to say the least. It is unclear whetehr it's normative and when it's normative whether that's a protocol or a policy statement. For confusability in the context of that same paragraph, "will not be digit-only" would be fine (and maintain the ambiguity, but that's a different issue). It is this and the extreme positioning of "-" that we should be concerned about here. ``xn--'' (and inner dashes) would return into protocol boundaries as a side effect. > > 2) on the digit concern, I previously agreed with the authors that > > this did not belong in the RFC but instead should be controlled by > > ICANN. Currently ICANN does not allow leading or trailing digits in > > TLDs. It does not really matter to me where that rule sits, as long as > > it is observed. The reason for the ICANN requirement was not "just" > > the confusability with octets or numeric addresses but also due to the > > results we see with leading trailing digits in a right-to-left > > environment. Because this is a new area it was thought that we better > > be conservative and restrict it completely. > > That is indeed a valid remark, IMO. This should be documented in the > draft, and that makes the motivation for such a rule even stronger. IMHO we (==IETF) should constrain ourselves to solve an observed ambiguity. ICANN is to set the policy and if there are valid reasons for restrictions, they don't completely have to originate from IETF documents. If there are special conceerns with digits in IDN TLDs, that's something hopefully covered in operational connsiderations in IDN documents, at least it is different from the 1123 amendment. > > Also, please let me know what I can help with to get this finalized. I > > do believe it is necessary in order for ICANN not to be in violation > > of the RFC when launching IDN TLDs. > > I still haven't heard any voices from the DNSOP chairs. I suppose they > are busy building a solid case defending how to make this document > _not_ end up on their table ... (Hi, Peter and Rob! ;-). First, given the sensitivity of the topic, I don't think an individual submission sets the right signal. I know that some core IETF protocols have been worked on this way recently, but it's my firm belief this is a step in the wrong direction. Open discussion is key here and for BCP or STD track, there'd be an main IETF list debac^Hte anyway. I'm happy to have the discussion continue on dnsop. FWIW, the draft is about to expire in a few days. Best regards, Peter From liman@autonomica.se Sun Aug 30 13:45:30 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 1391728C13D for ; Sun, 30 Aug 2009 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.460, 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 q0zaM0Ozkufh for ; Sun, 30 Aug 2009 13:45:29 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 28DE13A6CD2 for ; Sun, 30 Aug 2009 13:45:28 -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 n7UKjYm5007088; Sun, 30 Aug 2009 22:45:34 +0200 (MEST) Received: from zaptop.autonomica.net (zaptop.autonomica.net [172.22.1.108]) by home.liman.net (8.14.3/8.14.3) with ESMTP id n7UKjYUn010998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Aug 2009 22:45:34 +0200 (MEST) Received: from zaptop.autonomica.net (localhost [IPv6:::1]) by zaptop.autonomica.net (8.14.3/8.14.3) with ESMTP id n7UKjR2Q001100; Sun, 30 Aug 2009 22:45:29 +0200 (CEST) To: Olafur Gudmundsson 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> From: Lars-Johan Liman Date: Sun, 30 Aug 2009 22:45:27 +0200 In-Reply-To: <200908282150.n7SLojkr017801@stora.ogud.com> (Olafur Gudmundsson's message of "Fri\, 28 Aug 2009 17\:50\:10 -0400") Message-ID: <22ab1hrpy0.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: Thomas Narten , 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: Sun, 30 Aug 2009 20:45:30 -0000 ogud@ogud.com: > I will suggest we do not send this to any working group but that > one or more of our AD's sponsor this to be an BCP. Any takers ? That was the original plan, IIRC. I'm can go either way, but I think that if we do need timely results, and we don't want World War III, that your proposal is probably the better. It _is_ policy stuff, rather than technical development ... or at least policy is an important ingredient. ;-) Cheers, /Liman