Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f3UJeqIj002712 for ietf-provreg-outgoing; Mon, 30 Apr 2001 21:40:52 +0200 (MEST) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3UJeoLt002707 for ; Mon, 30 Apr 2001 21:40:51 +0200 (MEST) Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id MAA18809 for ; Mon, 30 Apr 2001 12:39:59 -0700 (PDT) Date: Mon, 30 Apr 2001 12:40:48 -0700 (PDT) From: Rick H Wesson To: "'ietf-provreg@cafax.se'" Subject: VeriSign Patents on Registries/Registrars and other readings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk all: below are some patents that Verisign has applied for, I thought some of you may be interested in these applications as they may impact some of your businesses if granted. I found these by searching for "VERISIGN" in wipo's database at http://pctgazette.wipo.int/ -rick WO 99/09726 - METHOD OF DETERMINING UNAVAILABILITY OF INTERNET DOMAIN NAMES Methods, systems, and articles of manufacture consistent with the present invention provide an improved query server that overcomes the shortcomings of existing domain name searching techniques by performing a multitude of searches simultaneously, transparent to the user. Specifically, the improved query server searches for existing domain name records in various domains and then displays the results in a formatted manner, thus eliminating the need for a user to perform individual searches. WO 01/20484 - METHODS AND APPARATUS FOR ESTABLISHING AND MAINTAINING INERNET DOMAIN NAME REGISTRATIONS Methods and apparatus for conducting transactions associated with managing Internet domain names includes establishing a connection between application programs of other users and a registrar of Internet domain names over the Internet, authenticating the right of the user to so request fulfillment of a transaction, establishing a secure socket layer within the connection and processing commands after such authentication. WO 00/65511 - A SHARED REGISTRATIONS SYSTEM FOR REGISTERING DOMAIN NAMES An apparatus and method for processing a domain name registration operation in a shared registration system is provided. A registry receives a request for performing a domain name registration operation from a registrar. The registry performs an authenticationof the registrar that sent the request. The registrar is determined to be authenticated, the registry then determines whether the registrar is authorized to perform an action necessitated by the operation. Subsequently, the registry executes the operation based on a determination that the registrar is authorized and stores changes necessitated by the operation in a database. A response indicating success or failure of the operation is sent to the registrar. WO 00/65507 - BUSINESS RULE ENGINE Methods and systems consistent with the present invention solve the inherent problems with existing systems that incorporate business rules by providing a business rule engine (BRE) that serves as a business rule repository for business rules. Specifically, the BRE maintains a collection of both rules and targets and an association between the rules and targets for e-commerce applications. Each time a client accesses an e-commerce application which triggers a business procedure (target) to execute a set of policies (rules), the application queries the BRE for a list of rules, and an order to apply the rules in response to the client's request. The BRE also provides a facility to modify, add, or delete both business rules and targets and modify the order of execution by the application. WO 00/57611 - APPARATUS AND METHOD FOR WEB FORWARDING An apparatus and method for forwarding a web address to another web address is presented. A web forwarder receives a request destined to a first web address including at least a domain name. The web forwarder then determines a forwarding uniform resource locator (URL) that corresponds to the domain name and redirects the request to a second web address that corresponds to the forwarding URL. WO 00/57298 - DOT COM BUSINESS CARD An apparatus and method for providing a single page web site is presented. A list of one or more domain names is displayed. Each domain name has either an associated link for purchasing a web page or an associated link for managing the web page. Information is stored indicating that a web page is associated with a selected domain name based on a determination that a link is selected for purchasing the associated web page. If a link is selected for managing the associated web page, then a customer is directed to a web page or web site for editing the associated web page. Return-Path: Received: by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f3UB7925029820 for ietf-provreg-outgoing; Mon, 30 Apr 2001 13:07:09 +0200 (MEST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3UB77Lt029815 for ; Mon, 30 Apr 2001 13:07:08 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04749; Mon, 30 Apr 2001 07:07:07 -0400 (EDT) Message-Id: <200104301107.HAA04749@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-02.txt Date: Mon, 30 Apr 2001 07:07:06 -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Generic Registry-Registrar Protocol Requirements Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-grrp-reqs-02.txt Pages : 25 Date : 27-Apr-01 This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-grrp-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010427152808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-grrp-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152808.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3KDv8t1020146 for ietf-provreg-outgoing; Fri, 20 Apr 2001 15:57:08 +0200 (MEST) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3KDv7Lt020141 for ; Fri, 20 Apr 2001 15:57:07 +0200 (MEST) Received: by sentry.gw.tislabs.com; id KAA01929; Fri, 20 Apr 2001 10:00:50 -0400 (EDT) Received: from dhcp20.gw.tislabs.com(192.94.214.120) by sentry.gw.tislabs.com via smap (V5.5) id xma001875; Fri, 20 Apr 01 10:00:29 -0400 X-Sender: lewis@pop.tislabs.com (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Apr 2001 09:51:17 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Subject: was RE: Question about draft-hollenbeck-epp-tcp-01.txt Cc: "'George Belotsky'" , ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:05 PM -0400 4/13/01, Hollenbeck, Scott wrote: >The subject document isn't yet a provreg WG work item. The discussion list >for the document is the NSI RRP mailing list until the WG decides to pick it >up. Since you asked the question here, though... Actually, it is valuable to discuss on this list non-WG documents that relate to the business at hand. These include James' and Eric's documents as well as the rest of the epp mappings. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3KCB59U019235 for ietf-provreg-outgoing; Fri, 20 Apr 2001 14:11:05 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3KCB4Lt019230 for ; Fri, 20 Apr 2001 14:11:04 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA24655; Fri, 20 Apr 2001 08:10:32 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0H87>; Fri, 20 Apr 2001 08:03:36 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Rick H Wesson'" , "'ietf-provreg@cafax.se'" Subject: RE: authinfo in updates/transfers Date: Fri, 20 Apr 2001 08:03:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Rick H Wesson [mailto:wessorh@ar.com] >Sent: Thursday, April 19, 2001 12:47 PM >To: 'ietf-provreg@cafax.se' >Subject: authinfo in updates/transfers > > > >folks, > >in scotts latest drafts a list a requirement fro authorization >for object >update. I request the follomg be removed from the requirements. > >3.4.4 Object Update > > ... > > [4] The protocol MUST provide services to confirm registrar > authorization to update an object. Two other requirements are related to this one: 3.4.6-[3] and 3.4.7-[4]. If 3.4.4-[4] goes, so should the other two. If no one objects I'll add this to the list of things to be fixed prior to IETF last call. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3JGkom4013135 for ietf-provreg-outgoing; Thu, 19 Apr 2001 18:46:50 +0200 (MEST) Received: from ibd.ar.com (ibd.ar.com [63.194.205.75]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3JGkmLt013130 for ; Thu, 19 Apr 2001 18:46:49 +0200 (MEST) Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id JAA29018 for ; Thu, 19 Apr 2001 09:46:18 -0700 (PDT) Date: Thu, 19 Apr 2001 09:46:47 -0700 (PDT) From: Rick H Wesson To: "'ietf-provreg@cafax.se'" Subject: authinfo in updates/transfers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk folks, in scotts latest drafts a list a requirement fro authorization for object update. I request the follomg be removed from the requirements. 3.4.4 Object Update ... [4] The protocol MUST provide services to confirm registrar authorization to update an object. There is no need to transmit authentication information for an object that only the registrar of record is allowed to update. There is no reason to transmit this information. If someone has a good reason for this requirement PLEASE speak now. I understand that the information is required for a transfer and I am NOT suggesting that requirement be removed for transfers. best regards, -rick Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3IB0DBi002786 for ietf-provreg-outgoing; Wed, 18 Apr 2001 13:00:13 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3IB0CLt002781 for ; Wed, 18 Apr 2001 13:00:12 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA18992 for ; Wed, 18 Apr 2001 07:00:12 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0GTW>; Wed, 18 Apr 2001 06:53:20 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Document Last Call Summary: Unresolved Items Date: Wed, 18 Apr 2001 06:53:12 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 3 April 2001, Ed Lewis issued a WG last call on this document: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt Here's a pointer to the announcement: http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00004.html What follows is a high-level summary of discussion during the last call period for which there was disagreement among list members. Additional discussion, or chair action to determine rough consensus, is required before document impact can be assessed. 1. Issues on 3.4.9 Object Information Query http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00053.html There was a discussion of adding a requirement for a query to report more abstract object relationships, but differing opinions on the appropriateness of adding such a requirement. This relates to issues also described in #2 and #3 below. A compromise proposal to document the existence of relationships was offered since there doesn't seem to be a consensus position on the changes suggested in the original comment. 2. comments on last draft http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00085.html There was a discussion touching on multiple topics; the final open points appear to relate to the abstract object relationship query questions first raised in #1 (see above) and the appropriateness of adding a requirement relating to back-end registry validation procedures. 3. 3.4/Object Ownership, esp. Name Server Ownership http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00091.html There was a discussion relating to name server management and operational issues with the restrictive management model described in the draft. Issues with the restrictive model and a more open model relating to #1 above were described, and discussion did not produce a clear preference. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3IAxiZE002769 for ietf-provreg-outgoing; Wed, 18 Apr 2001 12:59:44 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3IAxgLt002764 for ; Wed, 18 Apr 2001 12:59:43 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA18988 for ; Wed, 18 Apr 2001 06:59:42 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0GTV>; Wed, 18 Apr 2001 06:52:50 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-provreg@cafax.se'" Subject: Document Last Call Summary: Resolved Items Date: Wed, 18 Apr 2001 06:52:45 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk On 3 April 2001, Ed Lewis issued a WG last call on this document: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt Here's a pointer to the announcement: http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00004.html What follows is a high-level summary of discussion during the last call period for which there seems (based on my observation of the discussions) to be agreement. Specific document changes suggested during the last-call process are described here; I intend to implement these changes prior to subjecting the document to an IETF-wide last call. Some of these discussions _did_ result in some issues for which I'm unsure that we have consensus, and those issues will be documented in a second summary message. 1. Nameserver MUST HAVE IP http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00015.html Specific change: 3.4.2-[3]; existing text: Name servers registered within the registry's authoritative TLDs MUST be registered with a valid IPv4 or IPv6 address. will be changed to: Name servers MUST be registered with valid IPv4 or IPv6 address when a "glue record" is REQUIRED for domain delegation. 2. Re: Provreg WG Last Call announcement http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00044.html This was a question that does not require document revision. 3. International Issues @ 3.4.2[6] and 9. http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00051.html I don't believe that any change is required: http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00069.html 4. Issues on 3.4.5. Object Transfer http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00052.html New requirement added to section 3.4.5: The protocol MUST provide services to describe all objects, including associated objects, that are transferred as a result of an object transfer. 5. Issues on 3.4.9 Object Information Query http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00053.html New requirement added to section 3.4.9: The protocol MUST provide services to identify all associated object references, such as name servers associated with domains (including delegations and hierarchical relationships) and contacts associated with domains. This information MUST be visible if the object associations have an impact on the success or failure of protocol operations. 6. Re: Provreg WG Last Call (8.4 Data Collection Requirements) http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00074.html Specific change: 8.4-[1]; existing text: A generic protocol MUST provide services to identify information whose disclosure is not strictly required for technical reasons. will be changed to: A generic protocol MUST provide services to identify data collection policies. Specific change: remove 8.4-[2]. 7. 3.4.9 [4] http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00077.html This was a question that does not require document revision. 8. comments on last draft http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00085.html Specific change: 1.1; existing text: Thin Registry: A registry in which some element of the social information... will be changed to: Thin Registry: A registry in which all elements of the social information... 9. A Comment on 9. [1] of the requirements document. http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00116.html Specific change: 9.-[1]; existing text: [RFC1035] restricts the encoding of Internet host and domain names in the DNS to a subset of the 7-bit US-ASCII character set. will be changed to: [RFC1035] describes Internet host and domain names using characters traditionally found in a subset of the 7-bit US-ASCII character set. 10. IPv6, was: Nameserver MUST HAVE IP http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00133.html This was a question that does not require document revision. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3HJ5Cmo027366 for ietf-provreg-outgoing; Tue, 17 Apr 2001 21:05:12 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3HJ59Lt027361 for ; Tue, 17 Apr 2001 21:05:12 +0200 (MEST) Received: from [192.168.2.116] (helo=[10.10.27.161]) by rcommail2 with esmtp (Exim 3.16 #2) id 14paiD-0004x0-00; Tue, 17 Apr 2001 15:00:29 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <3ADC0B30.9987594A@knipp.de> References: <3ADC0B30.9987594A@knipp.de> Date: Tue, 17 Apr 2001 14:59:50 -0400 To: Klaus Malorny , "Hollenbeck, Scott" From: "Jordyn A. Buchanan" Subject: Re: Issues on 3.4.9 Object Information Query Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:21 AM +0200 4/17/01, Klaus Malorny wrote: > >Nevertheless I don't think we get a full consensus on this topic. But to end >the discussion for now, I would be glad just to have some indicators that show >that an object is referenced by others and therefore cannot be deleted. As far >as I understand the e-mails, this is something that the discussion >participants could agree upon. I think we can all agree on that. Jordyn Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3HCA2Tv024646 for ietf-provreg-outgoing; Tue, 17 Apr 2001 14:10:02 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3HCA1Lt024641 for ; Tue, 17 Apr 2001 14:10:01 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA15865; Tue, 17 Apr 2001 08:09:23 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0F7K>; Tue, 17 Apr 2001 08:02:34 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: IPv6, was: Nameserver MUST HAVE IP Date: Tue, 17 Apr 2001 08:02:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Tuesday, April 17, 2001 5:57 AM >To: ietf-provreg@cafax.se >Subject: IPv6, was: Nameserver MUST HAVE IP > > > > >One short question regarding the appearance of "IPv6" in 3.4.2[2]. Is this an >address according to RFC 1886, i.e. a full 128 bit address/AAAA record, or an >address according to RFC 2874, i.e. a partial address with a prefix/A6 record >chain, or any of both? Do we need to detail this in the requirements document? Just as there is no reference to the specification of an IPv4 address in the requirements draft, the specification of an IPv6 address isn't a requirement issue but a protocol specification issue. Jumping ahead, though, I believe the proper reference to define IPv6 address syntax for protocol purposes is RFC1883. 1886 and 2874 describe DNS extensions to support IPv6 (that is, how the addresses are represented in the DNS), which is probably something that may differ from registry to registry. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3H9swKS024105 for ietf-provreg-outgoing; Tue, 17 Apr 2001 11:54:58 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3H9svLt024100 for ; Tue, 17 Apr 2001 11:54:57 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA06299; Tue, 17 Apr 2001 11:54:56 +0200 (METDST) Message-ID: <3ADC1386.8248C1DD@knipp.de> Date: Tue, 17 Apr 2001 11:57:26 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: IPv6, was: Nameserver MUST HAVE IP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk One short question regarding the appearance of "IPv6" in 3.4.2[2]. Is this an address according to RFC 1886, i.e. a full 128 bit address/AAAA record, or an address according to RFC 2874, i.e. a partial address with a prefix/A6 record chain, or any of both? Do we need to detail this in the requirements document? regards Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3H9JWge023960 for ietf-provreg-outgoing; Tue, 17 Apr 2001 11:19:32 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3H9JVLt023955 for ; Tue, 17 Apr 2001 11:19:31 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA23820; Tue, 17 Apr 2001 11:19:21 +0200 (METDST) Message-ID: <3ADC0B30.9987594A@knipp.de> Date: Tue, 17 Apr 2001 11:21:52 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: "Jordyn A. Buchanan" , ietf-provreg@cafax.se Subject: Re: Issues on 3.4.9 Object Information Query References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > I understand, and I am not disputing that there is a need for this > information. We are disagreeing on the reporting/delivery method. > > VeriSign (then NSI Registry) actually implemented this sort of > reverse-relationship query service via the NSI RRP in the early days of the > SRS test bed. Requesting information about a name server would include a > list of all domains delegated to the server. It quickly became clear to us > (with only six registrars) that this service was unworkable via the protocol > due to serious server-side memory management and DB performance > requirements, and we were working with the best commercial hardware and > software available at the time. > > I still believe that a different query protocol or offline reporting > services is the most efficient way to provide the potentially large volume > of information associated with contact and name server relational queries. > However, if part of the problem is that it's not obvious when object > relationships exist, would it be an acceptable compromise to make it > completely obvious that there are existing object relationships? For > example, if a name server query returned the number of domain delegations, > or a contact query returned the number of object associations, or if each > had some kind of status value that indicated active associations? Each > option would provide explicit notice that there are relationships to be > undone, eliminating the uncertainty before attempting a delete operation. > > Hi Scott, there are still some misunderstandings. "Normal" queries should not return all domains it is responsible for. I thought to include this only if the request explicitly requests this information. Therefore the impact on performance wouldn't be that great. Nevertheless I don't think we get a full consensus on this topic. But to end the discussion for now, I would be glad just to have some indicators that show that an object is referenced by others and therefore cannot be deleted. As far as I understand the e-mails, this is something that the discussion participants could agree upon. regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3GKjKx1020664 for ietf-provreg-outgoing; Mon, 16 Apr 2001 22:45:20 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3GKjJLt020659 for ; Mon, 16 Apr 2001 22:45:19 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14pFqn-0001f3-00; Mon, 16 Apr 2001 16:43:57 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Mon, 16 Apr 2001 16:44:43 -0400 Date: Mon, 16 Apr 2001 16:44:43 -0400 From: George Belotsky To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se Subject: Re: A Comment on 9. [1] of the requirements document. Message-ID: <20010416164443.B12397@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Fri, Apr 13, 2001 at 10:25:40PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks for making this change, Scott. George. On Fri, Apr 13, 2001 at 10:25:40PM -0400, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: George Belotsky [mailto:george@register.com] > > Sent: Friday, April 13, 2001 7:25 PM > > To: Hollenbeck, Scott > > Cc: ietf-provreg@cafax.se > > Subject: Re: A Comment on 9. [1] of the requirements document. > > > > [snip] > > > In sum, RFC 1035 says 2 things: > > > > (i) store names into DNS as per the ABNF in 2.3.1. > > (ii) when implementing DNS software, ensure that it > > will be able to support all 8 bits per character > > (except the null) as per 2.3.3. > > Last time I checked, this WG was dealing with (i) and not (ii), and the ABNF > very clearly defines domain and host names using 7-bit US-ASCII characters. > However, in the interest of concluding this discussion I am willing to > concede that the requirement text saying "the encoding of Internet host and > domain names in the DNS" might be misunderstood since 1035 does also > describe labels in more liberal terms. How about this for a rewording: > > "[RFC1035] describes Internet host and domain names using characters > traditionally found in a subset of the 7-bit US-ASCII character set." > > If anyone objects, please include single-sentence alternative wording that > explains why there is an internationalization issue with domain and host > names. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3E2WeIl007123 for ietf-provreg-outgoing; Sat, 14 Apr 2001 04:32:40 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3E2WXLt007118 for ; Sat, 14 Apr 2001 04:32:33 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id WAA11912; Fri, 13 Apr 2001 22:32:29 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0FBB>; Fri, 13 Apr 2001 22:25:46 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'George Belotsky'" Cc: ietf-provreg@cafax.se Subject: RE: A Comment on 9. [1] of the requirements document. Date: Fri, 13 Apr 2001 22:25:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: George Belotsky [mailto:george@register.com] > Sent: Friday, April 13, 2001 7:25 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: A Comment on 9. [1] of the requirements document. > [snip] > In sum, RFC 1035 says 2 things: > > (i) store names into DNS as per the ABNF in 2.3.1. > (ii) when implementing DNS software, ensure that it > will be able to support all 8 bits per character > (except the null) as per 2.3.3. Last time I checked, this WG was dealing with (i) and not (ii), and the ABNF very clearly defines domain and host names using 7-bit US-ASCII characters. However, in the interest of concluding this discussion I am willing to concede that the requirement text saying "the encoding of Internet host and domain names in the DNS" might be misunderstood since 1035 does also describe labels in more liberal terms. How about this for a rewording: "[RFC1035] describes Internet host and domain names using characters traditionally found in a subset of the 7-bit US-ASCII character set." If anyone objects, please include single-sentence alternative wording that explains why there is an internationalization issue with domain and host names. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3E2C474007059 for ietf-provreg-outgoing; Sat, 14 Apr 2001 04:12:04 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3E2C3Lt007054 for ; Sat, 14 Apr 2001 04:12:03 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id WAA11898; Fri, 13 Apr 2001 22:12:02 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0FA9>; Fri, 13 Apr 2001 22:05:18 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'George Belotsky'" , ietf-provreg@cafax.se Subject: RE: Question about draft-hollenbeck-epp-tcp-01.txt Date: Fri, 13 Apr 2001 22:05:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk The subject document isn't yet a provreg WG work item. The discussion list for the document is the NSI RRP mailing list until the WG decides to pick it up. Since you asked the question here, though... RECOMMENDED is strong enough language to make the appropriate point, so I won't argue against removing OPTIONAL. > -----Original Message----- > From: George Belotsky [mailto:george@register.com] > Sent: Friday, April 13, 2001 4:09 PM > To: ietf-provreg@cafax.se > Subject: Question about draft-hollenbeck-epp-tcp-01.txt > > > On page 4 of "draft-hollenbeck-epp-tcp-01.txt", it says > > "An EPP command MUST be a well-formed XML instance. An EPP command > begins with an OPTIONAL (but RECOMMENDED) XML processing instruction, > followed by an element..." > > Should we drop 'OPTIONAL' (and just keep 'RECOMMENDED')? The two > mean different things according to RFC 2119. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DNP3w4005791 for ietf-provreg-outgoing; Sat, 14 Apr 2001 01:25:03 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DNP2Lt005786 for ; Sat, 14 Apr 2001 01:25:02 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14oCuw-0004Ig-00; Fri, 13 Apr 2001 19:23:54 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 13 Apr 2001 19:24:30 -0400 Date: Fri, 13 Apr 2001 19:24:30 -0400 From: George Belotsky To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se Subject: Re: A Comment on 9. [1] of the requirements document. Message-ID: <20010413192430.G3107@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Fri, Apr 13, 2001 at 06:05:48PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott: Section 2.3.1 is the **preferred name syntax**, as clearly indicated. It says explicitly in 2.3.3 that "... future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided". Hence, it would appear that an RFC 1035-compliant implementation must preserve all 8 bits of each octet whenever possible. In sum, RFC 1035 says 2 things: (i) store names into DNS as per the ABNF in 2.3.1. (ii) when implementing DNS software, ensure that it will be able to support all 8 bits per character (except the null) as per 2.3.3. Thus, RFC 1035 does not restrict the encoding in the DNS to the 7-bit subset -- in fact, it strongly discourages such a restriction. What RFC 1035 does restrict is what a user, system administrator, etc. is allowed to put in the DNS. While the above distinctions are subtle, they are sometimes very relevant. For example, getting it wrong can result in non-compliant implementations, which may be significant. George. On Fri, Apr 13, 2001 at 06:05:48PM -0400, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: George Belotsky [mailto:george@register.com] > > Sent: Friday, April 13, 2001 3:01 PM > > To: Hollenbeck, Scott > > Cc: ietf-provreg@cafax.se > > Subject: Re: A Comment on 9. [1] of the requirements document. > > > > > > Please note 2.3.3. You are specifically told to avoid storing > > labels as 7-bit ASCII. > > The ABNF specification provided in RFC1035 section 2.3.1 is unambiguous WRT > labels used to represent domain and host names. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DMCZFG005509 for ietf-provreg-outgoing; Sat, 14 Apr 2001 00:12:35 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DMCWLt005502 for ; Sat, 14 Apr 2001 00:12:32 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id SAA11711; Fri, 13 Apr 2001 18:12:31 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F010T>; Fri, 13 Apr 2001 18:05:48 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'George Belotsky'" Cc: ietf-provreg@cafax.se Subject: RE: A Comment on 9. [1] of the requirements document. Date: Fri, 13 Apr 2001 18:05:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: George Belotsky [mailto:george@register.com] > Sent: Friday, April 13, 2001 3:01 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: A Comment on 9. [1] of the requirements document. > > > Please note 2.3.3. You are specifically told to avoid storing > labels as 7-bit ASCII. The ABNF specification provided in RFC1035 section 2.3.1 is unambiguous WRT labels used to represent domain and host names. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DL7RRU005310 for ietf-provreg-outgoing; Fri, 13 Apr 2001 23:07:27 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DL7QLt005305 for ; Fri, 13 Apr 2001 23:07:26 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3DL7GD20073; Fri, 13 Apr 2001 17:07:16 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104132107.f3DL7GD20073@nic-naa.net> To: George Belotsky cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: A Comment on 9. [1] of the requirements document. In-Reply-To: Your message of "Fri, 13 Apr 2001 16:36:48 EDT." <20010413163648.E3107@register.com> Date: Fri, 13 Apr 2001 17:07:16 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Am I correct in understanding that the issue before this WG is master file character encodings? There are other datums in master files than names, so the LDH restriction on ASCII code points used in A records isn't mooted by citing the total scope of master file ASCII values, or the quoting mechanism for master files (unless it is also a quoting mechanism for strings we have associated with A records). Amusing aside, when French redaction of the "ou" sound common in Abenaki began, circa 1600, French lacked a "w", and to write "ou", the Jesuits wrote "8" (small gap at the apex of the upper loop), which is still used in Abenaki today. The case folding rule for "8" is that 8 == 8. We don't have a case folding rule for 7 or 9, yet ;-) Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DKbUpe005096 for ietf-provreg-outgoing; Fri, 13 Apr 2001 22:37:30 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DKbTLt005091 for ; Fri, 13 Apr 2001 22:37:29 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14oAIg-000364-00; Fri, 13 Apr 2001 16:36:14 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 13 Apr 2001 16:36:48 -0400 Date: Fri, 13 Apr 2001 16:36:48 -0400 From: George Belotsky To: Eric Brunner-Williams in Portland Maine Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: Re: A Comment on 9. [1] of the requirements document. Message-ID: <20010413163648.E3107@register.com> References: <20010413160047.C3107@register.com> <200104132022.f3DKMaD19856@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104132022.f3DKMaD19856@nic-naa.net>; from brunner@nic-naa.net on Fri, Apr 13, 2001 at 04:22:36PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Here are the quoting rules, from RFC 1035, page 34. Note particularly the '\DDD' notation. ----------------------------------------------------------------------- Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. In particular: of the root. @ A free standing @ is used to denote the current origin. \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. ( ) Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses. ; Semicolon is used to start a comment; the remainder of the line is ignored. --------------------------------------------------------------------------- Although the above functionality is in the standard, it does not mean that it is currently used, as you are discouraged from using it. George. On Fri, Apr 13, 2001 at 04:22:36PM -0400, Eric Brunner-Williams in Portland Maine wrote: > > with zero parity. Non-alphabetic codes must match exactly. > > 3com? How is "3" case folded? > > > separated by dots. Quoting conventions allow arbitrary characters to be > > Quoting conventons? Elaborate please. Pointers to actual instance examples > would be helpful. > > Eric -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DKMmnw005061 for ietf-provreg-outgoing; Fri, 13 Apr 2001 22:22:48 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DKMlLt005056 for ; Fri, 13 Apr 2001 22:22:47 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3DKMaD19856; Fri, 13 Apr 2001 16:22:36 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104132022.f3DKMaD19856@nic-naa.net> To: George Belotsky cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: A Comment on 9. [1] of the requirements document. In-Reply-To: Your message of "Fri, 13 Apr 2001 16:00:47 EDT." <20010413160047.C3107@register.com> Date: Fri, 13 Apr 2001 16:22:36 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > with zero parity. Non-alphabetic codes must match exactly. 3com? How is "3" case folded? > separated by dots. Quoting conventions allow arbitrary characters to be Quoting conventons? Elaborate please. Pointers to actual instance examples would be helpful. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DK9Cer005016 for ietf-provreg-outgoing; Fri, 13 Apr 2001 22:09:12 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DK9BLt005011 for ; Fri, 13 Apr 2001 22:09:11 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14o9ru-0008Pv-00 for ietf-provreg@cafax.se; Fri, 13 Apr 2001 16:08:35 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 13 Apr 2001 16:09:09 -0400 Date: Fri, 13 Apr 2001 16:09:09 -0400 From: George Belotsky To: ietf-provreg@cafax.se Subject: Question about draft-hollenbeck-epp-tcp-01.txt Message-ID: <20010413160909.D3107@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-provreg@cafax.se Precedence: bulk On page 4 of "draft-hollenbeck-epp-tcp-01.txt", it says "An EPP command MUST be a well-formed XML instance. An EPP command begins with an OPTIONAL (but RECOMMENDED) XML processing instruction, followed by an element..." Should we drop 'OPTIONAL' (and just keep 'RECOMMENDED')? The two mean different things according to RFC 2119. George. -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DK1VGk004974 for ietf-provreg-outgoing; Fri, 13 Apr 2001 22:01:31 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DK1ULt004969 for ; Fri, 13 Apr 2001 22:01:30 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14o9jn-0007YO-00; Fri, 13 Apr 2001 16:00:11 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 13 Apr 2001 16:00:47 -0400 Date: Fri, 13 Apr 2001 16:00:47 -0400 From: George Belotsky To: Eric Brunner-Williams in Portland Maine Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: Re: A Comment on 9. [1] of the requirements document. Message-ID: <20010413160047.C3107@register.com> References: <20010413150111.A3107@register.com> <200104131932.f3DJWkD19687@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104131932.f3DJWkD19687@nic-naa.net>; from brunner@nic-naa.net on Fri, Apr 13, 2001 at 03:32:46PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk >From RFC 1035, Page 9: Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >From RFC 1035, Page 34: s make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. Quoting conventions allow arbitrary characters to be stored in domain names. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------------- It is quite clear that DNS was intended to support arbitrary characters (except '\0') in labels, although you were discouraged to use the functionality. How widely it is supported, and whether it is useful in our context, is a different story. Nevertheless, I did not think we -- as part of a standards-making body -- would be too much hurt by quoting the prior work of that same body accurately in our documents. If this is not the case, then I am very sorry to have bothered all of you. George. On Fri, Apr 13, 2001 at 03:32:46PM -0400, Eric Brunner-Williams in Portland Maine wrote: > 7-bit store would alter alignment semantics, and should 8th bit semantics > attach (in the conjectured future of 1035), require stateful encoding of > primary-to-store, and stateful decodings of store-to-primary. > > Terminator labels (other than NULL) introduce the iso2022 escape problem, > or memory-aligned stateful encoding. > > "avoid stateful store and escapes" is not equivalent to "use all 8 bits" > > Eric -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DJX7WR004859 for ietf-provreg-outgoing; Fri, 13 Apr 2001 21:33:07 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DJX5Lt004854 for ; Fri, 13 Apr 2001 21:33:06 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3DJWkD19687; Fri, 13 Apr 2001 15:32:46 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104131932.f3DJWkD19687@nic-naa.net> To: George Belotsky cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: A Comment on 9. [1] of the requirements document. In-Reply-To: Your message of "Fri, 13 Apr 2001 15:01:11 EDT." <20010413150111.A3107@register.com> Date: Fri, 13 Apr 2001 15:32:46 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk 7-bit store would alter alignment semantics, and should 8th bit semantics attach (in the conjectured future of 1035), require stateful encoding of primary-to-store, and stateful decodings of store-to-primary. Terminator labels (other than NULL) introduce the iso2022 escape problem, or memory-aligned stateful encoding. "avoid stateful store and escapes" is not equivalent to "use all 8 bits" Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DJ1qvN004732 for ietf-provreg-outgoing; Fri, 13 Apr 2001 21:01:52 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DJ1pLt004727 for ; Fri, 13 Apr 2001 21:01:52 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14o8o7-0006s5-00; Fri, 13 Apr 2001 15:00:35 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 13 Apr 2001 15:01:11 -0400 Date: Fri, 13 Apr 2001 15:01:11 -0400 From: George Belotsky To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se Subject: Re: A Comment on 9. [1] of the requirements document. Message-ID: <20010413150111.A3107@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Fri, Apr 13, 2001 at 01:04:31PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Please note 2.3.3. You are specifically told to avoid storing labels as 7-bit ASCII. 2.3.1. Preferred name syntax The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. ........... 2.3.3. Character Case For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided. On Fri, Apr 13, 2001 at 01:04:31PM -0400, Hollenbeck, Scott wrote: > >-----Original Message----- > >From: George Belotsky [mailto:george@register.com] > >Sent: Friday, April 13, 2001 12:43 PM > >To: ietf-provreg@cafax.se > >Subject: A Comment on 9. [1] of the requirements document. > > > > > >Section 9. [1] is quoted below. > > > > > >" [RFC1035] restricts the encoding of Internet host and domain names > > in the DNS to a subset of the 7-bit US-ASCII character set. More > > recent standards, such as [RFC2130] and [RFC2277], describe the need > > to develop protocols for an international Internet. These and other > > standards MUST be considered during the protocol design process to > > ensure world-wide usability of a generic registry registrar protocol." > > > >This is not quite correct. Quote from RFC1035 follows. > > > >"Although labels can contain any 8 bit values in octets that make up a > >label, it is strongly recommended that labels follow the preferred > >syntax described elsewhere in this memo, which is compatible with > >existing host naming conventions. Name servers and resolvers must > >compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII > >with zero parity. Non-alphabetic codes must match exactly." > > > >Thus, DNS labels can contain arbitrary octets. If such labels are > >properly supported by existing software, it may be possible to make > >use this functionality. > > The statement is absolutely correct. Please re-read section 2.3.1, > "Preferred name syntax", starting at the bottom of page 6. It very clearly > constrains the label space for domain and host names as described. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DHBGbq004224 for ietf-provreg-outgoing; Fri, 13 Apr 2001 19:11:16 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DHBFLt004218 for ; Fri, 13 Apr 2001 19:11:15 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA10935; Fri, 13 Apr 2001 13:11:14 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F01Z6>; Fri, 13 Apr 2001 13:04:31 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'George Belotsky'" , ietf-provreg@cafax.se Subject: RE: A Comment on 9. [1] of the requirements document. Date: Fri, 13 Apr 2001 13:04:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: George Belotsky [mailto:george@register.com] >Sent: Friday, April 13, 2001 12:43 PM >To: ietf-provreg@cafax.se >Subject: A Comment on 9. [1] of the requirements document. > > >Section 9. [1] is quoted below. > > >" [RFC1035] restricts the encoding of Internet host and domain names > in the DNS to a subset of the 7-bit US-ASCII character set. More > recent standards, such as [RFC2130] and [RFC2277], describe the need > to develop protocols for an international Internet. These and other > standards MUST be considered during the protocol design process to > ensure world-wide usability of a generic registry registrar protocol." > >This is not quite correct. Quote from RFC1035 follows. > >"Although labels can contain any 8 bit values in octets that make up a >label, it is strongly recommended that labels follow the preferred >syntax described elsewhere in this memo, which is compatible with >existing host naming conventions. Name servers and resolvers must >compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII >with zero parity. Non-alphabetic codes must match exactly." > >Thus, DNS labels can contain arbitrary octets. If such labels are >properly supported by existing software, it may be possible to make >use this functionality. The statement is absolutely correct. Please re-read section 2.3.1, "Preferred name syntax", starting at the bottom of page 6. It very clearly constrains the label space for domain and host names as described. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DHAQEw004214 for ietf-provreg-outgoing; Fri, 13 Apr 2001 19:10:26 +0200 (MEST) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DHAPLt004208 for ; Fri, 13 Apr 2001 19:10:25 +0200 (MEST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id TAA04284 for ; Fri, 13 Apr 2001 19:10:25 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.3/8.11.2) with ESMTP id f3DHAPK37393 for ; Fri, 13 Apr 2001 19:10:25 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200104131710.f3DHAPK37393@bartok.sidn.nl> To: ietf-provreg@cafax.se Subject: Re: Subscribe In-reply-to: Your message of Fri, 13 Apr 2001 12:22:21 -0400. <002901c0c435$eabf72e0$0110a8c0@forman.com> Date: Fri, 13 Apr 2001 19:10:25 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk This was a Pilot error from me. Humble apologies. I'll get Cham Feng on the list anyway. jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DGwopd004151 for ietf-provreg-outgoing; Fri, 13 Apr 2001 18:58:50 +0200 (MEST) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DGwnLt004146 for ; Fri, 13 Apr 2001 18:58:50 +0200 (MEST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id SAA04229 for ; Fri, 13 Apr 2001 18:58:49 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.11.3/8.11.2) id f3DGwnb37364 for ietf-provreg@cafax.se; Fri, 13 Apr 2001 18:58:49 +0200 (CEST) (envelope-from jaap) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DGMnLt003944 for ; Fri, 13 Apr 2001 18:22:49 +0200 (MEST) Received: from [10.10.24.25] (helo=wsnt956) by rcommail2 with smtp (Exim 3.16 #2) id 14o6Kr-0006cb-00 for ietf-provreg@cafax.se; Fri, 13 Apr 2001 12:22:13 -0400 Message-ID: <002901c0c435$eabf72e0$0110a8c0@forman.com> From: "Chan Feng" To: Subject: Subscribe Date: Fri, 13 Apr 2001 12:22:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C0C414.63987620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C0C414.63987620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subscribe Thanks! - Chan Feng Manager of Systems Development Register.com - the first step on the web Office: (212) 798 x 9136 Mobile: (917) 567-2183 ------=_NextPart_000_0026_01C0C414.63987620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Subscribe

Thanks!
 
- Chan Feng
Manager of Systems=20 Development
Register.com - the first step on the web
Office: (212) = 798 x=20 9136
Mobile: (917) 567-2183
------=_NextPart_000_0026_01C0C414.63987620-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3DGhGZV004063 for ietf-provreg-outgoing; Fri, 13 Apr 2001 18:43:16 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3DGhFLt004058 for ; Fri, 13 Apr 2001 18:43:15 +0200 (MEST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14o6ed-00009w-00 for ietf-provreg@cafax.se; Fri, 13 Apr 2001 12:42:39 -0400 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 13 Apr 2001 12:43:14 -0400 Date: Fri, 13 Apr 2001 12:43:14 -0400 From: George Belotsky To: ietf-provreg@cafax.se Subject: A Comment on 9. [1] of the requirements document. Message-ID: <20010413124314.A2722@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-provreg@cafax.se Precedence: bulk Section 9. [1] is quoted below. " [RFC1035] restricts the encoding of Internet host and domain names in the DNS to a subset of the 7-bit US-ASCII character set. More recent standards, such as [RFC2130] and [RFC2277], describe the need to develop protocols for an international Internet. These and other standards MUST be considered during the protocol design process to ensure world-wide usability of a generic registry registrar protocol." This is not quite correct. Quote from RFC1035 follows. "Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly." Thus, DNS labels can contain arbitrary octets. If such labels are properly supported by existing software, it may be possible to make use this functionality. George. -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3CEjiYm027539 for ietf-provreg-outgoing; Thu, 12 Apr 2001 16:45:44 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3CEjfLt027534 for ; Thu, 12 Apr 2001 16:45:43 +0200 (MEST) Received: from [192.168.2.116] (helo=[169.254.19.131]) by rcommail2 with esmtp (Exim 3.16 #2) id 14niK1-00014I-00; Thu, 12 Apr 2001 10:43:47 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <3AD40FA5.9A078C35@knipp.de> References: <3AD2B547.8777F22E@knipp.de> <3AD40FA5.9A078C35@knipp.de> Date: Thu, 12 Apr 2001 10:42:45 -0400 To: Klaus Malorny From: "Jordyn A. Buchanan" Subject: Re: Issues on 3.4.9 Object Information Query Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:02 AM +0200 4/11/01, Klaus Malorny wrote: >Just think of the following "conversation": > > Client: delete domain blabla.tld > Server: deletion denied. Object still in use. > >and now? What are you doing now in the case that *you* think that the domain >is *not* in use? Do you want to pay for the domain until you get a database >dump end of next month or quarter revealing the problem? > >I don't know whether it is possible for a different registrar to register a >name server below a certain domain (I know it's not possible under NSI's >system, and it is always a pain -- sorry Scott). If so, situations with >unknown references could easily appear. As Scott has pointed out, this particular situation is handled by EPP already. That's a protocol discussion as opposed to a requirements discussion, however, so I'll make a different argument. There's no doubt that when you get such a result, you need a way to find the relationships. We all agree to that. However, given the high transactional volumes that we may see in provreg environments, it is inappropriate to try to deliver potentially large relationship reports through the same channel actually used for provisioning. An analogy, albeit somewhat strained: you work for a large company with 5000 phone lines. If you want to add a new phone line or change the services associated with a particular line, you probably call them on the phone and explain their needs to one of their representatives. That's provisioning. If you want a list of all your phone lines and what services are associated with each, you don't want them to read you a list, but you would like them to fax or mail you a report. That's reporting. These two functions *could* technically be handled over the same channel, but it's better if you have well-optimized ways to handle the different needs. > > > I think you may under-appreciate just how much this functionality may >> increase processing time and message size. We (register.com) have >> about three million domain names on our name servers. Right now, >> there's only a few hundred thousand on any given name server, but our >> goal is to get them all on the same set of name servers. I know that >> other organizations have very large numbers of domain names >> associated with individual name servers; likewise, there are some >> contacts associated with many domains. Do we really want to be >> returning data sets of this size through a provisioning protocol? We >> need a way to get information on object associations, but it doesn't >> belong in provreg. >> > >As I mentioned above, I don't underestimate it. Although it is not a nice way >to solve the problem, there is still the possibility to truncate the output to >a reasonable size. Some databases even have extensions to SQL to limit the >number of reported rows. So there is always a solution. I was actually going to use the line of argument above to prove my point in my first e-mail, but I knew that someone would make it for me if I waited. If you're conceding that sometimes the data set is too large to be reasonably transmitted through provreg, then you're conceding the need for a separate reporting mechanism. If we need a separate reporting mechanism anyway, why not just use that for reporting functions and not clutter up the provreg protocol and implementations with this extra clutter? Jordyn Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3CDrHhW027187 for ietf-provreg-outgoing; Thu, 12 Apr 2001 15:53:17 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3CDrFLt027182 for ; Thu, 12 Apr 2001 15:53:16 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA07175; Thu, 12 Apr 2001 09:52:41 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0D87>; Thu, 12 Apr 2001 09:46:01 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" Cc: "Jordyn A. Buchanan" , ietf-provreg@cafax.se Subject: RE: Issues on 3.4.9 Object Information Query Date: Thu, 12 Apr 2001 09:46:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Thursday, April 12, 2001 5:36 AM >To: Hollenbeck, Scott >Cc: Jordyn A. Buchanan; ietf-provreg@cafax.se >Subject: Re: Issues on 3.4.9 Object Information Query > > >"Hollenbeck, Scott" wrote: >> > >> > >> >Just think of the following "conversation": >> > >> > Client: delete domain blabla.tld >> > Server: deletion denied. Object still in use. >> > >> >and now? What are you doing now in the case that *you* think that the >> domain >> >is *not* in use? Do you want to pay for the domain until you get a database >> >dump end of next month or quarter revealing the problem? >> >> Ahh, but the problem will be immediately obvious given the requirement to >> explicitly identify the *.blabla.tld name servers in the response to a >> general object information query. The client who wants to delete the domain >> can determine exactly which other objects are involved by doing an info >> query on the domain object. >> >> > >Yes, exactly. This is all I want. But not only for domains, but for other >object types, too. I assume that a contact or a name server cannot be deleted >if it is used by a domain. So the domains need to be reported. I understand, and I am not disputing that there is a need for this information. We are disagreeing on the reporting/delivery method. VeriSign (then NSI Registry) actually implemented this sort of reverse-relationship query service via the NSI RRP in the early days of the SRS test bed. Requesting information about a name server would include a list of all domains delegated to the server. It quickly became clear to us (with only six registrars) that this service was unworkable via the protocol due to serious server-side memory management and DB performance requirements, and we were working with the best commercial hardware and software available at the time. I still believe that a different query protocol or offline reporting services is the most efficient way to provide the potentially large volume of information associated with contact and name server relational queries. However, if part of the problem is that it's not obvious when object relationships exist, would it be an acceptable compromise to make it completely obvious that there are existing object relationships? For example, if a name server query returned the number of domain delegations, or a contact query returned the number of object associations, or if each had some kind of status value that indicated active associations? Each option would provide explicit notice that there are relationships to be undone, eliminating the uncertainty before attempting a delete operation. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3CBHqJV026405 for ietf-provreg-outgoing; Thu, 12 Apr 2001 13:17:52 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3CBHpLt026396 for ; Thu, 12 Apr 2001 13:17:52 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id NAA25622 ; Thu, 12 Apr 2001 13:17:48 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3CBIB508817; Thu, 12 Apr 2001 13:18:11 +0200 Date: Thu, 12 Apr 2001 13:18:11 +0200 From: Olivier Guillard / AFNIC To: Eric Brunner-Williams in Portland Maine Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: Re: comments on last draft Message-ID: <20010412131811.G11284@james.nic.fr> References: <20010411121341.A21676@james.nic.fr> <200104111330.f3BDUSD11154@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200104111330.f3BDUSD11154@nic-naa.net>; from brunner@nic-naa.net on Wed, Apr 11, 2001 at 09:30:28AM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric, If I understand well what you say ( I'm not sure :), it is going for me to the right direction. > You are mistaken. There is a set of operations, each has a semantic and a > syntax that are (subject to correction) adequately specified. May I ask you where I can find the specs of this set of operations? olivier le mercredi 11 avril à 09 H 30 , Eric Brunner-Williams in Portland Maine a écrit : > [snip] > > > >> >3.4.5 Object Transfer > ... > > It seems to me that allow the original sponsoring registrar to approve or > > reject a requested object transfer is a policie question, not a technical > > You are mistaken. There is a set of operations, each has a semantic and a > syntax that are (subject to correction) adequately specified. One operation > (xfr) has an implicit order-of-events issue. Picking one is a technical > necessity. If your policy requirement is not met, then you should be making > the case that we should make xfr's implicit order-of-events explicit, and > add a mechanism for operational selection of which order-of-events is to be > used, allowing multiple-choice, hence allowing for operational selection of > policy. > > Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3CB6FiC026338 for ietf-provreg-outgoing; Thu, 12 Apr 2001 13:06:15 +0200 (MEST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3CB6DLt026333 for ; Thu, 12 Apr 2001 13:06:14 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26016; Thu, 12 Apr 2001 07:06:11 -0400 (EDT) Message-Id: <200104121106.HAA26016@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jseng-provreg-opp-00.txt Date: Thu, 12 Apr 2001 07:06:07 -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Object Provisioning Protocol (OPP) Author(s) : J. Seng, W. Tan Filename : draft-jseng-provreg-opp-00.txt Pages : Date : 11-Apr-01 This document describes a message-based, application layer protocol for the provisioning and management of objects stored in a shared central repository through service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jseng-provreg-opp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jseng-provreg-opp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jseng-provreg-opp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010411124418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jseng-provreg-opp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jseng-provreg-opp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010411124418.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3CAgbaf026273 for ietf-provreg-outgoing; Thu, 12 Apr 2001 12:42:37 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3CAgaLt026268 for ; Thu, 12 Apr 2001 12:42:36 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id MAA16403; Thu, 12 Apr 2001 12:41:20 +0200 (METDST) Message-ID: <3AD586D9.BE618CB2@knipp.de> Date: Thu, 12 Apr 2001 12:43:37 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: 3.4/Object Ownership, esp. Name Server Ownership References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > >-----Original Message----- > >From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > >Sent: Wednesday, April 11, 2001 7:41 AM > >To: 'Klaus Malorny'; ietf-provreg@cafax.se > >Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership > > [snip] > > >Now, one can argue (and we have, we've talked about this more than once) > >that this is a restrictive model, and that any registrar should be able to > >create a host in foo.com. As I've said before, this introduces a different > >set of difficulties regarding management of foo.com that I believe are more > >difficult to solve. Once you have multiple registrars creating objects > that > >are hierarchically related to foo.com the registrar of foo.com doesn't have > >a complete picture of the domain object, which may lead to inter-registrar > >(that is, _competing_ registrar) coordination requirements and associated > >problems. > > After taking some more time to step back and consider the operational issues > associated with changing the domain-name server relationship as described in > the requirements draft, I'd like to ask anyone who believes that the > separation model is more appropriate to explain how the following scenarios > might be addressed: > > The possibility of redirection and DoS attacks increases if multiple > registrars are capable of registering hosts as name servers. For example, > registrar A sponsors foo.com, which has been delegated to ns1.foo.com and > ns2.foo.com. Host www.foo.com exists in the foo.com zone. Registrar B > registers www.foo.com as a name server object, with an IP address different > from the one specified in the foo.com zone, resulting in a redirection that > registrar A (and the registrant of foo.com) can do nothing about without > explicit action from registrar B, who may refuse to cooperate. Yes, even > registrar A can register www.foo.com as a name server and cause problems, > but with only one registrar involved the problem is _much_ easier to > resolve. > > If we allow domain objects (such as foo.com) to be deleted without requiring > deletion or renaming of name server objects (such as ns1.foo.com) registered > under the domain, we allow creation of orphaned A records. This doesn't > have an immediate operational consequence for the DNS (queries for something > like www.foo.com will yield an NXDOMAIN response), but it does become a > garbage collection issue in the zone that publishes the glue record for > ns1.foo.com, which remains after foo.com has been deleted. This, too, can > present a denial of service issue when someone re-registers foo.com and they > try to register a name server named ns1.foo.com, which won't be possible > because the old ns1.foo.com remains! > > Hi Scott, first of all, I agree to your analysis regarding the problem of the deletion of a domain without the deletion of its name servers, and I also think that the consequences of it should be avoided. Nevertheless, I would like to remark that this problem will appear whatever we define in this protocol caused by the ability to use name servers outside the control of the registry, i.e. name servers belonging to other ccTLDs or gTLDs not managed by the registry. There are solutions to the problem of course. I haven't deliberated the following two solutions completely, but I would like to mention them: 1) If a domain gets deleted, all existing name servers are deleted also. If these name servers are used in any other domain, they are removed from these domains, i.e. each those domains looses one name server. A drawback of this solution is of course a lot of hidden changes not visible to the registrars that might be affected by that. But the registrars could be notified. 2) We had a long debate about unique identifiers on the list recently. This solution would really use them! The name servers belonging to a certain domain do not reference the domain by its name, but by its UID. If the domain gets deleted, its UID becomes void. The name server objects remain intact, but due to the void reference they are no longer used for the zone file generation. The registrar sponsoring the name server would get a notification about the deletion of the domain. In the circumstance that a new domain is created with the same name, this domain would get another UID, different to the UID of the previous domain. The existing name servers would still have the old UIDs in their references and would not be used for the zone generation. By an update, the registrar may change the name server. If he uses the same domain again, the UID of the reference will be updated to the new UID. For the problem you mention for the registration of name servers by registrars not sponsoring the corresponding domain, one could either disallow the specification of the IP address or just ignore it in the zone file generation. (There we come back to the discussion "Nameserver MUST HAVE IP", so I'll stop here). regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3C9Y9s6026069 for ietf-provreg-outgoing; Thu, 12 Apr 2001 11:34:09 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3C9Y9Lt026064 for ; Thu, 12 Apr 2001 11:34:09 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA20497; Thu, 12 Apr 2001 11:33:53 +0200 (METDST) Message-ID: <3AD5770B.1C2A9E75@knipp.de> Date: Thu, 12 Apr 2001 11:36:11 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: "Jordyn A. Buchanan" , ietf-provreg@cafax.se Subject: Re: Issues on 3.4.9 Object Information Query References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > > > >Just think of the following "conversation": > > > > Client: delete domain blabla.tld > > Server: deletion denied. Object still in use. > > > >and now? What are you doing now in the case that *you* think that the > domain > >is *not* in use? Do you want to pay for the domain until you get a database > >dump end of next month or quarter revealing the problem? > > Ahh, but the problem will be immediately obvious given the requirement to > explicitly identify the *.blabla.tld name servers in the response to a > general object information query. The client who wants to delete the domain > can determine exactly which other objects are involved by doing an info > query on the domain object. > > Yes, exactly. This is all I want. But not only for domains, but for other object types, too. I assume that a contact or a name server cannot be deleted if it is used by a domain. So the domains need to be reported. regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3C8Ac10025691 for ietf-provreg-outgoing; Thu, 12 Apr 2001 10:10:38 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3C8AaLt025686 for ; Thu, 12 Apr 2001 10:10:37 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id KAA27321 ; Thu, 12 Apr 2001 10:10:34 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3C8Aq102394; Thu, 12 Apr 2001 10:10:52 +0200 Date: Thu, 12 Apr 2001 10:10:52 +0200 From: Olivier Guillard / AFNIC To: Edward Lewis Cc: Mats Dufberg , "Hollenbeck, Scott" , ietf-provreg@cafax.se, tech@nic.fr Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010412101052.A23674@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Wed, Apr 11, 2001 at 03:00:28PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edward, Technically speacking, I agree with Mats, So I disagree with the document direction. Formally speaking, I agree with you, So I disagree with this: Name servers registered within the registry's authoritative TLDs SHOULD be registered with a valid IPv4 or IPv6 address. Olivier le mercredi 11 avril à 15 H 00 , Edward Lewis a écrit : > At 8:27 AM -0400 4/9/01, Mats Dufberg wrote: > >Name servers MUST be registered with valid IPv4 or IPv6 address when "glue > >record" is stricly needed for delegation of a domain from the TLD. The > >address MAY be removed when no longer needed for strict "glue record". > > Remember that our scope in this document is the set of requirements for a > suitable protocol. The latter sentence addresses the way in which a > registry handle the data, an issue certainly outside our scope. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BLaX7W022804 for ietf-provreg-outgoing; Wed, 11 Apr 2001 23:36:33 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BLaVLt022799 for ; Wed, 11 Apr 2001 23:36:31 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3BLaCD12818 for ; Wed, 11 Apr 2001 17:36:13 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104112136.f3BLaCD12818@nic-naa.net> To: ietf-provreg@cafax.se Subject: Privacy: policy{access,statement{purpose,recipient,retention},expiry} Date: Wed, 11 Apr 2001 17:36:12 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Introduction In this memo I'll cover data collection considerations in detail. The requirement to meet is: (draft-ietf-provreg-grrp-reqs-01.txt, bis) provide services to identify data collection policies The 25-word summary is a data collection policy vocabulary is specified which identifies domain-name registration data collection policies. The vocabulary is expressed in in ABNF (grammer representation of XML syntax) and in XSD. The protocol transports these schema as it does any other, to provide the required service. In the following, indentation is used to show relationships. Policy Access Statement Purpose Recipient Retention Expiry There are seven sections that follow: policy {access, statement {purpose, recipient, retention}, expiry} Each resembles the note I sent earlier this week on the ACCESS element, which appears here again with corrections (thanks Scott), and as I remarked in the earlier note, there are issues to resolve: 1. does the set of attributes cover the R* problem space discussed in the provreg WG list? 2. is the XML right? Motivational discussion can get flushed out in the list, here I'm just getting the (I think) the functional requirement met, or getting significantly closer to that goal. Eric BEGIN BEGIN BEGIN X. The POLICY element The POLICY element is defined as the container for data collection policy statements. The POLICY element MUST contain all of the following elements: defined subsequent one or more, defined subsequent ("statement-blocks"), defined subsequent // Policy ABNF (grammer representation of XML syntax) policy = "" access *statement-block expiry "" X.1. The ACCESS element The ACCESS element is defined as the ability of registrant to view registrant originated data and address questions or concerns to the registration service provider. Registration service providers MUST disclose one value for the access attribute. The method of access is not specified. The ACCESS element must contain one of the following elements: access is provided to all social data only access is provided to all technical data only access is provided to all technical and social data registrant data exists but access is not provided registrant data is not persistent // Access ABNF (grammer representation of XML syntax) access = "" access_disclosure "" access_disclosure = "" | ; socal data only "" | ; technical data only "" | ; all data "" | ; access not provided "" | ; data not persistent X.2 The STATEMENT element The STATEMENT element is defined as a container that groups together PURPOSE element, RECIPIENT element, RETENTION element, and DATA-GROUP elements. // Statement ABNF (grammer representation of XML syntax) statement-block = "" purpose recipient retention 1*data-group "" X.2.1 The PURPOSE element Each STATEMENT element MUST contain a PURPOSE element that contains one or more purposes of data collection or uses of data. Registration service providers MUST classify their data practices into one one or more of the purposes specified below. The PURPOSE element MUST contain all that apply of the following: dn name registration (dnso) tm mark registration (trademark) ip address registration (aso) contacting registrants for marketing purposes something other than the above // Access ABNF (grammer representation of XML syntax) purpose = "" 1*purposevalue "" purposevalue = "" "" "" "" "" X.2.2 The RECIPIENT element Each STATEMENT element MUST contain a RECIPIENT element that contains one or more recipients of the collected data. Registration service providers MUST classify their recipients into one or more of the recipients specified below. The RECIPIENT element MUST contain all that apply of the following: ourselves and/or our agents and/or us as agents legal entities following our practices legal entities following unknown practices unrelated third parties public fora // Recipient ABNF (grammer representation of XML syntax) recipient = "" 1*recipientvalue "" recipientvalue = "" "" "" "" "" X.2.3 The RETENTION element Each STATEMENT element MUST contain a RETENTION element that contains one of the following: The RETENTION element MUST contain one of the following: data is not persistent data is persistent (functional requirement) data is persistent (legal requirement) data is persistent (non-functional requirement) data is persistent (indefinitely) // Retention ABNF (grammer representation of XML syntax) retention = "" 1*retentionvalue "" recipientvalue = "" "" "" "" "" X.3 The Expiry element The EXPIRY element is defined as the temporal scope of a policy. The expiry is given as either an absolute expiry time, or a relative expiry time. An absolute expiry time is a dateTime, at which the policy is no longer valid. The lexical representation for dateTime is the [ISO 8601] extended format CCYY-MM-DDThh:mm:ssZ, where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. The letter "Z" indicates Coordinated Universal Time (UTC) (canonical representation for dateTime). A relative expiry time gives a duration until the policy is no longer valid. The lexical representation for duration is the [ISO 8601] extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. // Expiry ABNF (grammer representation of XML syntax) expiry = " absolute = `date="` dateTime `"` relative = `time="` timeDuration `"` END END END Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BJ1PGO022050 for ietf-provreg-outgoing; Wed, 11 Apr 2001 21:01:25 +0200 (MEST) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BJ1NLt022045 for ; Wed, 11 Apr 2001 21:01:24 +0200 (MEST) Received: by sentry.gw.tislabs.com; id PAA10494; Wed, 11 Apr 2001 15:05:04 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010483; Wed, 11 Apr 01 15:04:55 -0400 Received: from [10.33.10.145] (dyn145.gw.tislabs.com [10.33.10.145]) by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id PAA23959; Wed, 11 Apr 2001 15:00:46 -0400 (EDT) X-Sender: lewis@pop.tislabs.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Apr 2001 15:00:28 -0400 To: Mats Dufberg From: Edward Lewis Subject: RE: Nameserver MUST HAVE IP Cc: "Hollenbeck, Scott" , Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 8:27 AM -0400 4/9/01, Mats Dufberg wrote: >Name servers MUST be registered with valid IPv4 or IPv6 address when "glue >record" is stricly needed for delegation of a domain from the TLD. The >address MAY be removed when no longer needed for strict "glue record". Remember that our scope in this document is the set of requirements for a suitable protocol. The latter sentence addresses the way in which a registry handle the data, an issue certainly outside our scope. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BG0sbP020894 for ietf-provreg-outgoing; Wed, 11 Apr 2001 18:00:54 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BG0rLt020889 for ; Wed, 11 Apr 2001 18:00:53 +0200 (MEST) Received: from [10.10.20.173] (helo=[169.254.19.131]) by rcommail2 with esmtp (Exim 3.16 #2) id 14nN2N-0002z6-00; Wed, 11 Apr 2001 12:00:07 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: References: Date: Wed, 11 Apr 2001 12:00:20 -0400 To: Mats Dufberg , Olivier Guillard / AFNIC From: "Jordyn A. Buchanan" Subject: Re: Nameserver MUST HAVE IP Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 4:56 PM +0200 4/11/01, Mats Dufberg wrote: >On Wed, 11 Apr 2001, Olivier Guillard / AFNIC wrote: > >> I suppose that nic-se remove the glues that are not longer needed >> in ALL cases, don't you? > >Yes, we do. > > >> I agree with all the arguments you have posted in this thread, about >> this topic and I would even write a "MUST" for your second "MAY". > >I wouldn't object. :-) You better have an awfully good definition of 'strictly needed' if you're going to make this a MUST. I'm slightly amused that the same people who were objecting to being told how to run their registry are now trying to tell everyone else how to run their registries. Jordyn > >> 3.4.2-[3], updated to cover strictly needed glue: >> >> Name servers MUST be registered with valid IPv4 or IPv6 address when "glue >> record" is stricly needed for delegation of a domain from the TLD. The >> address MUST be removed when no longer needed for strict "glue record". >> ^^^^ >> regards, >> >> Olivier >> > > > >----------------------------------------------------------------- >Mats Dufberg +46-8-545 857 06 >dufberg@nic-se.se fax: +46-8-545 857 29 -- Jordyn A. Buchanan jordyn@register.com Futurist +1.212.798.9262 Register.com http://www.register.com/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BFITMA020578 for ietf-provreg-outgoing; Wed, 11 Apr 2001 17:18:29 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BFIRLt020573 for ; Wed, 11 Apr 2001 17:18:28 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3BFI1D11590; Wed, 11 Apr 2001 11:18:01 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104111518.f3BFI1D11590@nic-naa.net> To: Eric Brunner-Williams in Portland Maine cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Registrant Access (Data Protection/Privacy) In-Reply-To: Your message of "Wed, 11 Apr 2001 10:10:31 EDT." <200104111410.f3BEAVD11241@nic-naa.net> Date: Wed, 11 Apr 2001 11:18:01 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Oops! Please disregard my last. I plead distraction or temporary insanity. When we did the P3P spec (ongoing) we put in the EXTENSION element and put in the optional attribute to allow the distinction between manditory and optional extensions. The ABNF is extension = "" PCDATA "" The schema is I hope this is a little less incoherent, and it shows I didn't grep for extension in your xsd set or I'd have found optExtType. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEvDia020476 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:57:13 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEvCLt020471 for ; Wed, 11 Apr 2001 16:57:13 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f3BEuqB27823; Wed, 11 Apr 2001 16:56:52 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Wed, 11 Apr 2001 16:56:52 +0200 (CEST) From: Mats Dufberg To: Olivier Guillard / AFNIC cc: , Subject: Re: Nameserver MUST HAVE IP In-Reply-To: <20010411164405.A15150@james.nic.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, 11 Apr 2001, Olivier Guillard / AFNIC wrote: > I suppose that nic-se remove the glues that are not longer needed > in ALL cases, don't you? Yes, we do. > I agree with all the arguments you have posted in this thread, about > this topic and I would even write a "MUST" for your second "MAY". I wouldn't object. :-) > 3.4.2-[3], updated to cover strictly needed glue: > > Name servers MUST be registered with valid IPv4 or IPv6 address when "glue > record" is stricly needed for delegation of a domain from the TLD. The > address MUST be removed when no longer needed for strict "glue record". > ^^^^ > regards, > > Olivier > ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEhpor020334 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:43:51 +0200 (MEST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEhnLt020329 for ; Wed, 11 Apr 2001 16:43:50 +0200 (MEST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f3BEhmq01319; Wed, 11 Apr 2001 07:43:48 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f3BEhm502643; Wed, 11 Apr 2001 07:43:48 -0700 Message-Id: <200104111443.f3BEhm502643@zed.isi.edu> Subject: Re: 3.4/Object Ownership, esp. Name Server Ownership To: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Wed, 11 Apr 2001 07:43:48 -0700 (PDT) Cc: ietf-provreg@cafax.se In-Reply-To: from "Hollenbeck, Scott" at Apr 11, 2001 10:10:52 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk This problem exists today. The (correct) answer is that the owner of the foo.com object has ultimate say in what is subserviant to the foo.com object, -REGARDLESS- of which registrar is allowed to make changes to objects chained to the foo.com parent object. One should ensure that the parent object is now allowed to be deleted without first ensuring that all entries that are chained have either been moved elsewhere, (www.foo.com -> b.example.net) or are deleted along with the parent... sort of like a unix file system... can't delete the directory w/o removing all the files underneith it. % The possibility of redirection and DoS attacks increases if multiple % registrars are capable of registering hosts as name servers. For example, % registrar A sponsors foo.com, which has been delegated to ns1.foo.com and % ns2.foo.com. Host www.foo.com exists in the foo.com zone. Registrar B % registers www.foo.com as a name server object, with an IP address different % from the one specified in the foo.com zone, resulting in a redirection that % registrar A (and the registrant of foo.com) can do nothing about without % explicit action from registrar B, who may refuse to cooperate. Yes, even % registrar A can register www.foo.com as a name server and cause problems, % but with only one registrar involved the problem is _much_ easier to % resolve. % % If we allow domain objects (such as foo.com) to be deleted without requiring % deletion or renaming of name server objects (such as ns1.foo.com) registered % under the domain, we allow creation of orphaned A records. This doesn't % have an immediate operational consequence for the DNS (queries for something % like www.foo.com will yield an NXDOMAIN response), but it does become a % garbage collection issue in the zone that publishes the glue record for % ns1.foo.com, which remains after foo.com has been deleted. This, too, can % present a denial of service issue when someone re-registers foo.com and they % try to register a name server named ns1.foo.com, which won't be possible % because the old ns1.foo.com remains! % % % -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEhjsB020326 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:43:45 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEhiLt020321 for ; Wed, 11 Apr 2001 16:43:44 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id QAA22012 ; Wed, 11 Apr 2001 16:43:42 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3BEi5G19295; Wed, 11 Apr 2001 16:44:05 +0200 Date: Wed, 11 Apr 2001 16:44:05 +0200 From: Olivier Guillard / AFNIC To: Mats Dufberg Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010411164405.A15150@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from dufberg@nic-se.se on Mon, Apr 09, 2001 at 02:27:59PM +0200 Sender: owner-ietf-provreg@cafax.se Precedence: bulk le lundi 09 avril à 14 H 27 , Mats Dufberg a écrit : > On Mon, 9 Apr 2001, Hollenbeck, Scott wrote: > > > >A SHOULD would be appropriate if storing the IP address for glue records > > >not strictly needed would be a better solution than not. I disagree. By > > >storing and announcing the IP address you increase the risk of have > > >different data in the mother zone than in the authoritative > > >zone. -- Data should be kept where it is authoritative as far as possible. > > > > ...and by not mentioning anything at all about the need for an IP address > > with a name server you run the larger risk of not having glue where it's > > needed. > > If a glue is needed and IP address is missing, the delegation should be > refused. > > > I don't have a problem with adding some words that describe why the > > SHOULD isn't a MUST (see below), but cutting out the requirement completely > > doesn't address the reality of needing addresses to produce glue records. > > > > 3.4.2-[3] existing text: > > Name servers registered within the registry's authoritative TLDs MUST be > > registered with a valid IPv4 or IPv6 address. > > > > 3.4.2-[3], change MUST to SHOULD and add new text: > > Name servers registered within the registry's authoritative TLDs SHOULD be > > registered with a valid IPv4 or IPv6 address only as required to produce DNS > > "glue" records. > > > There could be a MUST for needed glue: > > 3.4.2-[3], updated to cover strictly needed glue: > > Name servers MUST be registered with valid IPv4 or IPv6 address when "glue > record" is stricly needed for delegation of a domain from the TLD. The > address MAY be removed when no longer needed for strict "glue record". > > > The MUST could be moved to somewhere else to say: > > Delegation MUST be refused if a valid IPv4 or IPv6 address is not > available for strictly needed "glue record". > > > Mats > > ----------------------------------------------------------------- > Mats Dufberg +46-8-545 857 06 > dufberg@nic-se.se fax: +46-8-545 857 29 > Matt, I suppose that nic-se remove the glues that are not longer needed in ALL cases, don't you? I agree with all the arguments you have posted in this thread, about this topic and I would even write a "MUST" for your second "MAY". 3.4.2-[3], updated to cover strictly needed glue: Name servers MUST be registered with valid IPv4 or IPv6 address when "glue record" is stricly needed for delegation of a domain from the TLD. The address MUST be removed when no longer needed for strict "glue record". ^^^^ regards, Olivier Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEglIG020308 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:42:47 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEgkLt020303 for ; Wed, 11 Apr 2001 16:42:46 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id QAA21487 ; Wed, 11 Apr 2001 16:42:42 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3BEh6s19233; Wed, 11 Apr 2001 16:43:06 +0200 Date: Wed, 11 Apr 2001 16:43:06 +0200 From: Olivier Guillard To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: Re: comments on last draft Message-ID: <20010411164306.E11284@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Wed, Apr 11, 2001 at 08:30:15AM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk le mercredi 11 avril à 08 H 30 , Hollenbeck, Scott a écrit : > >> >** BEGIN REMARK *************************************************** > >I understand, but as part of a generic registrar registry protocole, and > >regarding the practises of many TLDs, I suppose that this service should > >be formalized within the object management sections and seen as a requirement. > >For many reasons, as many other ccTLDs, we need to check and validate the > >demands of DN. > > This isn't necessarily a protocol issue, it's a back-end policy issue! What > your registry does within your back end is your business; the protocol > shouldn't introduce any features that keep you from doing what you need to > do. That's what 8.2-[1] says. This kind of check might be performed by the registry, by the registrar or by a third party which is not the registrar, nor the registry. An entry to be able to discusse with the server to perform this seem important in many TLD environement. > More than once people have complained about requirements that had a policy > slant, and I've removed or reworded every one that was brought to my attention. > Thus, I don't believe it proper to add a new policy-oriented requirement. I'm sorry, but reading this paper I have a lot of difficulties to discern what are technical-oriented requirements from what are policy-oriented requirements. > > >> > >> [snip] > >> > > > >shame :( > > > >additional sections in root servers can be a real pain if not properly > >maintained. > > Shame? It's common e-mail courtesy to remove sections of a message > for which no response is provided, and I think we've addressed the > name server-IP address issue very thoroughly as part of another > thread. Exact, and it seems that there is no consensus on this topic. > >Well, if I understand what you say: > > > >1) domain name object, with a required field ("name" or "designation" > > e.g.: "toto.com."); > >2) name server objects whith an equivalent required field that depend > > on a domain name object designation (e.g: ns1."toto.com.") > >3) the maintenance of these objects should not be centralized (here > > starts the troubles) > >3bis) for example, a domain object might be remove, this operation having > > no effect on the namerservers designated by this domain (no foreign > > key in nameserver objets is another word). > > > >> > > >> >Will it be sufficient to have a whole coherent db? > >> > >> My assertion is that this is the most reasonable of multiple options, and > >> that it is indeed possible to maintain relational integrity. > > > > > >I would appreciate other point of view on this topic because personally, I > >don't think that this option is the most reasonable to maintain relational > >integrity. > > Klaus just raised a similar thought with name server and domains objects on > another thread. I've responded there as well, and I'd like to carry on that > discussion there if possible to help keep it focused. Scott, I havn't found the thread, sorry. I don't see any satisfactory answer to this question. > >It seems to me that allow the original sponsoring registrar to approve or > >reject a requested object transfer is a policie question, not a technical > >requirement anyway. But I understand that some registries might need this > >feature (actually we do). In this case, the grace period element should > >be more explicit. > > No, you've quoted the wrong sentence. Look at 3.4.5-[5] and -[6], where it > very clearly says that a registrar has to have an opportunity to approve, > reject, or cancel transfer requests. There used to be explicit mention of a > grace period, but it was removed because someone (sorry, I forget who) said > that was a matter of registry policy. As written, saying that a registrar > MUST have an opportunity to approve or reject a transfer means that it can't > happen right away, which means that there has to be an opportunity (or grace > period) to respond. We don't talk about the same issue. My question is how long the registrant will see his/her domain blocked for if the original registrar reject any transfert attempts? > >> >> >3.4.7 Object Deletion > >> >> >--------------------- > >> >> >whois responsible for the db integrity? > > > >> >> Each client is responsible for the integrity of the objects > >> >they sponsor. > >> > > >> >Will it be sufficient to have a whole coherent db? > >> > >> Yes, I think so. > > > >By experience, I don't. > >> >> > [3] .... crouik .... > >> >> > successful transfer request or completed transfer (if any), the > >> >> > most recent authorization information and identifiers describing > >> >> > ^^^^^^^^^^^^^^^^^^^^^^ > >> >> > domain names associated with the social information > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > My objection is that the kind of abstract object relationships described are > more appropriately determined by a query protocol or reporting service. My objection here is that your objection is subjective, I could object the same way for more than half of the datas return on this one for example: [1] The protocol MUST provide services to retrieve information describing a domain name from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the domain, the creation date and time, the expiration date and time (if any), the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last successful transfer request or completed transfer (if any), the current status of the domain, the most recent authorization information, identifiers describing social information associated with the domain, and the child name servers registered in the domain. The most recent authorization information MUST be returned only to the current sponsoring registrar. Regards, -- Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard@nic.fr || tel: +33 1 39 30 83 31 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEQDEA020201 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:26:13 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEQCLt020196 for ; Wed, 11 Apr 2001 16:26:12 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA03776; Wed, 11 Apr 2001 10:25:37 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0D1H>; Wed, 11 Apr 2001 10:18:59 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , "Jordyn A. Buchanan" Cc: ietf-provreg@cafax.se Subject: RE: Issues on 3.4.9 Object Information Query Date: Wed, 11 Apr 2001 10:18:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Wednesday, April 11, 2001 4:03 AM >To: Jordyn A. Buchanan >Cc: Hollenbeck, Scott; ietf-provreg@cafax.se >Subject: Re: Issues on 3.4.9 Object Information Query > > >"Jordyn A. Buchanan" wrote: >> >> At 9:24 AM +0200 4/10/01, Klaus Malorny wrote: >> >> >>[...] > >> >I think it does. >> >> Why? These are fairly separate functions. The set of capabilities >> currently defined within provreg are all basically required for >> object registration and provisioning. The capability you're talking >> about is more useful for "maintenance, database synchronisation, >> error detection etc." as you mention below. It seems like we could >> handle the separate functions and purposes through separate >> mechanisms. >> > >Just think of the following "conversation": > > Client: delete domain blabla.tld > Server: deletion denied. Object still in use. > >and now? What are you doing now in the case that *you* think that the domain >is *not* in use? Do you want to pay for the domain until you get a database >dump end of next month or quarter revealing the problem? Ahh, but the problem will be immediately obvious given the requirement to explicitly identify the *.blabla.tld name servers in the response to a general object information query. The client who wants to delete the domain can determine exactly which other objects are involved by doing an info query on the domain object. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEHdqr020144 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:17:39 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEHcLt020139 for ; Wed, 11 Apr 2001 16:17:38 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA03719 for ; Wed, 11 Apr 2001 10:17:37 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0DDZ>; Wed, 11 Apr 2001 10:10:59 -0400 Message-ID: From: "Hollenbeck, Scott" To: ietf-provreg@cafax.se Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership Date: Wed, 11 Apr 2001 10:10:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] >Sent: Wednesday, April 11, 2001 7:41 AM >To: 'Klaus Malorny'; ietf-provreg@cafax.se >Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership [snip] >Now, one can argue (and we have, we've talked about this more than once) >that this is a restrictive model, and that any registrar should be able to >create a host in foo.com. As I've said before, this introduces a different >set of difficulties regarding management of foo.com that I believe are more >difficult to solve. Once you have multiple registrars creating objects that >are hierarchically related to foo.com the registrar of foo.com doesn't have >a complete picture of the domain object, which may lead to inter-registrar >(that is, _competing_ registrar) coordination requirements and associated >problems. After taking some more time to step back and consider the operational issues associated with changing the domain-name server relationship as described in the requirements draft, I'd like to ask anyone who believes that the separation model is more appropriate to explain how the following scenarios might be addressed: The possibility of redirection and DoS attacks increases if multiple registrars are capable of registering hosts as name servers. For example, registrar A sponsors foo.com, which has been delegated to ns1.foo.com and ns2.foo.com. Host www.foo.com exists in the foo.com zone. Registrar B registers www.foo.com as a name server object, with an IP address different from the one specified in the foo.com zone, resulting in a redirection that registrar A (and the registrant of foo.com) can do nothing about without explicit action from registrar B, who may refuse to cooperate. Yes, even registrar A can register www.foo.com as a name server and cause problems, but with only one registrar involved the problem is _much_ easier to resolve. If we allow domain objects (such as foo.com) to be deleted without requiring deletion or renaming of name server objects (such as ns1.foo.com) registered under the domain, we allow creation of orphaned A records. This doesn't have an immediate operational consequence for the DNS (queries for something like www.foo.com will yield an NXDOMAIN response), but it does become a garbage collection issue in the zone that publishes the glue record for ns1.foo.com, which remains after foo.com has been deleted. This, too, can present a denial of service issue when someone re-registers foo.com and they try to register a name server named ns1.foo.com, which won't be possible because the old ns1.foo.com remains! Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BEAnbW020084 for ietf-provreg-outgoing; Wed, 11 Apr 2001 16:10:49 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BEAmLt020079 for ; Wed, 11 Apr 2001 16:10:48 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3BEAVD11241; Wed, 11 Apr 2001 10:10:31 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104111410.f3BEAVD11241@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Eric Brunner-Williams in Portland Maine'" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: Registrant Access (Data Protection/Privacy) In-Reply-To: Your message of "Wed, 11 Apr 2001 09:21:47 EDT." Date: Wed, 11 Apr 2001 10:10:31 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I stuck it (an extension) in there (ACCESS element) for extensibility. At the moment I can't think of any extensions to the access-values, and I'm open to alternatives. There is a typo in the ABNF, the final lacks a "/", and I've just about got the package policy {access, statement {purpose, recipient, retention}, expiry} ready to send to the list. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BDUmgp019793 for ietf-provreg-outgoing; Wed, 11 Apr 2001 15:30:48 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BDUkLt019788 for ; Wed, 11 Apr 2001 15:30:47 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3BDUSD11154; Wed, 11 Apr 2001 09:30:28 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104111330.f3BDUSD11154@nic-naa.net> To: Olivier Guillard / AFNIC cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, tech@nic.fr, brunner@nic-naa.net Subject: Re: comments on last draft In-Reply-To: Your message of "Wed, 11 Apr 2001 12:13:41 +0200." <20010411121341.A21676@james.nic.fr> Date: Wed, 11 Apr 2001 09:30:28 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk [snip] > >> >3.4.5 Object Transfer ... > It seems to me that allow the original sponsoring registrar to approve or > reject a requested object transfer is a policie question, not a technical You are mistaken. There is a set of operations, each has a semantic and a syntax that are (subject to correction) adequately specified. One operation (xfr) has an implicit order-of-events issue. Picking one is a technical necessity. If your policy requirement is not met, then you should be making the case that we should make xfr's implicit order-of-events explicit, and add a mechanism for operational selection of which order-of-events is to be used, allowing multiple-choice, hence allowing for operational selection of policy. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BDSYRe019770 for ietf-provreg-outgoing; Wed, 11 Apr 2001 15:28:34 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BDSWLt019765 for ; Wed, 11 Apr 2001 15:28:33 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA03512; Wed, 11 Apr 2001 09:28:26 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0DCJ>; Wed, 11 Apr 2001 09:21:48 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: ietf-provreg@cafax.se Subject: RE: Registrant Access (Data Protection/Privacy) Date: Wed, 11 Apr 2001 09:21:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Eric, Can you provide some more detail describing what the "extension" is all about? The DTD described in the reference you provided describes an element with an optional attribute with name "optional" and enumerated values of "yes" or "no", and parsed character data for the content. Is this just a string of unspecified additional information? There may be a more compact way of representing this structure using the access_disclosure elements as attributes of the ACCESS element, like this: This is PCDATA. This is PCDATA, too. >-----Original Message----- >From: Eric Brunner-Williams in Portland Maine >[mailto:brunner@nic-naa.net] >Sent: Monday, April 09, 2001 1:41 PM >To: ietf-provreg@cafax.se >Subject: Registrant Access (Data Protection/Privacy) > > >In a note sent to both the provreg and whois lists earlier this year, >Patrik Faltstrom mentioned registrant access in the context of data >protection. More recently, Sheer noted that while specific requirements >are "local", e.g., specific "data-access" functional requirements, the >abstract form is of general interest. > >Here is a fragment (draft forthcomming, RSN!!!) on access >policy and its >expression in ABNF (grammer representation of XML syntax) and in XSD. > >Modified from http://www.w3.org/TR/P3P/#ACCESS [1] > >The element is defined as the ability of registrant to view >registrant originated data and address questions or concerns to the >registration service provider. Registration service providers MUST >disclose one value for the access attribute. The method of access is >not specified. (Note this has _nothing_ to do with whois:43 or whois:xx >"access", which is outside the scope of a provisioning protocol.) > >The ACCESS element must contain one of the following elements: > > access is provided to all social data only > access is provided to all technical data only > access is provided to all technical and social data > registrant data exists but access is not provided > registrant data is not persistent > > >The (P3P-consistent) ABNF for this is: > > access = "" > access_disclosure > *extension > "" > > access_disclosure = "" | ; socal data only > "" | ; technical data only > "" | ; all data > "" | ; access not provided > "" | ; data not persistent > [snip] Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BCb2Rr019467 for ietf-provreg-outgoing; Wed, 11 Apr 2001 14:37:02 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BCb0Lt019462 for ; Wed, 11 Apr 2001 14:37:01 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA03360; Wed, 11 Apr 2001 08:36:54 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0DB1>; Wed, 11 Apr 2001 08:30:16 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Olivier Guillard / AFNIC'" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: RE: comments on last draft Date: Wed, 11 Apr 2001 08:30:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f3BCb2Lt019463 Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Olivier Guillard / AFNIC [mailto:Olivier.Guillard@nic.fr] >Sent: Wednesday, April 11, 2001 6:14 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se; tech@nic.fr >Subject: Re: comments on last draft > > >le mardi 10 avril à 14 H 27 , Hollenbeck, Scott a écrit : >> >1. Introduction >> >--------------- >> > >> >** BEGIN REMARK *************************************************** >> > >> >The idea here is that the validating process is a step that need >> >to be performed under certain TLD (may be not by the registry). >> >This validation can have many reason (data protection, naming >> >plan etc.). >> > >> >An entry point to allow this step must be available somewhere >> >in the protocole (probably in the object management section), >> > >> >Something like: >> > >> > The protocol MUST provide services that allow a validating service >> > to approve or reject object registration. Requests to approve or >> > reject the registration objects MUST be limited. Unauthorized >> > attempts to approve or reject the object registration MUST be >> > explicitly rejected. >> > >> >if there is no "validating service" for a particular registry, this feature >> >will not be used. >> >> This is why 8.2-[1] was added based on an earlier request from you. It >> already says that validation services may be provided. > >I understand, but as part of a generic registrar registry protocole, and >regarding the practises of many TLDs, I suppose that this service should >be formalized within the object management sections and seen as a requirement. >For many reasons, as many other ccTLDs, we need to check and validate the >demands of DN. This isn't necessarily a protocol issue, it's a back-end policy issue! What your registry does within your back end is your business; the protocol shouldn't introduce any features that keep you from doing what you need to do. That's what 8.2-[1] says. More than once people have complained about requirements that had a policy slant, and I've removed or reworded every one that was brought to my attention. Thus, I don't believe it proper to add a new policy-oriented requirement. >> >> [snip] >> > >shame :( > >additional sections in root servers can be a real pain if not properly >maintained. Shame? It's common e-mail courtesy to remove sections of a message for which no response is provided, and I think we've addressed the name server-IP address issue very thoroughly as part of another thread. >> >> >** BEGIN REMARK >*************************************************** > >> >> >> >> If example.com is removed, server ns1.example.com will have to removed or >> >> renamed. >> > >> >Is this a requirement? >> >> Not specifically, because it's more a matter of how a registry manages it's >> data. >> >> >> test.com will have to be updated to note the change. Each >> >> client/registrar is responsible for the integrity of the objects >> >> they sponsor. > > >Well, if I understand what you say: > >1) domain name object, with a required field ("name" or "designation" > e.g.: "toto.com."); >2) name server objects whith an equivalent required field that depend > on a domain name object designation (e.g: ns1."toto.com.") >3) the maintenance of these objects should not be centralized (here > starts the troubles) >3bis) for example, a domain object might be remove, this operation having > no effect on the namerservers designated by this domain (no foreign > key in nameserver objets is another word). > >> > >> >Will it be sufficient to have a whole coherent db? >> >> My assertion is that this is the most reasonable of multiple options, and >> that it is indeed possible to maintain relational integrity. > > >I would appreciate other point of view on this topic because personally, I >don't think that this option is the most reasonable to maintain relational >integrity. Klaus just raised a similar thought with name server and domains objects on another thread. I've responded there as well, and I'd like to carry on that discussion there if possible to help keep it focused. >> >> >3.4.5 Object Transfer >> >> >--------------------- >> >> > >> >> > [6] The protocol MUST provide services that allow the original >> >> > sponsoring registrar to approve or reject a requested object transfer. >> >> > Requests to approve or reject the transfer of registered objects MUST >> >> > be limited to the registrar that currently sponsors the registered >> >> > object. Unauthorized attempts to approve or reject the transfer of a >> >> > registered object MUST be explicitly rejected. >> >> > >> >> >For how long? What happens if the registrant WANTS to transfer his/her >> >> >domain and the current registrar doesn't? is there any grace period? >> >> > >> >> >the real point is: where is the user here? >> >> > >> >> >** END REMARK *************************************************** >> >> >> >> "How long" and grace periods are a registry policy matter. It will >> >> be up to each registry to figure out what works for them. >> > >> >Then a fonctionality must be implemented to allow the registry to configure >> >a grace period in this situation. >> >> That functionality is already provided in the "approve", "cancel" and >> "reject" transfer mechanisms described in section 3.4.5. > >You mean it's "implicit" in the following sentence: > > Unauthorized attempts to approve or reject the transfer of a registered > object MUST be explicitly rejected. > >It seems to me that allow the original sponsoring registrar to approve or >reject a requested object transfer is a policie question, not a technical >requirement anyway. But I understand that some registries might need this >feature (actually we do). In this case, the grace period element should >be more explicit. No, you've quoted the wrong sentence. Look at 3.4.5-[5] and -[6], where it very clearly says that a registrar has to have an opportunity to approve, reject, or cancel transfer requests. There used to be explicit mention of a grace period, but it was removed because someone (sorry, I forget who) said that was a matter of registry policy. As written, saying that a registrar MUST have an opportunity to approve or reject a transfer means that it can't happen right away, which means that there has to be an opportunity (or grace period) to respond. >> >> >3.4.7 Object Deletion >> >> >--------------------- >> >> >whois responsible for the db integrity? > >> >> Each client is responsible for the integrity of the objects >> >they sponsor. >> > >> >Will it be sufficient to have a whole coherent db? >> >> Yes, I think so. > >By experience, I don't. > > >> >> > [3] .... crouik .... >> >> > successful transfer request or completed transfer (if any), the >> >> > most recent authorization information and identifiers describing >> >> > ^^^^^^^^^^^^^^^^^^^^^^ >> >> > domain names associated with the social information >> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> >> This gets into another thread that's currently open on the mailing list, >> >> that of queries returning what Klaus has called "reverse" associations. >> >> I don't believe that such a feature is proper in a provisioning protocol, >> >> but it is appropriate for a query protocol or reporting service. >> > >> >I think the protocole should support this, even if a registry can >> >disable the feature (question of policie). >> >> I think we'll have to agree to disagree on this point. > >I don't see the problem to see this fonctionality implemented if it's >possible to NOT use it? My objection is that the kind of abstract object relationships described are more appropriately determined by a query protocol or reporting service. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BBmnqQ019259 for ietf-provreg-outgoing; Wed, 11 Apr 2001 13:48:49 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BBmlLt019254 for ; Wed, 11 Apr 2001 13:48:48 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA03249; Wed, 11 Apr 2001 07:48:14 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0DAJ>; Wed, 11 Apr 2001 07:41:36 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership Date: Wed, 11 Apr 2001 07:41:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Wednesday, April 11, 2001 5:33 AM >To: Hollenbeck, Scott; ietf-provreg@cafax.se >Subject: 3.4/Object Ownership, esp. Name Server Ownership > > > > >Hallo! > >One thing I nearly forgot is the question of object ownership. The section 3.4 >is a bit unspecific to this topic. In the spec the term "sponsoring registrar" >appears, which obviously describes the ownership of an object. On the first >view one could think that the registrar which creates an object automatically >owns/sponsors this object. But section "3.4.5 Object Transfer" tells us that >name servers that belong (in a technical sense) to the zone of a domain are >also transferred to the new owner. This implies that the ownership of name >servers is related to the ownership of the corresponding domain. Now the >problems start: > > - may have name servers a different owner than the domain they belong to? > > - if not, may other registrars have the ability to register a name server > that belong to a domain sponsored by another registar? Is the ownership > automatically transferred to that registrar just after registration? > > >One big problem we regularly have with NSI's current registry system is that >it disallows the registration of a name server belonging to a domain >registered by another registrar. The requirement to be able to do that might >be unreasonable in the first view. But many customers choose to use multiple >registrars simultaneously for registering their domains, and it is rather >difficult to explain to them that we can't register their domains with name >servers they had specified and they own. It is a serious flaw in the design of >the current system and should be avoided in any new protocol. > >Therefore, the requirement document should detail the question of ownership >and restrictions regarding it. > >Scott, could you please describe how you envisage the behaviour? The draft doesn't use the term "ownership" anywhere, and for good reason. What "ownership" means depends on legal definitions that vary from place to place, and I want no part of trying to determine how different entities interpret the term. "Sponsorship", on the other hand, describes the relationship between a client and the objects the client creates in the repository. The client that creates an object has administrative rights to manage the object in the repository. I don't see a requirement anywhere in the draft that says that only the registrar who creates foo.com can create hosts in foo.com. Maybe that's a hole, because 3.4.5 does say that if foo.com is transferred, all of the foo.com hosts are transferred as well. I don't think foo.com hosts should be transferred unless they are all sponsored by the same registrar. Without this requirement, the other alternative is to change 3.4.5-[1] to remove everything after the first sentence and go back to the drawing board to figure out how to deal with host transfers. If the list really supports the idea of allowing any registrar to create a host object, then we also need to support explicit host transfers. As currently written, 3.4.5 says that name server sponsorship relations must be maintained when a domain is transferred. If foo.com is transferred, all of the foo.com hosts are transferred as well. If we assume that no other registrar can create hosts in foo.com, a consistent sponsorship relationship is changed when a domain transfer takes place. 3.4.9 says that the list of name servers that are subject to transfer must be visible as part of the information describing a domain, so there's no surprise or hidden relationships. Now, one can argue (and we have, we've talked about this more than once) that this is a restrictive model, and that any registrar should be able to create a host in foo.com. As I've said before, this introduces a different set of difficulties regarding management of foo.com that I believe are more difficult to solve. Once you have multiple registrars creating objects that are hierarchically related to foo.com the registrar of foo.com doesn't have a complete picture of the domain object, which may lead to inter-registrar (that is, _competing_ registrar) coordination requirements and associated problems. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BAML83018896 for ietf-provreg-outgoing; Wed, 11 Apr 2001 12:22:21 +0200 (MEST) Received: from nohope.patoche.org (nohope.patoche.org [213.228.57.2]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BAMJLt018891 for ; Wed, 11 Apr 2001 12:22:20 +0200 (MEST) Received: (from patrick@localhost) by nohope.patoche.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA03729; Wed, 11 Apr 2001 12:20:31 +0200 Date: Wed, 11 Apr 2001 12:20:31 +0200 From: Patrick To: Klaus Malorny Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: Re: 3.4/Object Ownership, esp. Name Server Ownership Message-ID: <20010411122031.D20991@nohope.patoche.org> References: <3AD424B1.BDB710DC@knipp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AD424B1.BDB710DC@knipp.de>; from Klaus.Malorny@knipp.de on Wed, Apr 11, 2001 at 11:32:33AM +0200 Organization: Gandi Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Apr 11, 2001 at 11:32:33AM +0200, Klaus Malorny took time to write: > One big problem we regularly have with NSI's current registry system is that > it disallows the registration of a name server belonging to a domain > registered by another registrar. The requirement to be able to do that might > be unreasonable in the first view. But many customers choose to use multiple > registrars simultaneously for registering their domains, and it is rather > difficult to explain to them that we can't register their domains with name > servers they had specified and they own. It is a serious flaw in the design of > the current system and should be avoided in any new protocol. Another real case even more impossible to handle now. A ``owns'' nameserver Z registered in the database as such. A wants to delete it for whatever reason from the database. If Z is used as nameserver for any domain, the deletion will be refused. Even if A does everything he can (contact the domain owner asking them to remove _his_ nameserver, etc...), he is blocked. Something should be attempted so that cases like that will not happen anymore. If A was really associated as owner of Z in the database, he would be possible for him maybe to delete it even if this case. Patrick. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3BADMJp018827 for ietf-provreg-outgoing; Wed, 11 Apr 2001 12:13:22 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3BADLLt018822 for ; Wed, 11 Apr 2001 12:13:21 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id MAA04935 ; Wed, 11 Apr 2001 12:13:17 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3BADfl09724; Wed, 11 Apr 2001 12:13:41 +0200 Date: Wed, 11 Apr 2001 12:13:41 +0200 From: Olivier Guillard / AFNIC To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: Re: comments on last draft Message-ID: <20010411121341.A21676@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Tue, Apr 10, 2001 at 02:27:15PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk le mardi 10 avril à 14 H 27 , Hollenbeck, Scott a écrit : > >1. Introduction > >--------------- > > > >** BEGIN REMARK *************************************************** > > > >The idea here is that the validating process is a step that need > >to be performed under certain TLD (may be not by the registry). > >This validation can have many reason (data protection, naming > >plan etc.). > > > >An entry point to allow this step must be available somewhere > >in the protocole (probably in the object management section), > > > >Something like: > > > > The protocol MUST provide services that allow a validating service > > to approve or reject object registration. Requests to approve or > > reject the registration objects MUST be limited. Unauthorized > > attempts to approve or reject the object registration MUST be > > explicitly rejected. > > > >if there is no "validating service" for a particular registry, this feature > >will not be used. > > This is why 8.2-[1] was added based on an earlier request from you. It > already says that validation services may be provided. I understand, but as part of a generic registrar registry protocole, and regarding the practises of many TLDs, I suppose that this service should be formalized within the object management sections and seen as a requirement. For many reasons, as many other ccTLDs, we need to check and validate the demands of DN. > > [snip] > shame :( additional sections in root servers can be a real pain if not properly maintained. > >> >** BEGIN REMARK *************************************************** > >> > >> If example.com is removed, server ns1.example.com will have to removed or > >> renamed. > > > >Is this a requirement? > > Not specifically, because it's more a matter of how a registry manages it's > data. > > >> test.com will have to be updated to note the change. Each > >> client/registrar is responsible for the integrity of the objects > >> they sponsor. Well, if I understand what you say: 1) domain name object, with a required field ("name" or "designation" e.g.: "toto.com."); 2) name server objects whith an equivalent required field that depend on a domain name object designation (e.g: ns1."toto.com.") 3) the maintenance of these objects should not be centralized (here starts the troubles) 3bis) for example, a domain object might be remove, this operation having no effect on the namerservers designated by this domain (no foreign key in nameserver objets is another word). > > > >Will it be sufficient to have a whole coherent db? > > My assertion is that this is the most reasonable of multiple options, and > that it is indeed possible to maintain relational integrity. I would appreciate other point of view on this topic because personally, I don't think that this option is the most reasonable to maintain relational integrity. > >> >3.4.5 Object Transfer > >> >--------------------- > >> > > >> > [6] The protocol MUST provide services that allow the original > >> > sponsoring registrar to approve or reject a requested object transfer. > >> > Requests to approve or reject the transfer of registered objects MUST > >> > be limited to the registrar that currently sponsors the registered > >> > object. Unauthorized attempts to approve or reject the transfer of a > >> > registered object MUST be explicitly rejected. > >> > > >> >For how long? What happens if the registrant WANTS to transfer his/her > >> >domain and the current registrar doesn't? is there any grace period? > >> > > >> >the real point is: where is the user here? > >> > > >> >** END REMARK *************************************************** > >> > >> "How long" and grace periods are a registry policy matter. It will > >> be up to each registry to figure out what works for them. > > > >Then a fonctionality must be implemented to allow the registry to configure > >a grace period in this situation. > > That functionality is already provided in the "approve", "cancel" and > "reject" transfer mechanisms described in section 3.4.5. You mean it's "implicit" in the following sentence: Unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected. It seems to me that allow the original sponsoring registrar to approve or reject a requested object transfer is a policie question, not a technical requirement anyway. But I understand that some registries might need this feature (actually we do). In this case, the grace period element should be more explicit. > >> >3.4.7 Object Deletion > >> >--------------------- > >> >whois responsible for the db integrity? > >> Each client is responsible for the integrity of the objects > >they sponsor. > > > >Will it be sufficient to have a whole coherent db? > > Yes, I think so. By experience, I don't. > >> > [3] .... crouik .... > >> > successful transfer request or completed transfer (if any), the > >> > most recent authorization information and identifiers describing > >> > ^^^^^^^^^^^^^^^^^^^^^^ > >> > domain names associated with the social information > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> This gets into another thread that's currently open on the mailing list, > >> that of queries returning what Klaus has called "reverse" associations. > >> I don't believe that such a feature is proper in a provisioning protocol, > >> but it is appropriate for a query protocol or reporting service. > > > >I think the protocole should support this, even if a registry can > >disable the feature (question of policie). > > I think we'll have to agree to disagree on this point. I don't see the problem to see this fonctionality implemented if it's possible to NOT use it? Regards, Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard@nic.fr Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3B9UOq9018673 for ietf-provreg-outgoing; Wed, 11 Apr 2001 11:30:24 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3B9UNLt018668 for ; Wed, 11 Apr 2001 11:30:23 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA23040; Wed, 11 Apr 2001 11:30:18 +0200 (METDST) Message-ID: <3AD424B1.BDB710DC@knipp.de> Date: Wed, 11 Apr 2001 11:32:33 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: 3.4/Object Ownership, esp. Name Server Ownership Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hallo! One thing I nearly forgot is the question of object ownership. The section 3.4 is a bit unspecific to this topic. In the spec the term "sponsoring registrar" appears, which obviously describes the ownership of an object. On the first view one could think that the registrar which creates an object automatically owns/sponsors this object. But section "3.4.5 Object Transfer" tells us that name servers that belong (in a technical sense) to the zone of a domain are also transferred to the new owner. This implies that the ownership of name servers is related to the ownership of the corresponding domain. Now the problems start: - may have name servers a different owner than the domain they belong to? - if not, may other registrars have the ability to register a name server that belong to a domain sponsored by another registar? Is the ownership automatically transferred to that registrar just after registration? One big problem we regularly have with NSI's current registry system is that it disallows the registration of a name server belonging to a domain registered by another registrar. The requirement to be able to do that might be unreasonable in the first view. But many customers choose to use multiple registrars simultaneously for registering their domains, and it is rather difficult to explain to them that we can't register their domains with name servers they had specified and they own. It is a serious flaw in the design of the current system and should be avoided in any new protocol. Therefore, the requirement document should detail the question of ownership and restrictions regarding it. Scott, could you please describe how you envisage the behaviour? Eventually, we should give up the ownership relationship between name servers and domains, including the implicit transfer of name servers on domain transfers -- even if this voids some results of earlier discussions here. BTW. the problem does not appear at the contacts, as each registrar can create his own entry (or even multiple) for the same entity. regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3B80c6U018200 for ietf-provreg-outgoing; Wed, 11 Apr 2001 10:00:38 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3B80aLt018195 for ; Wed, 11 Apr 2001 10:00:37 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id KAA07665; Wed, 11 Apr 2001 10:00:29 +0200 (METDST) Message-ID: <3AD40FA5.9A078C35@knipp.de> Date: Wed, 11 Apr 2001 10:02:45 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Jordyn A. Buchanan" CC: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: Re: Issues on 3.4.9 Object Information Query References: <3AD2B547.8777F22E@knipp.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Jordyn A. Buchanan" wrote: > > At 9:24 AM +0200 4/10/01, Klaus Malorny wrote: > > >>[...] > >I think it does. > > Why? These are fairly separate functions. The set of capabilities > currently defined within provreg are all basically required for > object registration and provisioning. The capability you're talking > about is more useful for "maintenance, database synchronisation, > error detection etc." as you mention below. It seems like we could > handle the separate functions and purposes through separate > mechanisms. > Just think of the following "conversation": Client: delete domain blabla.tld Server: deletion denied. Object still in use. and now? What are you doing now in the case that *you* think that the domain is *not* in use? Do you want to pay for the domain until you get a database dump end of next month or quarter revealing the problem? I don't know whether it is possible for a different registrar to register a name server below a certain domain (I know it's not possible under NSI's system, and it is always a pain -- sorry Scott). If so, situations with unknown references could easily appear. > >> [...] > > > >This function is very useful for maintenance, database synchronisation, error > >detection etc. as I mentioned earlier. I agree that this function should not > >be a "standard" function, i.e., the normal query should not report the reverse > >references, as a name server may be used by thousands of domains and this > >would increase processing time and message size. It should be done either as > >an option or as a separate request. > > I think you may under-appreciate just how much this functionality may > increase processing time and message size. We (register.com) have > about three million domain names on our name servers. Right now, > there's only a few hundred thousand on any given name server, but our > goal is to get them all on the same set of name servers. I know that > other organizations have very large numbers of domain names > associated with individual name servers; likewise, there are some > contacts associated with many domains. Do we really want to be > returning data sets of this size through a provisioning protocol? We > need a way to get information on object associations, but it doesn't > belong in provreg. > As I mentioned above, I don't underestimate it. Although it is not a nice way to solve the problem, there is still the possibility to truncate the output to a reasonable size. Some databases even have extensions to SQL to limit the number of reported rows. So there is always a solution. > Jordyn > regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AIY2Nx014137 for ietf-provreg-outgoing; Tue, 10 Apr 2001 20:34:02 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AIY1Lt014132 for ; Tue, 10 Apr 2001 20:34:01 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA01756; Tue, 10 Apr 2001 14:33:59 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0CVH>; Tue, 10 Apr 2001 14:27:22 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Olivier Guillard'" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: RE: comments on last draft Date: Tue, 10 Apr 2001 14:27:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f3AIY1Lt014133 Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Olivier Guillard [mailto:Olivier.Guillard@nic.fr] >Sent: Tuesday, April 10, 2001 2:10 PM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se; tech@nic.fr >Subject: Re: comments on last draft > > >Thank you for your quick response > >le mardi 10 avril à 12 H 48 , Hollenbeck, Scott a écrit : >> >1. Introduction >> >--------------- >> > >> >** BEGIN REMARK *************************************************** >> >just a comment here: there is no definition for those >registries that >> > validate information (social and/or technical) >> > stored and published for a given TLD. >> > >> There's no additional definition for a "validating" registry because I >> didn't see validation as a model discriminator. > >The idea here is that the validating process is a step that need >to be performed under certain TLD (may be not by the registry). >This validation can have many reason (data protection, naming >plan etc.). > >An entry point to allow this step must be available somewhere >in the protocole (probably in the object management section), > >Something like: > > The protocol MUST provide services that allow a validating service > to approve or reject object registration. Requests to approve or > reject the registration objects MUST be limited. Unauthorized > attempts to approve or reject the object registration MUST be > explicitly rejected. > >if there is no "validating service" for a particular registry, this feature >will not be used. This is why 8.2-[1] was added based on an earlier request from you. It already says that validation services may be provided. [snip] > >> >** BEGIN REMARK *************************************************** >> > >> > [4] Some managed objects represent shared resources that MAY be >> > referenced by multiple registrars. Requests to associate a known >> > shared resource object with another registered object MUST NOT be >> > limited to the registrar that sponsors the registered objects. For >> > example, server ns1.example.com (managed by registrar X) MAY be >> > associated with both domain example.com (managed by registrar X) and >> > domain test.com (managed by registrar Y). Registrar X maintains >> > administrative control over domain example.com and server >> > ns1.example.com, and registrar Y maintains administrative control over >> > domain test.com. Registrar Y does not have administrative control >> > over server ns1.example.com. >> > >> >A question here: what happens to test.com if example.com is removed? >> > >> >And another more important one: >> >Who is responsible for the db integrity? >> > >> > >> >** END REMARK *************************************************** >> >> If example.com is removed, server ns1.example.com will have to removed or >> renamed. > >Is this a requirement? Not specifically, because it's more a matter of how a registry manages it's data. >> test.com will have to be updated to note the change. Each >> client/registrar is responsible for the integrity of the objects >> they sponsor. > >It means that the client must be very aware of many things :) > >Will it be sufficient to have a whole coherent db? My assertion is that this is the most reasonable of multiple options, and that it is indeed possible to maintain relational integrity. >> >> >3.4.5 Object Transfer >> >--------------------- >> > >> >** BEGIN REMARK *************************************************** >> > >> > [2] The protocol MUST provide services to transfer social information >> > objects among authorized registrars. >> > >> >This point is sensitive, because personal information do not have the >> >same status in each country. For example we have implemented a red list >> >for domains belonging to individuals. >> > >> > >> >** END REMARK *************************************************** >> >> Agreed -- how this is managed will be a registry policy matter. > >Yes, that's one of the reason why we need to check and validate if it is >really an individual that register a domain name. > >> >** BEGIN REMARK *************************************************** >> > >> > [6] The protocol MUST provide services that allow the original >> > sponsoring registrar to approve or reject a requested object transfer. >> > Requests to approve or reject the transfer of registered objects MUST >> > be limited to the registrar that currently sponsors the registered >> > object. Unauthorized attempts to approve or reject the transfer of a >> > registered object MUST be explicitly rejected. >> > >> >For how long? What happens if the registrant WANTS to transfer his/her >> >domain and the current registrar doesn't? is there any grace period? >> > >> >the real point is: where is the user here? >> > >> >** END REMARK *************************************************** >> >> "How long" and grace periods are a registry policy matter. It will be up to >> each registry to figure out what works for them. > >Then a fonctionality must be implemented to allow the registry to configure >a grace period in this situation. That functionality is already provided in the "approve", "cancel" and "reject" transfer mechanisms described in section 3.4.5. > >> >> >3.4.7 Object Deletion >> >--------------------- >> >** BEGIN REMARK *************************************************** >> > >> >All sub chapters >> >---------------- >> > >> >whois responsible for the db integrity? >> > >> > >> >** END REMARK *************************************************** >> >> Each client is responsible for the integrity of the objects >they sponsor. > >Will it be sufficient to have a whole coherent db? Yes, I think so. >> >** BEGIN REMARK *************************************************** >> > >> > [3] The protocol MUST provide services to retrieve social information >> > from the registry. Returned information MUST include identification >> > attributes (which MAY include name, address, telephone numbers, and >> > e-mail address), the identifier of the registrar that originally >> > registered the information, the creation date and time, the date and >> > time of the last successful update (if any), the identifier of the >> > registrar that performed the last update, the date and time of last >> > successful transfer request or completed transfer (if any), the >> > most recent authorization information and identifiers describing >> > ^^^^^^^^^^^^^^^^^^^^^^ >> > domain names associated with the social information >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > >> >** END REMARK *************************************************** >> >> This gets into another thread that's currently open on the mailing list, >> that of queries returning what Klaus has called "reverse" associations. I >> don't believe that such a feature is proper in a provisioning protocol, but >> it is appropriate for a query protocol or reporting service. > >I think the protocole should support this, even if a registry can >disable the feature (question of policie). I think we'll have to agree to disagree on this point. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AI9phx013971 for ietf-provreg-outgoing; Tue, 10 Apr 2001 20:09:51 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AI9oLt013966 for ; Tue, 10 Apr 2001 20:09:50 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id UAA24771 ; Tue, 10 Apr 2001 20:09:46 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3AIABV24563; Tue, 10 Apr 2001 20:10:11 +0200 Date: Tue, 10 Apr 2001 20:10:11 +0200 From: Olivier Guillard To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: Re: comments on last draft Message-ID: <20010410201011.F16328@james.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from shollenbeck@verisign.com on Tue, Apr 10, 2001 at 12:48:02PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thank you for your quick response le mardi 10 avril à 12 H 48 , Hollenbeck, Scott a écrit : > >1. Introduction > >--------------- > > > >** BEGIN REMARK *************************************************** > >just a comment here: there is no definition for those registries that > > validate information (social and/or technical) > > stored and published for a given TLD. > > > There's no additional definition for a "validating" registry because I > didn't see validation as a model discriminator. The idea here is that the validating process is a step that need to be performed under certain TLD (may be not by the registry). This validation can have many reason (data protection, naming plan etc.). An entry point to allow this step must be available somewhere in the protocole (probably in the object management section), Something like: The protocol MUST provide services that allow a validating service to approve or reject object registration. Requests to approve or reject the registration objects MUST be limited. Unauthorized attempts to approve or reject the object registration MUST be explicitly rejected. if there is no "validating service" for a particular registry, this feature will not be used. > >** END REMARK *************************************************** > > > >3.4.2 Object Registration > >------------------------- > > > >** BEGIN REMARK *************************************************** > > > > [3] The protocol ...... > >....cut...... > > I think we've covered this particular requirement very thoroughly in another > thread. I disagree with the change from MUST to SHOULD or MAY in the first > sentence; we know for a fact that there are registries that require this > feature. The second MUST will be changed to a SHOULD with an explanation of > when it has to happen. Ok, I understand the first MUST if there are registries that require this feature (even if I don't see any reason why we would use this feature today). But I still think that the question of registring Name Servers with or without IP is a question of policy regarding the registration of the name servers objet and shouldn't be stressed by a SHOULD. ---> A name server MAY NOT be associated to any IP address. > > > > > >** END REMARK *************************************************** > >** BEGIN REMARK *************************************************** > > > > [4] Some managed objects represent shared resources that MAY be > > referenced by multiple registrars. Requests to associate a known > > shared resource object with another registered object MUST NOT be > > limited to the registrar that sponsors the registered objects. For > > example, server ns1.example.com (managed by registrar X) MAY be > > associated with both domain example.com (managed by registrar X) and > > domain test.com (managed by registrar Y). Registrar X maintains > > administrative control over domain example.com and server > > ns1.example.com, and registrar Y maintains administrative control over > > domain test.com. Registrar Y does not have administrative control > > over server ns1.example.com. > > > >A question here: what happens to test.com if example.com is removed? > > > >And another more important one: > >Who is responsible for the db integrity? > > > > > >** END REMARK *************************************************** > > If example.com is removed, server ns1.example.com will have to removed or > renamed. Is this a requirement? > test.com will have to be updated to note the change. Each > client/registrar is responsible for the integrity of the objects > they sponsor. It means that the client must be very aware of many things :) Will it be sufficient to have a whole coherent db? > > >3.4.5 Object Transfer > >--------------------- > > > >** BEGIN REMARK *************************************************** > > > > [2] The protocol MUST provide services to transfer social information > > objects among authorized registrars. > > > >This point is sensitive, because personal information do not have the > >same status in each country. For example we have implemented a red list > >for domains belonging to individuals. > > > > > >** END REMARK *************************************************** > > Agreed -- how this is managed will be a registry policy matter. Yes, that's one of the reason why we need to check and validate if it is really an individual that register a domain name. > >** BEGIN REMARK *************************************************** > > > > [6] The protocol MUST provide services that allow the original > > sponsoring registrar to approve or reject a requested object transfer. > > Requests to approve or reject the transfer of registered objects MUST > > be limited to the registrar that currently sponsors the registered > > object. Unauthorized attempts to approve or reject the transfer of a > > registered object MUST be explicitly rejected. > > > >For how long? What happens if the registrant WANTS to transfer his/her > >domain and the current registrar doesn't? is there any grace period? > > > >the real point is: where is the user here? > > > >** END REMARK *************************************************** > > "How long" and grace periods are a registry policy matter. It will be up to > each registry to figure out what works for them. Then a fonctionality must be implemented to allow the registry to configure a grace period in this situation. > > >3.4.7 Object Deletion > >--------------------- > >** BEGIN REMARK *************************************************** > > > >All sub chapters > >---------------- > > > >whois responsible for the db integrity? > > > > > >** END REMARK *************************************************** > > Each client is responsible for the integrity of the objects they sponsor. Will it be sufficient to have a whole coherent db? > >** BEGIN REMARK *************************************************** > > > > [3] The protocol MUST provide services to retrieve social information > > from the registry. Returned information MUST include identification > > attributes (which MAY include name, address, telephone numbers, and > > e-mail address), the identifier of the registrar that originally > > registered the information, the creation date and time, the date and > > time of the last successful update (if any), the identifier of the > > registrar that performed the last update, the date and time of last > > successful transfer request or completed transfer (if any), the > > most recent authorization information and identifiers describing > > ^^^^^^^^^^^^^^^^^^^^^^ > > domain names associated with the social information > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > >** END REMARK *************************************************** > > This gets into another thread that's currently open on the mailing list, > that of queries returning what Klaus has called "reverse" associations. I > don't believe that such a feature is proper in a provisioning protocol, but > it is appropriate for a query protocol or reporting service. I think the protocole should support this, even if a registry can disable the feature (question of policie). -- Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard@nic.fr || tel: +33 1 39 30 83 31 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AHCmf1013673 for ietf-provreg-outgoing; Tue, 10 Apr 2001 19:12:48 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AHClLt013668 for ; Tue, 10 Apr 2001 19:12:47 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3AHCPD07455; Tue, 10 Apr 2001 13:12:25 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104101712.f3AHCPD07455@nic-naa.net> To: Olivier Guillard cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se, tech@nic.fr, brunner@nic-naa.net Subject: Re: comments on last draft In-Reply-To: Your message of "Tue, 10 Apr 2001 18:12:26 +0200." <20010410181226.D16328@james.nic.fr> Date: Tue, 10 Apr 2001 13:12:25 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Olivier, In your remarks concerning 3.4.5 [2], transfer of social data, I appreciate that the status of personal information is jurisdictionally scoped. I hope that my notes, beginning with yesterday's on the ACCESS element, and continuing today and tomorrow, which will propose a P3P-inspired metadata labels capable of expressing both the data collection practice, and the jurisdictional scoping, will provide the mechanism to meet this requirement. Eric Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AGt0bY013529 for ietf-provreg-outgoing; Tue, 10 Apr 2001 18:55:00 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AGssLt013524 for ; Tue, 10 Apr 2001 18:54:54 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA01138; Tue, 10 Apr 2001 12:54:43 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0CQP>; Tue, 10 Apr 2001 12:48:07 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Olivier Guillard'" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: RE: comments on last draft Date: Tue, 10 Apr 2001 12:48:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks for your comments, Olivier. I'll address them below. >-----Original Message----- >From: Olivier Guillard [mailto:Olivier.Guillard@nic.fr] >Sent: Tuesday, April 10, 2001 12:12 PM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se; tech@nic.fr >Subject: comments on last draft > > >Dear Scott and all, > >Afnic is the .fr registry. We have read this draft: >http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt >with a great interest. > >We thank you for this job that contribute harmonizing >practises. > >We wished to ask you some questions and express ideas >about certain chapters found in this document either >because we don't understand them or because they doesn't >matche our practises. > >For an easier reading: > >Each point is framed by a ** REM ***... >The chapters titles are given >The particular suggestions added in the original text are underlined > ^^^^^^^^^^ >Regards, > > >Olivier > > >1. Introduction >--------------- > >** BEGIN REMARK *************************************************** > >Thin Registry: A registry in which some element of the social information > associated with registered entities is distributed between > a shared registry and the registrars served by the registry. > >Thin Registry: A registry in which all elements of the social information... > ^^^ > >just a comment here: there is no definition for those registries that > validate information (social and/or technical) > stored and published for a given TLD. > > >** END REMARK *************************************************** I'm OK with the suggested change; I can't think of any social information that we maintain in the thin VeriSign registry as an example. There's no additional definition for a "validating" registry because I didn't see validation as a model discriminator. >3.4.2 Object Registration >------------------------- > >** BEGIN REMARK *************************************************** > > [3] The protocol MUST provide services to register name servers. Name > server registration MUST NOT be limited to a specific period of time. > Name servers registered within the registry's authoritative TLDs MUST > be registered with a valid IPv4 or IPv6 address. A name server MAY be > registered with multiple IP addresses. An IP address MAY be shared > among multiple name servers using distinct server names. Name servers > that exist in TLDs other than those for which the registry is > authoritative MUST be registered without an IP address providing that > the server's TLD is itself a valid TLD. > >.fr db don't need independant name server objects today. We understand >that name servers objects can be useful, but only in certain environment >and only if their maintenance are associated with relevant policie >usage (like contacting the techs that maintain domains served by a >nameserver being suppressed for example). > >Anyway, the time spent to check the integrity of existing datas under >certain environment does not justify today the implementation of such >a feature, for us, it shouldn't be a requirement. > >Morover, if it's implemented, we don't see why the IP address should be >required. It is only necessary when a given NS serves a zone under which >it's referenced. > >For example: > >If exemple.fr is served by ns.exemple.fr, then we need the IP of >ns.exemple.fr as glue. >If exemple.fr is also served by ns.example.com or ns.dupont.fr it's >not our buisness to announce the IP address of those hosts, so why >ask for this information? (we check that these NS are properly >resolved before announcing exemple.fr) > >We would suggest a "SHOULD" and a "MAY" here: > > [3] The protocol SHOULD (or even MAY) provide services to register > ^^^^^^ ^^^ > name servers. Name server registration MUST NOT be limited to a > specific period of time. Name servers registered within the > registry's authoritative TLDs MAY be registered with a valid > ^^^ > IPv4 or IPv6 address. > > >** END REMARK *************************************************** I think we've covered this particular requirement very thoroughly in another thread. I disagree with the change from MUST to SHOULD or MAY in the first sentence; we know for a fact that there are registries that require this feature. The second MUST will be changed to a SHOULD with an explanation of when it has to happen. >** BEGIN REMARK *************************************************** > > [4] The protocol MUST provide services to manage name servers that MAY > be associated with multiple domains. > >Why again (see above)? > > [4] The protocol MAY provide services to manage name servers that MAY > ^^^ > be associated with multiple domains. > > >Something like: > >"The protocol MAY provide services to manage multiple domain name maintaining." > >Would be another way of maintaining multiple domain changes > > >** END REMARK *************************************************** See my response above. There is no requirement for a registry that doesn't need this feature (or other server management features) to use it. >3.4.3 Object Association >------------------------ > >** BEGIN REMARK *************************************************** > > [2] The protocol MUST provide services to associate IP addresses with > name servers. Name servers MAY have multiple IP addresses. An IP > address MAY be associated with multiple name servers. > >Once again, we don't see why IP addresses of NS should be required. > >---> A name server MAY NOT be associated to any IP address. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >** END REMARK *************************************************** Again, this is a required feature for some other registries. If AFNIC doesn't need it, you won't be required to use it. >** BEGIN REMARK *************************************************** > > [4] Some managed objects represent shared resources that MAY be > referenced by multiple registrars. Requests to associate a known > shared resource object with another registered object MUST NOT be > limited to the registrar that sponsors the registered objects. For > example, server ns1.example.com (managed by registrar X) MAY be > associated with both domain example.com (managed by registrar X) and > domain test.com (managed by registrar Y). Registrar X maintains > administrative control over domain example.com and server > ns1.example.com, and registrar Y maintains administrative control over > domain test.com. Registrar Y does not have administrative control > over server ns1.example.com. > >A question here: what happens to test.com if example.com is removed? > >And another more important one: >Who is responsible for the db integrity? > > >** END REMARK *************************************************** If example.com is removed, server ns1.example.com will have to removed or renamed. test.com will have to be updated to note the change. Each client/registrar is responsible for the integrity of the objects they sponsor. >3.4.5 Object Transfer >--------------------- > >** BEGIN REMARK *************************************************** > > [2] The protocol MUST provide services to transfer social information > objects among authorized registrars. > >This point is sensitive, because personal information do not have the >same status in each country. For example we have implemented a red list >for domains belonging to individuals. > > >** END REMARK *************************************************** Agreed -- how this is managed will be a registry policy matter. >** BEGIN REMARK *************************************************** > > [6] The protocol MUST provide services that allow the original > sponsoring registrar to approve or reject a requested object transfer. > Requests to approve or reject the transfer of registered objects MUST > be limited to the registrar that currently sponsors the registered > object. Unauthorized attempts to approve or reject the transfer of a > registered object MUST be explicitly rejected. > >For how long? What happens if the registrant WANTS to transfer his/her >domain and the current registrar doesn't? is there any grace period? > >the real point is: where is the user here? > >** END REMARK *************************************************** "How long" and grace periods are a registry policy matter. It will be up to each registry to figure out what works for them. >3.4.7 Object Deletion >--------------------- >** BEGIN REMARK *************************************************** > >All sub chapters >---------------- > >whois responsible for the db integrity? > > >** END REMARK *************************************************** Each client is responsible for the integrity of the objects they sponsor. >3.4.8 Object Existence >---------------------- > >** BEGIN REMARK *************************************************** > > [2] The protocol MUST provide services to determine if a name server > exists in the registry. Name servers MUST be searchable by fully > qualified name. > >-> [2] The protocol MAY provide services to determine if a name server > ^^^ >see above > >** END REMARK *************************************************** See my responses above as well. >** BEGIN REMARK *************************************************** > > [3] The protocol MUST provide services to determine if a social > information object exists in the registry. Social information MUST be > searchable by a registry-unique identifier. > >What if this information is not connected to any domain name object? >For example, I personally think that it should be cleaned up and in >all cases NOT published anymore (issue to manage in 3.4.8) > >** END REMARK *************************************************** A registry or registrar could certainly clean up contacts with no active associations, but I don't think that's protocol requirement. >3.4.9 Object Information Query >------------------------------ > >** BEGIN REMARK *************************************************** > > [2] The protocol MUST provide services to retrieve information > describing a name server from the registry. > >-> [2] The protocol MAY provide services to retrieve information... > ^^^ > >see above > > >** END REMARK *************************************************** Me too, see above. >** BEGIN REMARK *************************************************** > > [3] The protocol MUST provide services to retrieve social information > from the registry. Returned information MUST include identification > attributes (which MAY include name, address, telephone numbers, and > e-mail address), the identifier of the registrar that originally > registered the information, the creation date and time, the date and > time of the last successful update (if any), the identifier of the > registrar that performed the last update, the date and time of last > successful transfer request or completed transfer (if any), the > most recent authorization information and identifiers describing > ^^^^^^^^^^^^^^^^^^^^^^ > domain names associated with the social information > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >** END REMARK *************************************************** This gets into another thread that's currently open on the mailing list, that of queries returning what Klaus has called "reverse" associations. I don't believe that such a feature is proper in a provisioning protocol, but it is appropriate for a query protocol or reporting service. >3.5 Domain Status Indicators >---------------------------- > >** BEGIN REMARK *************************************************** > >SUGGESTION: > >One of the states could be "validation process". A domain name >could then be pending waiting for (for example) an intermediate >service or a third party validation. > >It would allow to implement the following (page 19): > >"However, intermediate services that preserve the integrity of the protocol >MAY be provided. For example, an intermediate service that determines if a >registrant is authorized to register a name in a TLD MAY be provided." > > >** END REMARK *************************************************** Could be, but the states listed in the draft are only suggestions, not a list that MUST be implemented. The suggested "newly created" state could also be used to indicate that something (such as validation) is going on between creation and activation. >7.6 Security >------------ > >** BEGIN REMARK *************************************************** > > [1] Transactional privacy and integrity services MUST be available at > some protocol layer. > > [2] This document describes requirements for basic user identification > and authentication services. A generic protocol MAY include > additional security services to protect against the attacks described > here, or a generic protocol MUST depend on other-layered protocols to > provide additional security services. > >==> What do "basic user identification and authentication services" >consist of? Why isn't AUTHENTICATION at least as important as PRIVACY >and INTEGRITY (presence of MUST key word)? > >** END REMARK *************************************************** Identification and authentication requirements are described in section 3.2, and there are indeed MUSTs used to describe them. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AGC7lZ013283 for ietf-provreg-outgoing; Tue, 10 Apr 2001 18:12:07 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AGC6Lt013278 for ; Tue, 10 Apr 2001 18:12:06 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id SAA26472 ; Tue, 10 Apr 2001 18:12:01 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f3AGCQn22199; Tue, 10 Apr 2001 18:12:26 +0200 Date: Tue, 10 Apr 2001 18:12:26 +0200 From: Olivier Guillard To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se, tech@nic.fr Subject: comments on last draft Message-ID: <20010410181226.D16328@james.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Scott and all, Afnic is the .fr registry. We have read this draft: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt with a great interest. We thank you for this job that contribute harmonizing practises. We wished to ask you some questions and express ideas about certain chapters found in this document either because we don't understand them or because they doesn't matche our practises. For an easier reading: Each point is framed by a ** REM ***... The chapters titles are given The particular suggestions added in the original text are underlined ^^^^^^^^^^ Regards, Olivier 1. Introduction --------------- ** BEGIN REMARK *************************************************** Thin Registry: A registry in which some element of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry. Thin Registry: A registry in which all elements of the social information... ^^^ just a comment here: there is no definition for those registries that validate information (social and/or technical) stored and published for a given TLD. ** END REMARK *************************************************** 3.4.2 Object Registration ------------------------- ** BEGIN REMARK *************************************************** [3] The protocol MUST provide services to register name servers. Name server registration MUST NOT be limited to a specific period of time. Name servers registered within the registry's authoritative TLDs MUST be registered with a valid IPv4 or IPv6 address. A name server MAY be registered with multiple IP addresses. An IP address MAY be shared among multiple name servers using distinct server names. Name servers that exist in TLDs other than those for which the registry is authoritative MUST be registered without an IP address providing that the server's TLD is itself a valid TLD. .fr db don't need independant name server objects today. We understand that name servers objects can be useful, but only in certain environment and only if their maintenance are associated with relevant policie usage (like contacting the techs that maintain domains served by a nameserver being suppressed for example). Anyway, the time spent to check the integrity of existing datas under certain environment does not justify today the implementation of such a feature, for us, it shouldn't be a requirement. Morover, if it's implemented, we don't see why the IP address should be required. It is only necessary when a given NS serves a zone under which it's referenced. For example: If exemple.fr is served by ns.exemple.fr, then we need the IP of ns.exemple.fr as glue. If exemple.fr is also served by ns.example.com or ns.dupont.fr it's not our buisness to announce the IP address of those hosts, so why ask for this information? (we check that these NS are properly resolved before announcing exemple.fr) We would suggest a "SHOULD" and a "MAY" here: [3] The protocol SHOULD (or even MAY) provide services to register ^^^^^^ ^^^ name servers. Name server registration MUST NOT be limited to a specific period of time. Name servers registered within the registry's authoritative TLDs MAY be registered with a valid ^^^ IPv4 or IPv6 address. ** END REMARK *************************************************** ** BEGIN REMARK *************************************************** [4] The protocol MUST provide services to manage name servers that MAY be associated with multiple domains. Why again (see above)? [4] The protocol MAY provide services to manage name servers that MAY ^^^ be associated with multiple domains. Something like: "The protocol MAY provide services to manage multiple domain name maintaining." Would be another way of maintaining multiple domain changes ** END REMARK *************************************************** 3.4.3 Object Association ------------------------ ** BEGIN REMARK *************************************************** [2] The protocol MUST provide services to associate IP addresses with name servers. Name servers MAY have multiple IP addresses. An IP address MAY be associated with multiple name servers. Once again, we don't see why IP addresses of NS should be required. ---> A name server MAY NOT be associated to any IP address. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ** END REMARK *************************************************** ** BEGIN REMARK *************************************************** [4] Some managed objects represent shared resources that MAY be referenced by multiple registrars. Requests to associate a known shared resource object with another registered object MUST NOT be limited to the registrar that sponsors the registered objects. For example, server ns1.example.com (managed by registrar X) MAY be associated with both domain example.com (managed by registrar X) and domain test.com (managed by registrar Y). Registrar X maintains administrative control over domain example.com and server ns1.example.com, and registrar Y maintains administrative control over domain test.com. Registrar Y does not have administrative control over server ns1.example.com. A question here: what happens to test.com if example.com is removed? And another more important one: Who is responsible for the db integrity? ** END REMARK *************************************************** 3.4.5 Object Transfer --------------------- ** BEGIN REMARK *************************************************** [2] The protocol MUST provide services to transfer social information objects among authorized registrars. This point is sensitive, because personal information do not have the same status in each country. For example we have implemented a red list for domains belonging to individuals. ** END REMARK *************************************************** ** BEGIN REMARK *************************************************** [6] The protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. Requests to approve or reject the transfer of registered objects MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected. For how long? What happens if the registrant WANTS to transfer his/her domain and the current registrar doesn't? is there any grace period? the real point is: where is the user here? ** END REMARK *************************************************** 3.4.7 Object Deletion --------------------- ** BEGIN REMARK *************************************************** All sub chapters ---------------- whois responsible for the db integrity? ** END REMARK *************************************************** 3.4.8 Object Existence ---------------------- ** BEGIN REMARK *************************************************** [2] The protocol MUST provide services to determine if a name server exists in the registry. Name servers MUST be searchable by fully qualified name. -> [2] The protocol MAY provide services to determine if a name server ^^^ see above ** END REMARK *************************************************** ** BEGIN REMARK *************************************************** [3] The protocol MUST provide services to determine if a social information object exists in the registry. Social information MUST be searchable by a registry-unique identifier. What if this information is not connected to any domain name object? For example, I personally think that it should be cleaned up and in all cases NOT published anymore (issue to manage in 3.4.8) ** END REMARK *************************************************** 3.4.9 Object Information Query ------------------------------ ** BEGIN REMARK *************************************************** [2] The protocol MUST provide services to retrieve information describing a name server from the registry. -> [2] The protocol MAY provide services to retrieve information... ^^^ see above ** END REMARK *************************************************** ** BEGIN REMARK *************************************************** [3] The protocol MUST provide services to retrieve social information from the registry. Returned information MUST include identification attributes (which MAY include name, address, telephone numbers, and e-mail address), the identifier of the registrar that originally registered the information, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last successful transfer request or completed transfer (if any), the most recent authorization information and identifiers describing ^^^^^^^^^^^^^^^^^^^^^^ domain names associated with the social information ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ** END REMARK *************************************************** 3.5 Domain Status Indicators ---------------------------- ** BEGIN REMARK *************************************************** SUGGESTION: One of the states could be "validation process". A domain name could then be pending waiting for (for example) an intermediate service or a third party validation. It would allow to implement the following (page 19): "However, intermediate services that preserve the integrity of the protocol MAY be provided. For example, an intermediate service that determines if a registrant is authorized to register a name in a TLD MAY be provided." ** END REMARK *************************************************** 7.6 Security ------------ ** BEGIN REMARK *************************************************** [1] Transactional privacy and integrity services MUST be available at some protocol layer. [2] This document describes requirements for basic user identification and authentication services. A generic protocol MAY include additional security services to protect against the attacks described here, or a generic protocol MUST depend on other-layered protocols to provide additional security services. ==> What do "basic user identification and authentication services" consist of? Why isn't AUTHENTICATION at least as important as PRIVACY and INTEGRITY (presence of MUST key word)? ** END REMARK *************************************************** -- Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard@nic.fr || tel: +33 1 39 30 83 31 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AEoN0A012707 for ietf-provreg-outgoing; Tue, 10 Apr 2001 16:50:23 +0200 (MEST) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AEoKLt012702 for ; Tue, 10 Apr 2001 16:50:21 +0200 (MEST) Received: from [165.247.213.113] (user-2ivfi54.dialup.mindspring.com [165.247.200.164]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id HAA18982; Tue, 10 Apr 2001 07:50:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <3AD2B547.8777F22E@knipp.de> References: <3AD2B547.8777F22E@knipp.de> Date: Tue, 10 Apr 2001 07:50:03 -0700 To: Klaus Malorny , "Hollenbeck, Scott" From: "Jordyn A. Buchanan" Subject: Re: Issues on 3.4.9 Object Information Query Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 9:24 AM +0200 4/10/01, Klaus Malorny wrote: >"Hollenbeck, Scott" wrote: >> >> OK, now I think I understand, and I think this is something that the WG >> needs to chew on for a bit because it gets close to a topic that I raised in >> the protocol design team report: does it make sense for a provisioning >> protocol to provide abstract relationship reporting services? > >I think it does. Why? These are fairly separate functions. The set of capabilities currently defined within provreg are all basically required for object registration and provisioning. The capability you're talking about is more useful for "maintenance, database synchronisation, error detection etc." as you mention below. It seems like we could handle the separate functions and purposes through separate mechanisms. > > I submit that it's not a good idea for a _provisioning_ protocol to provide >> a query service to (as an example) list all of the domains delegated to a >> particular name server, or all of the domains for which I happen to be a >> contact. > >This function is very useful for maintenance, database synchronisation, error >detection etc. as I mentioned earlier. I agree that this function should not >be a "standard" function, i.e., the normal query should not report the reverse >references, as a name server may be used by thousands of domains and this >would increase processing time and message size. It should be done either as >an option or as a separate request. I think you may under-appreciate just how much this functionality may increase processing time and message size. We (register.com) have about three million domain names on our name servers. Right now, there's only a few hundred thousand on any given name server, but our goal is to get them all on the same set of name servers. I know that other organizations have very large numbers of domain names associated with individual name servers; likewise, there are some contacts associated with many domains. Do we really want to be returning data sets of this size through a provisioning protocol? We need a way to get information on object associations, but it doesn't belong in provreg. Jordyn -- Jordyn A. Buchanan jordyn@register.com Futurist +1.212.798.9262 Register.com http://www.register.com/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AEYCTx012607 for ietf-provreg-outgoing; Tue, 10 Apr 2001 16:34:12 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AEYBLt012602 for ; Tue, 10 Apr 2001 16:34:11 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3AEXhD06988; Tue, 10 Apr 2001 10:33:43 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104101433.f3AEXhD06988@nic-naa.net> To: Peter Eisenhauer cc: Eric Brunner-Williams in Portland Maine , "Hollenbeck, Scott" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: 3.4.9 [4] In-Reply-To: Your message of "Tue, 10 Apr 2001 14:42:40 +0200." <20010410144240.A14748@tornado.schlund.de> Date: Tue, 10 Apr 2001 10:33:43 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The question is: If a registry wants to regulate access to information by its > own policy, can this done using the current version of the specification? Should it? What is the use case? RegistrANT Elf restricts the RECIPIENTS of its data to itself, RegistRAR Gnome, and RegisTRY Wizard. RegistRAR Gnome restricts the RECIPIENTS of RegistrANT Elf's data to RegistrANT Elf, itself, and RegisTRY Wizard. RegisTRY Wizard adds RegistRAR Troll to the RECIPIENTS of RegistrANT Elf data. Is the use case a) general, and b) desireable, and c) something to put into the protocol? Your question is about the RECIPIENTS of data. May the RegisTRY determine the RECIPIENTS of data, in conflict with the RECIPIENTS designated by the registrar that currently sponsors an item of data, and in conflict with the RECIPIENTS designated by the data-originator (registrANT)? The issue, if general as posed here, should be addressed in Section 8.4, "Data Collection Requirements". If specific to Object Query, it should still be reflected in Section 8.4. As Scott and I have remarked, the Data Collection work is in-progress. I hope to get more out today. Careful reading and comments always welcome. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3ACoHvv011759 for ietf-provreg-outgoing; Tue, 10 Apr 2001 14:50:17 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3ACoGLt011754 for ; Tue, 10 Apr 2001 14:50:17 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA00004; Tue, 10 Apr 2001 08:49:43 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0CH9>; Tue, 10 Apr 2001 08:43:07 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" Cc: ietf-provreg@cafax.se Subject: RE: Issues on 3.4.9 Object Information Query Date: Tue, 10 Apr 2001 08:43:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Tuesday, April 10, 2001 3:25 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se >Subject: Re: Issues on 3.4.9 Object Information Query > > >"Hollenbeck, Scott" wrote: >> >> OK, now I think I understand, and I think this is something that the WG >> needs to chew on for a bit because it gets close to a topic that I raised in >> the protocol design team report: does it make sense for a provisioning >> protocol to provide abstract relationship reporting services? > >I think it does. >> >> I submit that it's not a good idea for a _provisioning_ protocol to provide >> a query service to (as an example) list all of the domains delegated to a >> particular name server, or all of the domains for which I happen to be a >> contact. > >This function is very useful for maintenance, database synchronisation, error >detection etc. as I mentioned earlier. I agree that this function should not >be a "standard" function, i.e., the normal query should not report the reverse >references, as a name server may be used by thousands of domains and this >would increase processing time and message size. It should be done either as >an option or as a separate request. > >> We already have requirements to identify object associations >> (3.4.9-[1], for example, says that contacts and subordinate "child" name >> servers have to be reported when retrieving information about a domain). >> > >Yes, but let us distinguish the directions of the references (compare to the >directions of the arrows in the example). Normal queries would only report >references that point away. On special request, also those references are >reported that point to the object itself. Another way to deal with the maintenance etc. issues is via offline reporting, which may provide a more flexible and DB-friendly way to extract the potentially large volumes of information that may be involved in these object relationships. Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3ACghfU011682 for ietf-provreg-outgoing; Tue, 10 Apr 2001 14:42:43 +0200 (MEST) Received: from mout02.kundenserver.de (mout02.kundenserver.de [195.20.224.133]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3ACggLt011677 for ; Tue, 10 Apr 2001 14:42:42 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout02.kundenserver.de with esmtp (Exim 2.12 #2) id 14mxTk-0001qU-00; Tue, 10 Apr 2001 14:42:40 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14mxTo-0003Af-00; Tue, 10 Apr 2001 14:42:44 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f3ACgfn14800; Tue, 10 Apr 2001 14:42:41 +0200 Date: Tue, 10 Apr 2001 14:42:40 +0200 From: Peter Eisenhauer To: Eric Brunner-Williams in Portland Maine Cc: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: Re: 3.4.9 [4] Message-ID: <20010410144240.A14748@tornado.schlund.de> References: <200104101220.f3ACK7D06633@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200104101220.f3ACK7D06633@nic-naa.net>; from brunner@nic-naa.net on Tue, Apr 10, 2001 at 08:20:07AM -0400 Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Apr 10, 2001 at 08:20:07AM -0400, Eric Brunner-Williams in Portland Maine wrote: > > This particular wording was requested by Eric Brunner-Williams. Eric, would > > you care to clarify, please? > > Sure. Here is the excerpt from my original (off-list) note to the author of > -06 (now -01) on February 8th: > > : 3.11 Object Information Query > : > : The return values of an information query (FQDN, NS, RegId) is detailed > : and the query mechanism is registrar indifferent, except that the most > : recent authorization identifier return is registrar specific, and any > : extension of registry specific semantics is on an opt-in basis by the > : incumbant registrar. > : > : Please invert the optional registry specific semantic extension so that > : opt-out is the default, e.g., s/limited to/granted by/. > : > : [4] Requests to retrieve information describing a registered object > : MAY be _granted_by_ the registrar that currently sponsors the registered > : object. > > In case memories aren't perfect (and mine usually isn't, at least about other > people's issues), the -06 draft had default opt-in disclosure semantics on > queries, as the registrar may LIMIT, as opposed to default opt-out, where the > registrar may GRANT. > > Here is the resulting text in -00, then -01, in 3.4.9 [4] > > >"Requests to retrieve information describing a registered object > > MAY be granted by the registrar that currently sponsors the registered > > object." > > Peter's suggested modification (below) allows the registry to modify the > recipients of registrant-originated data, and to modify the recipients of > registrar-sponsored data (usually equivalent datums). > > "... MAY be granted by the registrar that currently sponsors the registered > object or MAY be granted by registry policy." > > I'd like to know what the motivating use cases are, as I don't know what > Peter ment in his motivational comment by "the (registry public) retrievel". > I trust we're not revisiting the whois:43 and/or whois:xx question, as that > is out of scope for the R* protocol. > > I await further clarification. I meant access by all other authorized users of the registry when I wrote "registry public", so this is no public access or whois issue. The question is: If a registry wants to regulate access to information by its own policy, can this done using the current version of the specification? It is only mentioned that the current sponsoring registrar MAY grant rights to retrieve information on an object -- however the registry itself is not mentioned. > > Eric Best Regards, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3ACKWub011533 for ietf-provreg-outgoing; Tue, 10 Apr 2001 14:20:32 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3ACKULt011526 for ; Tue, 10 Apr 2001 14:20:30 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3ACK7D06633; Tue, 10 Apr 2001 08:20:07 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104101220.f3ACK7D06633@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Peter Eisenhauer'" , ietf-provreg@cafax.se, brunner@nic-naa.net Subject: Re: 3.4.9 [4] In-Reply-To: Your message of "Tue, 10 Apr 2001 06:54:59 EDT." Date: Tue, 10 Apr 2001 08:20:07 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This particular wording was requested by Eric Brunner-Williams. Eric, would > you care to clarify, please? Sure. Here is the excerpt from my original (off-list) note to the author of -06 (now -01) on February 8th: : 3.11 Object Information Query : : The return values of an information query (FQDN, NS, RegId) is detailed : and the query mechanism is registrar indifferent, except that the most : recent authorization identifier return is registrar specific, and any : extension of registry specific semantics is on an opt-in basis by the : incumbant registrar. : : Please invert the optional registry specific semantic extension so that : opt-out is the default, e.g., s/limited to/granted by/. : : [4] Requests to retrieve information describing a registered object : MAY be _granted_by_ the registrar that currently sponsors the registered : object. In case memories aren't perfect (and mine usually isn't, at least about other people's issues), the -06 draft had default opt-in disclosure semantics on queries, as the registrar may LIMIT, as opposed to default opt-out, where the registrar may GRANT. Here is the resulting text in -00, then -01, in 3.4.9 [4] >"Requests to retrieve information describing a registered object > MAY be granted by the registrar that currently sponsors the registered > object." Peter's suggested modification (below) allows the registry to modify the recipients of registrant-originated data, and to modify the recipients of registrar-sponsored data (usually equivalent datums). "... MAY be granted by the registrar that currently sponsors the registered object or MAY be granted by registry policy." I'd like to know what the motivating use cases are, as I don't know what Peter ment in his motivational comment by "the (registry public) retrievel". I trust we're not revisiting the whois:43 and/or whois:xx question, as that is out of scope for the R* protocol. I await further clarification. Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AB5f5T011131 for ietf-provreg-outgoing; Tue, 10 Apr 2001 13:05:41 +0200 (MEST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AB5YLt011126 for ; Tue, 10 Apr 2001 13:05:40 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11079; Tue, 10 Apr 2001 07:05:33 -0400 (EDT) Message-Id: <200104101105.HAA11079@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-provreg-epp-01.txt Date: Tue, 10 Apr 2001 07:05:32 -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-epp-01.txt Pages : 62 Date : 09-Apr-01 This document describes a connection-oriented, application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-epp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-epp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010409125136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-epp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-epp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010409125136.I-D@ietf.org> --OtherAccess-- --NextPart-- Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3AB1ivh011088 for ietf-provreg-outgoing; Tue, 10 Apr 2001 13:01:44 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3AB1hLt011083 for ; Tue, 10 Apr 2001 13:01:44 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA29825; Tue, 10 Apr 2001 07:01:42 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0CG4>; Tue, 10 Apr 2001 06:55:06 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Peter Eisenhauer'" , ietf-provreg@cafax.se Subject: RE: 3.4.9 [4] Date: Tue, 10 Apr 2001 06:54:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Peter Eisenhauer [mailto:eisenhauer@schlund.de] >Sent: Tuesday, April 10, 2001 5:09 AM >To: ietf-provreg@cafax.se >Subject: 3.4.9 [4] > > > >3.4.9 [4]: >"Requests to retrieve information describing a registered object > MAY be granted by the registrar that currently sponsors the registered > object." > >As far as I understand the (registry public) retrievel of object information >using the protocol then is handle by registrar policy? Shouldn't it be >possible also to the registry? > >Suggestion: > >"... MAY be granted by the registrar that currently sponsors the registered > object or MAY be granted by registry policy." > >Or is this not neccessary because of 1-3 the registry MUST provide services to >retrieve information and therefore by definition is able to grant rights to >retrieve information? This particular wording was requested by Eric Brunner-Williams. Eric, would you care to clarify, please? Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3A99BrH010779 for ietf-provreg-outgoing; Tue, 10 Apr 2001 11:09:11 +0200 (MEST) Received: from mout03.kundenserver.de (mout03.kundenserver.de [195.20.224.218]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3A99ALt010773 for ; Tue, 10 Apr 2001 11:09:10 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout03.kundenserver.de with esmtp (Exim 2.12 #2) id 14mu95-0000cz-00 for ietf-provreg@cafax.se; Tue, 10 Apr 2001 11:09:07 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14mu9A-0001gB-00 for ietf-provreg@cafax.se; Tue, 10 Apr 2001 11:09:12 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f3A999207752 for ietf-provreg@cafax.se; Tue, 10 Apr 2001 11:09:09 +0200 Date: Tue, 10 Apr 2001 11:09:09 +0200 From: Peter Eisenhauer To: ietf-provreg@cafax.se Subject: 3.4.9 [4] Message-ID: <20010410110909.A7699@tornado.schlund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk 3.4.9 [4]: "Requests to retrieve information describing a registered object MAY be granted by the registrar that currently sponsors the registered object." As far as I understand the (registry public) retrievel of object information using the protocol then is handle by registrar policy? Shouldn't it be possible also to the registry? Suggestion: "... MAY be granted by the registrar that currently sponsors the registered object or MAY be granted by registry policy." Or is this not neccessary because of 1-3 the registry MUST provide services to retrieve information and therefore by definition is able to grant rights to retrieve information? Best Regards, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3A7MkH8010280 for ietf-provreg-outgoing; Tue, 10 Apr 2001 09:22:46 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3A7MjLt010275 for ; Tue, 10 Apr 2001 09:22:45 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id JAA18100; Tue, 10 Apr 2001 09:22:41 +0200 (METDST) Message-ID: <3AD2B547.8777F22E@knipp.de> Date: Tue, 10 Apr 2001 09:24:55 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: Issues on 3.4.9 Object Information Query References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > OK, now I think I understand, and I think this is something that the WG > needs to chew on for a bit because it gets close to a topic that I raised in > the protocol design team report: does it make sense for a provisioning > protocol to provide abstract relationship reporting services? I think it does. > > I submit that it's not a good idea for a _provisioning_ protocol to provide > a query service to (as an example) list all of the domains delegated to a > particular name server, or all of the domains for which I happen to be a > contact. This function is very useful for maintenance, database synchronisation, error detection etc. as I mentioned earlier. I agree that this function should not be a "standard" function, i.e., the normal query should not report the reverse references, as a name server may be used by thousands of domains and this would increase processing time and message size. It should be done either as an option or as a separate request. > We already have requirements to identify object associations > (3.4.9-[1], for example, says that contacts and subordinate "child" name > servers have to be reported when retrieving information about a domain). > Yes, but let us distinguish the directions of the references (compare to the directions of the arrows in the example). Normal queries would only report references that point away. On special request, also those references are reported that point to the object itself. > BTW (and I hate to open this can of worms), there is no current requirement > to associate contact information with name servers. This was for demonstration purposes only. CORE has the ability to associate a contact in its SRS, but the feature is rarely used AFAIK. So for me, you can keep the can closed ;-) > > regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3A009kP007673 for ietf-provreg-outgoing; Tue, 10 Apr 2001 02:00:09 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3A003Lt007668 for ; Tue, 10 Apr 2001 02:00:08 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA29493; Mon, 9 Apr 2001 19:59:36 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0C1M>; Mon, 9 Apr 2001 19:53:01 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" , ietf-provreg@cafax.se Subject: RE: Provreg WG Last Call (8.4 Data Collection Requirements) Date: Mon, 9 Apr 2001 19:53:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Monday, April 09, 2001 6:33 PM > To: ietf-provreg@cafax.se > Subject: Re: Provreg WG Last Call (8.4 Data Collection Requirements) > > > Proposed (minor) changes to draft-ietf-provreg-grrp-reqs-01.txt: > 8.4 Data Collection Requirements > > current text: > [1] Some of the data exchanged between a registrar and registry MAY be > ... > A generic protocol MUST provide services to identify information whose > disclosure is not strictly required for technical reasons. > > proposed text: > [1] Some of the data exchanged between a registrar and registry MAY be > ... > A generic protocol MUST provide services to identify data collection > policies. > > Comment: > The first sentence is motivational, and is "close enough". > The second states a requirement, and is over-specific and incomplete. OK. > current text: > [2] Some of the social information exchanged between a registrar and > registry MAY be REQUIRED to create, manage, or operate Internet or DNS > infrastructure facilities, such as zone files. Such information is > subject to public disclosure per relevant IETF standards. > > proposed text: > None. This section to be omitted. Bill Manning originally requested this requirement. Any objections to removal, Bill? Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39MXXHT007354 for ietf-provreg-outgoing; Tue, 10 Apr 2001 00:33:33 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39MXWLt007349 for ; Tue, 10 Apr 2001 00:33:32 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f39MX9D04530 for ; Mon, 9 Apr 2001 18:33:10 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104092233.f39MX9D04530@nic-naa.net> To: ietf-provreg@cafax.se Subject: Re: Provreg WG Last Call (8.4 Data Collection Requirements) Date: Mon, 09 Apr 2001 18:33:09 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Proposed (minor) changes to draft-ietf-provreg-grrp-reqs-01.txt: 8.4 Data Collection Requirements current text: [1] Some of the data exchanged between a registrar and registry MAY be ... A generic protocol MUST provide services to identify information whose disclosure is not strictly required for technical reasons. proposed text: [1] Some of the data exchanged between a registrar and registry MAY be ... A generic protocol MUST provide services to identify data collection policies. Comment: The first sentence is motivational, and is "close enough". The second states a requirement, and is over-specific and incomplete. current text: [2] Some of the social information exchanged between a registrar and registry MAY be REQUIRED to create, manage, or operate Internet or DNS infrastructure facilities, such as zone files. Such information is subject to public disclosure per relevant IETF standards. proposed text: None. This section to be omitted. Comment: The distinction between "social" and "technical" data originally was that the second was reflected in zone files. "infrastructure facilities" is not sufficiently precise. The need for an exemption from a disclosure label is obviated by labels for disclosure and for non-disclosure. We may need to add some data granularity beyond "technical" and "social", but this is a better choice than suggesting that external texts remove any need to put data collection labels on collected data. If I've missed something seminal in the decomposition of the T && S model in the past couple of weeks (and I have been distracted), please let me know. Eric Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39IqIk8006006 for ietf-provreg-outgoing; Mon, 9 Apr 2001 20:52:18 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39IqHLt006001 for ; Mon, 9 Apr 2001 20:52:18 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f39IppD03781; Mon, 9 Apr 2001 14:51:51 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104091851.f39IppD03781@nic-naa.net> To: "Hollenbeck, Scott" cc: "'Eric Brunner-Williams in Portland Maine'" , "'ietf-provreg@cafax.se'" , brunner@nic-naa.net Subject: Re: Registrant Access (Data Protection/Privacy) In-Reply-To: Your message of "Mon, 09 Apr 2001 13:47:05 EDT." Date: Mon, 09 Apr 2001 14:51:51 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, That's a good question, which is why I snuck "non persistent" into the text, just to get a bite ;-) I've mentioned off-list that one way to view access is cache validation, as the data (t && s) is persistent at its ultimate sink(s) (thin && thick), but is transient at intermediate points (if any) in the provisioning chain. To address this we need to either, as P3P does, to impute temporal properties with a PURPOSE element, or as P3P also does, associate vague temporal properties to RETENTION element, which we need anyway, or as P3P also does, create an element which contains specific (ISO 8601) temporal properties, which we also need anyway ;-) I'm a fan of good temporal identifiers, so I propose the later. In my opening and motivating para I managed to miss Paul Kane's cite: > For registries based in Europe, EU directive 95/46/EC, says "data subjects > (registrants) must have the ability to inspect and modify information > (including its deletion) directly with the Data User" (registry).... I also managed to miss the chance to reply to co-Chair Jaap and Bart Boswinkel's reading of both Directive 95/46 [1], and agree that 95/46 does not require the right of access be read as extending the scope of the protocol to registrants, (see (42) and (43) of the preamble, and Art 10., which establishes a right of access and a right to rectify, not a specific mechanism to accomplish either). References: [1] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data http://europa.eu.int/eur-lex/en/lif/dat/1995/en_395L0046.html Eric Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39IA3wX005778 for ietf-provreg-outgoing; Mon, 9 Apr 2001 20:10:03 +0200 (MEST) Received: from dmz.ambler.net (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39IA1Lt005773 for ; Mon, 9 Apr 2001 20:10:02 +0200 (MEST) Received: from underslunky ([192.168.1.23]) by dmz.ambler.net (8.11.0/8.8.7) with SMTP id f39I9Bw18979; Mon, 9 Apr 2001 11:09:11 -0700 Message-ID: <032601c0c120$444bb3a0$1701a8c0@underslunky> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Hollenbeck, Scott" , "'Klaus Malorny'" , References: Subject: Re: Nameserver MUST HAVE IP Date: Mon, 9 Apr 2001 11:09:47 -0700 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f39IA3Lt005774 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I disagree that the requirement should be removed completely, and reiterate > my earlier suggestion that replacing the MUST with a SHOULD would be more > appropriate. FWIW, I agree. (I've agreed with pretty-much all changes so far, but realized I've been silently agreeing, so I wanted to clear my throat a little :-)) Christopher Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39HrmDG005634 for ietf-provreg-outgoing; Mon, 9 Apr 2001 19:53:48 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39HrkLt005629 for ; Mon, 9 Apr 2001 19:53:47 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA28354; Mon, 9 Apr 2001 13:53:40 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0B66>; Mon, 9 Apr 2001 13:47:05 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" Cc: "'ietf-provreg@cafax.se'" Subject: RE: Registrant Access (Data Protection/Privacy) Date: Mon, 9 Apr 2001 13:47:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks for taking this on and offering this up as a proposal, Eric. My question: how should "not persistent" be interpreted in the context of associating social information with other objects? I looked at the P3P ACCESS element definition (1) for clues, and saw nothing that helped me understand. (1) http://www.w3.org/TR/2000/CR-P3P-20001215/#ACCESS >-----Original Message----- >From: Eric Brunner-Williams in Portland Maine >[mailto:brunner@nic-naa.net] >Sent: Monday, April 09, 2001 1:41 PM >To: ietf-provreg@cafax.se >Subject: Registrant Access (Data Protection/Privacy) > > >In a note sent to both the provreg and whois lists earlier this year, >Patrik Faltstrom mentioned registrant access in the context of data >protection. More recently, Sheer noted that while specific requirements >are "local", e.g., specific "data-access" functional requirements, the >abstract form is of general interest. > >Here is a fragment (draft forthcomming, RSN!!!) on access >policy and its >expression in ABNF (grammer representation of XML syntax) and in XSD. > >Modified from http://www.w3.org/TR/P3P/#ACCESS [1] > >The element is defined as the ability of registrant to view >registrant originated data and address questions or concerns to the >registration service provider. Registration service providers MUST >disclose one value for the access attribute. The method of access is >not specified. (Note this has _nothing_ to do with whois:43 or whois:xx >"access", which is outside the scope of a provisioning protocol.) > >The ACCESS element must contain one of the following elements: > > access is provided to all social data only > access is provided to all technical data only > access is provided to all technical and social data > registrant data exists but access is not provided > registrant data is not persistent > > >The (P3P-consistent) ABNF for this is: > > access = "" > access_disclosure > *extension > "" > > access_disclosure = "" | ; socal data only > "" | ; technical data only > "" | ; all data > "" | ; access not provided > "" | ; data not persistent > >This ends the modification of Section 3.2.5 of the current (CR'ed) P3P Spec >for a Registrar-Registry provisioning protocol, using XML element-attribute >formalism to deliver a provreg (work-in-progress) vocabulary. > >At this point there are three issues to resolve: > > 1. Does the set of access_disclosure attributes cover the R* problem > space discussed in the provreg WG list? >and > 2. Is the XML consistent with our current usage cases for XML encoding > of R* entity policy and registrANT data? >and > 3. Is "The method of access is not specified" adequate for this WG? > > >The first and third items are up to the R* implementors and observing protocol >and policy wonks to discuss. > >The second item is partially addressed by the following xml schema fragment, >which does not (yet) have a general "POLICY" element within which to hang an >"ACCESS" element, or other elements, e.g., "PURPOSE" (also previously discussed >in this working group mailing list), "RECIPIENT", etc. I've used "abc" below, >it could just as well be "epp" or "xrp" or "abc". > > > > > > > > > > > > > > > > > >Comments and corrections please. > >Eric > >References: > >[1] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification >W3C Candidate Recommendation 15 December 2000, Section 3.2.5 >http://www.w3.org/TR/2000/CR-P3P-20001215 > Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39HfjqJ005571 for ietf-provreg-outgoing; Mon, 9 Apr 2001 19:41:45 +0200 (MEST) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39HfiLt005566 for ; Mon, 9 Apr 2001 19:41:44 +0200 (MEST) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f39HfJD03469 for ; Mon, 9 Apr 2001 13:41:20 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104091741.f39HfJD03469@nic-naa.net> To: ietf-provreg@cafax.se Subject: Registrant Access (Data Protection/Privacy) Date: Mon, 09 Apr 2001 13:41:19 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-provreg@cafax.se Precedence: bulk In a note sent to both the provreg and whois lists earlier this year, Patrik Faltstrom mentioned registrant access in the context of data protection. More recently, Sheer noted that while specific requirements are "local", e.g., specific "data-access" functional requirements, the abstract form is of general interest. Here is a fragment (draft forthcomming, RSN!!!) on access policy and its expression in ABNF (grammer representation of XML syntax) and in XSD. Modified from http://www.w3.org/TR/P3P/#ACCESS [1] The element is defined as the ability of registrant to view registrant originated data and address questions or concerns to the registration service provider. Registration service providers MUST disclose one value for the access attribute. The method of access is not specified. (Note this has _nothing_ to do with whois:43 or whois:xx "access", which is outside the scope of a provisioning protocol.) The ACCESS element must contain one of the following elements: access is provided to all social data only access is provided to all technical data only access is provided to all technical and social data registrant data exists but access is not provided registrant data is not persistent The (P3P-consistent) ABNF for this is: access = "" access_disclosure *extension "" access_disclosure = "" | ; socal data only "" | ; technical data only "" | ; all data "" | ; access not provided "" | ; data not persistent This ends the modification of Section 3.2.5 of the current (CR'ed) P3P Spec for a Registrar-Registry provisioning protocol, using XML element-attribute formalism to deliver a provreg (work-in-progress) vocabulary. At this point there are three issues to resolve: 1. Does the set of access_disclosure attributes cover the R* problem space discussed in the provreg WG list? and 2. Is the XML consistent with our current usage cases for XML encoding of R* entity policy and registrANT data? and 3. Is "The method of access is not specified" adequate for this WG? The first and third items are up to the R* implementors and observing protocol and policy wonks to discuss. The second item is partially addressed by the following xml schema fragment, which does not (yet) have a general "POLICY" element within which to hang an "ACCESS" element, or other elements, e.g., "PURPOSE" (also previously discussed in this working group mailing list), "RECIPIENT", etc. I've used "abc" below, it could just as well be "epp" or "xrp" or "abc". Comments and corrections please. Eric References: [1] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification W3C Candidate Recommendation 15 December 2000, Section 3.2.5 http://www.w3.org/TR/2000/CR-P3P-20001215 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39GmTtf005222 for ietf-provreg-outgoing; Mon, 9 Apr 2001 18:48:29 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39GmSLt005217 for ; Mon, 9 Apr 2001 18:48:28 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id SAA09010; Mon, 9 Apr 2001 18:48:21 +0200 (METDST) Message-ID: <3AD1E854.70D1FFB3@knipp.de> Date: Mon, 09 Apr 2001 18:50:28 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: International Issues @ 3.4.2[6] and 9. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > This is where I'm getting confused. As currently written (by Harald > Alvestrand), 9.-[2] basically says that we MUST represent data in accordance > with international standards for the data in question, and that we MAY need > to represent it twice (which implies (maybe this is the problem) once in > ASCII format and once in an optional non-ASCII format). An > internationalization requirement would be out of place in 3.4.2. > > Are you suggesting that 9.-[2] should more explicitly state that one of the > social information representations MUST be ASCII, and a second non-ASCII > format is OPTIONAL? > > To me the wording of 9[2] is a bit vague and abstract. After your comment, I re-read the paragraph multiple times, and I can interpret it in my sense now. My mistake was that I applied the "appropriate thought" to the previously mentioned country information/phone number format only. The following text talks about "formatting" which does not necessarily include a limitation of the allowed characters (in my understanding). I don't think that we need to mention the use of an Latin letter subset as a MUST, as I don't want to exclude a more intelligent and/or less western oriented solution from the final protocol. My only aim is to have the problem and its importance addressed clearly. regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39FU9Rk001368 for ietf-provreg-outgoing; Mon, 9 Apr 2001 17:30:09 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39FU4Lt001358 for ; Mon, 9 Apr 2001 17:30:04 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA27705; Mon, 9 Apr 2001 11:29:55 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BW5>; Mon, 9 Apr 2001 11:23:21 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" Cc: ietf-provreg@cafax.se Subject: RE: Issues on 3.4.9 Object Information Query Date: Mon, 9 Apr 2001 11:23:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Monday, April 09, 2001 9:43 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se >Subject: Re: Issues on 3.4.9 Object Information Query > > >"Hollenbeck, Scott" wrote: >> >>> [...] >> >> Good suggestions, but I'm not sure I understand the >distinction between the >> suggested new requirements. What does [0] say that [5] doesn't? I'm >> inclined to add [5], but I'm not sure I see the need for [0] >if we add [5]. >> >> > > >Hi Scott, > >let me explain: we have a domain that references name servers >and contacts. >Name servers eventually reference contacts, too. But name >servers may also >contain implicit references to the domain they belong to. > >e.g. > > domain X.COM -> owner A > -> admin B > -> tech C > -> ns1 NS.Y.DE -> tech C > -> ns2 NS.Z.COM -> tech D > (->) domain Z.COM > > > >In 3.4.9[1], the registry will surely report the contacts and name servers, >and in 3.4.9[2] the registry will report the contacts, if any. > >Subsection [0] was thought to generalize that a bit. In the case of ns2, not >only tech "D" should be reported, but also domain "Z.COM". This may be trivial >for humans, but not necessarily for machines (esp. in a more complex domain >structure, e.g. in the anticipated .name TLD or those with different >registration levels, e.g. .fr). I still don't get it. As far as I know DNS machines do not have any trouble understanding that "ns.z.com" and "z.com" are related. >With "reverse references" I mean the ability to detected the uses of a certain >object. In the given example, the service would report "NS.Y.DE" and "X.COM" >as objects referencing contact "D". Similar to that, a request to domain >"Z.COM" would report "NS.Z.COM". This function is important to detect >"orphaned" objects or to analyse a failed deletion request. > >Implicit references are important to be reported if the outcome of operations >depends on it. If the domain "Z.COM" can be removed while keeping the name >server "NS.Z.COM" in the database, I don't have any problems if the reference >is not reported -- but not in the case that it can't be removed. OK, now I think I understand, and I think this is something that the WG needs to chew on for a bit because it gets close to a topic that I raised in the protocol design team report: does it make sense for a provisioning protocol to provide abstract relationship reporting services? I submit that it's not a good idea for a _provisioning_ protocol to provide a query service to (as an example) list all of the domains delegated to a particular name server, or all of the domains for which I happen to be a contact. We already have requirements to identify object associations (3.4.9-[1], for example, says that contacts and subordinate "child" name servers have to be reported when retrieving information about a domain). BTW (and I hate to open this can of worms), there is no current requirement to associate contact information with name servers. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39FA4Mp000460 for ietf-provreg-outgoing; Mon, 9 Apr 2001 17:10:04 +0200 (MEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39FA3Lt000455 for ; Mon, 9 Apr 2001 17:10:03 +0200 (MEST) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA20615; Mon, 9 Apr 2001 17:07:22 +0200 (CEST) Date: Mon, 9 Apr 2001 17:07:22 +0200 (CEST) From: Shane Kerr To: "Hollenbeck, Scott" cc: ietf-provreg@cafax.se Subject: RE: International Issues @ 3.4.2[6] and 9. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 9 Apr 2001, Hollenbeck, Scott wrote: > Are you suggesting that 9.-[2] should more explicitly state that one > of the social information representations MUST be ASCII, and a > second non-ASCII format is OPTIONAL? This makes sense to me. While I may not be able to type in a Kanji address on my keyboard, using Latin characters may result in a record incomprehensible to the person the data is actually about - which is probably not desirable. Required ASCII plus optional non-ASCII seems just swell to me. :P -- Shane p.s. As a completely off-topic aside, this would seem to be the right solution for DNS too. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39ElNFC027346 for ietf-provreg-outgoing; Mon, 9 Apr 2001 16:47:23 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39ElMLt027341 for ; Mon, 9 Apr 2001 16:47:22 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA27505; Mon, 9 Apr 2001 10:46:47 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BVL>; Mon, 9 Apr 2001 10:40:13 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" Cc: ietf-provreg@cafax.se Subject: RE: International Issues @ 3.4.2[6] and 9. Date: Mon, 9 Apr 2001 10:40:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Monday, April 09, 2001 9:08 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se >Subject: Re: International Issues @ 3.4.2[6] and 9. > [snip] >Hi Scott, > >there is a misunderstanding, eventually caused by my bad english. I do _not_ >propose any support for any special character _encoding_ or whatever, but I >propose to restrict the _use_ to the ASCII character set, esp. to the 26 latin >letters (+ non-letter characters, of course) for an international version of >the social data. > >I'm trying to figure out how a Japanese spells the name of an arabic domain >owner ;-) I came to the conclusion that we need a common base to communicate >and exchange information, and the lowest denominator in this are IMHO the 26 >latin letters. It resembles the version b) you mention, with the exception >that I didn't want to talk about character encodings (UTF8, ISO 8859, ASCII or >whatever), which is clearly out of scope, but on the characters which can >actually be used, similar to a pattern matching international phone numbers. I'm OK with use of ASCII for a required version of the social data. >I think that the topic is important not only for generic TLDs, but also for >country code TLDs. Although ccTLD domains are normally registered by the >people of the corresponding country, it should be possible for people from >different countries to contact owner, admin, technical contacts etc., e.g. in >case of malfunction. > >Therefore I believe it is important enough to put this topic into the >requirements document at the place I mentioned (instead of leaving this up to >the registry's policy) -- maybe with different words or different level of >detail, but more concrete than the current text. If you disagree with this, >then you should consider to replace the second "MUST" in section 9[2] with >"MAY" or "SHOULD", as you shouldn't enforce internationalization there while >omitting it in 3.4.2. This is where I'm getting confused. As currently written (by Harald Alvestrand), 9.-[2] basically says that we MUST represent data in accordance with international standards for the data in question, and that we MAY need to represent it twice (which implies (maybe this is the problem) once in ASCII format and once in an optional non-ASCII format). An internationalization requirement would be out of place in 3.4.2. Are you suggesting that 9.-[2] should more explicitly state that one of the social information representations MUST be ASCII, and a second non-ASCII format is OPTIONAL? Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39DwCx6018942 for ietf-provreg-outgoing; Mon, 9 Apr 2001 15:58:12 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39DwBLt018937 for ; Mon, 9 Apr 2001 15:58:12 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id PAA12559; Mon, 9 Apr 2001 15:58:08 +0200 (METDST) Message-ID: <3AD1C070.A03A10D5@knipp.de> Date: Mon, 09 Apr 2001 16:00:16 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: Issues on 3.4.5. Object Transfer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > > [...] > >---8<--- > >3.4.5[1] ... > > > >The registry MUST report the object identifiers of all objects that are > >transferred along with the domain object. > > > >3.4.8[6] > > > >The protocol MUST provide services to determine all objects that would get > >implicitly transferred on a transfer of a certain object. > >---8<--- > > Isn't this second requirement addressed in the "object query" requirement > that you suggested in another message? Yes, you are right. I wanted to keep the two proposals independent. The name servers would be reported as implicit reverse references according to the other proposal. The registrar could conclude that these name servers get transferred also, but still there would not be a function that tells this expressis verbis. > I think that's a more appropriate > place to list object associations vs. in the "does it exist" query. Could I > also suggest a rewording of the first new requirement?: > > "The protocol MUST provide services to describe all objects, including > associated objects, that are transferred as a result of an object transfer." > > We can't specify registry requirements in this document, and I think it > better to make the requirement more general as opposed to specifically > targeting domain object transfers. Ok. > > regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39DuuDr018934 for ietf-provreg-outgoing; Mon, 9 Apr 2001 15:56:56 +0200 (MEST) Received: from mout02.kundenserver.de (mout02.kundenserver.de [195.20.224.133]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39DutLt018929 for ; Mon, 9 Apr 2001 15:56:55 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout02.kundenserver.de with esmtp (Exim 2.12 #2) id 14mcA1-0003lO-00; Mon, 9 Apr 2001 15:56:53 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14mcA5-0001tW-00; Mon, 9 Apr 2001 15:56:57 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f39Durx20877; Mon, 9 Apr 2001 15:56:53 +0200 Date: Mon, 9 Apr 2001 15:56:53 +0200 From: Peter Eisenhauer To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010409155653.A20859@tornado.schlund.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from shollenbeck@verisign.com on Mon, Apr 09, 2001 at 08:03:30AM -0400 Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, Apr 09, 2001 at 08:03:30AM -0400, Hollenbeck, Scott wrote: > >-----Original Message----- > >From: Mats Dufberg [mailto:dufberg@nic-se.se] > >Sent: Monday, April 09, 2001 7:26 AM > >To: Hollenbeck, Scott > >Cc: ietf-provreg@cafax.se > >Subject: RE: Nameserver MUST HAVE IP > > > > > >On Mon, 9 Apr 2001, Hollenbeck, Scott wrote: > > > >> >IMHO we should remove the requirement in 3.4.2[3] that a > >nameserver MUST > >> have > >> >an IP address if its name lies registered in the > >registrar's TLD. The > >> >discussions here and the interesting report quoted by > >Elisabeth Porteneuve > >> >showed that this requirement does not add much to the "health" > >> >of the domain name system. > >> > >> I disagree that the requirement should be removed > >completely, and reiterate > >> my earlier suggestion that replacing the MUST with a SHOULD > >would be more > >> appropriate. > > > >A SHOULD would be appropriate if storing the IP address for glue records > >not strictly needed would be a better solution than not. I disagree. By > >storing and announcing the IP address you increase the risk of have > >different data in the mother zone than in the authoritative > >zone. -- Data should be kept where it is authoritative as far as possible. > > ...and by not mentioning anything at all about the need for an IP address > with a name server you run the larger risk of not having glue where it's > needed. I don't have a problem with adding some words that describe why the > SHOULD isn't a MUST (see below), but cutting out the requirement completely > doesn't address the reality of needing addresses to produce glue records. > > 3.4.2-[3] existing text: > Name servers registered within the registry's authoritative TLDs MUST be > registered with a valid IPv4 or IPv6 address. > > 3.4.2-[3], change MUST to SHOULD and add new text: > Name servers registered within the registry's authoritative TLDs SHOULD be > registered with a valid IPv4 or IPv6 address only as required to produce DNS > "glue" records. > > In my opinion this ensures that we still have a requirement for addresses to > produce glue records, and covered the concern that addresses aren't required > for all name servers. > > > > >From my point of view this seems to be a good solution. Best Regards, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39DeWow016287 for ietf-provreg-outgoing; Mon, 9 Apr 2001 15:40:32 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39DeVLt016282 for ; Mon, 9 Apr 2001 15:40:31 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id PAA04294; Mon, 9 Apr 2001 15:40:27 +0200 (METDST) Message-ID: <3AD1BC4C.B3019A94@knipp.de> Date: Mon, 09 Apr 2001 15:42:36 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: Issues on 3.4.9 Object Information Query References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > >> [...] > > Good suggestions, but I'm not sure I understand the distinction between the > suggested new requirements. What does [0] say that [5] doesn't? I'm > inclined to add [5], but I'm not sure I see the need for [0] if we add [5]. > > Hi Scott, let me explain: we have a domain that references name servers and contacts. Name servers eventually reference contacts, too. But name servers may also contain implicit references to the domain they belong to. e.g. domain X.COM -> owner A -> admin B -> tech C -> ns1 NS.Y.DE -> tech C -> ns2 NS.Z.COM -> tech D (->) domain Z.COM In 3.4.9[1], the registry will surely report the contacts and name servers, and in 3.4.9[2] the registry will report the contacts, if any. Subsection [0] was thought to generalize that a bit. In the case of ns2, not only tech "D" should be reported, but also domain "Z.COM". This may be trivial for humans, but not necessarily for machines (esp. in a more complex domain structure, e.g. in the anticipated .name TLD or those with different registration levels, e.g. .fr). With "reverse references" I mean the ability to detected the uses of a certain object. In the given example, the service would report "NS.Y.DE" and "X.COM" as objects referencing contact "D". Similar to that, a request to domain "Z.COM" would report "NS.Z.COM". This function is important to detect "orphaned" objects or to analyse a failed deletion request. Implicit references are important to be reported if the outcome of operations depends on it. If the domain "Z.COM" can be removed while keeping the name server "NS.Z.COM" in the database, I don't have any problems if the reference is not reported -- but not in the case that it can't be removed. The topic overlaps a bit with my other proposal regarding transfers. See my next e-mail ;-) regards Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39D5mnG012416 for ietf-provreg-outgoing; Mon, 9 Apr 2001 15:05:48 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39D5gLt012411 for ; Mon, 9 Apr 2001 15:05:43 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id PAA23257; Mon, 9 Apr 2001 15:05:29 +0200 (METDST) Message-ID: <3AD1B41A.79828074@knipp.de> Date: Mon, 09 Apr 2001 15:07:38 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: International Issues @ 3.4.2[6] and 9. References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Hollenbeck, Scott" wrote: > > > > >---8<--- > >3.4.2. > > > >[6] ... > > > >The social data MUST contain a version ("international variant") that uses > >internatioal standards for names, addresses, phone numbers > >etc. and uses a restricted character subset (US-ASCII). > > > >The social data MAY additionally contain multiple versions ("national > >variants") that MAY use national representations of names, addresses and > phone > >numbers and MAY use any characters which are supported by the protocol. > These > >versions MUST be tagged with a country and/or language identification > >according to RFC XXXX/ISO 639/ISO 3166. > >---8<--- > > I think the existing text is more appropriate; it allows for non-ASCII > representations as needed. Plus, at IETF-50 there was room consensus that > charsets other than UTF-8 should not be used, which gets us back to either: > > a) One set of data in UTF-8, which would support a singular representation > using both ASCII and non-ASCII characters, or > > b) Two sets of data, with one (required) in ASCII and the other (if desired) > in potentially non-ASCII UTF-8. My recollection is that most folks who > spoke up at the IETF meeting thought this was the best alternative. > > Of course, this list is the final arbiter. > > Hi Scott, there is a misunderstanding, eventually caused by my bad english. I do _not_ propose any support for any special character _encoding_ or whatever, but I propose to restrict the _use_ to the ASCII character set, esp. to the 26 latin letters (+ non-letter characters, of course) for an international version of the social data. I'm trying to figure out how a Japanese spells the name of an arabic domain owner ;-) I came to the conclusion that we need a common base to communicate and exchange information, and the lowest denominator in this are IMHO the 26 latin letters. It resembles the version b) you mention, with the exception that I didn't want to talk about character encodings (UTF8, ISO 8859, ASCII or whatever), which is clearly out of scope, but on the characters which can actually be used, similar to a pattern matching international phone numbers. I think that the topic is important not only for generic TLDs, but also for country code TLDs. Although ccTLD domains are normally registered by the people of the corresponding country, it should be possible for people from different countries to contact owner, admin, technical contacts etc., e.g. in case of malfunction. Therefore I believe it is important enough to put this topic into the requirements document at the place I mentioned (instead of leaving this up to the registry's policy) -- maybe with different words or different level of detail, but more concrete than the current text. If you disagree with this, then you should consider to replace the second "MUST" in section 9[2] with "MAY" or "SHOULD", as you shouldn't enforce internationalization there while omitting it in 3.4.2. regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39CaEYa012247 for ietf-provreg-outgoing; Mon, 9 Apr 2001 14:36:14 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39CaDLt012242 for ; Mon, 9 Apr 2001 14:36:13 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA26966; Mon, 9 Apr 2001 08:35:40 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BRJ>; Mon, 9 Apr 2001 08:29:06 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: Issues on 3.4.5. Object Transfer Date: Mon, 9 Apr 2001 08:29:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Monday, April 09, 2001 5:24 AM >To: ietf-provreg@cafax.se >Subject: Issues on 3.4.5. Object Transfer > > > > >I have some problems with the implicit transfer of name servers whose domain >names are contained in the zone of the domain being transferred (despite the >fact that I dislike the model). The server should not do any "hidden" things. >It may be unclear to the registrar that it gets other objects. Therefore, the >registry should report what it does at least. > >As a consequence, I would like to see the following additions in the protocol: > >---8<--- >3.4.5[1] ... > >The registry MUST report the object identifiers of all objects that are >transferred along with the domain object. > >3.4.8[6] > >The protocol MUST provide services to determine all objects that would get >implicitly transferred on a transfer of a certain object. >---8<--- Isn't this second requirement addressed in the "object query" requirement that you suggested in another message? I think that's a more appropriate place to list object associations vs. in the "does it exist" query. Could I also suggest a rewording of the first new requirement?: "The protocol MUST provide services to describe all objects, including associated objects, that are transferred as a result of an object transfer." We can't specify registry requirements in this document, and I think it better to make the requirement more general as opposed to specifically targeting domain object transfers. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39CSGiA010996 for ietf-provreg-outgoing; Mon, 9 Apr 2001 14:28:16 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39CSGLt010991 for ; Mon, 9 Apr 2001 14:28:16 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f39CRx019903; Mon, 9 Apr 2001 14:27:59 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Mon, 9 Apr 2001 14:27:59 +0200 (CEST) From: Mats Dufberg To: "Hollenbeck, Scott" cc: Subject: RE: Nameserver MUST HAVE IP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 9 Apr 2001, Hollenbeck, Scott wrote: > >A SHOULD would be appropriate if storing the IP address for glue records > >not strictly needed would be a better solution than not. I disagree. By > >storing and announcing the IP address you increase the risk of have > >different data in the mother zone than in the authoritative > >zone. -- Data should be kept where it is authoritative as far as possible. > > ...and by not mentioning anything at all about the need for an IP address > with a name server you run the larger risk of not having glue where it's > needed. If a glue is needed and IP address is missing, the delegation should be refused. > I don't have a problem with adding some words that describe why the > SHOULD isn't a MUST (see below), but cutting out the requirement completely > doesn't address the reality of needing addresses to produce glue records. > > 3.4.2-[3] existing text: > Name servers registered within the registry's authoritative TLDs MUST be > registered with a valid IPv4 or IPv6 address. > > 3.4.2-[3], change MUST to SHOULD and add new text: > Name servers registered within the registry's authoritative TLDs SHOULD be > registered with a valid IPv4 or IPv6 address only as required to produce DNS > "glue" records. There could be a MUST for needed glue: 3.4.2-[3], updated to cover strictly needed glue: Name servers MUST be registered with valid IPv4 or IPv6 address when "glue record" is stricly needed for delegation of a domain from the TLD. The address MAY be removed when no longer needed for strict "glue record". The MUST could be moved to somewhere else to say: Delegation MUST be refused if a valid IPv4 or IPv6 address is not available for strictly needed "glue record". Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39CQg1T010979 for ietf-provreg-outgoing; Mon, 9 Apr 2001 14:26:42 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39CQfLt010974 for ; Mon, 9 Apr 2001 14:26:41 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA26937; Mon, 9 Apr 2001 08:26:03 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BRC>; Mon, 9 Apr 2001 08:19:29 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: Issues on 3.4.9 Object Information Query Date: Mon, 9 Apr 2001 08:19:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Monday, April 09, 2001 5:48 AM >To: ietf-provreg@cafax.se >Subject: Issues on 3.4.9 Object Information Query > > > > >I am missing functions that clearly report the relationships between the >objects. Although I assume that forward references are reported on [1], [2] >and [3], I would like to have this expressed clearly. In addition, reverse >references cannot be determined by the current version of the requirements >document, obviously. > >Therefore, I would like to have the following additions in the protocol*: > >---8<--- >3.4.9[0] (to be inserted before [1]) > >All object information queries MUST report all references to other objects. >This MUST also include objects that are referenced implicitly, if the >existance of the reference may affect the outcome of any operation. > >3.4.9[5] >For any existing object the protocol MUST provide services to determine all >reverse references, i.e. to list up the identifiers of those objects that use >the given object. This MUST also include objects that reference the given >object implicitly (e.g. name servers that belong to a given domain), if the >existance of the reference may affect the outcome of any operation (e.g. >deletions). > >---8<--- Good suggestions, but I'm not sure I understand the distinction between the suggested new requirements. What does [0] say that [5] doesn't? I'm inclined to add [5], but I'm not sure I see the need for [0] if we add [5]. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39CLJdE010477 for ietf-provreg-outgoing; Mon, 9 Apr 2001 14:21:19 +0200 (MEST) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39CLILt010472 for ; Mon, 9 Apr 2001 14:21:18 +0200 (MEST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id OAA73563; Mon, 9 Apr 2001 14:21:17 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.3/8.11.2) with ESMTP id f39CLHK21638; Mon, 9 Apr 2001 14:21:17 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200104091221.f39CLHK21638@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP In-reply-to: Your message of Mon, 09 Apr 2001 06:50:05 -0400. Date: Mon, 09 Apr 2001 14:21:17 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk I disagree that the requirement should be removed completely, and reiterate my earlier suggestion that replacing the MUST with a SHOULD would be more appropriate. I personally opt for the SHOULD. jaap PS The whole discussion is a bit off-topic, or at best, deals with the policy of the registry how it creates the zone-file. We, the dutch registry also have the ``use ony glue when needed'' model. but in the (email based) ``rrp protocol'' with the registrar, they can give the IP numbers as well. We always check wether the nameserver actually works properly before we do anything. So whether the delegation is accepted, the nameserver is changed etc. etc., we first check. Thus far I have personally never seen the problem that nameservers became completely (as demonstrated by paf) without glue although it is rumored that it happened once in the last 15 years. But it is a problem inherent to the current DNS protocol and, as others have noted, it is not something which can be solved by a provreg protocol adequately. A clueless operator (even when thinking he is smart) can always manage himself in a glueless situation when he works hard at it. An, strictly speaking, the provreg protocol doesn't specify one should create a zonefile. That is outside the scope of this protocol. So even with a MUST in the requirement, it is still up to the policies of the TLD whether this information is actually used in the zone-file. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39CGqOb010041 for ietf-provreg-outgoing; Mon, 9 Apr 2001 14:16:52 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39CGpLt010035 for ; Mon, 9 Apr 2001 14:16:51 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA26897; Mon, 9 Apr 2001 08:16:18 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BQY>; Mon, 9 Apr 2001 08:09:44 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: International Issues @ 3.4.2[6] and 9. Date: Mon, 9 Apr 2001 08:09:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Monday, April 09, 2001 5:08 AM >To: ietf-provreg@cafax.se >Subject: International Issues @ 3.4.2[6] and 9. > > > > >I would like to have some additions to 3.4.2: > >rationale > >Allthough section 9[2] mentions the problem of different languages and scripts >and gives a solution, especially in the requirement to MAY have multiple >versions of names, addresses etc. in different versions, I think it is >important to substantiate this for the so-called social data in section >3.4.2[6]. We should force to have a version of the social data that is >understandable around the world so we can assure that the data >is useful outside the country where it is originated. > > >added text > >---8<--- >3.4.2. > >[6] ... > >The social data MUST contain a version ("international variant") that uses >internatioal standards for names, addresses, phone numbers >etc. and uses a restricted character subset (US-ASCII). > >The social data MAY additionally contain multiple versions ("national >variants") that MAY use national representations of names, addresses and phone >numbers and MAY use any characters which are supported by the protocol. These >versions MUST be tagged with a country and/or language identification >according to RFC XXXX/ISO 639/ISO 3166. >---8<--- I think the existing text is more appropriate; it allows for non-ASCII representations as needed. Plus, at IETF-50 there was room consensus that charsets other than UTF-8 should not be used, which gets us back to either: a) One set of data in UTF-8, which would support a singular representation using both ASCII and non-ASCII characters, or b) Two sets of data, with one (required) in ASCII and the other (if desired) in potentially non-ASCII UTF-8. My recollection is that most folks who spoke up at the IETF meeting thought this was the best alternative. Of course, this list is the final arbiter. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39CAIPS009094 for ietf-provreg-outgoing; Mon, 9 Apr 2001 14:10:18 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39CAGLt009089 for ; Mon, 9 Apr 2001 14:10:17 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA26880; Mon, 9 Apr 2001 08:10:05 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BQ4>; Mon, 9 Apr 2001 08:03:31 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Mats Dufberg'" Cc: ietf-provreg@cafax.se Subject: RE: Nameserver MUST HAVE IP Date: Mon, 9 Apr 2001 08:03:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Mats Dufberg [mailto:dufberg@nic-se.se] >Sent: Monday, April 09, 2001 7:26 AM >To: Hollenbeck, Scott >Cc: ietf-provreg@cafax.se >Subject: RE: Nameserver MUST HAVE IP > > >On Mon, 9 Apr 2001, Hollenbeck, Scott wrote: > >> >IMHO we should remove the requirement in 3.4.2[3] that a >nameserver MUST >> have >> >an IP address if its name lies registered in the >registrar's TLD. The >> >discussions here and the interesting report quoted by >Elisabeth Porteneuve >> >showed that this requirement does not add much to the "health" >> >of the domain name system. >> >> I disagree that the requirement should be removed >completely, and reiterate >> my earlier suggestion that replacing the MUST with a SHOULD >would be more >> appropriate. > >A SHOULD would be appropriate if storing the IP address for glue records >not strictly needed would be a better solution than not. I disagree. By >storing and announcing the IP address you increase the risk of have >different data in the mother zone than in the authoritative >zone. -- Data should be kept where it is authoritative as far as possible. ...and by not mentioning anything at all about the need for an IP address with a name server you run the larger risk of not having glue where it's needed. I don't have a problem with adding some words that describe why the SHOULD isn't a MUST (see below), but cutting out the requirement completely doesn't address the reality of needing addresses to produce glue records. 3.4.2-[3] existing text: Name servers registered within the registry's authoritative TLDs MUST be registered with a valid IPv4 or IPv6 address. 3.4.2-[3], change MUST to SHOULD and add new text: Name servers registered within the registry's authoritative TLDs SHOULD be registered with a valid IPv4 or IPv6 address only as required to produce DNS "glue" records. In my opinion this ensures that we still have a requirement for addresses to produce glue records, and covered the concern that addresses aren't required for all name servers. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39BQbE5001537 for ietf-provreg-outgoing; Mon, 9 Apr 2001 13:26:37 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39BQaLt001532 for ; Mon, 9 Apr 2001 13:26:36 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f39BQJA17707; Mon, 9 Apr 2001 13:26:19 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Mon, 9 Apr 2001 13:26:19 +0200 (CEST) From: Mats Dufberg To: "Hollenbeck, Scott" cc: Subject: RE: Nameserver MUST HAVE IP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, 9 Apr 2001, Hollenbeck, Scott wrote: > >IMHO we should remove the requirement in 3.4.2[3] that a nameserver MUST > have > >an IP address if its name lies registered in the registrar's TLD. The > >discussions here and the interesting report quoted by Elisabeth Porteneuve > >showed that this requirement does not add much to the "health" > >of the domain name system. > > I disagree that the requirement should be removed completely, and reiterate > my earlier suggestion that replacing the MUST with a SHOULD would be more > appropriate. A SHOULD would be appropriate if storing the IP address for glue records not strictly needed would be a better solution than not. I disagree. By storing and announcing the IP address you increase the risk of have different data in the mother zone than in the authoritative zone. -- Data should be kept where it is authoritative as far as possible. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f39Av8cw000736 for ietf-provreg-outgoing; Mon, 9 Apr 2001 12:57:08 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f39Av7Lt000731 for ; Mon, 9 Apr 2001 12:57:07 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id GAA26815; Mon, 9 Apr 2001 06:56:40 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BQF>; Mon, 9 Apr 2001 06:50:06 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Klaus Malorny'" , ietf-provreg@cafax.se Subject: RE: Nameserver MUST HAVE IP Date: Mon, 9 Apr 2001 06:50:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >Sent: Monday, April 09, 2001 4:31 AM >To: ietf-provreg@cafax.se >Subject: Re: Nameserver MUST HAVE IP > > > > >IMHO we should remove the requirement in 3.4.2[3] that a nameserver MUST have >an IP address if its name lies registered in the registrar's TLD. The >discussions here and the interesting report quoted by Elisabeth Porteneuve >showed that this requirement does not add much to the "health" >of the domain name system. I disagree that the requirement should be removed completely, and reiterate my earlier suggestion that replacing the MUST with a SHOULD would be more appropriate. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f399jXbJ026890 for ietf-provreg-outgoing; Mon, 9 Apr 2001 11:45:33 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f399jWLt026885 for ; Mon, 9 Apr 2001 11:45:33 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA25863; Mon, 9 Apr 2001 11:45:32 +0200 (METDST) Message-ID: <3AD1853E.15077200@knipp.de> Date: Mon, 09 Apr 2001 11:47:42 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Issues on 3.4.9 Object Information Query Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk I am missing functions that clearly report the relationships between the objects. Although I assume that forward references are reported on [1], [2] and [3], I would like to have this expressed clearly. In addition, reverse references cannot be determined by the current version of the requirements document, obviously. Therefore, I would like to have the following additions in the protocol*: ---8<--- 3.4.9[0] (to be inserted before [1]) All object information queries MUST report all references to other objects. This MUST also include objects that are referenced implicitly, if the existance of the reference may affect the outcome of any operation. 3.4.9[5] For any existing object the protocol MUST provide services to determine all reverse references, i.e. to list up the identifiers of those objects that use the given object. This MUST also include objects that reference the given object implicitly (e.g. name servers that belong to a given domain), if the existance of the reference may affect the outcome of any operation (e.g. deletions). ---8<--- regards, Klaus Malorny * this is, of course, a proposal. Sorry if the wording in this and previous e-mails insults in any way. ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f399M9ZQ026154 for ietf-provreg-outgoing; Mon, 9 Apr 2001 11:22:09 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f399M8Lt026149 for ; Mon, 9 Apr 2001 11:22:09 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA17793; Mon, 9 Apr 2001 11:22:08 +0200 (METDST) Message-ID: <3AD17FC2.707AA4CC@knipp.de> Date: Mon, 09 Apr 2001 11:24:18 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Issues on 3.4.5. Object Transfer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk I have some problems with the implicit transfer of name servers whose domain names are contained in the zone of the domain being transferred (despite the fact that I dislike the model). The server should not do any "hidden" things. It may be unclear to the registrar that it gets other objects. Therefore, the registry should report what it does at least. As a consequence, I would like to see the following additions in the protocol: ---8<--- 3.4.5[1] ... The registry MUST report the object identifiers of all objects that are transferred along with the domain object. 3.4.8[6] The protocol MUST provide services to determine all objects that would get implicitly transferred on a transfer of a certain object. ---8<--- regards, Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3995wE3025823 for ietf-provreg-outgoing; Mon, 9 Apr 2001 11:05:58 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3995vLt025818 for ; Mon, 9 Apr 2001 11:05:57 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id LAA11892; Mon, 9 Apr 2001 11:05:57 +0200 (METDST) Message-ID: <3AD17BF7.F3E0284@knipp.de> Date: Mon, 09 Apr 2001 11:08:07 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: International Issues @ 3.4.2[6] and 9. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk I would like to have some additions to 3.4.2: rationale Allthough section 9[2] mentions the problem of different languages and scripts and gives a solution, especially in the requirement to MAY have multiple versions of names, addresses etc. in different versions, I think it is important to substantiate this for the so-called social data in section 3.4.2[6]. We should force to have a version of the social data that is understandable around the world so we can assure that the data is useful outside the country where it is originated. added text ---8<--- 3.4.2. [6] ... The social data MUST contain a version ("international variant") that uses internatioal standards for names, addresses, phone numbers etc. and uses a restricted character subset (US-ASCII). The social data MAY additionally contain multiple versions ("national variants") that MAY use national representations of names, addresses and phone numbers and MAY use any characters which are supported by the protocol. These versions MUST be tagged with a country and/or language identification according to RFC XXXX/ISO 639/ISO 3166. ---8<--- Well, this could be generalized, of course, and be put in section 9. regards Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f398TAXD025634 for ietf-provreg-outgoing; Mon, 9 Apr 2001 10:29:10 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f398T9Lt025629 for ; Mon, 9 Apr 2001 10:29:10 +0200 (MEST) Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id KAA23923; Mon, 9 Apr 2001 10:29:07 +0200 (METDST) Message-ID: <3AD17356.7D88303C@knipp.de> Date: Mon, 09 Apr 2001 10:31:18 +0200 From: Klaus Malorny X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk IMHO we should remove the requirement in 3.4.2[3] that a nameserver MUST have an IP address if its name lies registered in the registrar's TLD. The discussions here and the interesting report quoted by Elisabeth Porteneuve showed that this requirement does not add much to the "health" of the domain name system. The more general question is whether it is the task of the protocol to protect the DNS from misconfigurations or not. If so, we should do this in a more generic form, e.g. to allow the protocol to reject a domain registration/update because of invalid/misconfigured/lame name servers, as it is done e.g. at the DENIC/.de registry -- although this will never be a panacea. regards Klaus Malorny ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f38DnBj7022012 for ietf-provreg-outgoing; Sun, 8 Apr 2001 15:49:11 +0200 (MEST) Received: from mout03.kundenserver.de (mout03.kundenserver.de [195.20.224.218]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f38DnBLt022007 for ; Sun, 8 Apr 2001 15:49:11 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout03.kundenserver.de with esmtp (Exim 2.12 #2) id 14mFYy-000629-00; Sun, 8 Apr 2001 15:49:08 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14mFZ2-0005Zg-00; Sun, 8 Apr 2001 15:49:12 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f38Dn9U13638; Sun, 8 Apr 2001 15:49:09 +0200 Date: Sun, 8 Apr 2001 15:49:09 +0200 From: Peter Eisenhauer To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010408154909.B13518@tornado.schlund.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from shollenbeck@verisign.com on Fri, Apr 06, 2001 at 12:55:59PM -0400 Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Apr 06, 2001 at 12:55:59PM -0400, Hollenbeck, Scott wrote: > >-----Original Message----- > >From: Peter Eisenhauer [mailto:eisenhauer@schlund.de] > >Sent: Friday, April 06, 2001 9:56 AM > >To: Bill Manning > >Cc: ietf-provreg@cafax.se > >Subject: Re: Nameserver MUST HAVE IP > > > > > >There is no need to register *all* name servers with ip addresses. > >e.g. think of a registry for .tld with 2 Domains: > > > >foo.tld with name servers ns1.foo.tld and ns2.foo.tld -- these > >name servers > >MUST be registered with ip addresses in the registry. > > > >bar.tld with nameservers ns3.foo.tld, ns4.foo.tld -- there is > >no need that > >the ip addresses of these name servers must be in the *registry*. > > > >In this model ip addresses for name servers in the registry > >are only needed for "real" glue records. > > After playing around with some NS and A records I understand what Peter is > saying, and he has a point -- the addresses aren't required in the TLD zone, > and some name server software packages may either drop the extraneous glue > records or refuse to load the zone if they exist. This does appear to be a > good reason to change the "MUST" to a "SHOULD" as originally suggested. > > Following the discussion I would say it has been shown that is is possible to run a registry without the strict requirement of registration with ip addresses for all name servers (in the registry TLD). So that appears to be a very good reason to change the "MUST". Maybe then there should be an addition like "registry must require all nameserver ip information to enable a healthy DNS system, at least glue records with are absolutely needed"? Best Regards, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f38Dcdaq021989 for ietf-provreg-outgoing; Sun, 8 Apr 2001 15:38:39 +0200 (MEST) Received: from mout01.kundenserver.de (mout01.kundenserver.de [195.20.224.132]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f38DccLt021984 for ; Sun, 8 Apr 2001 15:38:39 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout01.kundenserver.de with esmtp (Exim 2.12 #2) id 14mFOo-0002YU-00; Sun, 8 Apr 2001 15:38:38 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14mFOq-0005Dd-00; Sun, 8 Apr 2001 15:38:40 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f38DcbO13592; Sun, 8 Apr 2001 15:38:37 +0200 Date: Sun, 8 Apr 2001 15:38:37 +0200 From: Peter Eisenhauer To: Urs Eppenberger Cc: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010408153837.A13518@tornado.schlund.de> References: <20010406151807.A3116@tornado.schlund.de> <548383.986572957@pbue.switch.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <548383.986572957@pbue.switch.ch>; from eppenberger@switch.ch on Fri, Apr 06, 2001 at 04:02:37PM +0200 Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk I *was* referring to name servers using a hostname within the registry's authoritative TLD. See the discussion about use of glue records in the registry. On Fri, Apr 06, 2001 at 04:02:37PM +0200, Urs Eppenberger wrote: > --On Freitag, 6. April 2001 15:18 Uhr +0200 Peter Eisenhauer > wrote: > > > draft-ietf-provreg-grrp-reqs-01.txt: > > "Name servers registered within the registry's authoritative TLDs MUST > > be registered with a valid IPv4 or IPv6 address." > > Hello Peter > I understand your concern, if you base it only on the text quoted above. > But reading chapter 3.4.2 [5] I understand it as follows: > o if you register a namserver in a registry which is authoritative for > TLD and the hostname of the nameserver is in the same TLD, then you > MUST register the IP address too > o you can register a nameserver in registries of other tlds, not in > the tld of its hostname, then you MAY register the IP address too, > these registries will ignore the IP addresses for their zone file. > > The phrase you quoted could be made more clear, for example: > "Name servers using a hostname within the registry's authoritative TLDs > MUST be registered with a valid IPv4 or IPv6 address." > > Does this help or does this confuse? > > Urs. > Best Regards, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f38BgcIs021702 for ietf-provreg-outgoing; Sun, 8 Apr 2001 13:42:38 +0200 (MEST) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f38BgcLt021697 for ; Sun, 8 Apr 2001 13:42:38 +0200 (MEST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id NAA68430 for ; Sun, 8 Apr 2001 13:42:37 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.11.3/8.11.2) id f38Bgak17486 for ietf-provreg@cafax.se; Sun, 8 Apr 2001 13:42:37 +0200 (CEST) (envelope-from jaap) Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36E2cLt012763 for ; Fri, 6 Apr 2001 16:02:38 +0200 (MEST) Received: from pbue.switch.ch ([130.59.4.112]) by central.switch.ch with esmtp (Exim 3.20 #1) id 14lWov-0007cP-00 for ietf-provreg@cafax.se; Fri, 06 Apr 2001 16:02:37 +0200 Date: Fri, 06 Apr 2001 16:02:37 +0200 From: Urs Eppenberger To: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <548383.986572957@pbue.switch.ch> In-Reply-To: <20010406151807.A3116@tornado.schlund.de> References: <20010406151807.A3116@tornado.schlund.de> X-Mailer: Mulberry/2.1.0a4 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On Freitag, 6. April 2001 15:18 Uhr +0200 Peter Eisenhauer wrote: > draft-ietf-provreg-grrp-reqs-01.txt: > "Name servers registered within the registry's authoritative TLDs MUST > be registered with a valid IPv4 or IPv6 address." Hello Peter I understand your concern, if you base it only on the text quoted above. But reading chapter 3.4.2 [5] I understand it as follows: o if you register a namserver in a registry which is authoritative for TLD and the hostname of the nameserver is in the same TLD, then you MUST register the IP address too o you can register a nameserver in registries of other tlds, not in the tld of its hostname, then you MAY register the IP address too, these registries will ignore the IP addresses for their zone file. The phrase you quoted could be made more clear, for example: "Name servers using a hostname within the registry's authoritative TLDs MUST be registered with a valid IPv4 or IPv6 address." Does this help or does this confuse? Urs. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f380pO0m019696 for ietf-provreg-outgoing; Sun, 8 Apr 2001 02:51:24 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f380pNLt019691 for ; Sun, 8 Apr 2001 02:51:23 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA26013; Sat, 7 Apr 2001 20:50:51 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BLR>; Sat, 7 Apr 2001 20:44:19 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Patrick Greenwell'" , ietf-provreg@cafax.se Subject: RE: Provreg WG Last Call announcement Date: Sat, 7 Apr 2001 20:44:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Patrick Greenwell [mailto:patrick@stealthgeeks.net] > Sent: Saturday, April 07, 2001 12:48 PM > To: ietf-provreg@cafax.se > Subject: Re: Provreg WG Last Call announcement > > > On Tue, 3 Apr 2001, Edward Lewis wrote: > > > So, in the effort to promote the requirements draft to an > RFC, let the last > > call begin. > > First, let me say thanks to all of you who have been labouring on this > draft. It's elegant in it's simplicity. > > I do have a question/comment: would the concept of state be appropriate > with social information as it is with certain other objects, say in the > case where privacy of information is desired and a higher-layered protocol > would take that state information(privacy lock or somesuch) into account? Some time ago we discussed data collection (particularly WRT social information) requirements, the end result of which has been captured in section 8.4 of the draft. The protocol-in-progress will include provisions to identify how social data may be used, though the WG hasn't yet produced a proposal to describe how this feature might be implemented. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f37HRIYE018783 for ietf-provreg-outgoing; Sat, 7 Apr 2001 19:27:18 +0200 (MEST) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f37HRGLt018778 for ; Sat, 7 Apr 2001 19:27:17 +0200 (MEST) Received: from c1193160-a.snvl1.sfba.home.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id KAA09293; Sat, 7 Apr 2001 10:27:13 -0700 X-Authentication-Warning: joy.songbird.com: c1193160-a.snvl1.sfba.home.com [65.0.152.112] didn't use HELO protocol Message-Id: <5.1.0.12.2.20010407102015.01d2c9b8@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.12 (Beta) Date: Sat, 07 Apr 2001 10:22:46 -0700 To: Patrick Greenwell From: Dave Crocker Subject: Privacy state/context Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk Patrick, I'm not entirely following your query. Could you elaborate? (Pure hypotheticals are fine. We can distinguish between your general query and your giving a detailed hypothetical that is only for pedagogy, not intended as a real proposal.) I would just like to better understand what kind of thing you have in mind. Thanks. d/ At 09:47 AM 4/7/2001, Patrick Greenwell wrote: >I do have a question/comment: would the concept of state be appropriate >with social information as it is with certain other objects, say in the >case where privacy of information is desired and a higher-layered protocol >would take that state information(privacy lock or somesuch) into account? ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f37GlbJo018628 for ietf-provreg-outgoing; Sat, 7 Apr 2001 18:47:37 +0200 (MEST) Received: from rockstar.stealthgeeks.net (rockstar.stealthgeeks.net [216.233.200.203]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with SMTP id f37GlYLt018623 for ; Sat, 7 Apr 2001 18:47:35 +0200 (MEST) Received: (qmail 60071 invoked by uid 1001); 7 Apr 2001 16:47:32 -0000 Date: Sat, 7 Apr 2001 09:47:32 -0700 (PDT) From: Patrick Greenwell To: Subject: Re: Provreg WG Last Call announcement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, 3 Apr 2001, Edward Lewis wrote: > So, in the effort to promote the requirements draft to an RFC, let the last > call begin. First, let me say thanks to all of you who have been labouring on this draft. It's elegant in it's simplicity. I do have a question/comment: would the concept of state be appropriate with social information as it is with certain other objects, say in the case where privacy of information is desired and a higher-layered protocol would take that state information(privacy lock or somesuch) into account? Thanks. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Earth is a single point of failure. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36MNCNR015574 for ietf-provreg-outgoing; Sat, 7 Apr 2001 00:23:12 +0200 (MEST) Received: from laudanum.saraf.com ([63.217.189.99]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36MNBLt015568 for ; Sat, 7 Apr 2001 00:23:12 +0200 (MEST) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f36MNAe30342; Fri, 6 Apr 2001 18:23:10 -0400 X-Authentication-Warning: laudanum.saraf.com: sheer owned process doing -bs Date: Fri, 6 Apr 2001 18:23:10 -0400 (EDT) From: Sheer El-Showk To: , Kent Crispin Subject: Re: Nameserver MUST HAVE IP In-Reply-To: <20010406121036.A29000@songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk > The requirement does not prevent names from becoming unresolvable -- > there are lots of other ways that can happen, and arguably, the > increased churn in the address data leads to more misconfigurations than > it prevents. It's hard to say. Personal experience has shown this to be the case. I've seen people spend a long time (and harrass the wrong people) trying to trace the problem with ns updates in the registry that turn out to be glue/authoritative record inconsistencies. The whole "glue" record concept is a necassary, but painful reality in DNS (I'm not sure what how much BIND and other DNS software give preference to records from an authoritative domain over a glue record in a higher level domain, but the mixup between the two can make for some very strange error). I think there's a very valid argument for eliminating replication nameserer IP information. If it is clear that one NS record per domain (at least a domain with nameservers in it) requires an IP address then people can focus on keeping that one machine as a "glue" between the TLD and the SLD and then use it to setup and maintain a large number of secondary/tertiary NS's for the domain (which have no ip addresses in the registry). There is really only a need for one "glue" between a TLD and an SLD (though a redundancy requirement, if dicated by the registry, like NSI does, is not a bad idea). Regards, Sheer Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36KpSoG015176 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:51:28 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36KpRLt015171 for ; Fri, 6 Apr 2001 22:51:27 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f36KpOC28113; Fri, 6 Apr 2001 22:51:24 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Fri, 6 Apr 2001 22:51:24 +0200 (CEST) From: Mats Dufberg To: Christopher Ambler cc: Subject: Re: Nameserver MUST HAVE IP In-Reply-To: <053401c0beda$31c95540$1701a8c0@underslunky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 6 Apr 2001, Christopher Ambler wrote: > >From a practical standpoint, yes, we can, in a way. When we build our .Web > zone, we do an SOA check on the name servers given. If the check fails such > that there aren't 2 valid name servers that both resolve and answer with > authority, the name doesn't go in the zone. For SE we have similar requirements, but say that the end up with foo.se. NS ns.foo.se. foo.se. NS ns2.foo.nu. ns.foo.se. A 192.0.2.30 foo.nu. NS ns.foo.nu. foo.nu. NS ns2.foo.se. ns.foo.nu. A 192.0.2.30 then you have lost all redundancy! Both delegations are dependen on one server. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36KhjNC015119 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:43:45 +0200 (MEST) Received: from dmz.ambler.net (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36KhhLt015114 for ; Fri, 6 Apr 2001 22:43:44 +0200 (MEST) Received: from underslunky ([192.168.1.23]) by dmz.ambler.net (8.11.0/8.8.7) with SMTP id f36Kgqw19122; Fri, 6 Apr 2001 13:42:56 -0700 Message-ID: <053401c0beda$31c95540$1701a8c0@underslunky> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Mats Dufberg" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: References: Subject: Re: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 13:43:06 -0700 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f36KhjLt015115 Sender: owner-ietf-provreg@cafax.se Precedence: bulk >I've seen that in real life! One was an SE domain and the other one was a >NU domain. Both domain had the same two nameservers, but for the SE domain >they used NU names, and vice versa. I talked to the holder, I he said that >he thought he was smart... > >We cannot prevent that from happening by allowing non-strict glue. >From a protocol standpoint, no. >From a practical standpoint, yes, we can, in a way. When we build our .Web zone, we do an SOA check on the name servers given. If the check fails such that there aren't 2 valid name servers that both resolve and answer with authority, the name doesn't go in the zone. The problem becomes apparent rather quickly, and the customer is notified that they need to fix it. But this is a policy at our registry, as it should be. Christopher Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36KfKbt015110 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:41:20 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36KfKLt015105 for ; Fri, 6 Apr 2001 22:41:20 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f36KfFG28086; Fri, 6 Apr 2001 22:41:15 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Fri, 6 Apr 2001 22:41:15 +0200 (CEST) From: Mats Dufberg To: "Jordyn A. Buchanan" cc: Subject: Re: Nameserver MUST HAVE IP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 6 Apr 2001, Jordyn A. Buchanan wrote: > All of this comes from treating name servers as attributes of domains > rather than objects. If you think of the name server as an object in > the registry as opposed to an attribute of SLD.se, then the > requirement of IP addresses for name server objects within the TLD > makes more sense. I realize that some registries today don't take > this approach, but the fact that it also happens to prevent loops > like the one I describe above is simply another argument in favor of > the name-server-as-object approach. That it how it works in the COM zone, and there it has two effects: 1. If ns.foo.com is nameserver of foo.com, and foo.com is deactivated (delegation removed) the com zone becomes authoritative for the ns.foo.com record, which is shouldn't. 2. If foo.com changes servers to dns.foo.com and dns2.foo.com and don't remove ns.foo.com, the com zone will announce ns.foo.com with an IP address that could be different from the one in the authoritative zone. In the com zone, the NS and A records are (or should be) only copies of what is in the authoritative zone, and we should keep just as much as is needed for the delegation of that zone. Loops should be prevented by good management of the holder (or its DNS operator) not by copying extra data to the com zone. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36KWaoK015058 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:32:36 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36KWZLt015053 for ; Fri, 6 Apr 2001 22:32:35 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f36KWRl28065; Fri, 6 Apr 2001 22:32:27 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Fri, 6 Apr 2001 22:32:27 +0200 (CEST) From: Mats Dufberg To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Subject: Re: Nameserver MUST HAVE IP In-Reply-To: <1620587.986595659@[192.168.1.29]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 6 Apr 2001, Patrik Fältström wrote: > But, what about these two zones: > > $ORIGIN foo.com. > foo.com. IN NS ns.bar.se. > > $ORIGIN bar.se. > bar.se. IN NS ns.foo.com. > > ;-) > > I have never seen this in real life, but it is possible at least > theoretically... > > I really would like to know about a real example, if anyone have one. I've seen that in real life! One was an SE domain and the other one was a NU domain. Both domain had the same two nameservers, but for the SE domain they used NU names, and vice versa. I talked to the holder, I he said that he thought he was smart... We cannot prevent that from happening by allowing non-strict glue. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36KLLnO015017 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:21:21 +0200 (MEST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36KLKLt015012 for ; Fri, 6 Apr 2001 22:21:20 +0200 (MEST) Received: from [192.168.1.29] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA14428; Fri, 6 Apr 2001 22:21:00 +0200 (MET DST) Date: Fri, 06 Apr 2001 22:20:59 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Mats Dufberg , "Jordyn A. Buchanan" cc: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <1620587.986595659@[192.168.1.29]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On 01-04-06 22.02 +0200 Mats Dufberg wrote: > If then ns3.foo.com and ns1.foo.se are the namesevers of bar.com, neither > of the IP addresses are needed (the IP address of ns1.foo.se is forbidden > in com zone). The IP address of ns3.foo.com is to be found in the foo.com > zone through normal lookup. But, what about these two zones: $ORIGIN foo.com. foo.com. IN NS ns.bar.se. $ORIGIN bar.se. bar.se. IN NS ns.foo.com. ;-) I have never seen this in real life, but it is possible at least theoretically... I really would like to know about a real example, if anyone have one. paf Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36KB7vO014973 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:11:07 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36KB6Lt014968 for ; Fri, 6 Apr 2001 22:11:06 +0200 (MEST) Received: from [10.10.20.173] (helo=[10.10.20.173]) by rcommail2 with esmtp (Exim 3.16 #2) id 14lcZ6-0006KL-00; Fri, 06 Apr 2001 16:10:40 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: References: Date: Fri, 6 Apr 2001 16:10:52 -0400 To: Mats Dufberg From: "Jordyn A. Buchanan" Subject: Re: Nameserver MUST HAVE IP Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 10:02 PM +0200 4/6/01, Mats Dufberg wrote: >On Fri, 6 Apr 2001, Jordyn A. Buchanan wrote: > >> If you are the authoritative registry for a TLD and you don't have >> the IP address of a name server within your TLD, how can the NS's IP >> address possibly be found through a "normal lookup"? > >If ns1.foo.com and ns2.foo.com are the nameservers of foo.com then the IP >addresses is a must. > >If then ns3.foo.com and ns1.foo.se are the namesevers of bar.com, neither >of the IP addresses are needed (the IP address of ns1.foo.se is forbidden >in com zone). The IP address of ns3.foo.com is to be found in the foo.com >zone through normal lookup. And if foo.com's name servers are in bar.com at the same time? I realize that this is an extreme example, but this is probably not something you want to allow. >If you don't think it works, I'll have to find some exampel from the SE >zone. :-) I think it works sometimes, but that doesn't make it a good idea. All of this comes from treating name servers as attributes of domains rather than objects. If you think of the name server as an object in the registry as opposed to an attribute of SLD.se, then the requirement of IP addresses for name server objects within the TLD makes more sense. I realize that some registries today don't take this approach, but the fact that it also happens to prevent loops like the one I describe above is simply another argument in favor of the name-server-as-object approach. Jordyn -- Jordyn A. Buchanan jordyn@register.com Futurist +1.212.798.9262 Register.com http://www.register.com/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36K2dug014918 for ietf-provreg-outgoing; Fri, 6 Apr 2001 22:02:39 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36K2cLt014913 for ; Fri, 6 Apr 2001 22:02:39 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f36K2al27804; Fri, 6 Apr 2001 22:02:36 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Fri, 6 Apr 2001 22:02:36 +0200 (CEST) From: Mats Dufberg To: "Jordyn A. Buchanan" cc: Subject: Re: Nameserver MUST HAVE IP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 6 Apr 2001, Jordyn A. Buchanan wrote: > If you are the authoritative registry for a TLD and you don't have > the IP address of a name server within your TLD, how can the NS's IP > address possibly be found through a "normal lookup"? If ns1.foo.com and ns2.foo.com are the nameservers of foo.com then the IP addresses is a must. If then ns3.foo.com and ns1.foo.se are the namesevers of bar.com, neither of the IP addresses are needed (the IP address of ns1.foo.se is forbidden in com zone). The IP address of ns3.foo.com is to be found in the foo.com zone through normal lookup. > The IP address is only a required element for name servers within the > registry's authoritative TLDs. The IP address is only needed if the nameserver is the nameserver of its own zone. That's the strict glue. If you don't think it works, I'll have to find some exampel from the SE zone. :-) Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36JMW22014716 for ietf-provreg-outgoing; Fri, 6 Apr 2001 21:22:32 +0200 (MEST) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36JMULt014711 for ; Fri, 6 Apr 2001 21:22:31 +0200 (MEST) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id MAA29142 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 12:10:36 -0700 Message-ID: <20010406121036.A29000@songbird.com> Date: Fri, 6 Apr 2001 12:10:36 -0700 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Mail-Followup-To: ietf-provreg@cafax.se References: <04c801c0bec6$f9dd5d10$1701a8c0@underslunky> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Jordyn A. Buchanan on Fri, Apr 06, 2001 at 02:45:49PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Apr 06, 2001 at 02:45:49PM -0400, Jordyn A. Buchanan wrote: > ...and this complies completely with the existing requirement. > > But I'll stop trying to argue this point. If people want to do allow > names in their registry to become unresolvable, I guess it's none of > my business. The requirement does not prevent names from becoming unresolvable -- there are lots of other ways that can happen, and arguably, the increased churn in the address data leads to more misconfigurations than it prevents. It's hard to say. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36Iq9BU014520 for ietf-provreg-outgoing; Fri, 6 Apr 2001 20:52:09 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36Iq7Lt014515 for ; Fri, 6 Apr 2001 20:52:07 +0200 (MEST) Received: from [10.10.20.173] (helo=[10.10.20.173]) by rcommail2 with esmtp (Exim 3.16 #2) id 14lbKh-0007uZ-00; Fri, 06 Apr 2001 14:51:43 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <04c801c0bec6$f9dd5d10$1701a8c0@underslunky> References: <04c801c0bec6$f9dd5d10$1701a8c0@underslunky> Date: Fri, 6 Apr 2001 14:45:49 -0400 To: "Christopher Ambler" , From: "Jordyn A. Buchanan" Subject: Re: Nameserver MUST HAVE IP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 11:25 AM -0700 4/6/01, Christopher Ambler wrote: > > I never understand the sense of the NSI requirements and the need for host >> handles. In Germany, we have more then 4,000,000 DE-domains, we only >> require the IP of the DNS, if the DNS is in the domain (eg. DNS >> "ns3.knipp.de" is responsible for the domain "knipp.de"). > >We take it a bit further for .Web, and require them when the name servers >are in any other .Web domain, since we'd rather be careful and avoid loops. >Sure, it could be resolved at build time, but we're lazy :-) > ...and this complies completely with the existing requirement. But I'll stop trying to argue this point. If people want to do allow names in their registry to become unresolvable, I guess it's none of my business. Jordyn -- Jordyn A. Buchanan jordyn@register.com Futurist +1.212.798.9262 Register.com http://www.register.com/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36InkW0014501 for ietf-provreg-outgoing; Fri, 6 Apr 2001 20:49:46 +0200 (MEST) Received: from balsa.cetp.ipsl.fr (balsa.cetp.ipsl.fr [193.52.172.32]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36IniLt014496 for ; Fri, 6 Apr 2001 20:49:45 +0200 (MEST) Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id UAA12320; Fri, 6 Apr 2001 20:49:05 +0200 (MET DST) Date: Fri, 6 Apr 2001 20:49:05 +0200 (MET DST) From: Elisabeth Porteneuve Message-Id: <200104061849.UAA12320@balsa.cetp.ipsl.fr> To: ietf-provreg@cafax.se, kent@songbird.com Subject: Re: Nameserver MUST HAVE IP Sender: owner-ietf-provreg@cafax.se Precedence: bulk Kent Crispin wrote: > > > You should be handing out glue records for name > > servers within your TLD. Taking your argument to an extreme, it's > > possible to have a situation in which xxx.de has the name servers > > ns1.yyy.de and ns2.yyy.de, with no IP address information. yyy.de > > could have the name servers ns1.xxx.de and ns2.xxx.de, with no IP > > address information. In that scenario, both xxx.de and yyy.de are > > broken. If you require that all .de name servers have IP addresses > > associated with them, that can't happen. > > Yes, as I said, the requirement may reduce the likelihood of broken > delegations, but I'm not sure how common the problem may be. > I am not sure if my note is strictly to the subject. The Men and Mice http://www.menandmice.com/dnsplace/healthsurvey.html?DHS1100 indicates enourmous percentage of misconfigurations, see quotation. I do not know how many of them are related to the case quoted above, or, more complicated, to the name servers accross TLDs. Elisabeth -- International Comparisons of "Domain Health" Highlights In March 2000, Men & Mice conducted a comparative Domain Health Survey for 8 selected countries. Random samples of 2000 zones were tested for United Kingdom (.uk), France (.fr), Canada (.ca), Australia (.au), Spain (.es) and Norway (.no). A random sample of 1000 zones was taken for Ireland (.ie) and 500 zones for Iceland (.is). It appears that Canada and United Kingdom have the largest number of incorrect zones (read about critera for errors in Methodology) or 70.30% and 70.05% respectively. A Domain Health Survey for .COM in February '00 shows incorrect zones as high as 72.5% (see figure below and further information here). The best condition was in France with 29.35% of incorrect zones. Close to France was Iceland with 32% incorrect zones, and ranking number three was Norway with 36.10% of incorrect zones. -- Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36IPrFg014397 for ietf-provreg-outgoing; Fri, 6 Apr 2001 20:25:53 +0200 (MEST) Received: from dmz.ambler.net (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36IPpLt014392 for ; Fri, 6 Apr 2001 20:25:52 +0200 (MEST) Received: from underslunky ([192.168.1.23]) by dmz.ambler.net (8.11.0/8.8.7) with SMTP id f36IPNw18455 for ; Fri, 6 Apr 2001 11:25:23 -0700 Message-ID: <04c801c0bec6$f9dd5d10$1701a8c0@underslunky> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: Subject: Re: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 11:25:34 -0700 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f36IPqLt014393 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I never understand the sense of the NSI requirements and the need for host > handles. In Germany, we have more then 4,000,000 DE-domains, we only > require the IP of the DNS, if the DNS is in the domain (eg. DNS > "ns3.knipp.de" is responsible for the domain "knipp.de"). We take it a bit further for .Web, and require them when the name servers are in any other .Web domain, since we'd rather be careful and avoid loops. Sure, it could be resolved at build time, but we're lazy :-) (e.g. foo.web resolves with ns.bar.web, but bar.web resolves with ns.foo.web) Christopher Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36INRIA014383 for ietf-provreg-outgoing; Fri, 6 Apr 2001 20:23:27 +0200 (MEST) Received: from dmz.ambler.net (c1420972-a.bllvu1.wa.home.com [65.4.137.192]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36INQLt014378 for ; Fri, 6 Apr 2001 20:23:26 +0200 (MEST) Received: from underslunky ([192.168.1.23]) by dmz.ambler.net (8.11.0/8.8.7) with SMTP id f36IMsw18441 for ; Fri, 6 Apr 2001 11:22:55 -0700 Message-ID: <04bf01c0bec6$a18d7be0$1701a8c0@underslunky> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: References: Subject: Re: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 11:23:08 -0700 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id f36INRLt014379 Sender: owner-ietf-provreg@cafax.se Precedence: bulk "Mats Dufberg" > On Fri, 6 Apr 2001, Peter Eisenhauer wrote: > > > So name servers in the registry with "real" glue records (don't like the term > > either) must be registered with ip addresses, the others could be handled like > > name server outside the registry. > > > > Then of course there must be checks, if the "glue" condition is valid if a > > nameserver is registered or if a domain is updated... > > The SE zone successfully uses the above model. No update is possible > without glue if glue is needed. Any glue not needed is discarded. Our .Web registry works the same way. We collect the data, but the zone builds without it if the glue isn't necessary. Christopher Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36I7cmj014240 for ietf-provreg-outgoing; Fri, 6 Apr 2001 20:07:38 +0200 (MEST) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36I7ZLt014232 for ; Fri, 6 Apr 2001 20:07:36 +0200 (MEST) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id KAA28166 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 10:55:40 -0700 Message-ID: <20010406105539.C26703@songbird.com> Date: Fri, 6 Apr 2001 10:55:39 -0700 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Mail-Followup-To: ietf-provreg@cafax.se References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Jordyn A. Buchanan on Fri, Apr 06, 2001 at 01:01:07PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Apr 06, 2001 at 01:01:07PM -0400, Jordyn A. Buchanan wrote: > >> If you are the authoritative registry for a TLD and you don't have > >> the IP address of a name server within your TLD, how can the NS's IP > >> address possibly be found through a "normal lookup"? > > > >You are mixing some things. Kent catched the sentence. > > No I'm not. You're arguing against a requirement that doesn't exist. > The requirements document says that IP addresses have to be present > for name servers within the TLD, it doesn't contemplate whether they > have to exist for name servers within the SLD. I don't know if I understand what you are saying. Is ns1.x.com a nameserver in the .com TLD? If not, then the requirement is empty. If yes, then Elmar's point holds. It is perfectly possible to have a nameserver externalns.x.com not be a server for the x.com zone, and just be a server for external domains. [...] > >I never understand the sense of the NSI requirements and the need for host > >handles. In Germany, we have more then 4,000,000 DE-domains, we only > >require the IP of the DNS, if the DNS is in the domain (eg. DNS > >"ns3.knipp.de" is responsible for the domain "knipp.de"). > > Within your registry, you can deal with this however you want. If > you want to create a new name server object each and every time a > name server is used, that's up to you. Personally, I think that's > pretty inefficient. I believe that the point is that the protocol requires you to supply an address *when you register*. This is unnecessary as a requirement, because there are three cases: 1) ns name is already registered 2) ns name is not registered but in the dns 3) ns name is not registered and not in the dns and only in this last case is it really necessary to supply an address. (Note that this condition is a more general description saying you need glue records.) But this last case is very rare these days. I would wager that if we examined the .com zone we would find that the large majority of domain names have nameservers outside their SLD. > However, if someone specifies the name server "ns3.knipp.de", and the > name server "ns3.knipp.de" does not exist within the .DE registry, > that's a problem. The name ns3.knipp.de exists within the .de tree, by definition, so if it exists at all, it is within the .de tree. So your condition reduces to "ns3.knipp.de" doesn't exist at all. Yes, that is a problem. The more interesting example would be "ns3.knipp.com" being a ns for the knipp.de domain. It makes sense that ns3.knipp.com should not be registered in the .de TLD... > You should be handing out glue records for name > servers within your TLD. Taking your argument to an extreme, it's > possible to have a situation in which xxx.de has the name servers > ns1.yyy.de and ns2.yyy.de, with no IP address information. yyy.de > could have the name servers ns1.xxx.de and ns2.xxx.de, with no IP > address information. In that scenario, both xxx.de and yyy.de are > broken. If you require that all .de name servers have IP addresses > associated with them, that can't happen. Yes, as I said, the requirement may reduce the likelihood of broken delegations, but I'm not sure how common the problem may be. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36I0SNq014165 for ietf-provreg-outgoing; Fri, 6 Apr 2001 20:00:28 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36I0RLt014160 for ; Fri, 6 Apr 2001 20:00:27 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA24381; Fri, 6 Apr 2001 13:59:13 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0BAF>; Fri, 6 Apr 2001 13:52:44 -0400 Message-ID: From: "Larson, Matt" To: "'Jordyn A. Buchanan'" , Elmar Knipp Cc: Kent Crispin , ietf-provreg@cafax.se Subject: RE: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 13:52:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk > However, if someone specifies the name server "ns3.knipp.de", and the > name server "ns3.knipp.de" does not exist within the .DE registry, > that's a problem. You should be handing out glue records for name > servers within your TLD. I don't think there's universal agreement on that. As others have already pointed out, storing and distributing A records that aren't required as glue records can be confusing. If I own foo.tld, and bar.tld (and only bar.tld) uses name server ns3.foo.tld, I don't want that A record in the tld zone. That record belongs to my zone and I want to be able to change it in only one place. If you're intent on providing a non-empty Additional section in referrals, configure the TLD's name servers to fetch such A records from the appropriate subzone and hand them out. (That being said, it's a bad idea to run in such a "glue fetching" configuration: it opens you up to a cache-poisoning attack, since it causes the TLD name server that would not otherwise initiate any queries to do so.) > Taking your argument to an extreme, it's > possible to have a situation in which xxx.de has the name servers > ns1.yyy.de and ns2.yyy.de, with no IP address information. yyy.de > could have the name servers ns1.xxx.de and ns2.xxx.de, with no IP > address information. In that scenario, both xxx.de and yyy.de are > broken. You're absolutely right, and you point out that this is not an easy problem to solve. I think you have to check for such circular references either at registration time or zone generation/publication time. You also have to decide how big a circle you're willing to accommodate. Before anyone points it out, I'm aware that what I'm preaching is different from VGRS's current practice wrt com, net and org. But we're certainly aware of the issue and working to fix it. Matt -- Matt Larson VeriSign Global Registry Services / www.verisign-grs.com Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36HBP1T013920 for ietf-provreg-outgoing; Fri, 6 Apr 2001 19:11:25 +0200 (MEST) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36HBNLt013915 for ; Fri, 6 Apr 2001 19:11:24 +0200 (MEST) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id JAA27642 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 09:59:30 -0700 Message-ID: <20010406095930.B26703@songbird.com> Date: Fri, 6 Apr 2001 09:59:30 -0700 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Mail-Followup-To: ietf-provreg@cafax.se References: <20010406151807.A3116@tornado.schlund.de> <20010406083941.A26703@songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Jordyn A. Buchanan on Fri, Apr 06, 2001 at 12:06:19PM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Apr 06, 2001 at 12:06:19PM -0400, Jordyn A. Buchanan wrote: > If you are the authoritative registry for a TLD and you don't have > the IP address of a name server within your TLD, how can the NS's IP > address possibly be found through a "normal lookup"? I think that the examples cited by Elmar and others have explained this pretty well -- the NS's are in different SLD's, but within the same TLD. This situation is extremely common -- in fact, it may be the usual case: a web hosting company may provide name service for hundreds of SLDs with nameservers within its own domain, and no glue is needed for any of those SLDs. Or consider all those parked domains... > The IP address is only a required element for name servers within the > registry's authoritative TLDs. For nameservers within other TLDs, > they are not required (indeed, I think they're prohibited). The reasoning is recursive? Kent -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36H3oAZ013869 for ietf-provreg-outgoing; Fri, 6 Apr 2001 19:03:50 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36H3nLt013864 for ; Fri, 6 Apr 2001 19:03:49 +0200 (MEST) Received: from [10.10.20.173] (helo=[10.10.20.173]) by rcommail2 with esmtp (Exim 3.16 #2) id 14lZcw-0006wa-00; Fri, 06 Apr 2001 13:02:28 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: References: Date: Fri, 6 Apr 2001 13:01:07 -0400 To: Elmar Knipp From: "Jordyn A. Buchanan" Subject: Re: Nameserver MUST HAVE IP Cc: Kent Crispin , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 6:35 PM +0200 4/6/01, Elmar Knipp wrote: >On Fri, 6 Apr 2001, Jordyn A. Buchanan wrote: > >> At 8:39 AM -0700 4/6/01, Kent Crispin wrote: >> >That is not what was said, if I understand correctly. The issue is not >> >whether the nameserver has an IP address; the issue is whether the NS >> >must be *registered*. That is, if the NS's IP address can be found >> >through normal lookup, then there is no need to register it. >> >> If you are the authoritative registry for a TLD and you don't have >> the IP address of a name server within your TLD, how can the NS's IP >> address possibly be found through a "normal lookup"? > >You are mixing some things. Kent catched the sentence. No I'm not. You're arguing against a requirement that doesn't exist. The requirements document says that IP addresses have to be present for name servers within the TLD, it doesn't contemplate whether they have to exist for name servers within the SLD. >We do not speak of "IP address of a name server within your TLD" but >rather of the name server of the SLD. > >There is no need to register the name server for an *SLD* (name and IP), >if the name server IS NOT in the new created SLD. Regardingless, in which >TLD the SLD is. In contrast, it is dangerous, because you have two places >for the same information (in real DNS and in the host handle). And this >two places are often out of sync :-( > >I never understand the sense of the NSI requirements and the need for host >handles. In Germany, we have more then 4,000,000 DE-domains, we only >require the IP of the DNS, if the DNS is in the domain (eg. DNS >"ns3.knipp.de" is responsible for the domain "knipp.de"). Within your registry, you can deal with this however you want. If you want to create a new name server object each and every time a name server is used, that's up to you. Personally, I think that's pretty inefficient. However, if someone specifies the name server "ns3.knipp.de", and the name server "ns3.knipp.de" does not exist within the .DE registry, that's a problem. You should be handing out glue records for name servers within your TLD. Taking your argument to an extreme, it's possible to have a situation in which xxx.de has the name servers ns1.yyy.de and ns2.yyy.de, with no IP address information. yyy.de could have the name servers ns1.xxx.de and ns2.xxx.de, with no IP address information. In that scenario, both xxx.de and yyy.de are broken. If you require that all .de name servers have IP addresses associated with them, that can't happen. Jordyn -- Jordyn A. Buchanan jordyn@register.com Futurist +1.212.798.9262 Register.com http://www.register.com/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36H2XwX013854 for ietf-provreg-outgoing; Fri, 6 Apr 2001 19:02:33 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36H2WLt013849 for ; Fri, 6 Apr 2001 19:02:32 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA24053; Fri, 6 Apr 2001 13:02:30 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0A84>; Fri, 6 Apr 2001 12:56:01 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Peter Eisenhauer'" Cc: ietf-provreg@cafax.se Subject: RE: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 12:55:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Peter Eisenhauer [mailto:eisenhauer@schlund.de] >Sent: Friday, April 06, 2001 9:56 AM >To: Bill Manning >Cc: ietf-provreg@cafax.se >Subject: Re: Nameserver MUST HAVE IP > > >There is no need to register *all* name servers with ip addresses. >e.g. think of a registry for .tld with 2 Domains: > >foo.tld with name servers ns1.foo.tld and ns2.foo.tld -- these >name servers >MUST be registered with ip addresses in the registry. > >bar.tld with nameservers ns3.foo.tld, ns4.foo.tld -- there is >no need that >the ip addresses of these name servers must be in the *registry*. > >In this model ip addresses for name servers in the registry >are only needed for "real" glue records. After playing around with some NS and A records I understand what Peter is saying, and he has a point -- the addresses aren't required in the TLD zone, and some name server software packages may either drop the extraneous glue records or refuse to load the zone if they exist. This does appear to be a good reason to change the "MUST" to a "SHOULD" as originally suggested. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36Ga87g013694 for ietf-provreg-outgoing; Fri, 6 Apr 2001 18:36:08 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36Ga7Lt013689 for ; Fri, 6 Apr 2001 18:36:07 +0200 (MEST) Received: from localhost (elmar@localhost) by hp9000.do.knipp.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id SAA10870; Fri, 6 Apr 2001 18:35:51 +0200 (METDST) X-Authentication-Warning: hp9000.do.knipp.de: elmar owned process doing -bs Date: Fri, 6 Apr 2001 18:35:51 +0200 (METDST) From: Elmar Knipp X-X-Sender: To: "Jordyn A. Buchanan" cc: Kent Crispin , Subject: Re: Nameserver MUST HAVE IP In-Reply-To: Message-ID: X-Ncc-RegID: de.knipp MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 6 Apr 2001, Jordyn A. Buchanan wrote: > At 8:39 AM -0700 4/6/01, Kent Crispin wrote: > >That is not what was said, if I understand correctly. The issue is not > >whether the nameserver has an IP address; the issue is whether the NS > >must be *registered*. That is, if the NS's IP address can be found > >through normal lookup, then there is no need to register it. > > If you are the authoritative registry for a TLD and you don't have > the IP address of a name server within your TLD, how can the NS's IP > address possibly be found through a "normal lookup"? You are mixing some things. Kent catched the sentence. We do not speak of "IP address of a name server within your TLD" but rather of the name server of the SLD. There is no need to register the name server for an *SLD* (name and IP), if the name server IS NOT in the new created SLD. Regardingless, in which TLD the SLD is. In contrast, it is dangerous, because you have two places for the same information (in real DNS and in the host handle). And this two places are often out of sync :-( I never understand the sense of the NSI requirements and the need for host handles. In Germany, we have more then 4,000,000 DE-domains, we only require the IP of the DNS, if the DNS is in the domain (eg. DNS "ns3.knipp.de" is responsible for the domain "knipp.de"). Regards, Elmar -- _____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Fon: +49 231 9703-0 Elmar.Knipp@knipp.de Fax: +49 231 9703-200 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36G7BhB013470 for ietf-provreg-outgoing; Fri, 6 Apr 2001 18:07:11 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36G7ALt013462 for ; Fri, 6 Apr 2001 18:07:10 +0200 (MEST) Received: from [10.10.20.173] (helo=[10.10.20.173]) by rcommail2 with esmtp (Exim 3.16 #2) id 14lYkU-0001Fy-00; Fri, 06 Apr 2001 12:06:10 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <20010406083941.A26703@songbird.com> References: <20010406151807.A3116@tornado.schlund.de> <20010406083941.A26703@songbird.com> Date: Fri, 6 Apr 2001 12:06:19 -0400 To: Kent Crispin , ietf-provreg@cafax.se From: "Jordyn A. Buchanan" Subject: Re: Nameserver MUST HAVE IP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 8:39 AM -0700 4/6/01, Kent Crispin wrote: >On Fri, Apr 06, 2001 at 09:55:57AM -0400, Jordyn A. Buchanan wrote: >> At 3:18 PM +0200 4/6/01, Peter Eisenhauer wrote: >> >draft-ietf-provreg-grrp-reqs-01.txt: >> > "Name servers registered within the registry's authoritative TLDs MUST >> > be registered with a valid IPv4 or IPv6 address." >> > >> >I think this should be registry policy, not protocol requirement. >> >There are models in which IPs are not needed for *all* name >>servers inside the >> >registry. The "MUST" excludes these solutions. >> >> Could you cite such an example? Name servers are hard to use if they >> have no IP address. > >That is not what was said, if I understand correctly. The issue is not >whether the nameserver has an IP address; the issue is whether the NS >must be *registered*. That is, if the NS's IP address can be found >through normal lookup, then there is no need to register it. If you are the authoritative registry for a TLD and you don't have the IP address of a name server within your TLD, how can the NS's IP address possibly be found through a "normal lookup"? The IP address is only a required element for name servers within the registry's authoritative TLDs. For nameservers within other TLDs, they are not required (indeed, I think they're prohibited). Jordyn -- Jordyn A. Buchanan jordyn@register.com Futurist +1.212.798.9262 Register.com http://www.register.com/ Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36FpbYP013369 for ietf-provreg-outgoing; Fri, 6 Apr 2001 17:51:37 +0200 (MEST) Received: from bywater.songbird.com (bywater.songbird.com [206.14.4.2]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36FpZLt013364 for ; Fri, 6 Apr 2001 17:51:36 +0200 (MEST) Received: (from kent@localhost) by bywater.songbird.com (8.9.1a/8.9.1) id IAA26872 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 08:39:42 -0700 Message-ID: <20010406083941.A26703@songbird.com> Date: Fri, 6 Apr 2001 08:39:41 -0700 From: Kent Crispin To: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Mail-Followup-To: ietf-provreg@cafax.se References: <20010406151807.A3116@tornado.schlund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Jordyn A. Buchanan on Fri, Apr 06, 2001 at 09:55:57AM -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Apr 06, 2001 at 09:55:57AM -0400, Jordyn A. Buchanan wrote: > At 3:18 PM +0200 4/6/01, Peter Eisenhauer wrote: > >draft-ietf-provreg-grrp-reqs-01.txt: > > "Name servers registered within the registry's authoritative TLDs MUST > > be registered with a valid IPv4 or IPv6 address." > > > >I think this should be registry policy, not protocol requirement. > >There are models in which IPs are not needed for *all* name servers inside the > >registry. The "MUST" excludes these solutions. > > Could you cite such an example? Name servers are hard to use if they > have no IP address. That is not what was said, if I understand correctly. The issue is not whether the nameserver has an IP address; the issue is whether the NS must be *registered*. That is, if the NS's IP address can be found through normal lookup, then there is no need to register it. Requiring NSs to be registered may reduce the number of lame delegations, but that really isn't clear. It does require maintenance of addresses in two places, which is a source of inconsistency. In any case, I agree that it shouldn't be a protocol requirement -- presuming that I actually understand what's being discussed, of course -- if I don't, let me down gently. -- Kent Crispin "Be good, and you will be kent@songbird.com lonesome." -- Mark Twain Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36FGowi013207 for ietf-provreg-outgoing; Fri, 6 Apr 2001 17:16:50 +0200 (MEST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36FGmLt013202 for ; Fri, 6 Apr 2001 17:16:49 +0200 (MEST) Received: from w2000 (unknown [203.121.81.78]) by mail.i-dns.net (Postfix) with SMTP id 966EEFFC0E for ; Fri, 6 Apr 2001 23:20:06 +0800 (SGT) Message-ID: <006e01c0beac$139f1920$0100a8c0@dready.org> From: "William Tan" To: References: <20010406151807.A3116@tornado.schlund.de> <200104061343.f36DhnW01136@zed.isi.edu> <20010406155552.A3288@tornado.schlund.de> Subject: Re: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 23:13:01 +0800 Organization: i-DNS.net Internation Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > bar.tld with nameservers ns3.foo.tld, ns4.foo.tld -- there is no need that > the ip addresses of these name servers must be in the *registry*. But "ns3.foo.tld" and "ns4.foo.tld" must be registered by foo.tld. bar.tld does not register the nameservers, but merely use them. wil Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36ERbIZ012920 for ietf-provreg-outgoing; Fri, 6 Apr 2001 16:27:37 +0200 (MEST) Received: from spider.nic-se.se (spider.nic-se.se [212.247.3.67]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36ERaLt012915 for ; Fri, 6 Apr 2001 16:27:36 +0200 (MEST) Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id f36ERWQ25456; Fri, 6 Apr 2001 16:27:32 +0200 (CEST) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Fri, 6 Apr 2001 16:27:32 +0200 (CEST) From: Mats Dufberg To: Peter Eisenhauer cc: Subject: Re: Nameserver MUST HAVE IP In-Reply-To: <20010406160709.A3308@tornado.schlund.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, 6 Apr 2001, Peter Eisenhauer wrote: > So name servers in the registry with "real" glue records (don't like the term > either) must be registered with ip addresses, the others could be handled like > name server outside the registry. > > Then of course there must be checks, if the "glue" condition is valid if a > nameserver is registered or if a domain is updated... The SE zone successfully uses the above model. No update is possible without glue if glue is needed. Any glue not needed is discarded. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36E7BoX012801 for ietf-provreg-outgoing; Fri, 6 Apr 2001 16:07:11 +0200 (MEST) Received: from mout03.kundenserver.de (mout03.kundenserver.de [195.20.224.218]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36E7ALt012796 for ; Fri, 6 Apr 2001 16:07:11 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout03.kundenserver.de with esmtp (Exim 2.12 #2) id 14lWtI-0002gh-00; Fri, 6 Apr 2001 16:07:08 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14lWtM-0003HN-00; Fri, 6 Apr 2001 16:07:12 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f36E79l03358; Fri, 6 Apr 2001 16:07:09 +0200 Date: Fri, 6 Apr 2001 16:07:09 +0200 From: Peter Eisenhauer To: "Hollenbeck, Scott" Cc: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010406160709.A3308@tornado.schlund.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from shollenbeck@verisign.com on Fri, Apr 06, 2001 at 09:33:57AM -0400 Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk See my previous posting with the example. So name servers in the registry with "real" glue records (don't like the term either) must be registered with ip addresses, the others could be handled like name server outside the registry. Then of course there must be checks, if the "glue" condition is valid if a nameserver is registered or if a domain is updated... I think the "Nameserver MUST be registered with ip address" is just too strong for a generic requirement. On Fri, Apr 06, 2001 at 09:33:57AM -0400, Hollenbeck, Scott wrote: > >-----Original Message----- > >From: Peter Eisenhauer [mailto:eisenhauer@schlund.de] > >Sent: Friday, April 06, 2001 9:18 AM > >To: ietf-provreg@cafax.se > >Subject: Nameserver MUST HAVE IP > > > > > >draft-ietf-provreg-grrp-reqs-01.txt: > > "Name servers registered within the registry's authoritative TLDs MUST > > be registered with a valid IPv4 or IPv6 address." > > > >I think this should be registry policy, not protocol requirement. > >There are models in which IPs are not needed for *all* name > >servers inside the registry. The "MUST" excludes these solutions. > > Could you provide an example of such a model and how it works? I agree that > it's not necessary for _all_ name servers to be registered with an address > or addresses (such as when dealing with a name server from a > non-authoritative TLD; the requirements deal with this situation), but I'd > like to understand if you're suggesting that it should be OK to allow > registration of ns1.foo.tld without addresses in the .tld registry, and what > the .tld registry does with such a server. > > Mit freundlichen Gruessen, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36Du3rc012716 for ietf-provreg-outgoing; Fri, 6 Apr 2001 15:56:03 +0200 (MEST) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36Du2Lt012711 for ; Fri, 6 Apr 2001 15:56:02 +0200 (MEST) Received: from [10.10.20.173] (helo=[172.16.1.59]) by rcommail2 with esmtp (Exim 3.16 #2) id 14lWiK-0004cZ-00; Fri, 06 Apr 2001 09:55:48 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <20010406151807.A3116@tornado.schlund.de> References: <20010406151807.A3116@tornado.schlund.de> Date: Fri, 6 Apr 2001 09:55:57 -0400 To: Peter Eisenhauer , ietf-provreg@cafax.se From: "Jordyn A. Buchanan" Subject: Re: Nameserver MUST HAVE IP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 3:18 PM +0200 4/6/01, Peter Eisenhauer wrote: >draft-ietf-provreg-grrp-reqs-01.txt: > "Name servers registered within the registry's authoritative TLDs MUST > be registered with a valid IPv4 or IPv6 address." > >I think this should be registry policy, not protocol requirement. >There are models in which IPs are not needed for *all* name servers inside the >registry. The "MUST" excludes these solutions. Could you cite such an example? Name servers are hard to use if they have no IP address. Jordyn Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36DtsJE012705 for ietf-provreg-outgoing; Fri, 6 Apr 2001 15:55:54 +0200 (MEST) Received: from mout01.kundenserver.de (mout01.kundenserver.de [195.20.224.132]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36DtrLt012700 for ; Fri, 6 Apr 2001 15:55:54 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout01.kundenserver.de with esmtp (Exim 2.12 #2) id 14lWiP-000126-00; Fri, 6 Apr 2001 15:55:53 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14lWiR-0002sl-00; Fri, 6 Apr 2001 15:55:55 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f36Dtqs03301; Fri, 6 Apr 2001 15:55:52 +0200 Date: Fri, 6 Apr 2001 15:55:52 +0200 From: Peter Eisenhauer To: Bill Manning Cc: ietf-provreg@cafax.se Subject: Re: Nameserver MUST HAVE IP Message-ID: <20010406155552.A3288@tornado.schlund.de> References: <20010406151807.A3116@tornado.schlund.de> <200104061343.f36DhnW01136@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200104061343.f36DhnW01136@zed.isi.edu>; from bmanning@ISI.EDU on Fri, Apr 06, 2001 at 06:43:49AM -0700 Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk There is no need to register *all* name servers with ip addresses. e.g. think of a registry for .tld with 2 Domains: foo.tld with name servers ns1.foo.tld and ns2.foo.tld -- these name servers MUST be registered with ip addresses in the registry. bar.tld with nameservers ns3.foo.tld, ns4.foo.tld -- there is no need that the ip addresses of these name servers must be in the *registry*. In this model ip addresses for name servers in the registry are only needed for "real" glue records. On Fri, Apr 06, 2001 at 06:43:49AM -0700, Bill Manning wrote: > % > % draft-ietf-provreg-grrp-reqs-01.txt: > % "Name servers registered within the registry's authoritative TLDs MUST > % be registered with a valid IPv4 or IPv6 address." > % > % I think this should be registry policy, not protocol requirement. > % There are models in which IPs are not needed for *all* name servers inside the > % registry. The "MUST" excludes these solutions. > % > > I am intriged. Please elaborate one model where an IP is not needed for a > nameserver. > > -- > --bill Mit freundlichen Gruessen, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36DhqeW012620 for ietf-provreg-outgoing; Fri, 6 Apr 2001 15:43:52 +0200 (MEST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36DhoLt012615 for ; Fri, 6 Apr 2001 15:43:51 +0200 (MEST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f36Dhnq11485; Fri, 6 Apr 2001 06:43:49 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f36DhnW01136; Fri, 6 Apr 2001 06:43:49 -0700 Message-Id: <200104061343.f36DhnW01136@zed.isi.edu> Subject: Re: Nameserver MUST HAVE IP To: eisenhauer@schlund.de (Peter Eisenhauer) Date: Fri, 6 Apr 2001 06:43:49 -0700 (PDT) Cc: ietf-provreg@cafax.se In-Reply-To: <20010406151807.A3116@tornado.schlund.de> from "Peter Eisenhauer" at Apr 06, 2001 03:18:07 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk % % draft-ietf-provreg-grrp-reqs-01.txt: % "Name servers registered within the registry's authoritative TLDs MUST % be registered with a valid IPv4 or IPv6 address." % % I think this should be registry policy, not protocol requirement. % There are models in which IPs are not needed for *all* name servers inside the % registry. The "MUST" excludes these solutions. % I am intriged. Please elaborate one model where an IP is not needed for a nameserver. -- --bill Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36DeaGp012606 for ietf-provreg-outgoing; Fri, 6 Apr 2001 15:40:36 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36DeYLt012601 for ; Fri, 6 Apr 2001 15:40:35 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA23095; Fri, 6 Apr 2001 09:40:31 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F0AWM>; Fri, 6 Apr 2001 09:34:03 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Peter Eisenhauer'" , ietf-provreg@cafax.se Subject: RE: Nameserver MUST HAVE IP Date: Fri, 6 Apr 2001 09:33:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Peter Eisenhauer [mailto:eisenhauer@schlund.de] >Sent: Friday, April 06, 2001 9:18 AM >To: ietf-provreg@cafax.se >Subject: Nameserver MUST HAVE IP > > >draft-ietf-provreg-grrp-reqs-01.txt: > "Name servers registered within the registry's authoritative TLDs MUST > be registered with a valid IPv4 or IPv6 address." > >I think this should be registry policy, not protocol requirement. >There are models in which IPs are not needed for *all* name >servers inside the registry. The "MUST" excludes these solutions. Could you provide an example of such a model and how it works? I agree that it's not necessary for _all_ name servers to be registered with an address or addresses (such as when dealing with a name server from a non-authoritative TLD; the requirements deal with this situation), but I'd like to understand if you're suggesting that it should be OK to allow registration of ns1.foo.tld without addresses in the .tld registry, and what the .tld registry does with such a server. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f36DI9eN012464 for ietf-provreg-outgoing; Fri, 6 Apr 2001 15:18:09 +0200 (MEST) Received: from mout02.kundenserver.de (mout02.kundenserver.de [195.20.224.133]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f36DI8Lt012459 for ; Fri, 6 Apr 2001 15:18:08 +0200 (MEST) Received: from [195.20.224.148] (helo=mxintern.kundenserver.de) by mout02.kundenserver.de with esmtp (Exim 2.12 #2) id 14lW7r-0006W9-00 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 15:18:07 +0200 Received: from [172.17.0.61] (helo=tornado.schlund.de) by mxintern.kundenserver.de with esmtp (Exim 2.12 #3) id 14lW7u-0001Hm-00 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 15:18:10 +0200 Received: (from eisen@localhost) by tornado.schlund.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f36DI7K03159 for ietf-provreg@cafax.se; Fri, 6 Apr 2001 15:18:07 +0200 Date: Fri, 6 Apr 2001 15:18:07 +0200 From: Peter Eisenhauer To: ietf-provreg@cafax.se Subject: Nameserver MUST HAVE IP Message-ID: <20010406151807.A3116@tornado.schlund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Organization: Schlund + Partner AG Sender: owner-ietf-provreg@cafax.se Precedence: bulk draft-ietf-provreg-grrp-reqs-01.txt: "Name servers registered within the registry's authoritative TLDs MUST be registered with a valid IPv4 or IPv6 address." I think this should be registry policy, not protocol requirement. There are models in which IPs are not needed for *all* name servers inside the registry. The "MUST" excludes these solutions. Best Regards, Peter Eisenhauer -- Peter Eisenhauer Schlund + Partner AG Erbprinzenstrasse 4-12 Tel: 0721/91374-0 76133 Karlsruhe E-Mail: eisenhauer@schlund.de Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f364Vxhf010064 for ietf-provreg-outgoing; Fri, 6 Apr 2001 06:31:59 +0200 (MEST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f364VuLt010059 for ; Fri, 6 Apr 2001 06:31:57 +0200 (MEST) Received: from w2000 (unknown [203.121.53.19]) by mail.i-dns.net (Postfix) with SMTP id 92EBAFFC10 for ; Fri, 6 Apr 2001 12:35:13 +0800 (SGT) Message-ID: <004001c0be51$fc984580$0100a8c0@dready.org> From: "William Tan" To: Subject: multiple copies Date: Fri, 6 Apr 2001 12:28:09 +0800 Organization: i-DNS.net Internation Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, I've been getting copies of the recent discussions on this mailing list. I wonder if this is something to do with the MLM on cafax.se, and if anyone has same problem? wil Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f35B7vCp004606 for ietf-provreg-outgoing; Thu, 5 Apr 2001 13:07:57 +0200 (MEST) Received: from heron.verisign.com ([216.168.233.95]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f35B7tLt004601 for ; Thu, 5 Apr 2001 13:07:56 +0200 (MEST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA19970; Thu, 5 Apr 2001 07:06:49 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F900D>; Thu, 5 Apr 2001 07:00:22 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" , "Paul M. Kane" Cc: Edward Lewis , ietf-provreg@cafax.se Subject: RE: [cctld-tech] Re: Generic Registry Registrar Protocol requirem ents Date: Thu, 5 Apr 2001 07:00:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-provreg@cafax.se Precedence: bulk >-----Original Message----- >From: Jaap Akkerhuis [mailto:jaap@sidn.nl] >Sent: Thursday, April 05, 2001 5:07 AM >To: Paul M. Kane >Cc: Hollenbeck, Scott; Edward Lewis; ietf-provreg@cafax.se >Subject: Re: [cctld-tech] Re: Generic Registry Registrar Protocol >requirements > > > >Hi Paul, > >First some administrativia: I announced this last call to various >mailinglists, with the intention that people should again be aware >of the work taking place at the provreg mailinglist. But it wasn't >my intention that the discussion should take place on the various >lists but should be contained on the ietf-provreg mailing list >only. Therefore, I bounced your message to this mailing list AND >took the liberty to subscribe you to the list as well. Furthermore, >I removed the cc's to the other mailing lists (tech@lists.centr.org, >dnr-forum@lists.centr.org & cctld-tech@wwtld.org) in this message. > > Hi Scott, > > This spec does not contain the framework of individual contact > identification. Why is it missing? > > When a registrar causes a serious trouble, the registry does > not have a way to identify a registrant... suggestions?? > >The draft doesn't specify it explicitly but it can be included in >the ``social data'' (it is a MAY, but I citate from memory so I >might have this detail wrong). It is up to the registry enforce >this data. Maybe I'm misunderstanding the question, but the draft has very clear requirements for contact identification, see 3.4.2-[6] where the more generic term "social data" is used to describe what is commonly referred to as a "contact". 3.4.3-[3] describes a requirement for associating "social data", such as registrant information, with other objects such as domain names. > For registries based in Europe, EU directive 95/46/EC, says > "data subjects (registrants) must have the ability to inspect > and modify information (including its deletion) directly with > the Data User" (registry).... This direct inspect/modify > provision is in addition to the Registrar which may be the > preferred path by many registries - suggestions?? In the ccTLDs > we operate from the UK we use passwords as a means of > identification, other registries use certificates and others > keys..... For gTLD registries based in Europe they will need > something!! > >First, to be strict, the protocol is a registry/registrar protocol, >so this is outside the scope of this particular protocol. If you >want to do allow this, one needs a registry/registrant protocol. > >Furthermore, after consultation with Bart Boswinkel, we (Bart & I) >came to the conclusion that this EU directive can be interpret on >in various ways and not necessarily dictates a direct >registry/registrant >relation. Jaap's interpretation is correct, but I'd also like to suggest that a registry may choose to allow direct access by registrants. There aren't any requirements that preclude this, and in fact the protocol documents that I've been working on don't use the terms "registry", "registrar", or "registrant" at all -- the parties are known as "client" and "server", and the definition of client is a matter of local policy. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3596wRB023395 for ietf-provreg-outgoing; Thu, 5 Apr 2001 11:06:58 +0200 (MEST) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3596vLt023390 for ; Thu, 5 Apr 2001 11:06:58 +0200 (MEST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id LAA51913; Thu, 5 Apr 2001 11:06:57 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.3/8.11.2) with ESMTP id f3596vK03260; Thu, 5 Apr 2001 11:06:57 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200104050906.f3596vK03260@bartok.sidn.nl> To: "Paul M. Kane" cc: "Hollenbeck, Scott" , Edward Lewis , ietf-provreg@cafax.se Subject: Re: [cctld-tech] Re: Generic Registry Registrar Protocol requirements In-reply-to: Your message of Thu, 05 Apr 2001 08:05:22 +0100. <3ACC1932.954BED5D@REACTO.com> Date: Thu, 05 Apr 2001 11:06:57 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Paul, First some administrativia: I announced this last call to various mailinglists, with the intention that people should again be aware of the work taking place at the provreg mailinglist. But it wasn't my intention that the discussion should take place on the various lists but should be contained on the ietf-provreg mailing list only. Therefore, I bounced your message to this mailing list AND took the liberty to subscribe you to the list as well. Furthermore, I removed the cc's to the other mailing lists (tech@lists.centr.org, dnr-forum@lists.centr.org & cctld-tech@wwtld.org) in this message. Hi Scott, This spec does not contain the framework of individual contact identification. Why is it missing? When a registrar causes a serious trouble, the registry does not have a way to identify a registrant... suggestions?? The draft doesn't specify it explicitly but it can be included in the ``social data'' (it is a MAY, but I citate from memory so I might have this detail wrong). It is up to the registry enforce this data. For registries based in Europe, EU directive 95/46/EC, says "data subjects (registrants) must have the ability to inspect and modify information (including its deletion) directly with the Data User" (registry).... This direct inspect/modify provision is in addition to the Registrar which may be the preferred path by many registries - suggestions?? In the ccTLDs we operate from the UK we use passwords as a means of identification, other registries use certificates and others keys..... For gTLD registries based in Europe they will need something!! First, to be strict, the protocol is a registry/registrar protocol, so this is outside the scope of this particular protocol. If you want to do allow this, one needs a registry/registrant protocol. Furthermore, after consultation with Bart Boswinkel, we (Bart & I) came to the conclusion that this EU directive can be interpret on in various ways and not necessarily dictates a direct registry/registrant relation. jaap Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f358ucaJ023326 for ietf-provreg-outgoing; Thu, 5 Apr 2001 10:56:38 +0200 (MEST) Received: from astrid1.nic.fr (astrid1.nic.fr [192.134.4.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f358ubLt023321 for ; Thu, 5 Apr 2001 10:56:37 +0200 (MEST) Received: from james.nic.fr (IDENT:root@james.nic.fr [192.134.4.83]) by astrid1.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id KAA25808 ; Thu, 5 Apr 2001 10:56:22 +0200 (MET DST) Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id f358uMQ12471; Thu, 5 Apr 2001 10:56:22 +0200 Date: Thu, 5 Apr 2001 10:56:22 +0200 From: Olivier Guillard To: "Paul M. Kane" Cc: "Hollenbeck, Scott" , Edward Lewis , ietf-provreg@cafax.se, jaap@sidn.nl, tech@lists.centr.org, dnr-forum@lists.centr.org, cctld-tech@wwtld.org Subject: Re: Generic Registry Registrar Protocol requirements Message-ID: <20010405105622.A11694@james.nic.fr> References: <3ACC1932.954BED5D@REACTO.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3ACC1932.954BED5D@REACTO.com>; from Paul.Kane@REACTO.com on Thu, Apr 05, 2001 at 08:05:22AM +0100 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Scott, This spec does not contain the framework of individual contact identification. Why is it missing? When a registrar causes a serious trouble, the registry does not have a way to identify a registrant... suggestions?? For registries based in Europe, EU directive 95/46/EC, says "data subjects (registrants) must have the ability to inspect and modify information (including its deletion) directly with the Data User" (registry).... This direct inspect/modify provision is in addition to the Registrar which may be the preferred path by many registries - suggestions?? In the ccTLDs we operate from the UK we use passwords as a means of identification, other registries use certificates and others keys..... For gTLD registries based in Europe they will need something!! Best Olivier Paul Kane, le jeudi 05 avril à écrit: >Hi Scott, > >This spec does not contain the framework of individual contact identification. >Why is it missing? > >When a registrar causes a serious trouble, the registry does not have a way to >identify a registrant... suggestions?? > >For registries based in Europe, EU directive 95/46/EC, says "data subjects >(registrants) must have the ability to inspect and modify information >(including its deletion) directly with the Data User" (registry).... This >direct inspect/modify provision is in addition to the Registrar which may be >the preferred path by many registries - suggestions?? >In the ccTLDs we operate from the UK we use passwords as a means of >identification, other registries use certificates and others keys..... For gTLD >registries based in Europe they will need something!! > >Best > >Paul > > Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f358HGY2023167 for ietf-provreg-outgoing; Thu, 5 Apr 2001 10:17:16 +0200 (MEST) Received: from bureau.sidn.nl (bureau.sidn.nl [193.176.144.162]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f358HFLt023162 for ; Thu, 5 Apr 2001 10:17:15 +0200 (MEST) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by bureau.sidn.nl (8.9.3/8.9.3) with ESMTP id KAA51549 for ; Thu, 5 Apr 2001 10:17:14 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.11.3/8.11.2) id f358HEo03083 for ietf-provreg@cafax.se; Thu, 5 Apr 2001 10:17:14 +0200 (CEST) (envelope-from jaap) Received: from mailer.ac (mailer.io [194.205.62.101]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3577ELt022764 for ; Thu, 5 Apr 2001 09:07:14 +0200 (MEST) Received: from REACTO.com ([194.205.62.97]) by mailer.ac (8.9.3/8.9.0) with ESMTP id IAA12072; Thu, 5 Apr 2001 08:07:06 +0100 Message-ID: <3ACC1932.954BED5D@REACTO.com> Date: Thu, 05 Apr 2001 08:05:22 +0100 From: "Paul M. Kane" Organization: REACTO.com X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: Edward Lewis , ietf-provreg@cafax.se, jaap@sidn.nl, tech@lists.centr.org, dnr-forum@lists.centr.org, cctld-tech@wwtld.org Subject: Re: Generic Registry Registrar Protocol requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Scott, This spec does not contain the framework of individual contact identification. Why is it missing? When a registrar causes a serious trouble, the registry does not have a way to identify a registrant... suggestions?? For registries based in Europe, EU directive 95/46/EC, says "data subjects (registrants) must have the ability to inspect and modify information (including its deletion) directly with the Data User" (registry).... This direct inspect/modify provision is in addition to the Registrar which may be the preferred path by many registries - suggestions?? In the ccTLDs we operate from the UK we use passwords as a means of identification, other registries use certificates and others keys..... For gTLD registries based in Europe they will need something!! Best Paul Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f34HA4xt018852 for ietf-provreg-outgoing; Wed, 4 Apr 2001 19:10:04 +0200 (MEST) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f34HA2Lt018847 for ; Wed, 4 Apr 2001 19:10:03 +0200 (MEST) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id RAA02086; Wed, 4 Apr 2001 17:10:00 GMT From: "Brian W. Spolarich" To: "Edward Lewis" Cc: Subject: RE: Provreg WG Last Call announcement Date: Wed, 4 Apr 2001 13:11:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk I'm aware of the process. I was being somewhat facetious. :-) -bws Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f34Gkql6018690 for ietf-provreg-outgoing; Wed, 4 Apr 2001 18:46:52 +0200 (MEST) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f34GkpLt018685 for ; Wed, 4 Apr 2001 18:46:51 +0200 (MEST) Received: by sentry.gw.tislabs.com; id MAA01511; Wed, 4 Apr 2001 12:50:24 -0400 (EDT) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001501; Wed, 4 Apr 01 12:49:41 -0400 X-Sender: lewis@64.214.53.125 Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Apr 2001 12:32:03 -0400 To: "Brian W. Spolarich" From: Edward Lewis Subject: RE: Provreg WG Last Call announcement Cc: "Edward Lewis" , , Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yes, in the terms that an RFC itself can't be edited. However, an RFC isn't (necessarily) the final word on a topic. So - once this document becomes an RFC, you can't comment on "it." But you can comment on the need to replace it later on. A little more clarification - a "standards track document" can ascend three levels - draft, proposed, and full. Each level has more stringent requirements. Also there is an STD series, which are RFC's that are "standards." The requirements document will likely be an informational document, which isn't standards track. See RFC 2026 for more details - a link to it is on the IETF home page. At 9:40 AM -0400 4/4/01, Brian W. Spolarich wrote: > >| It is important to note that it is never too late to comment on a >| document, even when a last call expires. (Well, once the document >| is an RFC, it is too late!) > > Really? RFC != Request For Comments? :-) > > -bws -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f34DcODQ017498 for ietf-provreg-outgoing; Wed, 4 Apr 2001 15:38:24 +0200 (MEST) Received: from admin1.corp.walid.com ([152.160.20.25]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f34DcMLt017493 for ; Wed, 4 Apr 2001 15:38:23 +0200 (MEST) Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id NAA29975; Wed, 4 Apr 2001 13:38:20 GMT From: "Brian W. Spolarich" To: "Edward Lewis" , Cc: Subject: RE: Provreg WG Last Call announcement Date: Wed, 4 Apr 2001 09:40:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-provreg@cafax.se Precedence: bulk | It is important to note that it is never too late to comment on a | document, even when a last call expires. (Well, once the document | is an RFC, it is too late!) Really? RFC != Request For Comments? :-) -bws Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f344w5BQ010873 for ietf-provreg-outgoing; Wed, 4 Apr 2001 06:58:05 +0200 (MEST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f344w4iM010868 for ; Wed, 4 Apr 2001 06:58:05 +0200 (MEST) Received: from [192.168.1.29] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id GAA20943; Wed, 4 Apr 2001 06:57:47 +0200 (MET DST) Date: Wed, 04 Apr 2001 06:57:37 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , Kent Crispin , ietf-provreg@cafax.se Subject: Re: HTTP Transport? (was: Re: Security Design Team) Message-ID: <6644546.986367457@[192.168.1.29]> In-Reply-To: <5.0.2.1.2.20010403213147.027eb450@127.0.0.1> References: <001701c0b611$d33d19b0$0200000a@maynardibm> <002001c0b5f9$3b92bb50$0100a8c0@dready.org> <005601c0b606$0098d950$0200000a@maynardibm> <001001c0b60b$014553b0$0100a8c0@dready.org> <001701c0b611$d33d19b0$0200000a@maynardibm> <5.0.2.1.2.20010403213147.027eb450@127.0.0.1> X-Mailer: Mulberry/2.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-provreg@cafax.se Precedence: bulk --On tisdag 3 april 2001 21.35 -0400 Richard Shockey wrote: > For the last time ...this list really needs understand that we will never > be permitted to use HTTP OK ..get it ..the IESG has made its statements > on this quite clear. Out of bounds out of scope...see IPP for further > information. IFF this wg want to use the HTTP syntax and protocol (which is not easy, just read HTTP/1.1 and see that you understand binary transport and chunking) and not something else, it is the case that the protocol have to be on a separate port number (not 80), and the wg further have to explain why the HTTP transport protocol is a more efficient transport mechanism than other transport mechanisms available. Note that I didn't write anything about "ability to pass firewall" or "already implemented". We develop a protocol which go between two endpoints, and not an API which you are to use. And, yes, as Richard says, the IESG is very nervous about reuse of protocols without a detailed description of issues like congestion (yes, if you reuse one protocol for a different use than what was intended, you get completely different characteristics on the IP layer) and routing (routing is something which should be handled on the lower layers, while application layer is point to point). That said, HTTP is reused in some protocols, like IPP, so I am not saying that HTTP is not reusable. Handwaving is though not enough as an argument. Patrik Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f3423DVm010453 for ietf-provreg-outgoing; Wed, 4 Apr 2001 04:03:13 +0200 (MEST) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f3423CiM010448 for ; Wed, 4 Apr 2001 04:03:12 +0200 (MEST) Received: from rds.ix.netcom.com (user-2ivemhf.dialup.mindspring.com [165.247.90.47]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA09691; Tue, 3 Apr 2001 22:02:58 -0400 (EDT) Message-Id: <5.0.2.1.2.20010403213147.027eb450@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Apr 2001 21:35:50 -0400 To: Kent Crispin , ietf-provreg@cafax.se From: Richard Shockey Subject: Re: HTTP Transport? (was: Re: Security Design Team) In-Reply-To: <20010326083524.D30725@songbird.com> References: <001701c0b611$d33d19b0$0200000a@maynardibm> <002001c0b5f9$3b92bb50$0100a8c0@dready.org> <005601c0b606$0098d950$0200000a@maynardibm> <001001c0b60b$014553b0$0100a8c0@dready.org> <001701c0b611$d33d19b0$0200000a@maynardibm> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 08:35 AM 3/26/2001 -0800, Kent Crispin wrote: >On Mon, Mar 26, 2001 at 05:28:43PM +0100, Maynard Kang wrote: > > William Tan wrote: > > > I do not see any technical advantage over TCP that HTTP provides, in this > > > context anyway. > > > > > > wil. > > > > Actually I don't think you can compare TCP and HTTP just like that. They > > are transport methods at different layers (HTTP is TCP based in any case). > >But http is just being used as a transport protocol -- you will have to >implement all the protocol elements on top of it, anyway. So the >comparison with plain old tcp is probably fairly accurate. For the last time ...this list really needs understand that we will never be permitted to use HTTP OK ..get it ..the IESG has made its statements on this quite clear. Out of bounds out of scope...see IPP for further information. kent I know you are well aware of this but there are many on the list that are unaware of this limitation...it was one of the key reasons BEEP was so esthetically embraced by the the IETF. > > You'll have to compare HTTP with some "undefined or new TCP-based > > application-layer transport protocol" > >We have to do a new application-layer protocol anyway. IMHO BEEP can solve the problem and is already RFC ready. >-- >Kent Crispin "Be good, and you will be >kent@songbird.com lonesome." -- Mark Twain Please note new address: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 Voice: 202.533.2811, April 1 Voice 571.434.5651 Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f341WUvC010297 for ietf-provreg-outgoing; Wed, 4 Apr 2001 03:32:30 +0200 (MEST) Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f341WRiM010292 for ; Wed, 4 Apr 2001 03:32:27 +0200 (MEST) Received: by sentry.gw.tislabs.com; id VAA23945; Tue, 3 Apr 2001 21:36:03 -0400 (EDT) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xmaa23939; Tue, 3 Apr 01 21:35:18 -0400 X-Sender: lewis@64.214.53.125 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Apr 2001 21:31:14 -0400 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Provreg WG Last Call announcement Cc: lewis@tislabs.com, jaap@sidn.nl Sender: owner-ietf-provreg@cafax.se Precedence: bulk The provreg WG chairs are issuing a working-group (i.e., mail-list) last call for comments on the document: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt This last call for comments will expire on April 17, 2001. Please address comments to either the list or to the document author (who is on the list). For those unfamiliar with the IETF document process, this is what will happen next. In the next two weeks, comments will be taken on this document. (The assumption by the WG chairs is that the document is rather stable.) After April 17, 2001, the author will summarize all discussions mail a summary to the list. In addition, if a consensus is reached that the results of these discussions requires a change to the document, the document will be edited. (Changing the document does not require a new last call period.) After all this is finished, the document is forwarded onto the IESG for consideration. The IESG, when it is happy with the document will also issue a last call, and IETF-wide last call. It is important to note that it is never too late to comment on a document, even when a last call expires. (Well, once the document is an RFC, it is too late!) So, in the effort to promote the requirements draft to an RFC, let the last call begin. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f3366rua025515 for ietf-provreg-outgoing; Tue, 3 Apr 2001 08:06:53 +0200 (MEST) Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f3366qiM025510 for ; Tue, 3 Apr 2001 08:06:53 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f3366gmR000512 for ; Tue, 3 Apr 2001 08:06:42 +0200 (MEST) To: ietf-provreg@cafax.se Subject: New list administrator. From: Lars-Johan Liman X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010403080642V.liman@autonomica.se> Date: Tue, 03 Apr 2001 08:06:42 +0200 X-Dispatcher: imput version 990905(IM130) Lines: 14 Sender: owner-ietf-provreg@cafax.se Precedence: bulk The ietf-provreg@cafax.se has a new list administrator: Jaap Akkerhuis , who will look after "lost subscriptions and ill-fated submissions" to the list from now on. This is mainly because I'm on leave of absence from my job until the end of June and only process mail sporadically, so this should improve response time radically. Best regards, /Liman ex list administrator #---------------------------------------------------------------------- # Lars-Johan Liman ! E-mail: liman@autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f32LcFAm022792 for ietf-provreg-outgoing; Mon, 2 Apr 2001 23:38:15 +0200 (MEST) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f32LcDiM022787 for ; Mon, 2 Apr 2001 23:38:14 +0200 (MEST) Received: by sentry.gw.tislabs.com; id RAA10277; Mon, 2 Apr 2001 17:41:52 -0400 (EDT) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010268; Mon, 2 Apr 01 17:41:31 -0400 X-Sender: lewis@64.214.53.125 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Apr 2001 17:37:32 -0400 To: "'ietf-provreg@cafax.se'" From: Edward Lewis Subject: Status reports (was RE: Design teams) Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks. I've been catching up so I didn't see this until today. Instead of making comments myself, I'll use this to remind the other two groups (and you know who you are) to submit "status" real soon now. At 11:41 AM -0400 3/26/01, Hollenbeck, Scott wrote: >Here's the info from the protocol design team. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f32LODn8022674 for ietf-provreg-outgoing; Mon, 2 Apr 2001 23:24:13 +0200 (MEST) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f32LOCiM022669 for ; Mon, 2 Apr 2001 23:24:12 +0200 (MEST) Received: by sentry.gw.tislabs.com; id RAA10055; Mon, 2 Apr 2001 17:27:50 -0400 (EDT) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xmac10038; Mon, 2 Apr 01 17:27:30 -0400 X-Sender: lewis@64.214.53.125 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Apr 2001 16:40:39 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: Minutes of our Minneapolis Meetings (rough cut) Cc: ietf-provreg@cafax.se Sender: owner-ietf-provreg@cafax.se Precedence: bulk So far I've received just one comment on the minutes - by Jaap. The minutes are due to the IETF fairly soon, so speak up now if you have comments. Also, I have the slides for the protocol and transport teams, but not the security team. If they still exist, please send them to me for the proceedings. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. Return-Path: Received: by nic.cafax.se (8.12.0.Beta6/8.12.0.Beta5) id f32BHQVT018662 for ietf-provreg-outgoing; Mon, 2 Apr 2001 13:17:26 +0200 (MEST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f32BHGiM018657 for ; Mon, 2 Apr 2001 13:17:24 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00309; Mon, 2 Apr 2001 07:17:14 -0400 (EDT) Message-Id: <200104021117.HAA00309@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-provreg@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-01.txt Date: Mon, 02 Apr 2001 07:17:13 -0400 Sender: owner-ietf-provreg@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF. Title : Generic Registry-Registrar Protocol Requirements Author(s) : S. Hollenbeck Filename : draft-ietf-provreg-grrp-reqs-01.txt Pages : 25 Date : 30-Mar-01 This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-provreg-grrp-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010330135930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-provreg-grrp-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330135930.I-D@ietf.org> --OtherAccess-- --NextPart--