Subject: VeriSign Patents on Registries/Registrars and other readings
From: Rick H Wesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 30 Apr 2001 12:40:48 -0700 (PDT)

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-02.txt
Date: Mon, 30 Apr 2001 07:07:06 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 20 Apr 2001 09:51:17 -0400
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: was RE: Question about draft-hollenbeck-epp-tcp-01.txt
Cc: "'George Belotsky'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: authinfo in updates/transfers
Date: Fri, 20 Apr 2001 08:03:35 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Rick H Wesson [mailto:[email-masked]]
>Sent: Thursday, April 19, 2001 12:47 PM
>To: [email-masked]'
>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.

<Scott/>

Date: Thu, 19 Apr 2001 09:46:47 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: authinfo in updates/transfers
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Document Last Call Summary: Unresolved Items
Date: Wed, 18 Apr 2001 06:53:12 -0400
Importance: high
Sender: [email-masked]

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.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Document Last Call Summary: Resolved Items
Date: Wed, 18 Apr 2001 06:52:45 -0400
Importance: high
Sender: [email-masked]

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.

<Scott/>

Date: Tue, 17 Apr 2001 14:59:50 -0400
To: Klaus Malorny <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Issues on 3.4.9 Object Information Query
Cc: [email-masked]
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: IPv6, was: Nameserver MUST HAVE IP
Date: Tue, 17 Apr 2001 08:02:32 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Tuesday, April 17, 2001 5:57 AM
>To: [email-masked]
>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.

<Scott/>

Date: Tue, 17 Apr 2001 11:57:26 +0200
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: IPv6, was: Nameserver MUST HAVE IP
Sender: [email-masked]

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
     [email-masked]             Tel. +49 231 9703 0

Date: Tue, 17 Apr 2001 11:21:52 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "Jordyn A. Buchanan" <[email-masked]>, [email-masked]
Subject: Re: Issues on 3.4.9 Object Information Query
Sender: [email-masked]

"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.
> 
> <Scott/>

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
     [email-masked]             Tel. +49 231 9703 0

Date: Mon, 16 Apr 2001 16:44:43 -0400
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document.
Sender: [email-masked]

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:[email-masked]]
> > Sent: Friday, April 13, 2001 7:25 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]
> > 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.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>
Cc: [email-masked]
Subject: RE: A Comment on 9. [1] of the requirements document.
Date: Fri, 13 Apr 2001 22:25:40 -0400
Sender: [email-masked]

> -----Original Message-----
> From: George Belotsky [mailto:[email-masked]]
> Sent: Friday, April 13, 2001 7:25 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> 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.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>, [email-masked]
Subject: RE: Question about draft-hollenbeck-epp-tcp-01.txt
Date: Fri, 13 Apr 2001 22:05:16 -0400
Sender: [email-masked]

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.

<Scott/> 

> -----Original Message-----
> From: George Belotsky [mailto:[email-masked]]
> Sent: Friday, April 13, 2001 4:09 PM
> To: [email-masked]
> 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 <epp> element..."
> 
> Should we drop 'OPTIONAL' (and just keep 'RECOMMENDED')?  The two
> mean different things according to RFC 2119.

Date: Fri, 13 Apr 2001 19:24:30 -0400
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document.
Sender: [email-masked]

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:[email-masked]]
> > Sent: Friday, April 13, 2001 3:01 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]
> > 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.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>
Cc: [email-masked]
Subject: RE: A Comment on 9. [1] of the requirements document.
Date: Fri, 13 Apr 2001 18:05:48 -0400
Sender: [email-masked]

> -----Original Message-----
> From: George Belotsky [mailto:[email-masked]]
> Sent: Friday, April 13, 2001 3:01 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> 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.

<Scott/>

To: George Belotsky <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document. 
Date: Fri, 13 Apr 2001 17:07:16 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 13 Apr 2001 16:36:48 -0400
From: George Belotsky <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document.
Sender: [email-masked]

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.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

To: George Belotsky <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document. 
Date: Fri, 13 Apr 2001 16:22:36 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

Date: Fri, 13 Apr 2001 16:09:09 -0400
From: George Belotsky <[email-masked]>
To: [email-masked]
Subject: Question about draft-hollenbeck-epp-tcp-01.txt
Sender: [email-masked]

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 <epp> 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.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Fri, 13 Apr 2001 16:00:47 -0400
From: George Belotsky <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document.
Sender: [email-masked]

>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:

<domain-name>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.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

To: George Belotsky <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document. 
Date: Fri, 13 Apr 2001 15:32:46 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 13 Apr 2001 15:01:11 -0400
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: A Comment on 9. [1] of the requirements document.
Sender: [email-masked]

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:[email-masked]]
> >Sent: Friday, April 13, 2001 12:43 PM
> >To: [email-masked]
> >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.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>, [email-masked]
Subject: RE: A Comment on 9. [1] of the requirements document.
Date: Fri, 13 Apr 2001 13:04:31 -0400
Sender: [email-masked]

>-----Original Message-----
>From: George Belotsky [mailto:[email-masked]]
>Sent: Friday, April 13, 2001 12:43 PM
>To: [email-masked]
>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.

<Scott/>

To: [email-masked]
Subject: Re: Subscribe 
Date: Fri, 13 Apr 2001 19:10:25 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

This was a Pilot error from me. Humble apologies. I'll get Cham Feng on
the list anyway.

	jaap

From: "Chan Feng" <[email-masked]>
To: <[email-masked]>
Subject: Subscribe
Date: Fri, 13 Apr 2001 12:22:21 -0400
Sender: [email-masked]

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT size=3D1>
<P>Subscribe</P></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>- Chan Feng<BR>Manager of Systems=20
Development<BR>Register.com - the first step on the web<BR>Office: (212) =
798 x=20
9136<BR>Mobile: (917) 567-2183</FONT></DIV></BODY></HTML>

------=_NextPart_000_0026_01C0C414.63987620--

Date: Fri, 13 Apr 2001 12:43:14 -0400
From: George Belotsky <[email-masked]>
To: [email-masked]
Subject: A Comment on 9. [1] of the requirements document.
Sender: [email-masked]

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.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Thu, 12 Apr 2001 10:42:45 -0400
To: Klaus Malorny <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Issues on 3.4.9 Object Information Query
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: "Jordyn A. Buchanan" <[email-masked]>, [email-masked]
Subject: RE: Issues on 3.4.9 Object Information Query
Date: Thu, 12 Apr 2001 09:46:00 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Thursday, April 12, 2001 5:36 AM
>To: Hollenbeck, Scott
>Cc: Jordyn A. Buchanan; [email-masked]
>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.
>> 
>> <Scott/>
>
>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.

<Scott/>

Date: Thu, 12 Apr 2001 13:18:11 +0200
From: Olivier Guillard / AFNIC <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: comments on last draft
Sender: [email-masked]

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-jseng-provreg-opp-00.txt
Date: Thu, 12 Apr 2001 07:06:07 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 12 Apr 2001 12:43:37 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: 3.4/Object Ownership, esp. Name Server Ownership
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> >-----Original Message-----
> >From: Hollenbeck, Scott [mailto:[email-masked]]
> >Sent: Wednesday, April 11, 2001 7:41 AM
> >To: 'Klaus Malorny'; [email-masked]
> >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!
> 
> <Scott/>

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
     [email-masked]             Tel. +49 231 9703 0

Date: Thu, 12 Apr 2001 11:36:11 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "Jordyn A. Buchanan" <[email-masked]>, [email-masked]
Subject: Re: Issues on 3.4.9 Object Information Query
Sender: [email-masked]

"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.
> 
> <Scott/>

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
     [email-masked]             Tel. +49 231 9703 0

Date: Thu, 12 Apr 2001 10:10:52 +0200
From: Olivier Guillard / AFNIC <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: Mats Dufberg <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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: [email-masked]
> 
> Dilbert is an optimist.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 

To: [email-masked]
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 <[email-masked]>
Sender: [email-masked]

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 <pick-an-element> 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:
	<ACCESS/>	defined subsequent
	<STATEMENT/>	one or more, defined subsequent ("statement-blocks"),
	<EXPIRY/>	defined subsequent

// Policy ABNF (grammer representation of XML syntax)

	policy			=	"<POLICY>" 
					access
					*statement-block
					expiry
					"</POLICY>"

<!--
Policy XSD fragment
-->
   <element name='POLICY'>
      <complexType>
         <sequence>
            <element ref='abc:ACCESS'/>
            <element ref='abc:STATEMENT' minOccurs='0' maxOccurs='unbounded'/>
            <element ref='abc:EXPIRY'/>
         </sequence>
      </complexType>
   </element>

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:

	<social/>	access is provided to all social data only
	<technical/>	access is provided to all technical data only
	<all/>		access is provided to all technical and social data
	<noaccess/>	registrant data exists but access is not provided
	<null/>		registrant data is not persistent

// Access ABNF (grammer representation of XML syntax)

	access			=	"<ACCESS>"
					access_disclosure
					"</ACCESS>"

	access_disclosure	=	"<social/>"	| ; socal data only
					"<technical/>"	| ; technical data only
					"<all/>"	| ; all data
					"<noaccess/>"	| ; access not provided
					"<null/>"	| ; data not persistent

<!--
Access XSD fragment
-->
   <element name='ACCESS'>
      <complexType name="access-value">
         <sequence>
            <choice>
               <element name='social' type='abc:access-value'/>
               <element name='technical' type='abc:access-value'/>
               <element name='all' type='abc:access-value'/>
               <element name='noaccess' type='abc:access-value'/>
               <element name='null' type='abc:access-value'/>
            </choice>
         </sequence>
      </complexType>
   </element>

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		= 	"<STATEMENT>"
					purpose
					recipient
					retention
					1*data-group
					"</STATEMENT>"

<!--
Statement XSD fragment
-->

   <element name='STATEMENT'>
      <complexType>
         <sequence>
            <element ref='abc:PURPOSE'/>
            <element ref='abc:RECIPIENT'/>
            <element ref='abc:RETENTION'/>
            <element ref='abc:DATA-GROUP' maxOccurs='unbounded'/>
         </sequence>
      </complexType>
   </element>

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:

	<dnreg/>	dn name registration (dnso)
	<tmreg/>	tm mark registration (trademark)
	<ipreg/>	ip address registration (aso)
	<contact/>	contacting registrants for marketing purposes
	<other-purpose>	something other than the above

// Access ABNF (grammer representation of XML syntax)

	purpose		=	"<PURPOSE>"
				1*purposevalue
				"</PURPOSE>"

	purposevalue	=	"<dnreg/>"
				"<tmreg/>"
				"<ipreg/>"
				"<contact/>"
				"<other-purpose/>"

<!--
Purpose XSD fragment
-->
   <element name='PURPOSE'>
      <complexType>
         <sequence>
            <choice maxOccurs='unbounded'>
               <element name='dnreg' type='abc:purpose-value'/>
               <element name='tmreg' type='abc:purpose-value'/>
               <element name='ipreg' type='abc:purpose-value'/>
               <element name='contact' type='abc:purpose-value'/>
               <element name='other-purpose'>
                  <complexType mixed='true'>
                     <attribute name='required' use='optional'
                     	type='abc:required-value'/>
                  </complexType>
               </element>
             </choice>
          </sequence>
      </complexType>
   </element>

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:

	<ours/>		ourselves and/or our agents and/or us as agents
	<same/>		legal entities following our practices
	<other-recipient/>
			legal entities following unknown practices
	<unrelated/>	unrelated third parties
	<public>	public fora

// Recipient ABNF (grammer representation of XML syntax)

	recipient	=	"<RECIPIENT>"
				1*recipientvalue
				"</RECIPIENT>"

	recipientvalue	=	"<ours/>"
				"<same/>"
				"<other-recipient/>"
				"<unrelated/>"
				"<public/>"

<!--
Recipient XSD fragment
-->
   <element name='RECIPIENT'>
      <complexType>
         <sequence>
            <choice maxOccurs='unbounded'>
               <element name='ours' type='abc:recipient-value'/>
               <element name='same' type='abc:recipient-value'/>
               <element name='other-recipient' type='abc:recipient-value'/>
               <element name='unrelated' type='abc:recipient-value'/>
               <element name='public' type='abc:recipient-value'/>
             </choice>
          </sequence>
      </complexType>
   </element>

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:

	<no-retention/>		data is not persistent
	<stated-purpose/>	data is persistent (functional requirement)
	<legal-requirement/>	data is persistent (legal requirement)
	<business-practices/>	data is persistent (non-functional requirement)
	<indefinitely>		data is persistent (indefinitely)

// Retention ABNF (grammer representation of XML syntax)

	retention	=	"<RETENTION>"
				1*retentionvalue
				"</RETENTION>"

	recipientvalue	=	"<no-retention/>"
				"<stated-purpose/>"
				"<legal-requirement/>"
				"<business-practices/>"
				"<indefinitely/>"

<!--
Recipient XSD fragment
-->
   <element name='RETENTION'>
      <complexType>
         <sequence>
            <choice maxOccurs='unbounded'>
               <element name='no-retention' type='abc:retention-value'/>
               <element name='stated-purpose' type='abc:retention-value'/>
               <element name='legal-requirement' type='abc:retention-value'/>
               <element name='business-practices' type='abc:retention-value'/>
               <element name='indefinitely' type='abc:retention-value'/>
             </choice>
          </sequence>
      </complexType>
   </element>

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		 	=	"<EXPIRY>
					absolute = `date="` dateTime `"`
					relative = `time="` timeDuration `"`
					</EXPIRY>

<!--
Expiry XSD fragment
-->
   <element name='EXPIRY'>
      <complexType>
	 <choice>
	    <attribute name='date' type='dateTime' use='optional'/>
            <attribute name='time' type='timeDuration' use='optional'/>
	 </choice>
      </complexType>
    </element>

END END END

Date: Wed, 11 Apr 2001 15:00:28 -0400
To: Mats Dufberg <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Nameserver MUST HAVE IP
Cc: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Wed, 11 Apr 2001 12:00:20 -0400
To: Mats Dufberg <[email-masked]>, Olivier Guillard / AFNIC <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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
>[email-masked]                           fax: +46-8-545 857 29

-- 
Jordyn A. Buchanan            [email-masked]
Futurist                      +1.212.798.9262
Register.com                  http://www.register.com/

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Registrant Access (Data Protection/Privacy) 
Date: Wed, 11 Apr 2001 11:18:01 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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 =	"<EXTENSION"
				[" optional=" `"` ("yes"|"no") `"`] ">"
				PCDATA
				"</EXTENSION>"

The schema is
<!--
Extension
-->
   <element name="EXTENSION">
      <complexType mixed="true">
         <choice minOccurs="0" maxOccurs="unbounded">
            <any processContents="skip" minOccurs="0" maxOcc urs="unbounded"/>
         </choice>
         <attribute name="optional" type="abc:yes_no" use="default" value="yes"/>
      </complexType>
  </element>

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

Date: Wed, 11 Apr 2001 16:56:52 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: Olivier Guillard / AFNIC <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

From: Bill Manning <[email-masked]>
Subject: Re: 3.4/Object Ownership, esp. Name Server Ownership
To: [email-masked] (Hollenbeck, Scott)
Date: Wed, 11 Apr 2001 07:43:48 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

 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!
% 
% <Scott/>
% 

-- 
--bill

Date: Wed, 11 Apr 2001 16:44:05 +0200
From: Olivier Guillard / AFNIC <[email-masked]>
To: Mats Dufberg <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
> [email-masked]                           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

Date: Wed, 11 Apr 2001 16:43:06 +0200
From: Olivier Guillard <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: comments on last draft
Sender: [email-masked]

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:[email-masked]
|| tel: +33 1 39 30 83 31

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, "Jordyn A. Buchanan" <[email-masked]>
Cc: [email-masked]
Subject: RE: Issues on 3.4.9 Object Information Query
Date: Wed, 11 Apr 2001 10:18:54 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Wednesday, April 11, 2001 4:03 AM
>To: Jordyn A. Buchanan
>Cc: Hollenbeck, Scott; [email-masked]
>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.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership
Date: Wed, 11 Apr 2001 10:10:52 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Hollenbeck, Scott [mailto:[email-masked]]
>Sent: Wednesday, April 11, 2001 7:41 AM
>To: 'Klaus Malorny'; [email-masked]
>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!

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Registrant Access (Data Protection/Privacy) 
Date: Wed, 11 Apr 2001 10:10:31 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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 <ACCESS> lacks a "/", and I've just
about got the package 
	policy {access, statement {purpose, recipient, retention}, expiry}
ready to send to the list.

Eric 

To: Olivier Guillard / AFNIC <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: comments on last draft 
Date: Wed, 11 Apr 2001 09:30:28 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

[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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Registrant Access (Data Protection/Privacy)
Date: Wed, 11 Apr 2001 09:21:47 -0400
Sender: [email-masked]

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:

<access disclosure="social">
 <extension optional="yes">This is PCDATA.</extension>
 <extension optional="no">This is PCDATA, too.</extension>
</access>

<Scott/>

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Monday, April 09, 2001 1:41 PM
>To: [email-masked]
>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 <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. (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:
>
>	<social/>	access is provided to all social data only
>	<technical/>	access is provided to all technical data only
>	<all/>		access is provided to all technical and social data
>	<noaccess/>	registrant data exists but access is not provided
>	<null/>		registrant data is not persistent
>
>
>The (P3P-consistent) ABNF for this is:
>
>	access			=	"<ACCESS>"
>					access_disclosure
>					*extension
>					"<ACCESS>"
>
>	access_disclosure	=	"<social/>"	| ; socal data only
>					"<technical/>"	| ; technical data
only
>					"<all/>"	| ; all data
>					"<noaccess/>"	| ; access not
provided
>					"<null/>"	| ; data not
persistent
>
[snip]

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Olivier Guillard / AFNIC'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: comments on last draft
Date: Wed, 11 Apr 2001 08:30:15 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Olivier Guillard / AFNIC [mailto:[email-masked]]
>Sent: Wednesday, April 11, 2001 6:14 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]; [email-masked]
>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.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership
Date: Wed, 11 Apr 2001 07:41:29 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Wednesday, April 11, 2001 5:33 AM
>To: Hollenbeck, Scott; [email-masked]
>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.

<Scott/>

Date: Wed, 11 Apr 2001 12:20:31 +0200
From: Patrick <[email-masked]>
To: Klaus Malorny <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: 3.4/Object Ownership, esp. Name Server Ownership
Organization: Gandi
Sender: [email-masked]

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.

Date: Wed, 11 Apr 2001 12:13:41 +0200
From: Olivier Guillard / AFNIC <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: comments on last draft
Sender: [email-masked]

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:[email-masked]

Date: Wed, 11 Apr 2001 11:32:33 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: 3.4/Object Ownership, esp. Name Server Ownership
Sender: [email-masked]

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
     [email-masked]             Tel. +49 231 9703 0

Date: Wed, 11 Apr 2001 10:02:45 +0200
From: Klaus Malorny <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Issues on 3.4.9 Object Information Query
Sender: [email-masked]

"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
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Olivier Guillard'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: comments on last draft
Date: Tue, 10 Apr 2001 14:27:15 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Olivier Guillard [mailto:[email-masked]]
>Sent: Tuesday, April 10, 2001 2:10 PM
>To: Hollenbeck, Scott
>Cc: [email-masked]; [email-masked]
>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.

<Scott/>

Date: Tue, 10 Apr 2001 20:10:11 +0200
From: Olivier Guillard <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: comments on last draft
Sender: [email-masked]

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:[email-masked]
|| tel: +33 1 39 30 83 31

To: Olivier Guillard <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: comments on last draft 
Date: Tue, 10 Apr 2001 13:12:25 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Olivier Guillard'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: comments on last draft
Date: Tue, 10 Apr 2001 12:48:02 -0400
Sender: [email-masked]

Thanks for your comments, Olivier.  I'll address them below.

<Scott/>

>-----Original Message-----
>From: Olivier Guillard [mailto:[email-masked]]
>Sent: Tuesday, April 10, 2001 12:12 PM
>To: Hollenbeck, Scott
>Cc: [email-masked]; [email-masked]
>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.

Date: Tue, 10 Apr 2001 18:12:26 +0200
From: Olivier Guillard <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: comments on last draft
Sender: [email-masked]

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:[email-masked]
|| tel: +33 1 39 30 83 31

Date: Tue, 10 Apr 2001 07:50:03 -0700
To: Klaus Malorny <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Issues on 3.4.9 Object Information Query
Cc: [email-masked]
Sender: [email-masked]

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            [email-masked]
Futurist                      +1.212.798.9262
Register.com                  http://www.register.com/

To: Peter Eisenhauer <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: 3.4.9 [4] 
Date: Tue, 10 Apr 2001 10:33:43 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Issues on 3.4.9 Object Information Query
Date: Tue, 10 Apr 2001 08:43:06 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Tuesday, April 10, 2001 3:25 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>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.

<Scott/>

Date: Tue, 10 Apr 2001 14:42:40 +0200
From: Peter Eisenhauer <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: 3.4.9 [4]
Organization: Schlund + Partner AG
Sender: [email-masked]

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: [email-masked]

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Peter Eisenhauer'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: 3.4.9 [4] 
Date: Tue, 10 Apr 2001 08:20:07 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-01.txt
Date: Tue, 10 Apr 2001 07:05:32 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Peter Eisenhauer'" <[email-masked]>, [email-masked]
Subject: RE: 3.4.9 [4]
Date: Tue, 10 Apr 2001 06:54:59 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Peter Eisenhauer [mailto:[email-masked]]
>Sent: Tuesday, April 10, 2001 5:09 AM
>To: [email-masked]
>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?

<Scott/>

Date: Tue, 10 Apr 2001 11:09:09 +0200
From: Peter Eisenhauer <[email-masked]>
To: [email-masked]
Subject: 3.4.9 [4]
Organization: Schlund + Partner AG
Sender: [email-masked]

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: [email-masked]

Date: Tue, 10 Apr 2001 09:24:55 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Issues on 3.4.9 Object Information Query
Sender: [email-masked]

"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 ;-)

> 
> <Scott/>

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, [email-masked]
Subject: RE: Provreg WG Last Call (8.4 Data Collection Requirements)
Date: Mon, 9 Apr 2001 19:53:00 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Monday, April 09, 2001 6:33 PM
> To: [email-masked]
> 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?

<Scott/>

To: [email-masked]
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 <[email-masked]>
Sender: [email-masked]

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Registrant Access (Data Protection/Privacy) 
Date: Mon, 09 Apr 2001 14:51:51 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Klaus Malorny'" <[email-masked]>, <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Date: Mon, 9 Apr 2001 11:09:47 -0700
Organization: Image Online Design, Inc.
Sender: [email-masked]

> 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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Registrant Access (Data Protection/Privacy)
Date: Mon, 9 Apr 2001 13:47:05 -0400 
Sender: [email-masked]

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

<Scott/>

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Monday, April 09, 2001 1:41 PM
>To: [email-masked]
>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 <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. (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:
>
>	<social/>	access is provided to all social data only
>	<technical/>	access is provided to all technical data only
>	<all/>		access is provided to all technical and social data
>	<noaccess/>	registrant data exists but access is not provided
>	<null/>		registrant data is not persistent
>
>
>The (P3P-consistent) ABNF for this is:
>
>	access			=	"<ACCESS>"
>					access_disclosure
>					*extension
>					"<ACCESS>"
>
>	access_disclosure	=	"<social/>"	| ; socal data only
>					"<technical/>"	| ; technical data
only
>					"<all/>"	| ; all data
>					"<noaccess/>"	| ; access not
provided
>					"<null/>"	| ; 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".
>
><!--
>Access element, modification of www.w3.org/TR/P3P/#ACCESS
>-->
>   <element name='ACCESS'>
>      <complexType name="access-value">
>         <sequence>
>            <choice>
>               <element name='social' type='abc:access-value'/>
>               <element name='technical' type='abc:access-value'/>
>               <element name='all' type='abc:access-value'/>
>               <element name='noaccess' type='abc:access-value'/>
>               <element name='null' type='abc:access-value'/>
>            </choice>
>            <element ref='abc:EXTENSION' minOccurs='0'
maxOccurs='unbounded'/>
>         </sequence>
>      </complexType>
>   </element>
>
>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 
>

To: [email-masked]
Subject: Registrant Access (Data Protection/Privacy)
Date: Mon, 09 Apr 2001 13:41:19 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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 <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. (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:

	<social/>	access is provided to all social data only
	<technical/>	access is provided to all technical data only
	<all/>		access is provided to all technical and social data
	<noaccess/>	registrant data exists but access is not provided
	<null/>		registrant data is not persistent

The (P3P-consistent) ABNF for this is:

	access			=	"<ACCESS>"
					access_disclosure
					*extension
					"<ACCESS>"

	access_disclosure	=	"<social/>"	| ; socal data only
					"<technical/>"	| ; technical data only
					"<all/>"	| ; all data
					"<noaccess/>"	| ; access not provided
					"<null/>"	| ; 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".

<!--
Access element, modification of www.w3.org/TR/P3P/#ACCESS
-->
   <element name='ACCESS'>
      <complexType name="access-value">
         <sequence>
            <choice>
               <element name='social' type='abc:access-value'/>
               <element name='technical' type='abc:access-value'/>
               <element name='all' type='abc:access-value'/>
               <element name='noaccess' type='abc:access-value'/>
               <element name='null' type='abc:access-value'/>
            </choice>
            <element ref='abc:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
         </sequence>
      </complexType>
   </element>

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 

Date: Mon, 09 Apr 2001 18:50:28 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: International Issues @ 3.4.2[6] and 9.
Sender: [email-masked]

"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?
> 
> <Scott/>

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
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Issues on 3.4.9 Object Information Query
Date: Mon, 9 Apr 2001 11:23:20 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 9:43 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>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].
>> 
>> <Scott/>
>
>
>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.

<Scott/>

Date: Mon, 9 Apr 2001 17:07:22 +0200 (CEST)
From: Shane Kerr <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: RE: International Issues @ 3.4.2[6] and 9.
Sender: [email-masked]

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.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: International Issues @ 3.4.2[6] and 9.
Date: Mon, 9 Apr 2001 10:40:12 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 9:08 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>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?

<Scott/>

Date: Mon, 09 Apr 2001 16:00:16 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Issues on 3.4.5. Object Transfer
Sender: [email-masked]

"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.

> 
> <Scott/>

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

Date: Mon, 9 Apr 2001 15:56:53 +0200
From: Peter Eisenhauer <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Organization: Schlund + Partner AG
Sender: [email-masked]

On Mon, Apr 09, 2001 at 08:03:30AM -0400, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: Mats Dufberg [mailto:[email-masked]]
> >Sent: Monday, April 09, 2001 7:26 AM
> >To: Hollenbeck, Scott
> >Cc: [email-masked]
> >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.
> 
> <Scott/>
> 
> <Scott/>

>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: [email-masked]

Date: Mon, 09 Apr 2001 15:42:36 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Issues on 3.4.9 Object Information Query
Sender: [email-masked]

"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].
> 
> <Scott/>

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
     [email-masked]             Tel. +49 231 9703 0

Date: Mon, 09 Apr 2001 15:07:38 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: International Issues @ 3.4.2[6] and 9.
Sender: [email-masked]

"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.
> 
> <Scott/>

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
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: Issues on 3.4.5. Object Transfer
Date: Mon, 9 Apr 2001 08:29:05 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 5:24 AM
>To: [email-masked]
>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.

<Scott/>

Date: Mon, 9 Apr 2001 14:27:59 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: Issues on 3.4.9 Object Information Query
Date: Mon, 9 Apr 2001 08:19:28 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 5:48 AM
>To: [email-masked]
>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].

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: Re: Nameserver MUST HAVE IP 
Date: Mon, 09 Apr 2001 14:21:17 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    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.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: International Issues @ 3.4.2[6] and 9.
Date: Mon, 9 Apr 2001 08:09:43 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 5:08 AM
>To: [email-masked]
>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.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Mats Dufberg'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Nameserver MUST HAVE IP
Date: Mon, 9 Apr 2001 08:03:30 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Mats Dufberg [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 7:26 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>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.

<Scott/>

<Scott/>

Date: Mon, 9 Apr 2001 13:26:19 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: Nameserver MUST HAVE IP
Date: Mon, 9 Apr 2001 06:50:05 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Monday, April 09, 2001 4:31 AM
>To: [email-masked]
>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.

<Scott/>

Date: Mon, 09 Apr 2001 11:47:42 +0200
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: Issues on 3.4.9 Object Information Query
Sender: [email-masked]

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
     [email-masked]             Tel. +49 231 9703 0

Date: Mon, 09 Apr 2001 11:24:18 +0200
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: Issues on 3.4.5. Object Transfer
Sender: [email-masked]

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
     [email-masked]             Tel. +49 231 9703 0

Date: Mon, 09 Apr 2001 11:08:07 +0200
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: International Issues @ 3.4.2[6] and 9.
Sender: [email-masked]

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
     [email-masked]             Tel. +49 231 9703 0

Date: Mon, 09 Apr 2001 10:31:18 +0200
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
     [email-masked]             Tel. +49 231 9703 0

Date: Sun, 8 Apr 2001 15:49:09 +0200
From: Peter Eisenhauer <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Organization: Schlund + Partner AG
Sender: [email-masked]

On Fri, Apr 06, 2001 at 12:55:59PM -0400, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: Peter Eisenhauer [mailto:[email-masked]]
> >Sent: Friday, April 06, 2001 9:56 AM
> >To: Bill Manning
> >Cc: [email-masked]
> >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.
> 
> <Scott/>

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: [email-masked]

Date: Sun, 8 Apr 2001 15:38:37 +0200
From: Peter Eisenhauer <[email-masked]>
To: Urs Eppenberger <[email-masked]>
Cc: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Organization: Schlund + Partner AG
Sender: [email-masked]

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
> <[email-masked]> 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: [email-masked]

Date: Fri, 06 Apr 2001 16:02:37 +0200
From: Urs Eppenberger <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

--On Freitag, 6. April 2001 15:18 Uhr +0200 Peter Eisenhauer
<[email-masked]> 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.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Patrick Greenwell'" <[email-masked]>, [email-masked]
Subject: RE: Provreg WG Last Call announcement
Date: Sat, 7 Apr 2001 20:44:16 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Patrick Greenwell [mailto:[email-masked]]
> Sent: Saturday, April 07, 2001 12:48 PM
> To: [email-masked]
> 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.

<Scott/> 

Date: Sat, 07 Apr 2001 10:22:46 -0700
To: Patrick Greenwell <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Privacy state/context
Cc: <[email-masked]>
Sender: [email-masked]

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   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Sat, 7 Apr 2001 09:47:32 -0700 (PDT)
From: Patrick Greenwell <[email-masked]>
To: <[email-masked]>
Subject: Re: Provreg WG Last Call announcement
Sender: [email-masked]

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.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Date: Fri, 6 Apr 2001 18:23:10 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: <[email-masked]>, Kent Crispin <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

> 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

Date: Fri, 6 Apr 2001 22:51:24 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: Christopher Ambler <[email-masked]>
cc: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Mats Dufberg" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 13:43:06 -0700
Organization: Image Online Design, Inc.
Sender: [email-masked]

>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

Date: Fri, 6 Apr 2001 22:41:15 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
cc: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

Date: Fri, 6 Apr 2001 22:32:27 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
cc: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

Date: Fri, 06 Apr 2001 22:20:59 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Mats Dufberg <[email-masked]>, "Jordyn A. Buchanan" <[email-masked]>
cc: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

--On 01-04-06 22.02 +0200 Mats Dufberg <[email-masked]> 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

Date: Fri, 6 Apr 2001 16:10:52 -0400
To: Mats Dufberg <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Cc: <[email-masked]>
Sender: [email-masked]

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            [email-masked]
Futurist                      +1.212.798.9262
Register.com                  http://www.register.com/

Date: Fri, 6 Apr 2001 22:02:36 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
cc: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

Date: Fri, 6 Apr 2001 12:10:36 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
[email-masked]                           lonesome." -- Mark Twain

Date: Fri, 6 Apr 2001 14:45:49 -0400
To: "Christopher Ambler" <[email-masked]>, <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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            [email-masked]
Futurist                      +1.212.798.9262
Register.com                  http://www.register.com/

Date: Fri, 6 Apr 2001 20:49:05 +0200 (MET DST)
From: Elisabeth Porteneuve <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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.
--

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 11:25:34 -0700
Organization: Image Online Design, Inc.
Sender: [email-masked]

> 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

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 11:23:08 -0700
Organization: Image Online Design, Inc.
Sender: [email-masked]

"Mats Dufberg" <[email-masked]>
> 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

Date: Fri, 6 Apr 2001 10:55:39 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
[email-masked]                           lonesome." -- Mark Twain

From: "Larson, Matt" <[email-masked]>
To: "'Jordyn A. Buchanan'" <[email-masked]>, Elmar Knipp <[email-masked]>
Cc: Kent Crispin <[email-masked]>, [email-masked]
Subject: RE: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 13:52:34 -0400 
Sender: [email-masked]

> 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 <[email-masked]>
VeriSign Global Registry Services / www.verisign-grs.com

Date: Fri, 6 Apr 2001 09:59:30 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
[email-masked]                           lonesome." -- Mark Twain

Date: Fri, 6 Apr 2001 13:01:07 -0400
To: Elmar Knipp <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Cc: Kent Crispin <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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            [email-masked]
Futurist                      +1.212.798.9262
Register.com                  http://www.register.com/

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Peter Eisenhauer'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 12:55:59 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Peter Eisenhauer [mailto:[email-masked]]
>Sent: Friday, April 06, 2001 9:56 AM
>To: Bill Manning
>Cc: [email-masked]
>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.

<Scott/>

Date: Fri, 6 Apr 2001 18:35:51 +0200 (METDST)
From: Elmar Knipp <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
cc: Kent Crispin <[email-masked]>, <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
     [email-masked]               Fax: +49 231 9703-200

Date: Fri, 6 Apr 2001 12:06:19 -0400
To: Kent Crispin <[email-masked]>, [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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            [email-masked]
Futurist                      +1.212.798.9262
Register.com                  http://www.register.com/

Date: Fri, 6 Apr 2001 08:39:41 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
[email-masked]                           lonesome." -- Mark Twain

From: "William Tan" <[email-masked]>
To: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 23:13:01 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

> 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

Date: Fri, 6 Apr 2001 16:27:32 +0200 (CEST)
From: Mats Dufberg <[email-masked]>
To: Peter Eisenhauer <[email-masked]>
cc: <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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
[email-masked]                           fax: +46-8-545 857 29

Date: Fri, 6 Apr 2001 16:07:09 +0200
From: Peter Eisenhauer <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Organization: Schlund + Partner AG
Sender: [email-masked]

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:[email-masked]]
> >Sent: Friday, April 06, 2001 9:18 AM
> >To: [email-masked]
> >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.
> 
> <Scott/>

Mit freundlichen Gruessen,
Peter Eisenhauer

-- 
Peter Eisenhauer                        Schlund + Partner AG
Erbprinzenstrasse 4-12                  Tel: 0721/91374-0
76133 Karlsruhe                         E-Mail: [email-masked]

Date: Fri, 6 Apr 2001 09:55:57 -0400
To: Peter Eisenhauer <[email-masked]>, [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
Sender: [email-masked]

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

Date: Fri, 6 Apr 2001 15:55:52 +0200
From: Peter Eisenhauer <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: [email-masked]
Subject: Re: Nameserver MUST HAVE IP
Organization: Schlund + Partner AG
Sender: [email-masked]

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: [email-masked]

From: Bill Manning <[email-masked]>
Subject: Re: Nameserver MUST HAVE IP
To: [email-masked] (Peter Eisenhauer)
Date: Fri, 6 Apr 2001 06:43:49 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

% 
% 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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Peter Eisenhauer'" <[email-masked]>, [email-masked]
Subject: RE: Nameserver MUST HAVE IP
Date: Fri, 6 Apr 2001 09:33:57 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Peter Eisenhauer [mailto:[email-masked]]
>Sent: Friday, April 06, 2001 9:18 AM
>To: [email-masked]
>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.

<Scott/>

Date: Fri, 6 Apr 2001 15:18:07 +0200
From: Peter Eisenhauer <[email-masked]>
To: [email-masked]
Subject: Nameserver MUST HAVE IP
Organization: Schlund + Partner AG
Sender: [email-masked]

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: [email-masked]

From: "William Tan" <[email-masked]>
To: <[email-masked]>
Subject: multiple copies
Date: Fri, 6 Apr 2001 12:28:09 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jaap Akkerhuis'" <[email-masked]>, "Paul M. Kane" <[email-masked]>
Cc: Edward Lewis <[email-masked]>, [email-masked]
Subject: RE: [cctld-tech] Re: Generic Registry Registrar Protocol requirem ents 
Date: Thu, 5 Apr 2001 07:00:21 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Jaap Akkerhuis [mailto:[email-masked]]
>Sent: Thursday, April 05, 2001 5:07 AM
>To: Paul M. Kane
>Cc: Hollenbeck, Scott; Edward Lewis; [email-masked]
>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 ([email-masked],
>[email-masked] & [email-masked]) 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.

<Scott/>

To: "Paul M. Kane" <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked]
Subject: Re: [cctld-tech] Re: Generic Registry Registrar Protocol requirements 
Date: Thu, 05 Apr 2001 11:06:57 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

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 ([email-masked],
[email-masked] & [email-masked]) 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

Date: Thu, 5 Apr 2001 10:56:22 +0200
From: Olivier Guillard <[email-masked]>
To: "Paul M. Kane" <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Generic Registry Registrar Protocol requirements
Sender: [email-masked]

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
>
>

Date: Thu, 05 Apr 2001 08:05:22 +0100
From: "Paul M. Kane" <[email-masked]>
Organization: REACTO.com
To: "Hollenbeck, Scott" <[email-masked]>
CC: Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Generic Registry Registrar Protocol requirements
Sender: [email-masked]

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

From: "Brian W. Spolarich" <[email-masked]>
To: "Edward Lewis" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Provreg WG Last Call announcement
Date: Wed, 4 Apr 2001 13:11:40 -0400
Importance: Normal
Sender: [email-masked]

  I'm aware of the process.  I was being somewhat facetious. :-)

  -bws

Date: Wed, 4 Apr 2001 12:32:03 -0400
To: "Brian W. Spolarich" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Provreg WG Last Call announcement
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Brian W. Spolarich" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Provreg WG Last Call announcement
Date: Wed, 4 Apr 2001 09:40:01 -0400
Importance: Normal
Sender: [email-masked]

| 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

Date: Wed, 04 Apr 2001 06:57:37 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Richard Shockey <[email-masked]>, Kent Crispin <[email-masked]>, [email-masked]
Subject: Re: HTTP Transport? (was: Re: Security Design Team)
Sender: [email-masked]

--On tisdag 3 april 2001 21.35 -0400 Richard Shockey 
<[email-masked]> 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

Date: Tue, 03 Apr 2001 21:35:50 -0400
To: Kent Crispin <[email-masked]>, [email-masked]
From: Richard Shockey <[email-masked]>
Subject: Re: HTTP Transport? (was: Re: Security Design Team)
Sender: [email-masked]

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
>[email-masked]                           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
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Tue, 3 Apr 2001 21:31:14 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Provreg WG Last Call announcement
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

To: [email-masked]
Subject: New list administrator.
From: Lars-Johan Liman <[email-masked]>
Date: Tue, 03 Apr 2001 08:06:42 +0200
Lines: 14
Sender: [email-masked]

The [email-masked] has a new list administrator: Jaap Akkerhuis
<[email-masked]>, 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: [email-masked]
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------

Date: Mon, 2 Apr 2001 17:37:32 -0400
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Status reports (was RE: Design teams)
Sender: [email-masked]

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.
>
><Scott/>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Mon, 2 Apr 2001 16:40:39 -0400
To: Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Minutes of our Minneapolis Meetings (rough cut)
Cc: [email-masked]
Sender: [email-masked]

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: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-01.txt
Date: Mon, 02 Apr 2001 07:17:13 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--