Subject: Re: APRICOT'2001
From: "James Seng/Personal" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>, <[email-masked]>
Date: Wed, 28 Feb 2001 09:34:52 +0800

> Your contribution to the requirements statements appear to be:
>
> 1. differences in policy, management, and business models exist.

I don't have contribution to the requirements doc. My company have a
registry but I am not involved in that part of it anymore.

But my opinion is that Asian NICs should put their requirements to the
table themselves. So what I am doing is informing them about the
presence of this group. And I am feedbacking their response to this
group.

> 2. a useless work-product will not be adopted.

And your XPR is? I don't think a 112 page I-D is something what I call
easy to understand, especially for those whose native language is not
English. I could not even be bother to give comment on it.

> Is that the best that can be done when the APRICOT best-and-brightest
are
> in one room?

Your continual sacarism against me indirectly is only getting silly.
"Please continue to act like an idiot", really, please continue to do
so.

But I am saying too much. I am going to keep quiet until I get my
proposal into this group.

-James Seng

Date: Wed, 28 Feb 2001 00:19:10 -0500
To: Jaap Akkerhuis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim meeting minutes
Cc: Rick H Wesson <[email-masked]>, "Bason, Chris" <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked]
Sender: [email-masked]

At 3:23 PM -0500 2/27/01, Jaap Akkerhuis wrote:
>Speaking as Ed's (evil) twin, why not discuss is here first?

Good idea, speaking for the other twin...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "James Seng/Personal" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], "Patrik Faltstrom" <[email-masked]>, [email-masked]
Subject: Re: APRICOT'2001 
Date: Tue, 27 Feb 2001 21:00:04 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

What was your point in making a presentation if not to elicit requirements?

Do you have the impression that you've convayed useful information from one
group to another?

Something is wrong when the only information comming out of a regional
operational meeting is non-specific.

Eric

Date: Wed, 28 Feb 2001 09:54:16 +0800
To: "James Seng/Personal" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: APRICOT'2001
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 08:15 PM 2/27/2001, James Seng/Personal wrote:
>Some feedback that this group can feel free to do what they like but if
>it the result is not suitable, they will just ignore it.

This is true for any IETF effort.

The way that specifications meet needs is for those who have the needs to 
participate in the IETF discussions.

Have they read the requirements or proposed specification?  Do they have 
criticisms or suggestions (or even demands) about the details?

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

To: "James Seng/Personal" <[email-masked]>
cc: [email-masked], "Patrik Faltstrom" <[email-masked]>, [email-masked]
Subject: Re: APRICOT'2001 
Date: Tue, 27 Feb 2001 17:26:47 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

James,

Your contribution to the requirements statements appear to be:

	1. differences in policy, management, and business models exist.

	2. a useless work-product will not be adopted.

Is that the best that can be done when the APRICOT best-and-brightest are
in one room?

Eric

To: Jaap Akkerhuis <[email-masked]>
cc: Richard Shockey <[email-masked]>, [email-masked], [email-masked]
Subject: Re: NewLevel XRP draft 
Date: Tue, 27 Feb 2001 17:17:24 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Jaap,

> I know see two xrp documents. ...

draft-brunner-xrp-00.txt is the memo NeuStar, Melboure IT, NeuLevel, and
Sundry Elves (tm) submitted as an I-D. It superceeds a memo with a working
title confusingly similar to one which it will have, after some more edits
and adoption by the WG as a WG document.

> Yuo mean that NeuLevel and NeuStar Melbourne are different companies?

I think so. Anyway, that's a non-technical detail and I don't care what
company name(s) associate themselves with any WG work-product.

I didn't intend our -00 as a placeholder, and I plan to submit a revision
prior to the -0n deadline of the 2nd, adding containers and profiles. It
should be obvious to everyone that xrp owes considerable to epp.

I want to thank everyone who worked the table mic at the Interim. I'd two
snow-bound munchkins at home and a third in-hospital, so "participation"
was as a short-order-cook, activity-animator, and social-worker, and even
so, I felt adequately "present". Very sorry about the beers. Minneapolis.

Eric

To: Rick H Wesson <[email-masked]>
cc: "Bason, Chris" <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked]
Subject: Re: Interim meeting minutes 
Date: Tue, 27 Feb 2001 21:23:39 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    > I believe the minutes were stated correctly.
    > I don't think we came to a general consensus
    > that Global Unique Handles were a "Good Thing".
    
That is what I also recall.
    
    I guess we should just re-debate this topic, Ed, could we get 10 minutes
    in Minneapolis to go over the issue?

Speaking as Ed's (evil) twin, why not discuss is here first?

	jaap

Date: Tue, 27 Feb 2001 11:28:59 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Bason, Chris" <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>
Subject: RE: Interim meeting minutes
Sender: [email-masked]

chris,

> I believe the minutes were stated correctly.
> I don't think we came to a general consensus
> that Global Unique Handles were a "Good Thing".

I guess we should just re-debate this topic, Ed, could we get 10 minutes
in Minneapolis to go over the issue?

-rick

Date: Tue, 27 Feb 2001 07:46:44 -0800
To: "James Seng/Personal" <[email-masked]>, <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: APRICOT'2001
Sender: [email-masked]

At 20.15 +0800 01-02-27, James Seng/Personal wrote:
>I have done the first discussion of ProvReg at the APRICOT'2001 today.
>Some NICs has expressed their shock this Working Group wish to push thru
>the Protocol, given that there are so many differences in policy,
>management and business models. Even among the Asian NICs, they do not
>have uniformed policy yet.

You have to differ between trying to do things quickly and "pushing" 
which for me implies creating a sloppy specification for a sloppy 
protocol.

The IETF process should be able to do a proper review on protocols 
which are created in a short timeframe, and what the review process 
is to look into is whether the protocol is bad or not fulfilling all 
requirements (or that the requiurements are not correct).

Just because there is a great interest in this protocol, and so many 
people want it, it is _extremely_ important that all people which 
have interest let this wg know whether some requirement is not 
fulfilled in the protocol, or missing in the requirements document.

It is a fact that different registries (please don't talk about 
TLD's) have different policy, have different things you can register 
(domains, ip-address blocks and whatever) and the requirements 
document have to list all of those requirements. For example that the 
policy is not known.

So, my message to those people would be to please participate _now_.

   paf

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

To: Richard Shockey <[email-masked]>
cc: [email-masked]
Subject: Re: NewLevel XRP draft 
Date: Tue, 27 Feb 2001 15:07:39 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    I did not see this come across the list here so I've taken the
    liberty of posting this here..

I noticed it before,

    This is the NeuLevel ( NeuStar Melbourne IT ) informational
    draft on our concepts for a Generic Registry Protocol for Domain
    Names.

    This document had many contributors from both companies and
    the next iteration of the draft will more accurately reflect
    these contributions.

Yuo mean that NeuLevel and NeuStar Melbourne are different companies?

    As I mentioned in the off site..this document should not be
    considered "competitive" to existing proposals but hopefully
    commentary.

    To the Chair ..I hope this could be included in our official
    WG documents moving forward.

I know see two xrp documents. There is this one, the is
draft-ietf-provreg-xrp-00.txt by McGarry, Damaraju, Amsden and
Zhang, and there is draft-brunner-xrp-00.txt Brunner, Damaraju,
Zhang.

This getting really confusing. Maybe someone should point out what
is really meant with the `XRP' protocol.

	jaap

From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>
Cc: "Patrik Faltstrom" <[email-masked]>
Subject: APRICOT'2001
Date: Tue, 27 Feb 2001 20:15:39 +0800
Sender: [email-masked]

Dear all,

I have done the first discussion of ProvReg at the APRICOT'2001 today.
Some NICs has expressed their shock this Working Group wish to push thru
the Protocol, given that there are so many differences in policy,
management and business models. Even among the Asian NICs, they do not
have uniformed policy yet.

Some feedback that this group can feel free to do what they like but if
it the result is not suitable, they will just ignore it.

A personal note from me (and I shall go into silence again until I have
my I-D):

While I understand there is a lot of ICANN pressure and commerical
interest to push thru ProvReg quickly (heck, I work for a company which
provides Registry Outsourcing too like some who is pushing this), I
think we also need to consider there are many registries (mostly
non-profit) in the world out there who barely struggle with their
current operation. Having a rigid, complicated protocol will only make
life more difficult for them without the right sets of tools. Don't
forget them in your equation while you chase for the $$$.

-James Seng

Date: Mon, 26 Feb 2001 18:05:21 -0500
To: [email-masked]
From: Richard Shockey <[email-masked]>
Subject: NewLevel XRP draft
Sender: [email-masked]

I did not see this come across the list here so I've taken the liberty of 
posting this here..

This is the NeuLevel ( NeuStar Melbourne IT ) informational draft on our 
concepts for a Generic Registry Protocol for Domain Names.

This document had many contributors from both companies and the next 
iteration of the draft will more accurately reflect these contributions.

As I mentioned in the off site..this document should not be considered 
"competitive" to existing proposals but hopefully commentary.

To the Chair ..I hope this could be included in our official WG documents 
moving forward.

Comments always welcome.

#######

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-brunner-xrp-00.txt
Date: Fri, 23 Feb 2001 06:46:08 -0500
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Extensible Registry Protocol (XRP)
         Author(s)       : E. Brunner et al.
         Filename        : draft-brunner-xrp-00.txt
         Pages           : 112
         Date            : 22-Feb-01

This memo describes a connection-oriented, application layer client-
server protocol for the provisioning and management of objects stored
in a shared top level domain (TLD) central registry.  The protocol
defines a command framework for object management operations and maps
the commands to the objects defined in an extensible object data
model.  The protocol is specified in XML Schema Definition.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-xrp-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-brunner-xrp-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
>.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "Bason, Chris" <[email-masked]>
To: Rick H Wesson <[email-masked]>, Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: RE: Interim meeting minutes
Date: Tue, 27 Feb 2001 08:16:17 -0500
Sender: [email-masked]

One comment about the Global Unique Handles:

I believe the minutes were stated correctly. 
I don't think we came to a general consensus 
that Global Unique Handles were a "Good Thing".

Chris Bason

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 9:41 PM
> To: Edward Lewis
> Cc: [email-masked]
> Subject: Re: Interim meeting minutes
> 
> 
> 
> I have a few comments about the minutes taken, they are inline.
> 
> -rick
> 
> On Mon, 26 Feb 2001, Edward Lewis wrote:
> 
> 
> > Handle Issues
> > 	- ability to reference objects in other registries
> > 	  specifically: Contacts
> > 	- move to a more general approach
> > 	- a global namespace for object storage for each registry
> > 	- privacy issues were brought up.
> > 	- Decided that there is no reason NOT to use it (But 
> shouldn't be in
> >           this protocol - only the ability to do it should 
> be in the protocol)
> > 	- Still an open issue
> 
> I don't think we decided anything, as an interm meeting can't 
> decide. I
> believe we recomended that Global Unique handles would be a 
> Good Thing(tm)
> for the protocol to support.
> 
> >
> > Transport Issues (BEEP, parsing at client)
> >   - statement made that transport alternatives are needed to improve
> > 	  efficiency
> 
> we discussed ways that the current proposals could shorten 
> the amount of
> data transfered by establishing context oriented data in the session
> establishment phase of protocol negoation.
> 
> > Design Teams
> 
> > 	- Design teams work all through March
> > 	- Deadline - end of week (Feb 23) for design team formation (5-7
> > people)
> [snip]
> 
> I hope the chairs will announce these soon, with well defined 
> objectives.
> 
> 
> > Discussion of consummating the collution effort
> > 	- Having a "commercial Implmentors consortium
> > 	- Interoperability testing
> > 	- Load testing
> > 	- Rich Shockey volunteered to start Implementors group
> > 		* Email to [email-masked] to join mailing list
> 
> The list is at [email-masked], PRI stands from ProvReg 
> Implementors. alot of
> folks have already subscribed. To subscribe send a message 
> with the word
> "Subscribe" (without the quotes) to [email-masked]
> 
> -rick
> 

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Interim meeting minutes
Date: Tue, 27 Feb 2001 07:27:06 -0500
Importance: Normal
Sender: [email-masked]

> Design Teams
> 	- Design teams work all through March
> 	- Deadline - end of week (Feb 23) for design team formation (5-7 people)

Jaap, Ed, any idea as to when the design team members will be announced?
Thanks.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Rick H Wesson
Sent: Monday, February 26, 2001 9:41 PM
To: Edward Lewis
Cc: [email-masked]
Subject: Re: Interim meeting minutes

I have a few comments about the minutes taken, they are inline.

-rick

On Mon, 26 Feb 2001, Edward Lewis wrote:

> Handle Issues
> 	- ability to reference objects in other registries
> 	  specifically: Contacts
> 	- move to a more general approach
> 	- a global namespace for object storage for each registry
> 	- privacy issues were brought up.
> 	- Decided that there is no reason NOT to use it (But shouldn't be in
>           this protocol - only the ability to do it should be in the
protocol)
> 	- Still an open issue

I don't think we decided anything, as an interm meeting can't decide. I
believe we recomended that Global Unique handles would be a Good Thing(tm)
for the protocol to support.

>
> Transport Issues (BEEP, parsing at client)
>   - statement made that transport alternatives are needed to improve
> 	  efficiency

we discussed ways that the current proposals could shorten the amount of
data transfered by establishing context oriented data in the session
establishment phase of protocol negoation.

> Design Teams
> 	- Design teams work all through March
> 	- Deadline - end of week (Feb 23) for design team formation (5-7
> people)
[snip]

I hope the chairs will announce these soon, with well defined objectives.

> Discussion of consummating the collution effort
> 	- Having a "commercial Implmentors consortium
> 	- Interoperability testing
> 	- Load testing
> 	- Rich Shockey volunteered to start Implementors group
> 		* Email to [email-masked] to join mailing list

The list is at [email-masked], PRI stands from ProvReg Implementors. alot of
folks have already subscribed. To subscribe send a message with the word
"Subscribe" (without the quotes) to [email-masked]

-rick

Date: Mon, 26 Feb 2001 18:41:02 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>
Subject: Re: Interim meeting minutes
Sender: [email-masked]

I have a few comments about the minutes taken, they are inline.

-rick

On Mon, 26 Feb 2001, Edward Lewis wrote:

> Handle Issues
> 	- ability to reference objects in other registries
> 	  specifically: Contacts
> 	- move to a more general approach
> 	- a global namespace for object storage for each registry
> 	- privacy issues were brought up.
> 	- Decided that there is no reason NOT to use it (But shouldn't be in
>           this protocol - only the ability to do it should be in the protocol)
> 	- Still an open issue

I don't think we decided anything, as an interm meeting can't decide. I
believe we recomended that Global Unique handles would be a Good Thing(tm)
for the protocol to support.

>
> Transport Issues (BEEP, parsing at client)
>   - statement made that transport alternatives are needed to improve
> 	  efficiency

we discussed ways that the current proposals could shorten the amount of
data transfered by establishing context oriented data in the session
establishment phase of protocol negoation.

> Design Teams

> 	- Design teams work all through March
> 	- Deadline - end of week (Feb 23) for design team formation (5-7
> people)
[snip]

I hope the chairs will announce these soon, with well defined objectives.

> Discussion of consummating the collution effort
> 	- Having a "commercial Implmentors consortium
> 	- Interoperability testing
> 	- Load testing
> 	- Rich Shockey volunteered to start Implementors group
> 		* Email to [email-masked] to join mailing list

The list is at [email-masked], PRI stands from ProvReg Implementors. alot of
folks have already subscribed. To subscribe send a message with the word
"Subscribe" (without the quotes) to [email-masked]

-rick

Date: Mon, 26 Feb 2001 20:53:47 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Interim meeting minutes
Cc: [email-masked]
Sender: [email-masked]

Thanks to our scribe, Paul George.

IETF provreg meeting
Location: 	Washington Dulles International Airport Marriott
Date:		Feb 20, 2001
Start Time:	10:00 AM EST
End Time:	3:00 PM EST

Chairs present

Ed Lewis
Jaap Akkerhuis

Minutes

Agenda review
	- requests to add items to agenda
		* nameservers as objects
		* namespaces
		* alternate transport strategies
		* BEEP
		* Security - authentication/PGP

State of the WG
	- Neustar's proposal side note
	- Slide: WG Documents
	- Slide: WG vs Milestones

Begin Requirements Discussion

Handle Issues
	- ability to reference objects in other registries
	  specifically: Contacts
	- move to a more general approach
	- a global namespace for object storage for each registry
	- privacy issues were brought up.
	- Decided that there is no reason NOT to use it (But shouldn't be in
          this protocol - only the ability to do it should be in the protocol)
	- Still an open issue

Transport Issues (BEEP, parsing at client)
  - statement made that transport alternatives are needed to improve
	  efficiency
  - suggestion made to specify that transport is a separate issue (agreement
    that it already is).
	- BEEP Protocol (short background)
		* Performance issues were brought up.
		* Suggestion to possibly move the transport, authentication and
		  security out of the protocol to simplify it.
		* Noted: the need to discuss the needs of domain lookups vs
all
		  other activities.
		* Decided that this is not critical for Requirements Document
		* Decision to move this discussion to the mailing list.

Data Collection Issues
	- data flows defined as technical vs social.
	- Identification of 4 data flow/collection properties:
		* Purpose
		* Recipients
		* Retention
		* Access
	- Issue: who announces their data collection policy and how do they
	  announce it (How to communicate data flow/collection policies)
	- It was brought up that this is distinct from security
	- Was suggested that this need arises when there are too many
	  relationships to track "out-of-band"
	- Decision to continue discussion on mailing list
	- Agreement that there should be a data collection section in the
	  requirements doc for the protocol

Security Issues
	- Discussion of the use of PGP certs for accessing data
	- Ability for the protocol to provide other solutions (from registries
	  and registrars)
	- The need to id a request by the Registrant all the way to the
Registry
	- The need to provide a second (or multiple) access points.
	- Agreement to change "Authentication ID" to "Authentication Info"
	- Discussion of the types of Contacts
		* Note that "billing", "tech" and "Admin" are considered
		  placeholders for the time being.

Lunch

NameServers as objects
	- nameserver roles:
		1 - attributes of domains
		2 - object in their own right
	- object would give the ability to lookup data with a handle at the
	  registry and protocol level.
	- Consensus that NameServers should be represented as objects in the
	  protocol.

I18N
	- discussion about whether or not we should reference either UTF8,
1646,
	  or 2277 as a requirement in the protocol
	- note that 2277 was already referenced
	- Decided that this was good enough.

Neustar XRP Proposal
	- Note that this document should be considered Neustar's view of
the RRP
	- Recognition that it is very similar to Hollenbeck's draft and noted
	  differences:
		* Uses BEEP explicitly
	- Neustar does not consider this to be in competition with Scott's
draft
	- Recognized the need to further ID differences between the two
          documents
	- Comments on XRP
		* Uses IP objects for notification of possible intellectual
                  property violations

	- Remain discussion centered around the PRESALES query and the fact
that
	  it represents 80-90% of all traffic load on a Registry's servers.
		* Possibly isolate the presale process into a different
protocol
		* Discussion of if the presale process belongs in the protocol
			- Check commands could be moved to another box
                          (implementation problem)
		* A note about making the check command contain optional
		  authentication, which then was noted: optional auth
results in
		  optionally robust data
		* Discussion about the point of separating the functionality
		  between two protocols
		* Discussion about using BEEP (for short time to market
		  considerations)

	- It was decided that a separate protocol is not yet necessary and
that
 	  this protocol should try to make the presales lookup as
lightweight as
	  possible in the current protocol.
  	* Assuming that the check domain functionality is actually a check
  	  object.

Design Teams
	- expected outcome of design teams
		* an in-depth study as to what needs to be included in the
 		  protocol spec.
		* Concentrates on part of the draft -or- design protocol while
 		  evaluating candidate protocols
	- Noted the need for multiple design teams
		* 1st  team looking at the base protocol
		* 2nd team looking at the transport mechanisms/issues
		* 3rd team looking at security
	- recognition of the need for multiple transport mechanisms because of
 	  email
	- Note that April is still the deadline for the initial requirements
          spec
	- Design teams work all through March
	- Deadline - end of week (Feb 23) for design team formation (5-7
people)
	- Note to make the next IETF meeting the deadline for the first
	  deliverable:
		* 1st deliverable: Issues and trade-offs w/ possible strategy
		  suggestions from each team.

Email addresses used as unique identifier
	- decided that it was not a good thing for now
	- Discussion moved to mailing list

Discussion : Security - transport security vs. information security
	- Security Design team should:
		* List threats
		* Suggest how to handle them
		* Perhaps categorize the threats and determine which of the
two
		  other teams should address the threat.

Discussion of IETF RFC creation process

Discussion of an Implementors Group to discuss design/protocol
implementation issues

Discussion of time-to-market for new registries

Discussion of group collusion issues/problems

Discussion of consummating the collution effort
	- Having a "commercial Implmentors consortium
	- Interoperability testing
	- Load testing
	- Rich Shockey volunteered to start Implementors group
		* Email to [email-masked] to join mailing list

Scott said he will submit a new provreg 00 soon.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sun, 25 Feb 2001 21:01:01 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: Minneapolis time slot
Cc: [email-masked]
Sender: [email-masked]

Update - we're now at 3:45-4:45pm, same day.  If you are planning on
attending the IETF for just the day of the provreg meeting, track the
agenda on the IETF website in case there are more changes.

At 9:31 PM -0500 2/21/01, Edward Lewis wrote:
>Our time slot in Minneapolis is *Tuesday* from 5pm-6pm.   (March 20.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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-brunner-xrp-00.txt
Date: Fri, 23 Feb 2001 06:46:08 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Extensible Registry Protocol (XRP)
	Author(s)	: E. Brunner et al.
	Filename	: draft-brunner-xrp-00.txt
	Pages		: 112
	Date		: 22-Feb-01
	
This memo describes a connection-oriented, application layer client-
server protocol for the provisioning and management of objects stored
in a shared top level domain (TLD) central registry.  The protocol
defines a command framework for object management operations and maps
the commands to the objects defined in an extensible object data
model.  The protocol is specified in XML Schema Definition.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-xrp-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-brunner-xrp-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-brunner-xrp-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-brunner-xrp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-brunner-xrp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: The XRP Spec
Date: Thu, 22 Feb 2001 15:33:08 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

has been submitted to the I-D editor. 

The XRP draft should be showing up on the IETF archive shortly.

Until it does, it is available via anonymous ftp from nic-naa.net
[24.95.12.91], and via http from here:

http://world.std.com/~iipc/draft-brunner-xrp-00.txt

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-00.txt
Date: Thu, 22 Feb 2001 07:05:26 -0500
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-00.txt
	Pages		: 23
	Date		: 21-Feb-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-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-ietf-provreg-grrp-reqs-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-ietf-provreg-grrp-reqs-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-ietf-provreg-grrp-reqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-grrp-reqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-00.txt
Date: Thu, 22 Feb 2001 07:05:21 -0500
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-00.txt
	Pages		: 49
	Date		: 21-Feb-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-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-ietf-provreg-epp-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-ietf-provreg-epp-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-ietf-provreg-epp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Wed, 21 Feb 2001 19:41:19 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: implementors list up
Sender: [email-masked]

all:

At the interim meeting we discussed setting up a list of implementors of
EPP/XRP to discuss and exchange information about implementing the various
schemas that have been discussed.

To subscribe send a message [email-masked], the list is a majordomo
list. The list is intended for registries, registrars and software
developers that wish to exchange information and possibly code for EPP/XRP
implementations.

I will probably set up a cvs server and web page if folks have a desire
for it. Once we have a public release we can go use sourceforge some
something like that.

problems, suggestions, etc. just drop me a note.

-rick

Date: Wed, 21 Feb 2001 21:31:14 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Minneapolis time slot
Cc: [email-masked]
Sender: [email-masked]

Our time slot in Minneapolis is *Tuesday* from 5pm-6pm.   (March 20.)

I said the wrong night during the interim meeting yesterday.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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-dn-defn-00.txt
Date: Wed, 21 Feb 2001 06:45:37 -0500
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		: Domain Name and Related Definitions
	Author(s)	: R. Rader
	Filename	: draft-ietf-provreg-dn-defn-00.txt
	Pages		: 7
	Date		: 20-Feb-01
	
Efforts are currently being undertaken to define and formalize 
registry/registrar communications protocols in light of the current 
and evolving scope and utility of DNS, domain name registries and 
related entities. In order for this work to be truly effective and 
broadly applicable, it is important that accepted definitions act as 
the foundation. This document is an attempt to create a starting 
point for the requisite dialogue that will ultimately foster the 
determination and acceptance of these new protocols. This document 
obsoletes <draft-rader-dnwhois-defn-00.txt>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-dn-defn-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-ietf-provreg-dn-defn-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-ietf-provreg-dn-defn-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-ietf-provreg-dn-defn-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-dn-defn-00.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]>
Reply-To: [email-masked], " [email-masked]" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Design Teams
Date: Tue, 20 Feb 2001 17:40:35 -0500
Sender: [email-masked]

One of the topics that came up at today's interim meeting was design team
formation.  The folks in the room though that three design teams would be
appropriate: one focused on protocol design, one focused on protocol
transport, and one focused on security.  Each team will be tasked to produce
a presentation of focus area issues and trade-offs to be discussed at the
March IETF meeting.  Teams of 5-7 people will be selected by our co-chairs
Ed and Jaap, who will confirm selections directly with members and this list
on Monday 26 February or Tuesday 27 February at the latest.

Anyone interested a taking part on one of the design teams MUST send a mail
note to both Ed and Jaap to confirm your interest.  You must identify which
team you wish to contribute to.  It would also be helpful if you also
provided some insights into any special skills that you would bring to the
team.

Here are the e-mail addresses you'll need to state your desire to
participate:

Jaap Akkerhuis <[email-masked]>, Edward Lewis <[email-masked]>

Please send your "I want to participate" requests to them directly, _not_ to
this list.  Issues with the approach discussed at today's meeting should be
sent to the list.

<Scott/> 

Date: Tue, 20 Feb 2001 09:03:28 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Conference Bridge - ProvReg @ Washington, 2/20/01
Cc: [email-masked]
Sender: [email-masked]

>\

Folks,

Scott Hollenbeck has arranged a telephone bridge to today's interim working 
group meeting for ProvReg.  4 remote participants can be supported.

Available:      10am - 5pm, Eastern US time.

Call:           +1.888.790.2032

Leader: Scott Hollenbeck

Code:           Marriott

If you have a problem, call Scott: +1.703.927.0067

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Today's teleconferencing info
Date: Tue, 20 Feb 2001 07:26:57 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott, Bill,

Please post the bridge no and the majik numbers.

Eric

Date: Mon, 19 Feb 2001 18:05:52 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
Sender: [email-masked]

 From the message thread, I am getting the sense that something basic is 
being missed.  Indeed it might be that *I* am the one doing the missing, 
but just in case not...

         Policy vs. mechanism...

It is neither complicated nor unusual to have a mechanism that permits 
separate bags of bits to be labeled, according to some SEPARATELY defined 
policy.

Defining such policies can be quite difficult, but why don't we separate 
that task from the one of simply permitting data "sections", with each 
section having its own label and being subject to possibly separate 
handling policies?

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: Bill Manning <[email-masked]>
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
To: [email-masked] (Hollenbeck, Scott)
Date: Mon, 19 Feb 2001 14:05:50 -0800 (PST)
Cc: [email-masked] ('Bill Manning'), [email-masked]
Sender: [email-masked]

 Hum... don't know where to put it. But it ought to be stated someplace.

% 
% Agreed -- are you suggesting another rewording of [3] or a new requirement
% [4]:
% 
% [4] Some of the social information exchanged between a registrar and
% registry MAY be REQUIRED
% for proper generation of zone files.  Information REQUIRED for proper
% generation of zone files is subject to public disclosure.

--bill

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bill Manning'" <[email-masked]>
Cc: [email-masked]
Subject: RE: grrp-reqs-06, 11. Security Considerations [3]
Date: Mon, 19 Feb 2001 16:44:43 -0500
Sender: [email-masked]

Agreed -- are you suggesting another rewording of [3] or a new requirement
[4]:

[4] Some of the social information exchanged between a registrar and
registry MAY be REQUIRED
for proper generation of zone files.  Information REQUIRED for proper
generation of zone files is subject to public disclosure.

I don't have a problem with moving text like this and [3] out of the
Security Considerations section since it does have more to do with use of
collected data (as Eric noted) than protocol security.  How about adding
section 8.4 for Data Collection and Disclosure Requirements?  I know Eric
asked for a Data Collection Considerations section, but section 8 exists to
capture requirements that don't have an explicit fit anywhere else.  Why not
put them here?

<Scott/> 

-----Original Message-----
From: Bill Manning [mailto:[email-masked]]
Sent: Monday, February 19, 2001 2:57 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]

from the archive:

[3] Some of the social information exchanged between a registrar and
registry can be considered personal, private, or otherwise restricted from
public disclosure.  Disclosure of such information MAY be restricted by laws
and/or business practices.  A generic protocol MUST provide services to
identify social information that is subject to disclosure restrictions
levied by laws and/or business practices.

	-----------------------------------------------------------

Very good.  However, some of the social information may be REQUIRED
for proper generation of zone files. Where this information is required,
it is subject to public disclosure.

From: "Bruce Miner" <[email-masked]>
To: "ietf-provreg" <[email-masked]>
Subject: RE: Tuesday provreg meeting in DC
Date: Mon, 19 Feb 2001 16:03:55 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C09A8D.8F774B00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'll be over around 9:00 am since the meeting room will be open then.

Bruce Miner

------=_NextPart_000_001B_01C09A8D.8F774B00
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I'll be over around 9:00 am since the =
meeting room=20
will be open then.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Bruce Miner</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01C09A8D.8F774B00--

From: Bill Manning <[email-masked]>
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
To: [email-masked] (Hollenbeck, Scott)
Date: Mon, 19 Feb 2001 11:56:33 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

from the archive:

[3] Some of the social information exchanged between a registrar and
registry can be considered personal, private, or otherwise restricted from
public disclosure.  Disclosure of such information MAY be restricted by laws
and/or business practices.  A generic protocol MUST provide services to
identify social information that is subject to disclosure restrictions
levied by laws and/or business practices.

	-----------------------------------------------------------

Very good.  However, some of the social information may be REQUIRED
for proper generation of zone files. Where this information is required,
it is subject to public disclosure.

% 
% Indeed, and that's why I suggested a rewording last week to make the intent
% more explicit:
% 
% http://www.cafax.se/ietf-provreg/maillist/2001-02/msg00169.html
% 
% <Scott/> 
% 
% -----Original Message-----
% From: Bill Manning [mailto:[email-masked]]
% Sent: Monday, February 19, 2001 11:46 AM
% To: [email-masked]
% Cc: [email-masked]; [email-masked]
% Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
% 
% 
%  Yup. I re-read it.
% 	I'm concerned that depending on venue, the level of information
% 	required changes.  DNS baseline vs DNS-TSIG, vs DNS-SIG/KEY
% 	not counting the goofy CERT rr injections for PGP/SSH key
% distribution
% 	will all change the amount of data that will need to be maintained.
% 
% 
% 
% % 
% % Bill,
% % 
% % Have a read of the definitions section ("Thick Registry" specifically),
% % where it describes "technical information" as "information needed to
% produce
% % zone files".
% % 
% % <Scott/>
% % 
% % -----Original Message-----
% % From: Bill Manning [mailto:[email-masked]]
% % Sent: Friday, February 16, 2001 10:27 AM
% % To: [email-masked]
% % Cc: [email-masked]
% % Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
% % 
% % 
% % % 
% % % Eric,
% % % 
% % % The intention of requirement 11-[3] isn't to document that "a mechanism
% % % exists to to distinguish technical from social information", it's
% intended
% % % to note that disclosure of non-technical information may be subject to
% % % restrictions and the protocol needs to provide a way to identify
% % information
% % % that is subject to disclosure restrictions.  This was added at the
% request
% % % of Karl Auerbach.
% % 
% % 	What is the distinction between "technical" and "non-technical"?
% % 	Are these definitions immutatble within/between juristictions?
% % 	Will they withstand legal review?
% % 	In which venues?
% % 
% % --bill
% 

-- 
--bill

To: Bill Manning <[email-masked]>
cc: [email-masked] (Hollenbeck, Scott), [email-masked], [email-masked]
Subject: Re: grrp-reqs-06, 11. Security Considerations [3] 
Date: Mon, 19 Feb 2001 13:28:16 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

So the answer is "many" if the question is "how many distinct flows exist?".

There exist two or more flows within the "technical information", depending
upon the model (Bill's note).

There exist two or more flows within the "social information", depending
upon the model (Eric's note).

So, the reason why we have a "Security Considerations" section, but not a
"Data Collection Considerations" section is ... 

To speak to Bill's earlier question:
% 	What is the distinction between "technical" and "non-technical"?

   Covered, zone vs non, per Scott.

% 	Are these definitions immutatble within/between juristictions?

   IMO no, given the variations between the US, the OEDC and EC data regiemes.

% 	Will they withstand legal review?

   See above.

% 	In which venues?

   See above.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: grrp-reqs-06, 11. Security Considerations [3]
Date: Mon, 19 Feb 2001 12:35:54 -0500
Sender: [email-masked]

Indeed, and that's why I suggested a rewording last week to make the intent
more explicit:

http://www.cafax.se/ietf-provreg/maillist/2001-02/msg00169.html

<Scott/> 

-----Original Message-----
From: Bill Manning [mailto:[email-masked]]
Sent: Monday, February 19, 2001 11:46 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]

 Yup. I re-read it.
	I'm concerned that depending on venue, the level of information
	required changes.  DNS baseline vs DNS-TSIG, vs DNS-SIG/KEY
	not counting the goofy CERT rr injections for PGP/SSH key
distribution
	will all change the amount of data that will need to be maintained.

% 
% Bill,
% 
% Have a read of the definitions section ("Thick Registry" specifically),
% where it describes "technical information" as "information needed to
produce
% zone files".
% 
% <Scott/>
% 
% -----Original Message-----
% From: Bill Manning [mailto:[email-masked]]
% Sent: Friday, February 16, 2001 10:27 AM
% To: [email-masked]
% Cc: [email-masked]
% Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
% 
% 
% % 
% % Eric,
% % 
% % The intention of requirement 11-[3] isn't to document that "a mechanism
% % exists to to distinguish technical from social information", it's
intended
% % to note that disclosure of non-technical information may be subject to
% % restrictions and the protocol needs to provide a way to identify
% information
% % that is subject to disclosure restrictions.  This was added at the
request
% % of Karl Auerbach.
% 
% 	What is the distinction between "technical" and "non-technical"?
% 	Are these definitions immutatble within/between juristictions?
% 	Will they withstand legal review?
% 	In which venues?
% 
% --bill

From: Bill Manning <[email-masked]>
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
To: [email-masked] (Hollenbeck, Scott)
Date: Mon, 19 Feb 2001 08:46:11 -0800 (PST)
Cc: [email-masked] ('Bill Manning'), [email-masked]
Sender: [email-masked]

 Yup. I re-read it.
	I'm concerned that depending on venue, the level of information
	required changes.  DNS baseline vs DNS-TSIG, vs DNS-SIG/KEY
	not counting the goofy CERT rr injections for PGP/SSH key distribution
	will all change the amount of data that will need to be maintained.

% 
% Bill,
% 
% Have a read of the definitions section ("Thick Registry" specifically),
% where it describes "technical information" as "information needed to produce
% zone files".
% 
% <Scott/>
% 
% -----Original Message-----
% From: Bill Manning [mailto:[email-masked]]
% Sent: Friday, February 16, 2001 10:27 AM
% To: [email-masked]
% Cc: [email-masked]
% Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
% 
% 
% % 
% % Eric,
% % 
% % The intention of requirement 11-[3] isn't to document that "a mechanism
% % exists to to distinguish technical from social information", it's intended
% % to note that disclosure of non-technical information may be subject to
% % restrictions and the protocol needs to provide a way to identify
% information
% % that is subject to disclosure restrictions.  This was added at the request
% % of Karl Auerbach.
% 
% 	What is the distinction between "technical" and "non-technical"?
% 	Are these definitions immutatble within/between juristictions?
% 	Will they withstand legal review?
% 	In which venues?
% 
% --bill
% 

-- 
--bill

To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Tuesday provreg meeting in DC
Date: Mon, 19 Feb 2001 09:56:27 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

All,

I won't be able to attend tomorrow's meeting.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: The agenda so far
Date: Sat, 17 Feb 2001 12:21:10 -0500
Sender: [email-masked]

We will have an LCD projector at our disposal.  I'll have a laptop with me
as I'm sure others will.

<Scott/> 

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Saturday, February 17, 2001 11:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: The agenda so far
> 
> 
> At 2:13 PM -0500 2/16/01, Rick H Wesson wrote:
> >would you please post the revised agenda for the meeting.
> 
>  9am  Pre-meeting gathering
> 
> 10am  Agenda bashing:                             10 min
>          Name the scribe...
>       WG status:                                   5 min
>       Requirements Document - Remaining Issues    15 min (tops)
>       The EPP proposal                            as needed
>       Neustar's XRP                               as needed
>       Short lunch break                           30 min to 
> get food, etc.
>       (Other proposals)                           as needed
>       Discussion of forming a design team         as needed
> 
> I haven't gotten any other requests for items.
> 
> During the pre-meeting, it would be good to identify topics 
> that we want to
> cover during the day - we are still getting comments on 
> requirements, so I
> think we should spend some time on that.
> 
> As far as logistics - Scott, do we have any display 
> equipment?  Overhead
> projector or screen projector?  Apparently there is a pizza 
> franchise in
> the hotel, that might be lunch for us.
> 
> Remember that this meeting supplements the mailing list discussion.
> Nothing will be finalized at the meeting and meeting notes 
> are due to the
> list with 10 (or was it 15) days of the meeting.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: RE: The agenda so far 
Date: Sat, 17 Feb 2001 12:20:11 -0500
Sender: [email-masked]

Works for me, especially since there has been no other comment provided on
the list.

<Scott/> 

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Saturday, February 17, 2001 12:10 PM
> To: Edward Lewis
> Cc: [email-masked]; [email-masked]
> Subject: Re: The agenda so far 
> 
> 
> Ed,
> 
> Scott and I can't seem to find a common ground for the i18n and data
> collection issue, 5 minutes for each to (re-)state the problem, and
> get sense-of-room, possibly at wrap-up.
> 
> Eric
> 

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: The agenda so far 
Date: Sat, 17 Feb 2001 12:09:55 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

Scott and I can't seem to find a common ground for the i18n and data
collection issue, 5 minutes for each to (re-)state the problem, and
get sense-of-room, possibly at wrap-up.

Eric

Date: Sat, 17 Feb 2001 11:11:21 -0500
To: <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: The agenda so far
Cc: [email-masked]
Sender: [email-masked]

At 2:13 PM -0500 2/16/01, Rick H Wesson wrote:
>would you please post the revised agenda for the meeting.

 9am  Pre-meeting gathering

10am  Agenda bashing:                             10 min
         Name the scribe...
      WG status:                                   5 min
      Requirements Document - Remaining Issues    15 min (tops)
      The EPP proposal                            as needed
      Neustar's XRP                               as needed
      Short lunch break                           30 min to get food, etc.
      (Other proposals)                           as needed
      Discussion of forming a design team         as needed

I haven't gotten any other requests for items.

During the pre-meeting, it would be good to identify topics that we want to
cover during the day - we are still getting comments on requirements, so I
think we should spend some time on that.

As far as logistics - Scott, do we have any display equipment?  Overhead
projector or screen projector?  Apparently there is a pizza franchise in
the hotel, that might be lunch for us.

Remember that this meeting supplements the mailing list discussion.
Nothing will be finalized at the meeting and meeting notes are due to the
list with 10 (or was it 15) days of the meeting.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: grrp-reqs-06, 11. Security Considerations [3] 
Date: Fri, 16 Feb 2001 22:41:00 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

If the remedy is well-defined in whatever legal arrangement exists between
the parties involved, then there is no protocol requirement.

I appreciate that you were attempting to address Karl's concern, but Karl
isn't the sharpest knife in the drawer, and policy without mechanism is
de rigeur in Privacy Advocacy Circles, but [3] doesn't appear to mean any
thing in particular.

How many data collection policy octets per session instantiation is "too
much" overhead?

The whole of the P3P vocabulary we mapped onto cookies is (maximally) 53,
of which 18 may take on 3 possible modifiers, so with all pathological
possibilities left in, the range of distinct values fits in 7 familiar bits.
XMLification can expand that almost infinitely, as it can anything.

How many policy and jurisdictional scope octets per transaction is "too
much" overhead?

As I mentioned, your reaching for OIDs and URI's is unnecessary, the number
of meaningfully distinct statutory and existing business practice data
collection models is very finite, smaller than the number of ICANN accredited
registrars. We already have their identifiers, we're just per-hop (few of
those to boot) picking an index into a well-known array of data collection
statutory and business models. Fits on a small pin, possibly the pointy end,
modulo the subsequent Baroque splendor of XMLification.

> The issue I am trying to address is one of privacy WRT what a registry can
> do with social data. 

Different issue, different section. My problem isn't one of a registry's
access, but of a registrant's authorization. Data originates policied, it
isn't apolicied until a registry (or registrar) makes a grant of policy to
it.

Please also see "purpose", "retention", and "access", in my notes to Jordyn,
your whois example only touches on "recipient", not repurposing, persistence,
or originator modification.

"A registry ... may allow registrants to opt-out", now there's an idea.

The rewording of [3] is different, but it isn't sufficient to prevent any
R-* social information collector from becomming an on-line marketeer, or
from merging off-line data with on-line data.

Well, I've tried twice. As an author of the cpexchange work, which attempts
onward-transport, _exactly_ what provreg is attempting, modulo the nuance
that some data ends up in zone files, and fewer registries exist than CRM
and list manager back ends, and an author of the p3p work, particularly the
namespace-, method-, and state-specific portions of putting policy into the
initial data collection, I'm disapointed.

I'll put out a seperate requirements draft by Friday, which is easier than
iterating on inadequate wording.

Cheers,
Eric

To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Agenda for Interim Meeting 
Date: Fri, 16 Feb 2001 16:53:12 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed, and Jaap,

>      Agenda bashing: (short)
>      WG status: (short)
>      The EPP proposal
>      Other proposals
>      Discussion of forming a design team
> 
> Comments?

Yes. Under "Other proposals" Neustar's XRP.

Eric

To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Tuesday provreg meeting in DC 
Date: Fri, 16 Feb 2001 16:00:59 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Yes. But only if you can prove:
	a) jurisdictionally appropriate age,
	b) the ability to express a data collection policy on a napkin
		(both sides may be used if expressed in xml),
and
	c) Unicode fluency after sufficient labelprep.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Tuesday provreg meeting in DC 
Date: Fri, 16 Feb 2001 14:47:43 -0500
Sender: [email-masked]

Eric's supplying the beer for a Monday night bar BOF?

<Scott/> 

> -----Original Message-----
> From: Jaap Akkerhuis [mailto:[email-masked]]
> Sent: Friday, February 16, 2001 1:21 PM
> To: Dave Crocker; [email-masked]
> Subject: Re: Tuesday provreg meeting in DC 
> 
> 
> 
>     
>     I'kll bette, I'm flying in the nigt before (and leave 
> tuesday evening).
> 
> H'mm, keyboard failure, actually, pilot error with new 
> keyboard. I'll try again.
> 
> I'll be there probably early (like Scott). I'm flying in the night
> before and will be around (So Eric can buy me a beer).
> 
> 	jaap
> 

Date: Fri, 16 Feb 2001 11:34:57 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: Tuesday provreg meeting in DC
Sender: [email-masked]

At 09:02 AM 2/16/2001, Dave Crocker wrote:
>Since the meeting room will be available from 9am, I'm planning to show up 
>then.

Folks,

I was just asked where the meeting was, so here's the details, posted in:

         <http://www.cafax.se/ietf-provreg/maillist/2001-01/msg00188.html>

         Washington Dulles Airport Marriott

         Tuesday 20 February, 10am - 5pm.

That's about as far West of D.C. and Baltimore-Washington International 
Airport (BWI) is East of D.C...

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Fri, 16 Feb 2001 11:13:08 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: Jaap Akkerhuis <[email-masked]>, Dave Crocker <[email-masked]>, <[email-masked]>
Subject: Re: Tuesday provreg meeting in DC
Sender: [email-masked]

Ed,

would you please post the revised agenda for the meeting.

thanks,

-rick

On Fri, 16 Feb 2001, Edward Lewis wrote:

> I'll probably be a late arrival (compared to 9), I should be able to be
> there by 10 but will try to get there earlier.  I fear that any attempt to
> get there close to 9 am will be thwarted by the DC Beltway.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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: Fri, 16 Feb 2001 13:47:41 -0500
To: Jaap Akkerhuis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Tuesday provreg meeting in DC
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

I'll probably be a late arrival (compared to 9), I should be able to be
there by 10 but will try to get there earlier.  I fear that any attempt to
get there close to 9 am will be thwarted by the DC Beltway.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Bill Manning <[email-masked]>
Subject: Re: Tuesday provreg meeting in DC
To: [email-masked] (Dave Crocker)
Date: Fri, 16 Feb 2001 10:37:35 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

Is there a conference bridge? If so, what are the majik numbers?

-- 
--bill

To: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Tuesday provreg meeting in DC 
Date: Fri, 16 Feb 2001 19:21:15 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    I'kll bette, I'm flying in the nigt before (and leave tuesday evening).

H'mm, keyboard failure, actually, pilot error with new keyboard. I'll try again.

I'll be there probably early (like Scott). I'm flying in the night
before and will be around (So Eric can buy me a beer).

	jaap

To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: Tuesday provreg meeting in DC 
Date: Fri, 16 Feb 2001 19:12:46 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Since the meeting room will be available from 9am, I'm planning to show up 
    then.
    
    Is anybody else similarly inclined, to get discussion going early?

I'kll bette, I'm flying in the nigt before (and leave tuesday evening).

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: grrp-reqs-06, 11. Security Considerations [3] 
Date: Fri, 16 Feb 2001 12:42:39 -0500
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Friday, February 16, 2001 11:36 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]; [email-masked]
>Subject: Re: grrp-reqs-06, 11. Security Considerations [3] 
>
>
>Scott,
>
>Well I knew it wasn't added at my request as I recall mentioning onward
>transport, jurisdictional issues, and data collection at San Diego.
>
>You make two points:
>
>	1. a mechanism capable of articulating a policy is not necessary
>	   for session policing (A & I excepted, naturally), as contract
>	   enforcement is available.
>
>	2. a mechanism capable of articulating data collection policy or
>	   the applicable jurisdiction of the data providor and 
>collector
>	   would be complex.
>
>Having finished last November a consortia activity for the 
>bulk transport
>of customer profile data, which presumes the data originates from http
>activity policed via P3P, and which looks dead similar to our notion of
>social information, I'm convinced neither point is defensible.
>
>Consider the case of intra-entity social data flows, the 
>motivation that
>brought IBM and HP to CPExchange, which is equivalent to the problem
>NSI-as-Registrar and NSI-as-Registry-Operator face. How does 
>contract law
>protect the participants? J-Random-Reseller originates 
>Registrant-J's data
>to NSI-as-Registrar, which onward-transports J's data to 
>NSI-as-Registry,
>and a policy botch is detected. Is the remedy J or 
>J-Random-Reseller forcing
>NSI-as-Registrar to sue NSI-as-Registry for breach or specific 
>performance?

The remedy should be well-defined in whatever legal arrangement exists
between the parties involved.

>Next, consider the case of inter-entity social data flows, without any
>jurisdictional complications (67 RegistRARs and one Registry merrily
>playing in CONUS only). No entity may make recourse to transaction- or
>session-specific mechanisms to associate policy (other than A 
>& I, sigh)
>with any datum. Everything better look like a nail.
>
>Finally, the above with jurisdictional complications, Sven 
>Moers in Berlin
>goes to a local reseller who uses Harald Alvestrand's 
>Oslo-based regional
>reseller who uses a UK-based Registrar to access a US-based 
>Registry. All
>hypothetical, but in real life Sven works at the Berlin Data Protection
>office. Jurisdiction shopping (the communicating parties have 
>some sort of
>legal arrangement in place) will either be entertaining, or 
>everything better
>look like a Deleware Nail.
>
>Do you assert that there no requirement for data collection 
>considerations,
>equivalent to your first point?

If I made that assertion the current requirement [3] (though I agree that
the meaning may not be clear; see below) would not exist, and my offer to
create such a section would not have been made.  

>(as I understand your first point, typing words on someone 
>else's keyboard
>at least as error-prone as typing on myown keyboard)
>
>If so then there is no reason to look at any mechanism to see 
>if one or more
>offer tractible solutions to an inextant requirement, however 
>I can't help
>but point out that from draft-jaye-http-trust-state-mgt-01.txt 
>to Section 4
>of the P3P CR draft we managed to express data collection in a 
>few bytes,
>and we've fewer than the old RIP limit on the number of 
>hops-to-Registry, so
>record route is also tractible, and if we look at the set of 
>meaningfully
>distinct statutory or contractual data collection practices, 
>the range of
>usefully unique identifiers hardly motivates OIDs or URIs or other junk
>in-band.
>
>I wouldn't have made the suggestion if I hadn't already 
>written the dtds,
>and morphing the syntax to asn.1 or bnf, or schema is 
>standards overhead,
>not operational overhead.

True, but moving policy identification data around _is_ operational
overhead, and I'm not convinced that it's necessary overhead in this
environment.

>Eric
>
>P.S. Just what exactly does [3] assert as a requirement other 
>than there
>     exists a mechanism exists to to distinguish technical from social
>     information? When I read it I thought "that doesn't say 
>anything the
>     cutting room floor doesn't already say -- data that 
>didn't get into
>     the zone file". Delete for lack of distinct meaning.

The issue I am trying to address is one of privacy WRT what a registry can
do with social data.  [3] is supposed to assert that the protocol must
provide a way to identify specific social data elements that require special
handling based on privacy policies.  For example, a registry's policy may
require publication of a registrant's name via whois or protocol query, but
it may allow registrants to opt-out of having other social information (such
as address and/or telephone number) published via whois or protocol query.
Would this re-wording be more clear:

[3] Some of the social information exchanged between a registrar and
registry can be considered personal, private, or otherwise restricted from
public disclosure.  Disclosure of such information MAY be restricted by laws
and/or business practices.  A generic protocol MUST provide services to
identify social information that is subject to disclosure restrictions
levied by laws and/or business practices.

<Scott/>

To: Dave Crocker <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Tuesday provreg meeting in DC 
Date: Fri, 16 Feb 2001 12:29:25 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I'll be in-hotel early evening, Monday.

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Tuesday provreg meeting in DC
Date: Fri, 16 Feb 2001 12:16:48 -0500
Importance: Normal
Sender: [email-masked]

Yes, I will be there at 9am.  Any suggestions as to what we could bring to
make this meeting move along??  (Besides a cattle prod :-) )

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Dave Crocker
Sent: Friday, February 16, 2001 12:03 PM
To: [email-masked]
Subject: Tuesday provreg meeting in DC
Importance: High

Since the meeting room will be available from 9am, I'm planning to show up
then.

Is anybody else similarly inclined, to get discussion going early?

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Tuesday provreg meeting in DC
Date: Fri, 16 Feb 2001 12:10:45 -0500
Sender: [email-masked]

I'll be there, probably at 8 or so make sure it all comes together on time.

<Scott/>

>-----Original Message-----
>From: Dave Crocker [mailto:[email-masked]]
>Sent: Friday, February 16, 2001 12:03 PM
>To: [email-masked]
>Subject: Tuesday provreg meeting in DC
>Importance: High
>
>
>Since the meeting room will be available from 9am, I'm 
>planning to show up 
>then.
>
>Is anybody else similarly inclined, to get discussion going early?

Date: Fri, 16 Feb 2001 09:02:30 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Tuesday provreg meeting in DC
Sender: [email-masked]

Since the meeting room will be available from 9am, I'm planning to show up 
then.

Is anybody else similarly inclined, to get discussion going early?

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: grrp-reqs-06, 11. Security Considerations [3] 
Date: Fri, 16 Feb 2001 11:35:47 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Well I knew it wasn't added at my request as I recall mentioning onward
transport, jurisdictional issues, and data collection at San Diego.

You make two points:

	1. a mechanism capable of articulating a policy is not necessary
	   for session policing (A & I excepted, naturally), as contract
	   enforcement is available.

	2. a mechanism capable of articulating data collection policy or
	   the applicable jurisdiction of the data providor and collector
	   would be complex.

Having finished last November a consortia activity for the bulk transport
of customer profile data, which presumes the data originates from http
activity policed via P3P, and which looks dead similar to our notion of
social information, I'm convinced neither point is defensible.

Consider the case of intra-entity social data flows, the motivation that
brought IBM and HP to CPExchange, which is equivalent to the problem
NSI-as-Registrar and NSI-as-Registry-Operator face. How does contract law
protect the participants? J-Random-Reseller originates Registrant-J's data
to NSI-as-Registrar, which onward-transports J's data to NSI-as-Registry,
and a policy botch is detected. Is the remedy J or J-Random-Reseller forcing
NSI-as-Registrar to sue NSI-as-Registry for breach or specific performance?

Next, consider the case of inter-entity social data flows, without any
jurisdictional complications (67 RegistRARs and one Registry merrily
playing in CONUS only). No entity may make recourse to transaction- or
session-specific mechanisms to associate policy (other than A & I, sigh)
with any datum. Everything better look like a nail.

Finally, the above with jurisdictional complications, Sven Moers in Berlin
goes to a local reseller who uses Harald Alvestrand's Oslo-based regional
reseller who uses a UK-based Registrar to access a US-based Registry. All
hypothetical, but in real life Sven works at the Berlin Data Protection
office. Jurisdiction shopping (the communicating parties have some sort of
legal arrangement in place) will either be entertaining, or everything better
look like a Deleware Nail.

Do you assert that there no requirement for data collection considerations,
equivalent to your first point?

(as I understand your first point, typing words on someone else's keyboard
at least as error-prone as typing on myown keyboard)

If so then there is no reason to look at any mechanism to see if one or more
offer tractible solutions to an inextant requirement, however I can't help
but point out that from draft-jaye-http-trust-state-mgt-01.txt to Section 4
of the P3P CR draft we managed to express data collection in a few bytes,
and we've fewer than the old RIP limit on the number of hops-to-Registry, so
record route is also tractible, and if we look at the set of meaningfully
distinct statutory or contractual data collection practices, the range of
usefully unique identifiers hardly motivates OIDs or URIs or other junk
in-band.

I wouldn't have made the suggestion if I hadn't already written the dtds,
and morphing the syntax to asn.1 or bnf, or schema is standards overhead,
not operational overhead.

Eric

P.S. Just what exactly does [3] assert as a requirement other than there
     exists a mechanism exists to to distinguish technical from social
     information? When I read it I thought "that doesn't say anything the
     cutting room floor doesn't already say -- data that didn't get into
     the zone file". Delete for lack of distinct meaning.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bill Manning'" <[email-masked]>
Cc: [email-masked]
Subject: RE: grrp-reqs-06, 11. Security Considerations [3]
Date: Fri, 16 Feb 2001 10:32:06 -0500
Sender: [email-masked]

Bill,

Have a read of the definitions section ("Thick Registry" specifically),
where it describes "technical information" as "information needed to produce
zone files".

<Scott/>

-----Original Message-----
From: Bill Manning [mailto:[email-masked]]
Sent: Friday, February 16, 2001 10:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]

% 
% Eric,
% 
% The intention of requirement 11-[3] isn't to document that "a mechanism
% exists to to distinguish technical from social information", it's intended
% to note that disclosure of non-technical information may be subject to
% restrictions and the protocol needs to provide a way to identify
information
% that is subject to disclosure restrictions.  This was added at the request
% of Karl Auerbach.

	What is the distinction between "technical" and "non-technical"?
	Are these definitions immutatble within/between juristictions?
	Will they withstand legal review?
	In which venues?

--bill

From: Bill Manning <[email-masked]>
Subject: Re: grrp-reqs-06, 11. Security Considerations [3]
To: [email-masked] (Hollenbeck, Scott)
Date: Fri, 16 Feb 2001 07:26:41 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

% 
% Eric,
% 
% The intention of requirement 11-[3] isn't to document that "a mechanism
% exists to to distinguish technical from social information", it's intended
% to note that disclosure of non-technical information may be subject to
% restrictions and the protocol needs to provide a way to identify information
% that is subject to disclosure restrictions.  This was added at the request
% of Karl Auerbach.

	What is the distinction between "technical" and "non-technical"?
	Are these definitions immutatble within/between juristictions?
	Will they withstand legal review?
	In which venues?

--bill

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, [email-masked]
Subject: RE: grrp-reqs-06, 9. Internationalization Considerations
Date: Fri, 16 Feb 2001 09:58:53 -0500
Sender: [email-masked]

Eric,

Instead of waiting for the alternative text I requested from you for 9-[1],
I've looked into rewriting it completely.  How does this strike you?:

[1] [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.

<Scott/>

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Wednesday, February 14, 2001 11:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: grrp-reqs-06, 9. Internationalization Considerations

  [1] Current Internet standards restrict the encoding of Internet host
  and domain names to a subset of the 7-bit US-ASCII character set.

Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a.
                                -      0-9       A-Z       a-z
We may as well mention ASCII case folding, 1035 has a reasonable Note
at the end of 2.3.1 Preferred name syntax.

  Registries and registrars now serve customers whose native languages
  require encodings other than US-ASCII, which automatically disallows  
  use of those languages when registering host and domain names.

Awkward language, what is it that "which" refers to? The "US-ASCII"
restricition, first sentence. If the subordinate clause is phrased
as a sentence ... 

  Support for internationalized host and domain names will greatly
  increase world-wide usability of a generic registry registrar
  protocol, so standards for exchanging internationalized information
  MUST be considered during the protocol design process.

Apple pie, but we don't actually state (or cite) what "internationalized"
means, yet, and the jump from "host and domain names" (technical data) to
social data (a subset of) "internationalized information" is left as an
exercise to the reader.

We could state:

	a. The protocol will support any encoding of technical and/or
	   social data, (code-set independent, or csi)
or
	b. The protocol will support some encodings (list) of technical
	   data, and some, possibly different, encodings (list) of social
	   data, (code-set dependent, or csd)
or
	c. The protocol will not support some encodings (list) of
	   technical data, and will not support some, possibly different,
	   encodings (list) of social data,

>From Deng Xiang's response we know that UTF8 encodings of technical data
is a requirement of a provreg protocol deployed by the .CN ccTLD Registry
and Registrars.

It is possible that the range of encodings for social data includes GBK
and Big5 as well as UTF8.

[snip]

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: grrp-reqs-06, 3.2 Identification and Authentication [3]
Date: Fri, 16 Feb 2001 08:58:31 -0500
Importance: Normal
Sender: [email-masked]

It sounds fine to me.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Hollenbeck, Scott
Sent: Friday, February 16, 2001 8:39 AM
To: [email-masked]
Subject: RE: grrp-reqs-06, 3.2 Identification and Authentication [3]

Are there any objections to Andre's proposed re-wording?

<Scott/>

-----Original Message-----
From: Andre Cormier [mailto:[email-masked]]
Sent: Wednesday, February 14, 2001 5:02 PM
To: Kent Crispin
Cc: [email-masked]; Eric Brunner-Williams in Portland Maine
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

Here's a proposition:

Lets change 
  [3] The protocol or another layered protocol MUST provide services to
      negotiate an identification and authentication mechanism
acceptable to
      both the server and the client.

To
  [3] The protocol or another layered protocol MUST provide services to
      negotiate an authentication mechanism acceptable to both the
server
      and the client.

[snip]

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: grrp-reqs-06, 11. Security Considerations [3]
Date: Fri, 16 Feb 2001 08:51:49 -0500
Sender: [email-masked]

Eric,

The intention of requirement 11-[3] isn't to document that "a mechanism
exists to to distinguish technical from social information", it's intended
to note that disclosure of non-technical information may be subject to
restrictions and the protocol needs to provide a way to identify information
that is subject to disclosure restrictions.  This was added at the request
of Karl Auerbach.

I have strong reservations against adding requirements to carry specific
policy or jurisdictional identification information because I believe this
would add a layer of complexity that we don't need on a per-transaction or
per-session basis.  For example, data use and data retention are a matter of
operational regulatory policy that is enforced by contract in some
environments.  Perhaps it's not that way in all environments (other
opinions, please?), but is it something that needs to be carried around in
the protocol when the communicating parties have some sort of legal
arrangement in place?

I wouldn't object to moving 11-[3] (or a rewording of it) to a new section,
though.  I just don't want to open a can of worms that will eventually
require us to create OIDs or URIs or whatever and associated documentation
to describe the policies behind those identifiers.

<Scott/>

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Thursday, February 15, 2001 7:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: grrp-reqs-06, 11. Security Considerations [3]

Scott,

Elsewhere we've established the division between technical and social
information (zone files vs billing files).

We can be specific about the minimum necessary data collection and
onward-transport policies for technical data.

We can be specific about the minimum necessary data collection and
onward-transport policies for social data,  

What your [3] manages is simply to assert a mechanism exists to to
distinguish technical from social information.

I propose that [3] be removed from Section 11, and a section added
with the requirements statements attempted in [3] revised and placed
in this new section.

1x. Data Collection Considerations

  [1] The protocol MUST allow each data transfer to include aggregations of
  information identifying the parties exchanging data, information about the
  jurisdiction of each party, and the data collection policies applicable to
  different pieces of data in the exchange.

  [2] The protocol MUST allow aggregations of specific policy
characteristics
  that describe how data can be used, how long data can be retained, who may
  be a recipient of the data, and the data access available to the data's
  originator.

This will allow a "record route" like feature for onward transport after
initial information collection, "signed" jurisdictionally and for business
practices for technical and social information [1],

and

This will allow object-specific expression of applicable data collection
policies (purpose/recipient/retention/access) [2].

Cheers,
Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: grrp-reqs-06, 3.2 Identification and Authentication [3]
Date: Fri, 16 Feb 2001 08:38:50 -0500
Sender: [email-masked]

Are there any objections to Andre's proposed re-wording?

<Scott/>

-----Original Message-----
From: Andre Cormier [mailto:[email-masked]]
Sent: Wednesday, February 14, 2001 5:02 PM
To: Kent Crispin
Cc: [email-masked]; Eric Brunner-Williams in Portland Maine
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

Here's a proposition:

Lets change 
  [3] The protocol or another layered protocol MUST provide services to
      negotiate an identification and authentication mechanism
acceptable to
      both the server and the client.

To
  [3] The protocol or another layered protocol MUST provide services to
      negotiate an authentication mechanism acceptable to both the
server
      and the client.

[snip]

Date: Thu, 15 Feb 2001 12:17:21 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: Martin Oldfield <[email-masked]>
cc: <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

> >>>>> "Sheer" == Sheer El-Showk <[email-masked]> writes a splendid
> >>>>> email in which the benefits of assigning each object in the
> >>>>> registry its own key are discussed. (I hope that's not too great
> >>>>> a misrepresentation.)

First Martin, thank you for your very flatteringly phrased summary.

I havn't gone over my email since reading your comments and its quite
possible I gave the wrong impression in it because we are, in reality, in
complete accord.  In no way did I envision every registry object having a
key associated with it.  Rather, the keys belong to real-word individuals
or entities and are used to sign registry objects to denote ownership.
That is, as a person (not a contact or an SLD holder or whatever), I have
a public key which (whether generated by a registrar on my behalf as has
been suggested by some, or a personal one) I use to tag a registry
entities over which I have authorities (which would be all the contacts
assocaited with me as a person, all domains I own, and any nameservers in
those domains).  When I transfer these entities (actually only domains can
be transfered) the registry must propagate the key change itself through
all dependent entities (this is much simpler than its sounds -- even in a
fat registries Contacts are not attributes of a domain, they are seperate
records referenced by domains and their ownership does not change with
domain ownership -- the only thing that has to be done is to change the
key on the nameservers under that domain).  That way the old owner has no
ability to affect the domains anymore.

Does this cover your concerns or did I misunderstand something you said.

Regards,
Sheer El-Showk

>
> I think there are two other disadvantages of this approach when
> compared to a scheme in which `contacts' (for want of a better word)
> authenticate themselves, and access rights are confered on the basis
> of the inter-object relationships.
>
> 1. Typically the registrant will have a whole bunch of objects in the
>    database. If each one of these has its own key, then I think most
>    registrants will get confused.
>
> 2. Concentrating on the case of a domain being transfered for a
>    moment, I think giving the domain its own key makes this harder. If
>    registrant A sells the domain to B, then after the sale A really
>    shouldn't have access rights. If the access to the domain is
>    controlled on the basis of its contacts then all well and good; if
>    its on the basis of a public key then one needs to ensure that all
>    the key management happens in synchrony.
>
> Cheers,
> --
> Martin Oldfield,
> AdamsNames Ltd.
>

To: [email-masked]
cc: [email-masked]
Subject: grrp-reqs-06, 11. Security Considerations [3]
Date: Thu, 15 Feb 2001 19:50:38 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Elsewhere we've established the division between technical and social
information (zone files vs billing files).

We can be specific about the minimum necessary data collection and
onward-transport policies for technical data.

We can be specific about the minimum necessary data collection and
onward-transport policies for social data,  

What your [3] manages is simply to assert a mechanism exists to to
distinguish technical from social information.

I propose that [3] be removed from Section 11, and a section added
with the requirements statements attempted in [3] revised and placed
in this new section.

1x. Data Collection Considerations

  [1] The protocol MUST allow each data transfer to include aggregations of
  information identifying the parties exchanging data, information about the
  jurisdiction of each party, and the data collection policies applicable to
  different pieces of data in the exchange.

  [2] The protocol MUST allow aggregations of specific policy characteristics
  that describe how data can be used, how long data can be retained, who may
  be a recipient of the data, and the data access available to the data's
  originator.

This will allow a "record route" like feature for onward transport after
initial information collection, "signed" jurisdictionally and for business
practices for technical and social information [1],

and

This will allow object-specific expression of applicable data collection
policies (purpose/recipient/retention/access) [2].

Cheers,
Eric

Date: Thu, 15 Feb 2001 07:34:57 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Feb 14, 2001 at 06:58:02PM -0500, Sheer El-Showk wrote:
[discussion of using PKI methods]

It's interesting to note that this stuff was disccused for the CORE SRS
at great length, in the context of what were called "Zone Keys" - a zone
key is a public key associated with a zone that authorizes updates. 
Here's an informal paper I wrote a couple of years ago.  It may
contribute something to this discussion:

	             Pros and Cons of NULL Zone Keys

This document compares two alternative models for the registrar-registry
protocol.

The first model is the "Optional Zone Key" (Optional) model.  The
second is the "Mandatory Zone Key" (Mandatory) model. 

1. Common assumptions

Both models assume that 

    1) a domain record in the registry db has a field called "zone key"
    that contains a cryptographic key that can be used to verify
    digital signatures. 

    2) there is a "current registrar" field in the domain record that
    identifies the registrar currently representing the domain.  A 
    database of corresponding registrar keys is kept, so that 
    registrar signatures may be verified.

    3) a registrar signature is necessary for any transaction. 

    4) in addition, if there is a non-NULL key in the "zone key"
    field, any transaction for that domain *must* have a valid "zone
    signature".

Furthermore, both models have a serious potential for disputes to
arise when a user without a zone key wishes to change registrars. 

2.	Optional Zone Keys

In this model a domain record may have a NULL zone key.  In such a
case, only the registrar signature is checked.  If the request is not
correctly signed by the registrar identified in the "current
registrar" field, the request is ignored. 

The primary advantage of this model is simplicity.

The primary problem with this model is that changing the value of the
"current registrar" field cannot be done without either the
cooperation of the current registrar, or involving a dispute that goes
to the registry.  More fundamentally, however, this is really just a
manifestation of the fact that the domain owner has *no* mechanical(*)
way of proving his identity. 

(*) A "mechanical" method is something that can be accomplished 
without involving human beings in the loop.

3.	Mandatory Zone Keys

In this model, *every* domain record in the registry db is required to have
a unique zone key.  Every request to modify data for the domain must
be signed by that key.  Since it is realized that the majority of
domain owners do not and will not provide a zone key, and will not
sign their requests, in the Mandatory model registrars are required to
generate unique private keys for such customers, install such keys as
the zone key, send a copy of the key back to the customer, and
securely keep a copy for the customer. 

The primary advantage of this model is that every customer has
available to them a mechanical method to change registrars, without
involving the old registrar. 

However, there are several significant problems:

    1) there is no simple, secure way to send the generated private
    key back to a user who doesn't use public key (PK) cryptography.

    2) Since, by construction, the users involved are not knowledgable
    about PK and digital signature, they are unlikely to properly
    protect and preserve the key sent back to them. 

    3) Also, these users are unlikely to make use of the opportunity
    offered to them, since they would have to climb a learning curve
    to do so.

    4) Assuming the user does learn about digital signatures, and
    wants to change registrars, the old registrar still has the zone
    key -- the user has to change the zone key, as well. 

    5) The big one -- every registrar has to *securely* maintain a
    database of private keys.  While this can be largely automated, it
    adds a great deal of complexity to do so, and opens up other
    liability issues. 

4.	Disputes

The interesting case is when a user who does not have (or has lost) a
zone key wants to change to a different registrar.  This is because
the simplest way for a user to handle a disagreement with a registrar
is to go to another registrar. 

With the Optional model there are two classes of users:

	1) those who knowledgably use digital signatures, and

	2) those who do not use digital signatures at all. 

With Mandatory model there are three classes of users: 

	1) those who knowledgably use digital signatures, 

        2) those who don't receive, or simply won't learn to use their
        private key (some customers may very well elect to not get
        their private key, since it will have to be sent in the clear
        if the customer doesn't already have PK technology under
        command), and

	3) those who have received a private key from their registrar, and 
	keep it, don't know how to use it, but could learn if necessary.

Note that the description of classes 1 and 2 are essentially the same
under both models. 

Class 1 (knowledgable digital signature users) cause very little
problem to either model.  I expect the size of class 1 to be slightly
larger in the Mandatory model than in the Optional model (because
there will be slightly more incentive to learn about digital
signatures), but probably not significantly larger. 

Class 2 users comprise the largest class in either model, though we
can expect the Mandatory model to have a significantly lower
percentage of class 2 users than the Optional model (the class 3 users
have to come from somewhere).  It is my belief that, from a policy and
dispute resolution point of view, class 2 users are essentially
identical in both models.  Both models will need to devise a
non-mechanical inter-registrar domain transfer protocol for class 2
users, and the existence or non-existence of a zone key is the most
trifling of technical details for this protocol. 

While the policy and dispute resolution procedures will be very
similar, there is substantially less incentive for a registrar to try
to "lock in" customers under the Mandatory model.  This is because a
registrar will have to assume that the user has a zone key and can
change registrar independently. 

However, in *any* case the incentive for a registrar to lock in
customers will be very low.  One of the most widely trumpeted
characteristics of the gTLD registries is domain name portability. 
Any registrar with a pattern of interfering with this property will
certainly be in conflict with the gTLD MoU, and such a pattern will
quickly be noticed and reported by customers.  The consequences would
be dire, the reward very small. 

Class 3 users are unique to the Mandatory model.  The problem they
present is key management and consulting load.  Not only will the
registrar have to worry about sending private keys in the clear to
their customers (with whatever liability a clever lawyer can make of
it), but they will be duty-bound to answer questions about the use of
that key. 

There is also a class of disputes/liabilities involved in maintaining
a key ring on behalf of a customer.  A compromised key allows
modifications to the domain; but there is no way of telling where that
modification came from.  The thief can send a modification request to
any registrar, and it will be accepted without question.  So a user
who screws up their own domain can claim that the registrar exposed
the key, and someone else (a key thief) did the damage.  In general,
it would be very hard for a registrar to prove that they did *not*
expose the keys -- the registrars employees need to sign requests on
behalf of their customers who don't use keys, so the security of the
key database is always going to be a problem.  Consider the anonymous,
untraceable damage a disgruntled registrar employee could cause. 

Of course, in the Optional model a disgruntled registrar employee can
cause damage as well, through misuse of the registrar key (which
employees will need to access).  However, it is *much* easier to
change a single registrar key when an employee leaves, than it is to
change thousands of zone keys.  [Technical note -- this is why you
store a registrar ID in a domain record, instead of a registrar KEY...]

5.	Summary

The issues are complex, unfortunately.  I have a significant bias 
towards the optional model, and I am afraid I may have slanted this 
document.

But, even so, I have to say that I think that scale clearly tips
toward the Optional model.  The disputes it allows are still largely
present in the Mandatory model (though perhaps in somewhat diminished
numbers), but it is simpler for the registrars to deal with, and the
Mandatory model creates potential for a whole new class of disputes.

If you have read this far, let me encourage you to make some 
comments. 

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

Date: Thu, 15 Feb 2001 14:23:18 +0000 (GMT)
To: Sheer El-Showk <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Sheer" == Sheer El-Showk <[email-masked]> writes a splendid
>>>>> email in which the benefits of assigning each object in the
>>>>> registry its own key are discussed. (I hope that's not too great 
>>>>> a misrepresentation.)

I think there are two other disadvantages of this approach when
compared to a scheme in which `contacts' (for want of a better word)
authenticate themselves, and access rights are confered on the basis
of the inter-object relationships.

1. Typically the registrant will have a whole bunch of objects in the
   database. If each one of these has its own key, then I think most
   registrants will get confused. 

2. Concentrating on the case of a domain being transfered for a
   moment, I think giving the domain its own key makes this harder. If
   registrant A sells the domain to B, then after the sale A really
   shouldn't have access rights. If the access to the domain is
   controlled on the basis of its contacts then all well and good; if
   its on the basis of a public key then one needs to ensure that all
   the key management happens in synchrony.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu, 15 Feb 2001 13:38:09 +0100
From: Patrick <[email-masked]>
To: Sheer El-Showk <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Organization: Gandi
Sender: [email-masked]

On Wed, Feb 14, 2001 at 06:58:02PM -0500, Sheer El-Showk took time to write:
> > I do not understand why here we try to let the registrant do things
> > wirthout going through a Registrar. Why make the registration of
> > nameserver a different case ?
> > 
> > The same problem exist in other part : like for contacts in the thick
> > registry. How do you handle them ? Someone register a contact through
> > a given Registrar. To help avoid the actual handle problems (each
> > different for a Registrar), they should be unique. Who can change
> > them ? Through wich Registrar ?
> 
> 
> Well, what I had mentioned, and what I think would be a good idea if we
> could find a system that would withstand registrant carelessnes (I'll

It is even more than a good idea : it is _mandatory_ in my eyes.
Other than that someone (the registry ? every registrar ?) will have
to support users and answer their request, when they forget their
password/PGP key/whatever, etc...
And that happens, a _lot_.

If a Registrant can do modifications through any Registrar, the
burden of support is on everyone involved (all Registrars). It might
be quite a lot of work. And Registrars will not see benefit to do it,
since someone can use a Registrar to make its modifications, which
will not mean that the Registrar will earn money with this. That is,
each Registrar will need to give few basic free services, not only to
their customers, but to anyone having registered a domain, even with
another Registrar.

> The problem with this is registrant carelessness.  Not that many people
> use PGP, and its not generally a very good idea to depend on non-technical
> people to safegaurd their data well (not that technical people are good at
> it, but at least they know when its important).  There would conceivably
> be a lot of cases of registrants losing floppies or hard disks with the
> only copy of their private key and hence losing their "proof of
> ownership" of their domains.

Exactly. Even more Registrants will forget their passphrase. Or they
will use bad methods to protect their key, and it will be stolen, and
such... If we go that route, things like that _must_ be taken into
account at the beginning.

> There is a second, and in my opinion, extremely important justification of
> this passthrough key system.  Registrar's aren't necassarily very good at
> maintaining their data integrity, and, as business, are apt to go belly-up
> every once in a while.  This leaves the registry with a lot of domains but

That is true. That is why the ICANN contract for .com/.net/.org
Registrars mentions that. Each registrar must take care of this, so
that its domains are going to another registrar in case of bankruptcy
or such, without noticeable change for the Registrants.

But that leads to a question.
I register a domain with Registrar A.
Then I decide to change the owner of the domain, by doing so through
Registrar B which will authentify me with my PGP key or such.
How are modifications going back to Registrar A in case of a thin
Registry ?
Same thing for change of contacts, nameservers, etc...

Does that mean that Registrars will need to share a common database ?
In that case I think it is more like a thick Registry.
Or will each Registrar have complete read/write access to other
Registrar databases ?

> without any idea of user ownership (in the thin registry model
> anyway) which is a Very Bad Thing (tm).  So, it would be nice if

Yes. Same thing, Registrar must be able to give all details to the
Registry. Date have to be stored securely with frequent backups.

> registrants could carry around some kind of uncompromisable proof of
> ownership of a domain.

Yes, but the problem lies down to : whatever proof you have (PGP key,
certificate, etc...), two things can happen :
- you can forget/destroy it
- someone can steal it from you.

The business in which you need this proof must take into account this
events and provide mecanisms to correct the situation.
Like I said, not an easy task.

Patrick.

Date: Wed, 14 Feb 2001 18:58:02 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: Patrick <[email-masked]>
cc: "Brian W. Spolarich" <[email-masked]>, James Seng/Personal <[email-masked]>, Kent Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

Hi Patrick,

Sorry if this is a forgotten topic and for taking so long to get back to
it.  I'm playing catchup on the list right now so I'd rather respond as
soon as I see a question directed to one of my posts.

> I do not understand why here we try to let the registrant do things
> wirthout going through a Registrar. Why make the registration of
> nameserver a different case ?
> 
> The same problem exist in other part : like for contacts in the thick
> registry. How do you handle them ? Someone register a contact through
> a given Registrar. To help avoid the actual handle problems (each
> different for a Registrar), they should be unique. Who can change
> them ? Through wich Registrar ?

Well, what I had mentioned, and what I think would be a good idea if we
could find a system that would withstand registrant carelessnes (I'll
elaborate on this in a second) is to have any entity in the registry
tagged via some public-private key mechanism.  This way you could always
direclty establish who owns it (without the hassle of
"out-of-band" authentication like physical address, email address,
etc... none of which can be practically implemented on any really
scale).  For contacts the owner (the key used to tag the data) should very
obviusly be the person the contact represents; for nameservers the owner
should be the owner of the appropriate domain; for domains the owner
should be whoever registered it (or had it transfered to them).  This way
as a Registrant I can go to a registrar and create a domain which gets
tagged with my public key.  Then, I could go to another registrar and
create a nameserver in that previous domain.  The backend registry lets me
do this (even thuogh its through another registrar, and even if its a
thin-registry that doens't track the domain SLD Holder or
whatever) because I can own the private key associated with that domains
public key so it knows I'm the valid domain owner and have the right to
add a nameserver to this domain.  Of course this makes life difficult for
registries since they can no longer assume they are the sole source of
nameserver registerations for their domains, but that just means they have
to redefine their function.

The problem with this is registrant carelessness.  Not that many people
use PGP, and its not generally a very good idea to depend on non-technical
people to safegaurd their data well (not that technical people are good at
it, but at least they know when its important).  There would conceivably
be a lot of cases of registrants losing floppies or hard disks with the
only copy of their private key and hence losing their "proof of
ownership" of their domains.

There is a second, and in my opinion, extremely important justification of
this passthrough key system.  Registrar's aren't necassarily very good at
maintaining their data integrity, and, as business, are apt to go belly-up
every once in a while.  This leaves the registry with a lot of domains but
without any idea of user ownership (in the thin registry model
anyway) which is a Very Bad Thing (tm).  So, it would be nice if
registrants could carry around some kind of uncompromisable proof of
ownership of a domain.

> Other than that I really welcome a global setup where registrant
> could make changes directly, without going through a Registrar, or
> using whatever Registrar they want. But if you go that route, you must
> consider all cases (change of ownership, change of contacts, change
> of Registar, change of nameservers, etc...).
> It seems to me a difficult case, but really interesting.
> 
> However going that way can really fast lead to this question : what
> purpose has the Registrar if a Registrant can do anything he wants
> directly to the Registry without using a Registrar ? Or by choosing
> any Registrar to do modifications by himself.
> 
> Would RRP (or its successor) be also a RegisTRANT-RegisTRY protocol ?

Registrars are, as I see them (especially in the fat registry
model) service companies that proxy for domain registration and make
domain management easier.  They help the registry by giving it a few
controllable sources of data access (ie only registrar's can directly
access a registry) and they help the customers by making registration easy
and managable (remember NSI a few years ago and the horror involved in not
having some of the nicer registration interfaces we have today).  The nice
thing about my suggested key system is it allows this registrar interface
to exist, but none-the-less authoritatively tracks domain ownership to an
individual.

Regards,
Sheer

Date: Tue, 13 Feb 2001 22:55:13 -0800 (PST)
From: wenhui zhang <[email-masked]>
Subject: Re: [idn] FYI: CNNIC services GBK, Big5, and UTF8 encodings 
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Hello
    The resolver of Chinese Domain Name System(CDNS),
as a part of CDNS
which CNNIC provides, is just like the resolver of
Netscape browser that
does not change the encoding of user's local requires
and send the original requirement to a code-switcher. 
The code switcher can transfer local
encoding to UTF-8 and vice versa. Any local encoding
query before it enter to name server is changed to
UTF8-based encoding query. The name server can handle
UTF8-based encoding query.The ACE-based domain name
will not be changed and its processes is just as
former.
    Using this mechanism, no matter what kind of
native encoding set,
the multilingual domain name system will work
correctly.

Yours regards

deng xiang
2001.2
--- Eric Brunner-Williams in Portland Maine
<[email-masked]> wrote:
> [Please trim the cc if replying!]
> 
> Announced Monday, February 5th, at the following
> URL:
> 
>
http://english.peopledaily.com.cn/200102/05/eng20010205_61600.html
> 
> My understanding is that CNNIC does or will provide
> a resolver which has
> 	support for these three encodings within the .cn
> ccTLD,
> 	defaults (like AOL keywords) any FQDN to FQDN.cn,
> 	supports these three encodings within the the DNS
> root, at least
> 		for some set of iso3166 labels, e.g., cn, and
> possibly tw
> 	and probably does more than the peopledaily writer
> describes.
> 
> These aren't ASCII Compatible Extension (ACE)
> encoding mechanisms, and differ
> from the iDNS/NSI mechanism deployment of last
> November, which is ACE-based.
> 
> For those familiar with either GBK or Big5, feel
> free to ignore the next
> two paras.
> 
> For those unfamiliar with the GB series, GBK is the
> MS Windows PRC version
> (K == kuozhan "extension"), see also GB 1390.1-93
> and GB 2312-80, and for
> the EUC-centric (me, other Unix i18n weenies),
> overlaps EUC-CN, and encodes
> the Chinese subset of ISO 10646-1:1993.
> 
> For those unfamiliar with Big5, it is the de facto
> standard in Taiwan (Mac
> and Windows) and is equivalent to the first two
> planes of CNS 11643-1992,
> and for the EUC-centric, differs from EUC-TW code
> sets 0 and 1 mainly in
> having an additional encoding block.
> 
> The CNNIC's approach appears to be at odds with a
> recent IDN WG I-D [1],
> which observed:
> 
> > Note also that because modern OS are Unicode based
> and have network-
> > downloadable IMEs, "interoperability" is becoming
> less equivalent to
> > "use BIG5 characters only" or "use GB2312
> character only" or "use
> > Shift-JIS characters only".
> 
> What appears to be the case is CNNIC is offering
> network-downloadable
> code-set-specific resolvers, independent of (native)
> Unicode deployment
> in OS products and input method extension delivery
> mechanisms.
> 
> Incidently, the January edition of the CNNIC
> semiannual data is available.
> Semiannual Survey Report on the Development of
> China's Internet (Jan. 2001)
> http://www.cnnic.cn/develst/e-cnnic200101.shtml
> 
> Corrections and additional comments welcome, Maine
> is a ways from Beijing.
> 
> Eric
> 
> [1] "Han Ideograph (CJK) for Internationalized
> Domain Names", Seng et al.,
>    
>
http://search.ietf.org/internet-drafts/draft-ietf-idn-cjk-00.txt
> 

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

To: "Jordyn A. Buchanan" <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] 
Date: Wed, 14 Feb 2001 17:27:45 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Jordyn, Kent,

Thanks to both of you for reading my reply.

There are two "big" issues, whether there is negociation (as originally
proposed by Andre), and whether I & A exhaust the policies for which we
have a requirement for in-band policing of subsequent data flows.

What concerns me about negociation is existence. Unless a suitable wand is
waved a simple request/reply rpc-like semantic becomes "full featured".
There are lots of wands, I'm partial to a few, but none are in grrp-reqs-06.

The second point is more nuanced. I-check and A-check are policy requirements,
and we firmly believe that mechanisms exist (modulo a scaling comment by
another commentor). Now we're ready to open the flood-gates and pour data
registry-ward ... but ... _if_ P-check is possible, and since it is a real
requirement (at least as real as the EC's data protection regime), then 
we haven't finished with required and feasible end-point property
determination prior to data transmission.

> - Name server objects may be subject to substantially different privacy 
> restrictions than contact objects.

Technical data ends up in a zone file, social data doesn't. Further,
depending on thick vs thin, social data delivery semantics differ from
those of technical data.

>                                    DNS data probably needs to be generally 
> world-readable, whereas I can certainly think of circumstances in which 
> names, address and phone numbers should be generally not world-readable.

We're not discussing whois publication, only the intra-R-* policied transport
of data. One reason why we should be careful about the rrp==whois assumption
many share.

> - A country may pass a law along the lines of "no one may publish phone 
> numbers of any citizen of our country".  Presumably, phone numbers of 
> citizens of other countries can be published, so restrictions on 
> publication vary based on the data.

Actually you may be interested in reverse and multi-criteria directories,
the subject of an EC DP WG publication, as it is germane to provreg. But,
in the example I provided, the _end-point_ policy is to publish all data
collected, w/o reference to the various policies for each originators' item
of data. I'm sorry if I didn't make that sufficiently clear.

> Even if you're right and I'm wrong, this affects only my assertion that we 
> solve this through extensions of object descriptions.  We can solve the 
> problem through the addition of commands later.

Thanks for humoring me thus far. Can we solve the problem (of I & A) through
subsequent additional mechanism?

> I agree they exist, but my point is that these policies are likely to be 
> announced and negotiated out-of-band on a contractual or regulatory 
> basis. 

The P3P profile (subset produced with a hatchet) for (dns) technical data
isn't complicated. The one for social data should be no more difficult
than the one the CPExchange group developed for the onward-transport of
customer data, or for P3P for very dull web pages.

>         Additionally, they are unlikely to change with regularity, so 
> there's no need for dynamic negotiation to occur.

I never sought dynamic negotiation of data collection, just an announcement
and consistent semantics requirement. However, now that you mention it, had
Gore won the US would have transitioned from "opt-out" to "opt-in" in the
current Congress, at least that was what all the smart marketers reckoned.

Eric (ex-Engage)

Date: Wed, 14 Feb 2001 17:02:21 -0500
From: Andre Cormier <[email-masked]>
To: Kent Crispin <[email-masked]>
CC: [email-masked], Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]
Sender: [email-masked]

Here's a proposition:

Lets change 
  [3] The protocol or another layered protocol MUST provide services to
      negotiate an identification and authentication mechanism
acceptable to
      both the server and the client.

To
  [3] The protocol or another layered protocol MUST provide services to
      negotiate an authentication mechanism acceptable to both the
server
      and the client.

This was more like my original idea. I had no intention of negotiating
identification at this point or any policies. I only wanted to make sure
that the protocol will be able handle more than one
authentication/security mecanism (like SASL defines). This will ensure
that those who needs privacy(TLS) and strong
authentication(Certificates) will be able to get it and those who needs
just plain text authentication will be able to get it too (as scary as
it sounds ;-) ).

SASL is very easy to implement and offer the greatest flexibility for
security.

So, it has nothing to do with the content, just the session.

Identification can be added as an other object or wathever means that
fit.

André

Date: Wed, 14 Feb 2001 13:10:20 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Feb 14, 2001 at 03:32:00PM -0500, Jordyn A. Buchanan wrote:
[...]
>  I'm 
> prepared to acknowledge that we're not dealing with the full scope of data 
> policy elements, but I don't think that means we should give up on solving 
> the problems that we can or hastily adopting a transport mechanism that may 
> or may not be well suited for the protocol we develop.

I'm not sure that there is any conflict here.

>>Note these data collection policies are not specific to any particular datum
>>(or object) within a flow between R-* entities, any more than are the A & I
>>policies.
> 
> Yes they are.  A couple of examples:

[examples]

Granted, but I don't think this is a major point.

>>How the data policies are implemented is (implementation specific). How they
>>are announced, let alone "negociated" is a protocol requirement, assuming that
>>policy differences do in fact exist. I think they do.
> 
> I agree they exist, but my point is that these policies are likely to be 
> announced and negotiated out-of-band on a contractual or regulatory 
> basis.  Additionally, they are unlikely to change with regularity, so 
> there's no need for dynamic negotiation to occur.

I don't read Eric's statement above as a contradiction to that point.  

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

Date: Wed, 14 Feb 2001 12:51:05 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Feb 14, 2001 at 02:05:39PM -0500, Eric Brunner-Williams in Portland Maine wrote:
>> My guess is that many elements of data policy that you are describing will 
>> be implemented by the registry or registrar outside of the context of this 
>> protocol.
> 
> Jordyn,
> 
> Assume that R-* entity [i] has data collection policy A.
> Assume that R-* entity [j] has data collection policy B.
> 
> Assume also that R-* entity [i] and R-* entity [j] identify and authenticate
> each other.
> 
> May they exchange Registrant technical data?
> May they exchange Registrant social data?

[...]

>How the data policies are implemented is (implementation specific). How they
>are announced, let alone "negociated" is a protocol requirement, assuming that
>policy differences do in fact exist. I think they do.

In virtually all cases we can expect that policies will largely be
expressed in legal documents drawn between the R-* parties.  It is hard
for me to imagine that we can design a protocol with sufficient power to
convey any significant policy, other than identification of the
particular policy.  Identification of the policy in force for a
particular record could be a text string identifying a contract, or some
other repository of policy information. 

I believe that I am agreeing with both of the above posters :-)

In a multiple registry environment, a single registrar could deal with
multiple registries, and thus have to deal with multiple policies
simultaneoulsy.  This seems to indicate that registrars would in the
long run tend to a least common denominator of access, because keeping
track of multiple policies would be too complex.  As is commonly the
case in such a situation, we might expect standardization of policy
terms. 

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

Date: Wed, 14 Feb 2001 15:32:00 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] 
Cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 02:05 PM 2/14/2001 -0500, Eric Brunner-Williams in Portland Maine wrote:
>This effects "repurposing", "redistribution" or "publication", a term I can't
>think of (though I know of a registry operator which claimed it had a right
>to indefinite registry data retention, independent of any operational status),
>and introduces inconsistent cache semantics (Registrant's write-access through
>a series of R-* "caches" to a Registry). This example is worse than using the
>(current) data collection statutory regime in the US for data originating in
>the EC, but non-negligible differences exist, and most of the root delegations
>follow the principle of political geography and delegated jurisdiction.

I'm not disputing that there are differences in data policy across 
jurisdictions, between different registries, registrars, etc.  I just don't 
see the need to try to accommodate the negotiation of the differences 
within the protocol.  In your example, [i] can write [j] a letter and tell 
them their data policy, and vice versa.  Often, the decision of whose 
policies will be "obeyed" by the various parties is a matter of legal or 
policy judgement, not a rules-based calculation of the appropriate policy 
based on characteristics communicated through a technical protocol.

I agree with the original point you made--this group is not prepared to 
deal with these issues.  I don't think that implies that we can't try to 
negotiating authentication and/or identification mechanisms, however.  I'm 
prepared to acknowledge that we're not dealing with the full scope of data 
policy elements, but I don't think that means we should give up on solving 
the problems that we can or hastily adopting a transport mechanism that may 
or may not be well suited for the protocol we develop.

>Note these data collection policies are not specific to any particular datum
>(or object) within a flow between R-* entities, any more than are the A & I
>policies.

Yes they are.  A couple of examples:

- Name server objects may be subject to substantially different privacy 
restrictions than contact objects.  DNS data probably needs to be generally 
world-readable, whereas I can certainly think of circumstances in which 
names, address and phone numbers should be generally not world-readable.
- A country may pass a law along the lines of "no one may publish phone 
numbers of any citizen of our country".  Presumably, phone numbers of 
citizens of other countries can be published, so restrictions on 
publication vary based on the data.

Even if you're right and I'm wrong, this affects only my assertion that we 
solve this through extensions of object descriptions.  We can solve the 
problem through the addition of commands later.

>How the data policies are implemented is (implementation specific). How they
>are announced, let alone "negociated" is a protocol requirement, assuming that
>policy differences do in fact exist. I think they do.

I agree they exist, but my point is that these policies are likely to be 
announced and negotiated out-of-band on a contractual or regulatory 
basis.  Additionally, they are unlikely to change with regularity, so 
there's no need for dynamic negotiation to occur.

Jordyn

To: "Jordyn A. Buchanan" <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] 
Date: Wed, 14 Feb 2001 14:05:39 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> My guess is that many elements of data policy that you are describing will 
> be implemented by the registry or registrar outside of the context of this 
> protocol.

Jordyn,

Assume that R-* entity [i] has data collection policy A.
Assume that R-* entity [j] has data collection policy B.

Assume also that R-* entity [i] and R-* entity [j] identify and authenticate
each other.

May they exchange Registrant technical data?
May they exchange Registrant social data?

To clairify (I hope), assume that R-* entity [i]'s data collection policy is:

purpose is "current"	data may be used by the service provider to complete
			the activity for which it was provided (registration),
recipient is "ours"	ourselves and/or our entities acting as our agents or
			entities for whom we are acting as an agent,
retention is "stated-purpose"
			data is retained to meet the stated purpose for which
			it was provided (registration), discard earliest
			possible,
and
access is "all"		all data may be subsequently modified by the originator
			(registrant modification, mentioned by paf)

and assume that R-* entity [j]'s data collection policy is:

purpose is "current" (above) and "telemarketing"
			data may be used to contact the individual via a
			voice telephone call for promotion of a product or
			service,
recipient is "ours" (above) and "unrelated" or "public"
			legal entities whose data usage practices are not
			known by the original service provider, or
			bulletin boards, public directories, or commercial
			CD-ROM directories
retention is "stated-purpose" (above) and "indefinitely" (obvious)
and
access is "none" (obvious)

Assuming that [i] is "downstream" of [j] (in the no-reseller case, [i] is the
RegistRAR and [j] is the RegisTRY:

This effects "repurposing", "redistribution" or "publication", a term I can't
think of (though I know of a registry operator which claimed it had a right
to indefinite registry data retention, independent of any operational status),
and introduces inconsistent cache semantics (Registrant's write-access through
a series of R-* "caches" to a Registry). This example is worse than using the
(current) data collection statutory regime in the US for data originating in
the EC, but non-negligible differences exist, and most of the root delegations
follow the principle of political geography and delegated jurisdiction.

Note these data collection policies are not specific to any particular datum
(or object) within a flow between R-* entities, any more than are the A & I
policies.

How the data policies are implemented is (implementation specific). How they
are announced, let alone "negociated" is a protocol requirement, assuming that
policy differences do in fact exist. I think they do.

Eric

Date: Wed, 14 Feb 2001 12:33:13 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:55 AM 2/14/2001 -0500, Eric Brunner-Williams in Portland Maine wrote:
>Andre,
>
> >> Absent BEEP, this requirement places upon the provreg design group the
> >> participant policy negociation problem.
> >To my knowledge this is not a big problem since SASL describes how to do
> >this and BEEP is using it. SASL = RFC 2222
>
>My concern is that BEEP isn't in grrp-reqs-06, and without it (or equivalent)
>provreg needs at least one participant policier negociation mechanism. I'm
>quite happy with BEEP in grrp-reqs-06, but until it is I'm concerned about
>the consequences of "MUST provide services to negotiate".

Since we haven't seen what our protocol looks like, I think it's premature 
to say whether or not BEEP is a good way to transport it.  I'm guessing 
that BEEP adds way too much overhead to be practical for high volume 
registries.  I'm willing to concede that it's too early to say that BEEP is 
not appropriate, but I'd be opposed to putting BEEP into the requirements.

> >          I do not see a problem with this requirement. If we don't have
> >a negociation mecanism, we are bound to change the protocol if we wish
> >to change the authentication method.
>
>And identification method, and anything else which participants use to
>policy data flows, e.g., data collection practices or any other policy
>possibly arising from political geography or generica or R-* practical
>considerations falls into the WHAT box of "MUST provide services to
>negotiate [WHAT]".
>
>I'm concerned that Identification and Authentication do not exhaust the
>criteria for provreg participants to policy data flows.

I think the concern expressed above is valid, but do we really have to 
worry about a generic mechanism to negotiate these things?  Given the 
general extensibility that we envision for the protocol, adding commands or 
extending objects to establish the appropriate policy set can be 
accomplished at a later time.

My guess is that many elements of data policy that you are describing will 
be implemented by the registry or registrar outside of the context of this 
protocol.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: grrp-reqs-06, 9. Internationalization Considerations
Date: Wed, 14 Feb 2001 12:29:10 -0500
Sender: [email-masked]

Eric,

Meta-comment: I've not cited references to specific technical specifications
anywhere in the requirements document because they describe _how_ the
protocol must address particular issues.  One going-in assumption behind the
requirements is that any mention of how to address an issue would be left to
the protocol specifications.  There has been a consistent effort to remove
indirect references to such specifications (such as the one alluded to in
3.4-[8] (which will be removed from the next version of the draft), or for
IPv4, or IPv6, etc.), so I don't believe it proper to introduce new
technical references in other sections.

Other comments noted below, preceded with [SAH].

<Scott/>

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Wednesday, February 14, 2001 11:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: grrp-reqs-06, 9. Internationalization Considerations

  [1] Current Internet standards restrict the encoding of Internet host
  and domain names to a subset of the 7-bit US-ASCII character set.

Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a.
                                -      0-9       A-Z       a-z
We may as well mention ASCII case folding, 1035 has a reasonable Note
at the end of 2.3.1 Preferred name syntax.

[SAH] OK, I'll add this reference because it helps describe the bounds of
the internationalization problem and it isn't a specific "solution"
reference.

  Registries and registrars now serve customers whose native languages
  require encodings other than US-ASCII, which automatically disallows  
  use of those languages when registering host and domain names.

Awkward language, what is it that "which" refers to? The "US-ASCII"
restricition, first sentence. If the subordinate clause is phrased
as a sentence ... 

[SAH] Alternative text, please.

  Support for internationalized host and domain names will greatly
  increase world-wide usability of a generic registry registrar
  protocol, so standards for exchanging internationalized information
  MUST be considered during the protocol design process.

Apple pie, but we don't actually state (or cite) what "internationalized"
means, yet, and the jump from "host and domain names" (technical data) to
social data (a subset of) "internationalized information" is left as an
exercise to the reader.

We could state:

	a. The protocol will support any encoding of technical and/or
	   social data, (code-set independent, or csi)
or
	b. The protocol will support some encodings (list) of technical
	   data, and some, possibly different, encodings (list) of social
	   data, (code-set dependent, or csd)
or
	c. The protocol will not support some encodings (list) of
	   technical data, and will not support some, possibly different,
	   encodings (list) of social data,

>From Deng Xiang's response we know that UTF8 encodings of technical data
is a requirement of a provreg protocol deployed by the .CN ccTLD Registry
and Registrars.

It is possible that the range of encodings for social data includes GBK
and Big5 as well as UTF8.

[SAH] I don't think we should describe any particular solution to the i18n
problem in this document.  The current wording is deliberately vague WRT a
solution so that the solution is left to the protocol designers.
  
  [2] The protocol MUST allow exchange of meta-data associated with
  objects in formats consistent with current internationalized character
  encoding and language representation standards.

I honestly don't know what this means. If it means code-set identifiers
or locale identifiers or something else, we should be more specific (and
useful) about "metadata". Every time I hear that word I reach for my RDF.

[SAH] I forget who suggested this requirement, it appears redundant after
reading the last sentence in [1].  Would it be OK to strike it?

  [3] All date and time values specified in a generic registry-registrar
  protocol MUST be expressed in Universal Coordinated Time.  Dates and  
  times MUST include information to represent a four-digit calendar
  year, a calendar month, a calendar day, hours, minutes, seconds,
  fractional seconds, and the time zone for Universal Coordinated Time.
  
I suggest we cite iso8601 and pick a specific format, b (UCT, above).

I do see a problem however with any "user and/or accounting package
friendly"
temporal identifier (and we do use time, Scott is going to add a temporal
identifer sufficient to support ordering in addition to what is in -06 at
the moment). The problem is that objects have temporal properties, and these
properties are passed around as operands and as identifiers in a common
representation (good) but with no common synchronization mechanism (bad).

Anyone for NTP (not for sorting out nano-payments) as a specific requirement
for temporal consistency? How about putting an upper bound on clock deltas
between provreg entities? I claim it is Feb. 14, 1901. Another possibility
is seperating "meta- or technical time" from "social time". The first
provreg
uses, NTP-esque, the second is in provreg messages.

[SAH] I'd prefer to not cite a specific technical reference for reasons
noted above.  I would _really_ like to avoid requiring a method of temporal
synchronization in the protocol because it adds another layer of complexity
that be better handled by another protocol or another protocol layer.  I
agree, though, that temporal synchronization can be an issue if client and
server have to make independent time-based decisions that require
consistency and wouldn't object to adding a requirement that says something
like this (perhaps to section 8.2?):

[n] Protocol clients and servers MUST maintain a consistent understanding of
the current date and time to effectively manage objects with temporal
properties.

[snip]

<Scott/>

To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3] 
Date: Wed, 14 Feb 2001 11:55:06 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Andre,

>> Absent BEEP, this requirement places upon the provreg design group the
>> participant policy negociation problem.
>To my knowledge this is not a big problem since SASL describes how to do
>this and BEEP is using it. SASL = RFC 2222

My concern is that BEEP isn't in grrp-reqs-06, and without it (or equivalent)
provreg needs at least one participant policier negociation mechanism. I'm
quite happy with BEEP in grrp-reqs-06, but until it is I'm concerned about
the consequences of "MUST provide services to negotiate".

>As i understand it this is for Registrars authentication to the
>registry. 

Symmetric, or rather participant indifferent, in -07.

>          I do not see a problem with this requirement. If we don't have
>a negociation mecanism, we are bound to change the protocol if we wish
>to change the authentication method.

And identification method, and anything else which participants use to
policy data flows, e.g., data collection practices or any other policy
possibly arising from political geography or generica or R-* practical
considerations falls into the WHAT box of "MUST provide services to
negotiate [WHAT]".

I'm concerned that Identification and Authentication do not exhaust the
criteria for provreg participants to policy data flows.

Cheers,
Eric

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: grrp-reqs-06, 9. Internationalization Considerations
Date: Wed, 14 Feb 2001 11:11:36 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

  [1] Current Internet standards restrict the encoding of Internet host
  and domain names to a subset of the 7-bit US-ASCII character set.

Lets be specific, rfc1035, and 0x2d,0x30-0x39,0x41-0x5a,0x6a-0x7a.
                                -      0-9       A-Z       a-z
We may as well mention ASCII case folding, 1035 has a reasonable Note
at the end of 2.3.1 Preferred name syntax.

  Registries and registrars now serve customers whose native languages
  require encodings other than US-ASCII, which automatically disallows  
  use of those languages when registering host and domain names.

Awkward language, what is it that "which" refers to? The "US-ASCII"
restricition, first sentence. If the subordinate clause is phrased
as a sentence ... 

  Support for internationalized host and domain names will greatly
  increase world-wide usability of a generic registry registrar
  protocol, so standards for exchanging internationalized information
  MUST be considered during the protocol design process.

Apple pie, but we don't actually state (or cite) what "internationalized"
means, yet, and the jump from "host and domain names" (technical data) to
social data (a subset of) "internationalized information" is left as an
exercise to the reader.

We could state:

	a. The protocol will support any encoding of technical and/or
	   social data, (code-set independent, or csi)
or
	b. The protocol will support some encodings (list) of technical
	   data, and some, possibly different, encodings (list) of social
	   data, (code-set dependent, or csd)
or
	c. The protocol will not support some encodings (list) of
	   technical data, and will not support some, possibly different,
	   encodings (list) of social data,

>From Deng Xiang's response we know that UTF8 encodings of technical data
is a requirement of a provreg protocol deployed by the .CN ccTLD Registry
and Registrars.

It is possible that the range of encodings for social data includes GBK
and Big5 as well as UTF8.
  
  [2] The protocol MUST allow exchange of meta-data associated with
  objects in formats consistent with current internationalized character
  encoding and language representation standards.

I honestly don't know what this means. If it means code-set identifiers
or locale identifiers or something else, we should be more specific (and
useful) about "metadata". Every time I hear that word I reach for my RDF.

  [3] All date and time values specified in a generic registry-registrar
  protocol MUST be expressed in Universal Coordinated Time.  Dates and  
  times MUST include information to represent a four-digit calendar
  year, a calendar month, a calendar day, hours, minutes, seconds,
  fractional seconds, and the time zone for Universal Coordinated Time.
  
I suggest we cite iso8601 and pick a specific format, b (UCT, above).

I do see a problem however with any "user and/or accounting package friendly"
temporal identifier (and we do use time, Scott is going to add a temporal
identifer sufficient to support ordering in addition to what is in -06 at
the moment). The problem is that objects have temporal properties, and these
properties are passed around as operands and as identifiers in a common
representation (good) but with no common synchronization mechanism (bad).

Anyone for NTP (not for sorting out nano-payments) as a specific requirement
for temporal consistency? How about putting an upper bound on clock deltas
between provreg entities? I claim it is Feb. 14, 1901. Another possibility
is seperating "meta- or technical time" from "social time". The first provreg
uses, NTP-esque, the second is in provreg messages.

Cheers,
Eric
P.S. Sent only to provreg, though nominal overlap with idn & whois.

References (add cite)
   [ISO8601] "Data elements and interchange formats -- Information
     interchange -- Representation of dates and times", 1988.
or/and
  [RFC2030] "Simple Network Time Protocol (SNTP) Version 4 for IPv4,
     IPv6 and OSI. D. Mills. October 1996.
and
  [insert one or more lists of encoding standards here]

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Definitions Merge 
Date: Tue, 13 Feb 2001 16:06:36 -0500
Importance: Normal
Sender: [email-masked]

Consider it done...

<  -----Original Message-----
<  From: [email-masked] [mailto:[email-masked]]On
<  Behalf Of Eric Brunner-Williams in Portland Maine
<  Sent: Tuesday, February 13, 2001 3:47 PM
<  To: Hollenbeck, Scott
<  Cc: [email-masked]'; [email-masked]
<  Subject: Re: Definitions Merge 
<  
<  
<  Works for me. Since you and he are in cahoots (cut from && paste 
<  to) can you
<  ask him to rename and adjust? I'll be happy to help, having 
<  nuanced. The co-s
<  should sign-off on the draft going from individual submission to 
<  WG queue.
<  
<  Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Definitions Merge 
Date: Tue, 13 Feb 2001 15:49:05 -0500
Sender: [email-masked]

Sure -- Ross, are you OK with this?

<Scott/>

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 3:47 PM
To: Hollenbeck, Scott
Cc: [email-masked]'; [email-masked]
Subject: Re: Definitions Merge 

Works for me. Since you and he are in cahoots (cut from && paste to) can you
ask him to rename and adjust? I'll be happy to help, having nuanced. The
co-s
should sign-off on the draft going from individual submission to WG queue.

Eric

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Definitions Merge 
Date: Tue, 13 Feb 2001 15:46:45 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Works for me. Since you and he are in cahoots (cut from && paste to) can you
ask him to rename and adjust? I'll be happy to help, having nuanced. The co-s
should sign-off on the draft going from individual submission to WG queue.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Definitions Merge 
Date: Tue, 13 Feb 2001 15:20:58 -0500
Sender: [email-masked]

Yes, I agree.  Perhaps Ross' document should be renamed (and the definitions
adjusted) to make it less whois-centric, especially if it's being picked up
as a provreg WG document?

<Scott/>

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 3:19 PM
To: Hollenbeck, Scott
Cc: [email-masked]'; [email-masked]
Subject: Re: Definitions Merge 

Scott,

There is at least one nuance which distinguishes a provreg definition of
"foo"
from a whois defintion of "foo", one which you captured in the distinction
between "technical information" and "social information". The "thick vs
thin"
model is distinguished by the distribution of "social information" only, and
this determines scope (end-points) for data flows for provreg.

In whois, there is no "technical information" (as whois makes no known use
of zone files), and I'm unclear if whois distinguishes between a registry
(global) and a registrar (local) provenance of data, nor the ordering of
entities between the query originator and the (eventual, not necessarily
unique) reply entity (or entities).

I don't mind a distinct definition-dump, I think we have at least one form
of "foo (depends who's answering, provreg or whois)" definition.

Eric

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Definitions Merge 
Date: Tue, 13 Feb 2001 15:19:24 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

There is at least one nuance which distinguishes a provreg definition of "foo"
from a whois defintion of "foo", one which you captured in the distinction
between "technical information" and "social information". The "thick vs thin"
model is distinguished by the distribution of "social information" only, and
this determines scope (end-points) for data flows for provreg.

In whois, there is no "technical information" (as whois makes no known use
of zone files), and I'm unclear if whois distinguishes between a registry
(global) and a registrar (local) provenance of data, nor the ordering of
entities between the query originator and the (eventual, not necessarily
unique) reply entity (or entities).

I don't mind a distinct definition-dump, I think we have at least one form
of "foo (depends who's answering, provreg or whois)" definition.

Eric

Date: Tue, 13 Feb 2001 14:18:10 -0500
From: Andre Cormier <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
CC: [email-masked]
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:
> 
> Last December Andre Cormier (1) proposed added requirement [3], viz
> 
>         [3] The protocol or another layered protocol MUST provide services to
>         negotiate an identification and authentication mechanism acceptable to
>         both the server and the client.
> 
> The requirement he's proposed is negociation between the server and the client
> as the precondition for subsequent transactions.
> 
> My issue with this is that the scope of R-* policied data flows is larger
> than participant identification and authentication, which is distinct from
> negociation proposed concerning the duration of a particular registration,
> (and I suppose equivalent object-specific properties).
> 
> As Richard Shockey noted (2), BEEP provides a negociation mechanism.
> Absent BEEP, this requirement places upon the provreg design group the
> participant policy negociation problem.
To my knowledge this is not a big problem since SASL describes how to do
this and BEEP is using it. SASL = RFC 2222

As i understand it this is for Registrars authentication to the
registry. I do not see a problem with this requirement. If we don't have
a negociation mecanism, we are bound to change the protocol if we wish
to change the authentication method.

> The specific policy I've in mind (wearing my P3P Spec hat) is neither
> participant identification nor authentication, but participant data
> collection policies.
> 
> I've proposed off-list that [1] and [2] be reworded to be symmetric, so
> they address server identification authentication. I propose that [3]
> be dropped, least we have the situation where we can negociate a means
> to identify and also authenticate any provreg participant, but can't
> negociate data collection policies.
> 
> The real throw-hands-up-in-dispair is that after two years of effort,
> the P3P activity couldn't figure out how to negociate a fundamental,
> and I don't want provreg to pause-to-refresh while revisiting a problem
> appealing to generalist aesthetics and not present deployment schedules.
> Everyone wants to negociate, and we don't really have negociated policed
> flows anywhere in the internet architecture (corrections gladly paid for).
> 
> Incidently, P3P has versioning. 1.0, ...
> 
> Cheers,
> Eric
> 
> (1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html
> (2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html

Date: Mon, 12 Feb 2001 07:57:57 -0800
To: George Belotsky <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: moving on, was Re: Fw: WG Review: ...
Cc: [email-masked], Patrik Faltstrom <[email-masked]>
Sender: [email-masked]

At 07:38 AM 2/12/2001, George Belotsky wrote:
>In response to your request for suggestions regarding the design team,
>here are some notes on its possible structure and operation.

IETF design teams self-organize.

Their output is subject to acceptance or revision by the working group, but 
the working group does not manage the internals of IETF design teams.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Mon, 12 Feb 2001 10:38:19 -0500
From: George Belotsky <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: Dave Crocker <[email-masked]>, [email-masked], Patrik Faltstrom <[email-masked]>
Subject: Re: moving on, was Re: Fw: WG Review: ...
Sender: [email-masked]

Ed:

In response to your request for suggestions regarding the design team,
here are some notes on its possible structure and operation.

   * Each team member will be assigned primary responsibility 
     for a part of the design.  The division of the overall task
     into these parts, as well as the assignment, shall be by
     unanimous consent.
   
   * Each member will focus on their area of primary responsibility.

   * The whole team will periodically review each member's work, but
     unanimous consent would not be required (i.e. in their area of
     primary responsibility, a member carries more weight than others
     on the team).  The reviews would thus focus primarily on the
     interfaces between constituent parts of the design.

Hopefully, the above arrangement will create a clear assignment of
responsibilities but in a relatively informal environment -- which is
conductive to the creative work of design.

George.

On Sun, Feb 04, 2001 at 12:06:42PM -0500, Edward Lewis wrote:
> As much as I hate to cut off communication on a topic, I don't think the
> revent thread on the charter is in any way is helping us arrive at
> protocol.  In fact, I might go so far as to say that this thread has gone
> off-topic for the mailing list.
> 
> All I can say here is that we have already had a discussion on the charter,
> and it has not yet been approved by the IESG.  I am waiting for feedback
> from the IESG before anything else can be done on this matter.  Further
> discussion on this is just like spinning tires in mud.
> 
> Let's get back to discussions on the requirements document (if there is any
> more to be held).  I assume there is consensus that the requirements
> document should be admitted to the WG (once we are official).
> 
> Suggestions for the Feb 20 meeting agenda are welcome.
> 
> I'd also like to hear thoughts about organizing a design team (whether we
> should, size, shape, nominees perhaps).
> 
> I think it is about time we begin to look at the EPP document.  Does the
> latest EPP draft meet the latest draft of requirements?  Is there an
> objection to including EPP in the WG set of documents?
> 
> If there is an alternative proposal to be considered, please identify it.
> 
> If there are other documents that should be added to the WG, please
> identify them.  (The definitions document will likely be one.)
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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.
> 
> 

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

From: "James Seng" <[email-masked]>
To: <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]
Date: Sun, 11 Feb 2001 05:55:21 +0800
Sender: [email-masked]

RFC2058.

-James Seng

> The real throw-hands-up-in-dispair is that after two years of effort,
> the P3P activity couldn't figure out how to negociate a fundamental,
> and I don't want provreg to pause-to-refresh while revisiting a
problem
> appealing to generalist aesthetics and not present deployment
schedules.
> Everyone wants to negociate, and we don't really have negociated
policed
> flows anywhere in the internet architecture (corrections gladly paid
for).
>
> Incidently, P3P has versioning. 1.0, ...
>
> Cheers,
> Eric
>
> (1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html
> (2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html

Date: Sat, 10 Feb 2001 23:28:31 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: WG ACTION: Provisioning Registry Protocol (provreg)
Sender: [email-masked]

Apparently, we're now legal...

>From: The IESG <[email-masked]>
>To: IETF-Announce:;;@tislabs.com
>Subject: WG ACTION: Provisioning Registry Protocol (provreg)
>Date: Sat, 10 Feb 2001 16:22:12 -0500
>Sender: [email-masked]
>
>
>A new working group has been formed in the Applications Area of the IETF.
>For additional information, contact the Area Directors
>or the WG Chair.
>
>
>Provisioning Registry Protocol (provreg)
>----------------------------------------
>
> Charter
> Last Modified: 05-Feb-01
>
> Current Status: Active Working Group
>
> Chair(s):
>     Jaap Akkerhuis <[email-masked]>
>     Ed Lewis <[email-masked]>
>
> Applications Area Director(s):
>     Ned Freed  <[email-masked]>
>     Patrik Faltstrom  <[email-masked]>
>
> Applications Area Advisor:
>     Patrik Faltstrom  <[email-masked]>
>
> Mailing Lists:
>     General Discussion:[email-masked]
>     To Subscribe:      [email-masked]
>         In Body:       subscribe ietf-provreg
>     Archive:           http://www.cafax.se/ietf-provreg/maillist/
>
>Description of Working Group:
>
>Administration of Domain Name Service (DNS) registration increasingly
>distinguishes between the operation of a "back-end" registry data base
>service for registrations, versus "front-end" support services by
>registrars who interact with registrants and with the registry.
>Especially for various Top-Level Domains, the desire is to permit
>multiple registrars to share access to the database.  Conversely, there
>is a desire to allow a registrar to access multiple registries via the
>same protocol, even if the registries differ in operational models.
>
>This working group will develop a specification of the requirements and
>limitations for a protocol that enables a registrar to access multiple
>registries and will develop a  protocol that satisfies those
>requirements. The protocol will permit interaction between a
>registrar's own application and registry applications.
>
>The initial specification will allow multiple registrars to register
>and maintain domain names within multiple Top Level Domains (TLDs). The
>specification should be flexible enough to support the different
>operational models of registries.  The specification should allow
>extension to support other registration data, such as address
>allocation and contact information. The working group will use as input
>the "Generic Registry-Registrar Protocol Requirements"
>(draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
>Protocol presentation, documented in (draft-hollenbeck-epp-nn).
>
>The group will consider support for multiple operational choices, such
>as for transport and security; it will create no new transport or
>security protocols.  The group may consider use of the new protocol for
>diverse registration and update scenarios, in order to understand
>limitations and possible extensions that are appropriate.  Specification
>for user interface access, such as by a web front end, is beyond the
>scope of this working group.
>
>Documentation from the working group will:
>
>* Specify the objects exchanged between the registry repository
>and registrars, the relationships among the objects, and the protocol
>for exchanging objects between a registrar and the registry; at a
>minimum the objects will include:  domain name, IP address, and contact
>details for registrants
>
>* Describe appropriate mechanisms for security during registrar access
>
>* List useful examples of registrar access transactions
>
> Goals and Milestones:
>
>   Feb 01       Working group agreement on functional requirements for
>protocol
>
>   Apr 01       Initial specification of provreg protocol
>
>
>   Jun 01       Second draft specification
>
>
>   Sep 01       Submit draft for standards track
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Transfer Notification a requirement?
Date: Sat, 10 Feb 2001 22:00:33 -0500
Sender: [email-masked]

I don't have a problem with striking 3.7-[8] if no one objects.

<Scott/> 

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:[email-masked]]
> Sent: Friday, February 09, 2001 12:06 PM
> To: James Seng/Personal; Ayesha Damaraju; [email-masked]
> Subject: Re: Transfer Notification a requirement?
> 
> 
> At 01:18 PM 2/9/2001 +0800, James Seng/Personal wrote:
> >I would like to point out again that this is one area where specific
> >design and policy which leak into requirements.
> >
> >The problem here is that Object Transfer must both 
> registrars to agree.
> >And to prevent abuse, it is policy decision that such transfer who
> >require giving the losing registrar to stop the transfer. (In other
> >words, it is the SERVER which is suppose to keep track of 
> this, not the
> >protocol).
> 
> I agree with James that 3.7 still contains some policy 
> language.  Can we 
> just lose 3.7 [8]?  That's a policy issue.  Everything else 
> just describes 
> capabilities that the protocol should have.  The protocol 
> *should* include 
> a capability for the losing registrar to stop the transfer 
> because some 
> registries do this.  If your registry doesn't act this way, 
> then you don't 
> have to pay attention.
> 
> >This problem _could_ be solved in another way, ie, by having
> >authorization access directly on objects. This allows the
> >owner/registrant to do whatever he wants with the object including
> >transfer so long he can provide the appropriate authorization.
> 
> This is already handled.  Everything is extensible and 3.7 
> [4] says "The 
> protocol MUST provide services to confirm registrar authorization to 
> transfer an object."  It's up to the registry to determine what that 
> authorization is.
> 
> >There are many ways to solve a problem. IMHO, requirements should be
> >independent of any design.
> 
> True.  I think we should lose 3.7 [8].  Then there's no policy in 3.7.
> 
> Jordyn
> 

From: "Peter Mott" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: grrp-reqs-06, 3.2 Object Registration [2]
Date: Sun, 11 Feb 2001 11:06:05 +1300
Importance: Normal
Sender: [email-masked]

> The temporal properties of domain name object registration needs
> clarification.
> The -06 text in [2] originates from a proposal by Geva Patz [1]
> who sought to
> remove arbitrary restrictions, as domain names then (circa -03)
> had fixed time
> associations.

There will be some ccTLD's whose interest in storing the registration
expiration date in the shared register is simply to publish the fact a
registrar/registrant contract is due to expire on that day/hour.

In such a model, the registry will charge the registrar for access to the
register, and a fee that relates to the number of records associated with
the registrar.

This sensible model has the registry send a two line invoice to each
registrar every month, and registrars pay a single bill each month.

Please do build as much complexity into the protocol you like, but lets make
sure it can also function without the need for the registry company to have
an interest in the domain name registration business.  There is a
possibility some registry operators have an interest in providing services
that meet the needs of registrars rather than acting as a bus conductor with
a very busy ticket clicker.

> Comments on the backs of $5 bills (larger is OK, but a minimum granularity
> is required). Thanks.

Sorry, I only pay by credit card on the net :-)

Peter Mott
.aq .tk .pn
-/-

To: [email-masked]
cc: [email-masked]
Subject: grrp-reqs-06, 3.2 Object Registration [2]
Date: Sat, 10 Feb 2001 16:16:10 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

The temporal properties of domain name object registration needs clarification.
The -06 text in [2] originates from a proposal by Geva Patz [1] who sought to
remove arbitrary restrictions, as domain names then (circa -03) had fixed time
associations. I believe the problem Geva was concerned with was the upper-bound
for domain name object registration.

A difficulty arises from this very lack of arbitrary restriction as no lower
bound requirement is available to the protocol designers, and we clearly do
not, in the case of fee-for-service regimes, want to move from existing forms
of fee recovery (credit card based is a common, though not universal model)
to "micro-payment" regimes.

The issues which need to be addressed by this requirment are accounting,
granularity of the units used to measure validity periods (where definite
temporal properties exist), etc.

  Current -06 text:
                                       ...  Registries SHOULD be allowed
  to accept indefinitely valid registrations if the policy that they are
  implementing permits, and to specify a default validity period if one
  is not selected by a registrar. ...

  Proposed text:

                                       ...  Registries SHOULD be allowed
  to accept indefinitely valid registrations if the policy that they are
  implementing permits, and to specify a default validity period if one
  is not selected by a registrar. Registries MUST be allowed to specify
  minimal validity periods consistent with the prevailing or preferred
  practice for fee-for-service recovery. ...

If anyone cares to observe that this is policy (micro-payment depricating,
macro-payment preferential), they are of course correct, and I don't want
to even think of importation of the requirement expressed in [2] into the
provreg system.

Comments on the backs of $5 bills (larger is OK, but a minimum granularity
is required). Thanks.

Cheers,
Eric

[1] http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00026.html
[2] rfc2870, Root Name Server Operational Requirements, Section 3.2.5.

To: [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: FYI: CNNIC services GBK, Big5, and UTF8 encodings 
Date: Sat, 10 Feb 2001 11:49:58 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

[Please trim the cc if replying!]

Announced Monday, February 5th, at the following URL:

http://english.peopledaily.com.cn/200102/05/eng20010205_61600.html

My understanding is that CNNIC does or will provide a resolver which has
	support for these three encodings within the .cn ccTLD,
	defaults (like AOL keywords) any FQDN to FQDN.cn,
	supports these three encodings within the the DNS root, at least
		for some set of iso3166 labels, e.g., cn, and possibly tw
	and probably does more than the peopledaily writer describes.

These aren't ASCII Compatible Extension (ACE) encoding mechanisms, and differ
from the iDNS/NSI mechanism deployment of last November, which is ACE-based.

For those familiar with either GBK or Big5, feel free to ignore the next
two paras.

For those unfamiliar with the GB series, GBK is the MS Windows PRC version
(K == kuozhan "extension"), see also GB 1390.1-93 and GB 2312-80, and for
the EUC-centric (me, other Unix i18n weenies), overlaps EUC-CN, and encodes
the Chinese subset of ISO 10646-1:1993.

For those unfamiliar with Big5, it is the de facto standard in Taiwan (Mac
and Windows) and is equivalent to the first two planes of CNS 11643-1992,
and for the EUC-centric, differs from EUC-TW code sets 0 and 1 mainly in
having an additional encoding block.

The CNNIC's approach appears to be at odds with a recent IDN WG I-D [1],
which observed:

> Note also that because modern OS are Unicode based and have network-
> downloadable IMEs, "interoperability" is becoming less equivalent to
> "use BIG5 characters only" or "use GB2312 character only" or "use
> Shift-JIS characters only".

What appears to be the case is CNNIC is offering network-downloadable
code-set-specific resolvers, independent of (native) Unicode deployment
in OS products and input method extension delivery mechanisms.

Incidently, the January edition of the CNNIC semiannual data is available.
Semiannual Survey Report on the Development of China's Internet (Jan. 2001)
http://www.cnnic.cn/develst/e-cnnic200101.shtml

Corrections and additional comments welcome, Maine is a ways from Beijing.

Eric

[1] "Han Ideograph (CJK) for Internationalized Domain Names", Seng et al.,
    http://search.ietf.org/internet-drafts/draft-ietf-idn-cjk-00.txt

To: [email-masked]
cc: [email-masked]
Subject: grrp-reqs-06, 3.2 Identification and Authentication [3]
Date: Fri, 09 Feb 2001 19:01:21 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Last December Andre Cormier (1) proposed added requirement [3], viz

	[3] The protocol or another layered protocol MUST provide services to
	negotiate an identification and authentication mechanism acceptable to
	both the server and the client.

The requirement he's proposed is negociation between the server and the client
as the precondition for subsequent transactions.

My issue with this is that the scope of R-* policied data flows is larger
than participant identification and authentication, which is distinct from
negociation proposed concerning the duration of a particular registration,
(and I suppose equivalent object-specific properties).

As Richard Shockey noted (2), BEEP provides a negociation mechanism.
Absent BEEP, this requirement places upon the provreg design group the
participant policy negociation problem.

The specific policy I've in mind (wearing my P3P Spec hat) is neither
participant identification nor authentication, but participant data
collection policies.

I've proposed off-list that [1] and [2] be reworded to be symmetric, so
they address server identification authentication. I propose that [3]
be dropped, least we have the situation where we can negociate a means
to identify and also authenticate any provreg participant, but can't 
negociate data collection policies.

The real throw-hands-up-in-dispair is that after two years of effort,
the P3P activity couldn't figure out how to negociate a fundamental,
and I don't want provreg to pause-to-refresh while revisiting a problem
appealing to generalist aesthetics and not present deployment schedules.
Everyone wants to negociate, and we don't really have negociated policed
flows anywhere in the internet architecture (corrections gladly paid for).

Incidently, P3P has versioning. 1.0, ...

Cheers,
Eric

(1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html
(2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Definitions Merge
Date: Fri, 9 Feb 2001 13:12:59 -0500 
Sender: [email-masked]

Ross Rader and I have been talking about moving definitions from the GRRP
requirements draft to his definitions draft so that we have a single
definitions reference.  The acronym explanations found in the GRRP draft
will stay; the definitions will be replaced with a reference to Ross' draft.

Any objections?

<Scott/>

Date: Fri, 09 Feb 2001 12:05:55 -0500
To: "James Seng/Personal" <[email-masked]>, "Ayesha Damaraju" <[email-masked]>, <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Transfer Notification a requirement?
Sender: [email-masked]

At 01:18 PM 2/9/2001 +0800, James Seng/Personal wrote:
>I would like to point out again that this is one area where specific
>design and policy which leak into requirements.
>
>The problem here is that Object Transfer must both registrars to agree.
>And to prevent abuse, it is policy decision that such transfer who
>require giving the losing registrar to stop the transfer. (In other
>words, it is the SERVER which is suppose to keep track of this, not the
>protocol).

I agree with James that 3.7 still contains some policy language.  Can we 
just lose 3.7 [8]?  That's a policy issue.  Everything else just describes 
capabilities that the protocol should have.  The protocol *should* include 
a capability for the losing registrar to stop the transfer because some 
registries do this.  If your registry doesn't act this way, then you don't 
have to pay attention.

>This problem _could_ be solved in another way, ie, by having
>authorization access directly on objects. This allows the
>owner/registrant to do whatever he wants with the object including
>transfer so long he can provide the appropriate authorization.

This is already handled.  Everything is extensible and 3.7 [4] says "The 
protocol MUST provide services to confirm registrar authorization to 
transfer an object."  It's up to the registry to determine what that 
authorization is.

>There are many ways to solve a problem. IMHO, requirements should be
>independent of any design.

True.  I think we should lose 3.7 [8].  Then there's no policy in 3.7.

Jordyn

Date: Fri, 9 Feb 2001 10:24:49 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Agenda for Interim Meeting
Cc: [email-masked]
Sender: [email-masked]

At 1:31 PM -0500 2/8/01, Hollenbeck, Scott wrote:
>I can probably get the room for an earlier start if our chairs wish to do
>so.

Scott is getting the room for 9am.  Those who want to gather early can do
so - to discuss issues, prepare agenda suggestions, gather volunteers for
scribe duties, etc.   But the meeting won't officially begin until about 10
so those arriving that morning can make it in.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "James Seng/Personal" <[email-masked]>
cc: "Ayesha Damaraju" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Transfer Notification a requirement? 
Date: Fri, 09 Feb 2001 08:09:00 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Mr. Seng,

Your (repeated) suggestion that the scope of the working group extend to
encompass the functionality of registrANT operations (below) has not yet
addressed the mechanism(s) by which the provreg protocol's authentication,
authorization, and presumably accounting activities scale.

> This problem _could_ be solved in another way, ie, by having
> authorization access directly on objects. This allows the
> owner/registrant to do whatever he wants with the object including
> transfer so long he can provide the appropriate authorization.

Do you have any suggestions in this area at this time?

Eric

To: Ayesha Damaraju <[email-masked]>
cc: [email-masked]
Subject: Re: Transfer Notification a requirement? 
Date: Fri, 09 Feb 2001 10:32:44 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    3.7 Object Transfer
    
    [6] The protocol MUST provide services that allow the original 
    sponsoring registrar to approve or reject a requested object transfer.
    ...............
    ...........

    [8] Object Transfer requests MUST NOT be acted upon without giving the
    losing registrar an opportunity to respond to the request...

    Unless [8] implies that a notification needs to be sent to the losing
    registrar to approve or reject giving them an opportunity - In which case i
   t
    
    needs to be clear, even otherwise notifying the sponsoring registrar to 
    approve or reject the transfer should be a requirement.

Note that the protocol MUST provide this service. However, it is
a policy decision whether the registry actually implements this.
As said before, the Dutch domain registry doesn't allow this. The
old (or ``loosing registar'') has some time to comment on the
transfer, but when there is no adequate reason to halt the transfer,
it will happen anyway. This to prevent a registrar taking a domain
hostage, because there is a conflict between registrar and registrant.
Something that happened a lot when we allowed the old regsitrar to
veto any transfer.

	jaap

From: "James Seng/Personal" <[email-masked]>
To: "Ayesha Damaraju" <[email-masked]>, <[email-masked]>
Subject: Re: Transfer Notification a requirement?
Date: Fri, 9 Feb 2001 13:18:45 +0800
Sender: [email-masked]

I would like to point out again that this is one area where specific
design and policy which leak into requirements.

The problem here is that Object Transfer must both registrars to agree.
And to prevent abuse, it is policy decision that such transfer who
require giving the losing registrar to stop the transfer. (In other
words, it is the SERVER which is suppose to keep track of this, not the
protocol).

This problem _could_ be solved in another way, ie, by having
authorization access directly on objects. This allows the
owner/registrant to do whatever he wants with the object including
transfer so long he can provide the appropriate authorization.

There are many ways to solve a problem. IMHO, requirements should be
independent of any design.

-James Seng

----- Original Message -----
From: "Ayesha Damaraju" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 09, 2001 1:59 AM
Subject: Transfer Notification a requirement?

>
> Considering below two requirements from GRRP_reqs_06
>
> 3.7 Object Transfer
>
> [6] The protocol MUST provide services that allow the original
> sponsoring registrar to approve or reject a requested object transfer.
> ...............
> ...........
>
> [8] Object Transfer requests MUST NOT be acted upon without giving the
> losing registrar an opportunity to respond to the request...
>
>
> Unless [8] implies that a notification needs to be sent to the losing
> registrar to approve or reject giving them an opportunity - In which
case it
>
> needs to be clear, even otherwise notifying the sponsoring registrar
to
> approve or reject the transfer should be a requirement.
>
> -Ayesha
>

Date: Thu, 08 Feb 2001 14:02:41 +0100
From: Urs Eppenberger <[email-masked]>
To: [email-masked]
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

--On Mittwoch, 7. Februar 2001 10:26 Uhr -0500 "Hollenbeck, Scott"
<[email-masked]> wrote:

> [11] The protocol MUST provide services to manage name servers associated
> with multiple domains.  No name server data SHOULD exist in the registry
> without an associated parent domain.

The first sentence is OK. It talks about protocol level.
The second sentence is about what a registry is allowed to store, and this
does not make sense here.

At SWITCH we register nameserver objects without checking if they are
'used'. We register the corresponding IP addresses and a contact person.
(Often fetching the e-mail address from the SOA record does not help in
case of misconfigurations, because e-mail just does not work anymore. For
this we keep a more or less complete set of contact information for the
hostmaster of the nameserver. He is the owner of the object and has the
right to change attribute values like IP adresses.)

We allow certain changes at a specific date, for example the replacement of
nameservers for a domain. For this you need to register the nameservers
first, without the connection to the domain. And at the agreed date the old
nameserver are replaced.

Therefore to require that 'no nameservers SHOULD exist' does not make sense
for me.

Urs.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Transfer Notification a requirement?
Date: Thu, 8 Feb 2001 14:05:22 -0500 
Sender: [email-masked]

Requirement 3.7-[7] was intended to address registrar/client awareness of
transfers:

[7] The protocol MUST provide services that allow both the original
sponsoring registrar and the potential new registrar to monitor the status
of both pending and completed transfer requests.

I didn't want to get more specific about how the monitoring or notification
facilities should look.

<Scott/>

> -----Original Message-----
> From: Ayesha Damaraju [mailto:[email-masked]]
> Sent: Thursday, February 08, 2001 1:00 PM
> To: [email-masked]
> Subject: Transfer Notification a requirement?
> 
> 
> 
> Considering below two requirements from GRRP_reqs_06
> 
> 3.7 Object Transfer
> 
> [6] The protocol MUST provide services that allow the original 
> sponsoring registrar to approve or reject a requested object transfer.
> ...............
> ...........
> 
> [8] Object Transfer requests MUST NOT be acted upon without giving the
> losing registrar an opportunity to respond to the request...
> 
> 
> Unless [8] implies that a notification needs to be sent to the losing
> registrar to approve or reject giving them an opportunity - 
> In which case it
> 
> needs to be clear, even otherwise notifying the sponsoring 
> registrar to 
> approve or reject the transfer should be a requirement.
> 
> -Ayesha
>  
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Generalizing the terminology
Date: Thu, 8 Feb 2001 13:58:14 -0500 
Sender: [email-masked]

Thanks for your detailed comments, Catherine.

While I understand people's comments about the requirements draft being very
domain name centric, it was explicitly done that way to define requirements
for a specific, narrow, manageable initial focus: domain names and data
associated with domain names.  As-is, I don't think there's anything in the
draft that precludes protocol extension to non-domain resources (to use
Catherine's term).

Not too long ago the idea of developing new requirements drafts for
non-domain resources was suggested by someone.  I'd much prefer that route
over trying to make the current requirements draft into something that it
wasn't meant to be from the start.

I agree that it would be a good idea to define the term "status" in the
context of a domain name before using it elsewhere in the document.

<Scott/>

> -----Original Message-----
> From: Catherine Murphy [mailto:[email-masked]]
> Sent: Thursday, February 08, 2001 12:44 PM
> To: [email-masked]
> Subject: Generalizing the terminology
> 
> 
> 
> I would like to offer the following specific revisions in an 
> attempt to
> reduce the domain name emphasis of the draft. I know that some of the
> recent discussion has already affected the draft, but this 
> mark-up goes
> against the most recent posting of 
> draft-hollenbeck-grrp-reqs-06.txt.  As
> a general comment, I think the document is well thought out and very
> thorough. Scott has done a great job getting this started. I 
> also realize
> that some of my points have already been made. My goal is to offer
> specific alternatives to the existing text. Only the text containing
> proposed changes is included below; everything else has been 
> <snip'd>. 
> 
> ---------------------------------------------
> Cathy Murphy <[email-masked]>
> Principal Software Engineer
> American Registry for Internet Numbers (ARIN)
> +1 703 227 9875
> 
> << Based on draft-hollenbeck-grrp-reqs-06.txt (January 19, 2001) >>
> 
> 1.1 Definitions, Acronyms, and Abbreviations
> 
>   [NEW] Resource: A generic term used to describe an object that is
>   the primary focus of a registration process. An example of a 
>   resource is a domain name or an IP address block. Supporting 
>   objects such as contact information are not resources.
> 
>   << If you don't agree with having something along the lines 
>      of this new definition, don't bother reading further. 
>      Most of the changes revolve around this specific term.  >>
> 
>   Registrant: An entity that registers resources in a registry
>                                        ^^^^^^^^^
>   through the services provided by a registrar.  Registrants include
>   individuals, organizations, and corporations.
> 
>   Registrar: An entity that provides front-end resource registration
>                                                ^^^^^^^^
>   services to registrants, providing a public interface to registry
>   services.
> 
>   Registry: An entity that provides back-end resource registration
>                                              ^^^^^^^^
>   services to registrars, managing a central repository of information
>   for a specific portion of that resource, e.g., a given TLD. 
>  A domain 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              
>    ^^^^^^
>   name registry is typically responsible for publication and 
> distribution 
>   ^^^^
>   of TLD zone files used by the Domain Name System.
> 
> 2.2 System Functions
> 
>   Registrars access a registry through a protocol to register objects
>   and perform object management functions.  Required functions include
>   session management; object creation, update, renewal, and deletion;
>   object query; and object transfer.
> 
>   A domain name registry generates DNS zone files for the 
> TLDs it serves. 
>   ^^^^^^^^^^^^^ 
>   These zone files are created and distributed to a series of 
> name servers
>   that provide the foundation for the domain name system.
> 
>   Registries MUST provide a whois search capability that 
> provides basic
>              ^^^^
>   query services for the objects managed by the registry.  ...
> 
> 3.4 Object Registration
> 
>   [1] The protocol MUST provide services to register Internet domain
>   names.
> 
>   << Why? If the protocol is being used for non-domain name resources,
>      this particular requirement seems excessively 
> restrictive, perhaps
>      appropriate for a domain name extension to the "generic" RRP. >>
> 
>   [2] The protocol MUST permit a starting and ending time for a 
>   resource registration to be negotiated, thereby ...
>   ^^^^^^^^
> 
>   [3] When a resource has been successfully registered, ...
>              ^^^^^^^^
> 
>   [5] If the resource being registered is a domain name, the protocol 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   MUST provide services to register name servers.  ...
> 
>   << Since there has already been extensive discussion about 
>      nameservers being objects versus attributes, I will not 
>      comment further here except to re-iterate that this 
>      portion of the protocol is somewhat distinct to domain
>      name registries. >>
>  
> 3.5 Object Association
> 
>   [3] The protocol MUST provide services to associate contacts with
>   resources. Associated contacts name MUST be identified by type.
>   ^^^^^^^^^
>   Contact types that MAY be associated with a resource include
>                                               ^^^^^^^^
>   "registrant", "technical", "administrative", and "billing".  A
>   registry MAY support a subset of these contact types.
> 
>   << Also, "abuse" >>
> 
> 3.6 Object Update
> 
>   [1] The protocol MUST provide services to update information
>   associated with registered resources.  Resource update
>                              ^^^^^^^^^   ^^^^^^^^
>   services MUST allow changes to status, associated name servers, and
>   associated contacts.
> 
>   << As far as I can tell, this is the first mention of status. 
>      I would like to see the definition of status, which is not
>      defined until 3.12, either moved up or explicitly referenced. 
>      When I first read this, my immediate thought was "Huh? Did I 
>      miss something? What's a status?" >> 
> 
>   [2] If the registry includes registration of associated 
> nameservers, 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   the protocol MUST provide services to update information
>   associated with registered name servers.  Name server 
> update services
>   MUST allow change to IP addresses and server name.
> 
> 3.7 Object Transfer
> 
>   << A general comment about object transfer: this entire section is
>      very specific to how domain names are transferred and does not 
>      relate well at all to when and how IP networks may be 
> transferred. 
>      I cannot speak to how other possible users of the GRRP might work
>      transfers, but I will propose other, more generic text for this 
>      section in another message thread. Or, this section 
> could be left 
>      in the protocol but identified as being domain name specific
>      requirements only. >> 
> 
> 3.8 Object Renewal/Extension
> 
>   [1] The protocol MUST provide services to renew or extend 
> the validity
>   period of registered resources.  If applicable, ...
>                        ^^^^^^^^^
> 
> 3.9 Object Deletion
> 
>   [1] The protocol MUST provide services to remove a resource from
>   the registry.                                      ^^^^^^^^
> 
>   [2] If the registry contains nameserver objects, the protocol MUST 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   provide services to remove a name server from the registry.
> 
>   << A nit: since this is the protocol, shouldn't these say something
>      like "An implementation of the protocol MUST provide"... >>
> 
> 3.10 Object Existence Query
> 
>   [1] The protocol MUST provide services to determine if a resource
>   exists in the registry. ...                              ^^^^^^^^
> 
> 3.11 Object Information Query
> 
>   [1] The protocol MUST provide services to retrieve information
>   describing a resource from the registry.  Returned information MUST
>                ^^^^^^^^
>   include the identifier of the current sponsoring registrar, the
>   identifier of the registrar that originally registered the 
> resource, 
>                                                              ^^^^^^^^
>   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 resource, the most recent authorization
>                         ^^^^^^^^
>       << another pesky status reference w/o definition yet >>
> 
>   identifier, contact identifiers associated with the resource, and, 
>                                                       ^^^^^^^^     ^
>   if applicable, the associated name servers registered to 
> the resource.  
>   ^^^^^^^^^^^^^^     ^^^^^^^^^^              
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>   The most recent authorization identifier MUST be returned 
> only to the 
>   current sponsoring registrar.
> 
> 3.12 Domain Status Indicators
> 
>   [1] The protocol MUST provide status indicators that identify the
>   operational state of a resource. ...  
>                          ^^^^^^^^
>   [3] A resource MAY have multiple statuses at any given time.  Some
>         ^^^^^^^^
>   statuses MAY be mutually exclusive.
> 

Date: Thu, 8 Feb 2001 13:39:13 -0500
From: George Belotsky <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
Cc: Catherine Murphy <[email-masked]>, Kent Crispin <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked]
Subject: Re: Nameserver as object/entity or not ?
Sender: [email-masked]

As can be seen from Jordyn's post, domains can be treated as objects
and still maintain the policy semantics that Catherine finds
desirable.

Once again, it is important not to confuse policy and mechanism.  In
an object oriented system, attributes of objects may be objects in
their own right.  This is a design issue that is part of the
mechanism.

We are unlikely to totally agree on a set of policies.  Policies will
also change over time, and will be influenced by many factors --
including legislative choices made in various jurisdictions.  Members
of this group can hope to have some input towards such legislative
choices, but will almost certainly not be in a position to make them.

It would thus be helpful to identify the policy problem space, rather
than try to finalize detailed policy decisions.  By correctly
identifying this space, we will build something long lasting and truly
valuable -- something that can outlive the policies of today and adapt
to the policies of the future. 

George.

On Thu, Feb 08, 2001 at 12:58:35PM -0500, Jordyn A. Buchanan wrote:
> At 10:57 AM 2/8/2001 -0500, Catherine Murphy wrote:
> 
> >IP registries are a case in point. While I can see where some domain
> >registries will want to treat nameservers as objects, we can not. The
> >nameserver information that ARIN receives for in-addr nameservers is an
> >attribute (or dependent object) of the IP network object. Kent's point of
> >potentially conflicting ownership/authentication would also hold true for
> >us. Since we are receiving the information from a particular network
> >registrant, the nameserver information only extends to the scope of his
> >authority, i.e., that network. The same nameservers could quite possibly
> >be listed for other networks, but the authority to change a nameserver is
> >limited. There is not inherent "ownership" of the nameserver information.
> >If both Network A and Network B list ns1.foobar.net as its in-addr
> >nameserver, Network A could not come to us and say, change all instances
> >of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that
> >change against its network; ns1.foobar.net would remain on network B.
> 
> I think that there are two separate issues here:
> 
> 1) Should name servers be treated as objects or as attributes of other objects?
> 
> 2) If nameservers are objects, how do we manage ownership of these objects?
> 
> Issue #2 seems to me to be mostly a matter of registry policy.  Some 
> registries may want to say that the owner of a domain implicitly owns all 
> nameservers within that domain.  Others may not, but may want to verify 
> that the owner of the domain approves of someone else having a nameserver 
> in their domain.  Others may not care at all.  The requirement should be 
> for an approach that accommodates these various policies.
> 
> If we look at our objects as being "pointers to nameservers" with the 
> possibility of multiple pointers to the same actual nameserver, I think we 
> can achieve a solution that achieves many of the benefits of the 
> nameserver-as-object approach without the inherent ownership issue.  Such 
> an approach allows a registrant to use a common name server object across 
> many domains (or IP blocks), but doesn't imply that the registrant "owns" 
> the name server or that changes made to the object changes the name server 
> for other people.
> 
> For example, both BigISP and SmallCo may use BigISP's nameserver, 
> NS1.BIGISP.NET.  BigISP creates an object in the database pointing to the 
> nameserver and names it "NS1-BIGISP".  SmallCo has a lot of domains and 
> realizes that they may want to get their own name servers later on, so they 
> create a new object pointing to the same nameserver and call it 
> "NS1-SMALLCO".  Later on, SmallCo does in fact get their own nameservers, 
> so they point "NS1-SMALLCO" at their new nameserver, 
> TINY.SMALLCO.COM.  This allows them to modify the nameserver information on 
> all of their domain names by making a simple modification to the nameserver 
> object, and doesn't affect BigISP's use of NS1.BIGISP.NET in any way.
> 
> If registries or registrars want to make each nameserver an attribute of a 
> domain that doesn't apply to any other domains, they can simply create a 
> new nameserver object for each domain.  This is slightly inefficient, but I 
> don't know why this is a desirable goal in and of it self in the first place.
> 
> >We also differ in that we will be tracking no other data about the
> >nameserver except for the nameserver itself, e.g., ns1.foobar.net.
> >(Currently, we receive the IP address of the nameserver, which is
> >displayed in whois, but is not used to produce glue records. Since we are
> >not authoritative for these nameservers, it does not make sense for us to
> >maintain the IP address.)
> 
> This is already dealt with by the existing requirements.  The IP address of 
> a name server is only required (indeed, is only allowed) if the name server 
> is "registered within the registry's authoritative TLDs".  So, only the 
> .NET registry needs to worry about the IP address of NS1.BIGISP.NET.  In my 
> scheme, we'd only want one version of the name server to actually have an 
> IP address to avoid states where multiple pointers have the same name but 
> different IP addresses.
> 
> Jordyn
> 

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

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Agenda for Interim Meeting
Date: Thu, 8 Feb 2001 13:31:55 -0500 
Sender: [email-masked]

I can probably get the room for an earlier start if our chairs wish to do
so.

<Scott/>

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Thursday, February 08, 2001 10:54 AM
> To: [email-masked]
> Subject: Re: Agenda for Interim Meeting
> 
> 
> Any chance we can start at 9am or even 8:30?
> 
> No doubt some people would arrive a bit later, just as some 
> people will 
> have to leave a bit early.  However traveling that far for 
> such a short 
> meeting makes extending the hours appropriate.
> 
> d/
> 
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg Consulting   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
> 

Date: Thu, 08 Feb 2001 12:58:35 -0500
To: Catherine Murphy <[email-masked]>, Kent Crispin <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Nameserver as object/entity or not ? 
Cc: [email-masked]
Sender: [email-masked]

At 10:57 AM 2/8/2001 -0500, Catherine Murphy wrote:

>IP registries are a case in point. While I can see where some domain
>registries will want to treat nameservers as objects, we can not. The
>nameserver information that ARIN receives for in-addr nameservers is an
>attribute (or dependent object) of the IP network object. Kent's point of
>potentially conflicting ownership/authentication would also hold true for
>us. Since we are receiving the information from a particular network
>registrant, the nameserver information only extends to the scope of his
>authority, i.e., that network. The same nameservers could quite possibly
>be listed for other networks, but the authority to change a nameserver is
>limited. There is not inherent "ownership" of the nameserver information.
>If both Network A and Network B list ns1.foobar.net as its in-addr
>nameserver, Network A could not come to us and say, change all instances
>of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that
>change against its network; ns1.foobar.net would remain on network B.

I think that there are two separate issues here:

1) Should name servers be treated as objects or as attributes of other objects?

2) If nameservers are objects, how do we manage ownership of these objects?

Issue #2 seems to me to be mostly a matter of registry policy.  Some 
registries may want to say that the owner of a domain implicitly owns all 
nameservers within that domain.  Others may not, but may want to verify 
that the owner of the domain approves of someone else having a nameserver 
in their domain.  Others may not care at all.  The requirement should be 
for an approach that accommodates these various policies.

If we look at our objects as being "pointers to nameservers" with the 
possibility of multiple pointers to the same actual nameserver, I think we 
can achieve a solution that achieves many of the benefits of the 
nameserver-as-object approach without the inherent ownership issue.  Such 
an approach allows a registrant to use a common name server object across 
many domains (or IP blocks), but doesn't imply that the registrant "owns" 
the name server or that changes made to the object changes the name server 
for other people.

For example, both BigISP and SmallCo may use BigISP's nameserver, 
NS1.BIGISP.NET.  BigISP creates an object in the database pointing to the 
nameserver and names it "NS1-BIGISP".  SmallCo has a lot of domains and 
realizes that they may want to get their own name servers later on, so they 
create a new object pointing to the same nameserver and call it 
"NS1-SMALLCO".  Later on, SmallCo does in fact get their own nameservers, 
so they point "NS1-SMALLCO" at their new nameserver, 
TINY.SMALLCO.COM.  This allows them to modify the nameserver information on 
all of their domain names by making a simple modification to the nameserver 
object, and doesn't affect BigISP's use of NS1.BIGISP.NET in any way.

If registries or registrars want to make each nameserver an attribute of a 
domain that doesn't apply to any other domains, they can simply create a 
new nameserver object for each domain.  This is slightly inefficient, but I 
don't know why this is a desirable goal in and of it self in the first place.

>We also differ in that we will be tracking no other data about the
>nameserver except for the nameserver itself, e.g., ns1.foobar.net.
>(Currently, we receive the IP address of the nameserver, which is
>displayed in whois, but is not used to produce glue records. Since we are
>not authoritative for these nameservers, it does not make sense for us to
>maintain the IP address.)

This is already dealt with by the existing requirements.  The IP address of 
a name server is only required (indeed, is only allowed) if the name server 
is "registered within the registry's authoritative TLDs".  So, only the 
.NET registry needs to worry about the IP address of NS1.BIGISP.NET.  In my 
scheme, we'd only want one version of the name server to actually have an 
IP address to avoid states where multiple pointers have the same name but 
different IP addresses.

Jordyn

From: Ayesha Damaraju <[email-masked]>
To: [email-masked]
Subject: Transfer Notification a requirement?
Date: Thu, 8 Feb 2001 11:59:59 -0600 
Sender: [email-masked]

Considering below two requirements from GRRP_reqs_06

3.7 Object Transfer

[6] The protocol MUST provide services that allow the original 
sponsoring registrar to approve or reject a requested object transfer.
...............
...........

[8] Object Transfer requests MUST NOT be acted upon without giving the
losing registrar an opportunity to respond to the request...

Unless [8] implies that a notification needs to be sent to the losing
registrar to approve or reject giving them an opportunity - In which case it

needs to be clear, even otherwise notifying the sponsoring registrar to 
approve or reject the transfer should be a requirement.

-Ayesha

Date: Thu, 8 Feb 2001 12:44:26 -0500 (EST)
From: Catherine Murphy <[email-masked]>
To: [email-masked]
Subject: Generalizing the terminology
Sender: [email-masked]

I would like to offer the following specific revisions in an attempt to
reduce the domain name emphasis of the draft. I know that some of the
recent discussion has already affected the draft, but this mark-up goes
against the most recent posting of draft-hollenbeck-grrp-reqs-06.txt.  As
a general comment, I think the document is well thought out and very
thorough. Scott has done a great job getting this started. I also realize
that some of my points have already been made. My goal is to offer
specific alternatives to the existing text. Only the text containing
proposed changes is included below; everything else has been <snip'd>. 

---------------------------------------------
Cathy Murphy <[email-masked]>
Principal Software Engineer
American Registry for Internet Numbers (ARIN)
+1 703 227 9875

<< Based on draft-hollenbeck-grrp-reqs-06.txt (January 19, 2001) >>

1.1 Definitions, Acronyms, and Abbreviations

  [NEW] Resource: A generic term used to describe an object that is
  the primary focus of a registration process. An example of a 
  resource is a domain name or an IP address block. Supporting 
  objects such as contact information are not resources.

  << If you don't agree with having something along the lines 
     of this new definition, don't bother reading further. 
     Most of the changes revolve around this specific term.  >>

  Registrant: An entity that registers resources in a registry
                                       ^^^^^^^^^
  through the services provided by a registrar.  Registrants include
  individuals, organizations, and corporations.

  Registrar: An entity that provides front-end resource registration
                                               ^^^^^^^^
  services to registrants, providing a public interface to registry
  services.

  Registry: An entity that provides back-end resource registration
                                             ^^^^^^^^
  services to registrars, managing a central repository of information
  for a specific portion of that resource, e.g., a given TLD.  A domain 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                 ^^^^^^
  name registry is typically responsible for publication and distribution 
  ^^^^
  of TLD zone files used by the Domain Name System.

2.2 System Functions

  Registrars access a registry through a protocol to register objects
  and perform object management functions.  Required functions include
  session management; object creation, update, renewal, and deletion;
  object query; and object transfer.

  A domain name registry generates DNS zone files for the TLDs it serves. 
  ^^^^^^^^^^^^^ 
  These zone files are created and distributed to a series of name servers
  that provide the foundation for the domain name system.

  Registries MUST provide a whois search capability that provides basic
             ^^^^
  query services for the objects managed by the registry.  ...

3.4 Object Registration

  [1] The protocol MUST provide services to register Internet domain
  names.

  << Why? If the protocol is being used for non-domain name resources,
     this particular requirement seems excessively restrictive, perhaps
     appropriate for a domain name extension to the "generic" RRP. >>

  [2] The protocol MUST permit a starting and ending time for a 
  resource registration to be negotiated, thereby ...
  ^^^^^^^^

  [3] When a resource has been successfully registered, ...
             ^^^^^^^^

  [5] If the resource being registered is a domain name, the protocol 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  MUST provide services to register name servers.  ...

  << Since there has already been extensive discussion about 
     nameservers being objects versus attributes, I will not 
     comment further here except to re-iterate that this 
     portion of the protocol is somewhat distinct to domain
     name registries. >>
 
3.5 Object Association

  [3] The protocol MUST provide services to associate contacts with
  resources. Associated contacts name MUST be identified by type.
  ^^^^^^^^^
  Contact types that MAY be associated with a resource include
                                              ^^^^^^^^
  "registrant", "technical", "administrative", and "billing".  A
  registry MAY support a subset of these contact types.

  << Also, "abuse" >>

3.6 Object Update

  [1] The protocol MUST provide services to update information
  associated with registered resources.  Resource update
                             ^^^^^^^^^   ^^^^^^^^
  services MUST allow changes to status, associated name servers, and
  associated contacts.

  << As far as I can tell, this is the first mention of status. 
     I would like to see the definition of status, which is not
     defined until 3.12, either moved up or explicitly referenced. 
     When I first read this, my immediate thought was "Huh? Did I 
     miss something? What's a status?" >> 

  [2] If the registry includes registration of associated nameservers, 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  the protocol MUST provide services to update information
  associated with registered name servers.  Name server update services
  MUST allow change to IP addresses and server name.

3.7 Object Transfer

  << A general comment about object transfer: this entire section is
     very specific to how domain names are transferred and does not 
     relate well at all to when and how IP networks may be transferred. 
     I cannot speak to how other possible users of the GRRP might work
     transfers, but I will propose other, more generic text for this 
     section in another message thread. Or, this section could be left 
     in the protocol but identified as being domain name specific
     requirements only. >> 

3.8 Object Renewal/Extension

  [1] The protocol MUST provide services to renew or extend the validity
  period of registered resources.  If applicable, ...
                       ^^^^^^^^^

3.9 Object Deletion

  [1] The protocol MUST provide services to remove a resource from
  the registry.                                      ^^^^^^^^

  [2] If the registry contains nameserver objects, the protocol MUST 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  provide services to remove a name server from the registry.

  << A nit: since this is the protocol, shouldn't these say something
     like "An implementation of the protocol MUST provide"... >>

3.10 Object Existence Query

  [1] The protocol MUST provide services to determine if a resource
  exists in the registry. ...                              ^^^^^^^^

3.11 Object Information Query

  [1] The protocol MUST provide services to retrieve information
  describing a resource from the registry.  Returned information MUST
               ^^^^^^^^
  include the identifier of the current sponsoring registrar, the
  identifier of the registrar that originally registered the resource, 
                                                             ^^^^^^^^
  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 resource, the most recent authorization
                        ^^^^^^^^
      << another pesky status reference w/o definition yet >>

  identifier, contact identifiers associated with the resource, and, 
                                                      ^^^^^^^^     ^
  if applicable, the associated name servers registered to the resource.  
  ^^^^^^^^^^^^^^     ^^^^^^^^^^              ^^^^^^^^^^^^^^^^^^^^^^^^^^
  The most recent authorization identifier MUST be returned only to the 
  current sponsoring registrar.

3.12 Domain Status Indicators

  [1] The protocol MUST provide status indicators that identify the
  operational state of a resource. ...  
                         ^^^^^^^^
  [3] A resource MAY have multiple statuses at any given time.  Some
        ^^^^^^^^
  statuses MAY be mutually exclusive.

Date: Thu, 8 Feb 2001 10:57:18 -0500 (EST)
From: Catherine Murphy <[email-masked]>
Reply-To: Catherine Murphy <[email-masked]>
To: Kent Crispin <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: Nameserver as object/entity or not ? 
Sender: [email-masked]

I'd like to chime in. Both Eric and Kent state the problem well: 

Eric Brunner-Williams in Portland Maine wrote:

> Making nameservers into first class objects isn't a given, as
> the dependency relationship between nameservers objects and domain objects
> mandates a contention mechanism.

Kent Crispin wrote:

> If you have nameserver objects, then you have in effect created
> potentially conflicting ownership/authentication domains, and this
> seems to me a very fundamental problem.  (That is, a domain can be 
"owned"
> by A, while the nameservers for the domain may be owned by "B".)  If
> only domains can be owned objects, then there are no possible conflicts
> (at least in the registry DB).

If the GRRP is to be used for something other than domain name
registration down the road, e.g., IP address registration, the protocol
should leave this characterization aside. 

IP registries are a case in point. While I can see where some domain
registries will want to treat nameservers as objects, we can not. The
nameserver information that ARIN receives for in-addr nameservers is an
attribute (or dependent object) of the IP network object. Kent's point of
potentially conflicting ownership/authentication would also hold true for
us. Since we are receiving the information from a particular network
registrant, the nameserver information only extends to the scope of his
authority, i.e., that network. The same nameservers could quite possibly
be listed for other networks, but the authority to change a nameserver is
limited. There is not inherent "ownership" of the nameserver information.
If both Network A and Network B list ns1.foobar.net as its in-addr
nameserver, Network A could not come to us and say, change all instances
of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that
change against its network; ns1.foobar.net would remain on network B.

We also differ in that we will be tracking no other data about the
nameserver except for the nameserver itself, e.g., ns1.foobar.net.
(Currently, we receive the IP address of the nameserver, which is
displayed in whois, but is not used to produce glue records. Since we are
not authoritative for these nameservers, it does not make sense for us to
maintain the IP address.) 

Cathy

---------------------------------------------
Cathy Murphy <[email-masked]>
Principal Software Engineer
American Registry for Internet Numbers (ARIN)
+1 703 227 9875

Date: Thu, 08 Feb 2001 07:53:44 -0800
To: <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Agenda for Interim Meeting
Sender: [email-masked]

Any chance we can start at 9am or even 8:30?

No doubt some people would arrive a bit later, just as some people will 
have to leave a bit early.  However traveling that far for such a short 
meeting makes extending the hours appropriate.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Agenda for Interim Meeting
Date: Thu, 8 Feb 2001 09:53:50 -0500 
Sender: [email-masked]

Salon D.  There is a directory listing rooms and users in/near the lobby (we
will be identified as "IETF provreg Working Group").  Check that directory
upon arrival for any unforeseen changes.

<Scott/>

> -----Original Message-----
> From: Christopher Ambler [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 7:28 PM
> To: [email-masked]
> Subject: Re: Agenda for Interim Meeting
> 
> 
> What room will the meeting be in?

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: 2 points
Date: Thu, 8 Feb 2001 08:35:35 -0500 
Sender: [email-masked]

OK, I'll strike the proposed second sentence if no one else has any
arguments to the contrary.

<Scott/>

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 10:47 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: 2 points
> 
> 
> % > % [11] The protocol MUST provide services to manage name 
> % > servers associated
> % > % with multiple domains.  No name server data SHOULD exist in 
> % > the registry
> % > % without an associated parent domain.
> % > 
> % > 	I'd loose the second sentence. 
> % 
> % Why?  The functional implication is that you can end up 
> with A records in a
> % zone without NS records that refer to those A records.  
> I've been told that
> % this won't cause server software like BIND to choke, but 
> it's not optimal.
> % 
> % <Scott/>
> 
> Hum...
> 	First off, can we "loose" the term domain? Or at least 
> 	the concept of "parent"?  I am really trying hard to
> 	make this generic. So that the "backend" database and
> 	its administration et.al. that we are talking about has
> 	three generic components:
> 		The delegation point particulars, e.g. the domain
> 		The description of the publication method, e.g. 
> nameservers
> 		Authorized contacts for each.
> 
> Because the situation is covered in the first sentence. Or there is
> an implied linkage in the second. Either the protocol will be able
> to "manage" nameservers, regardless of delegation data Or, 
> you are mandating
> that "orpahn" nameserver data SHOULD exist w/o an associated 
> delegation
> data. I would expect that, operationally, there would be times when
> namserver data would exist w/o any association to other delegation
> information. (Very temporary)  At no time should delegation 
> particulars or
> nameserver data exist without accompanying authorized contact data.
> 
> 
> --bill 

From: Bill Manning <[email-masked]>
Subject: Re: 2 points
To: [email-masked] (Hollenbeck, Scott)
Date: Wed, 7 Feb 2001 19:46:58 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

% > % [11] The protocol MUST provide services to manage name 
% > servers associated
% > % with multiple domains.  No name server data SHOULD exist in 
% > the registry
% > % without an associated parent domain.
% > 
% > 	I'd loose the second sentence. 
% 
% Why?  The functional implication is that you can end up with A records in a
% zone without NS records that refer to those A records.  I've been told that
% this won't cause server software like BIND to choke, but it's not optimal.
% 
% <Scott/>

Hum...
	First off, can we "loose" the term domain? Or at least 
	the concept of "parent"?  I am really trying hard to
	make this generic. So that the "backend" database and
	its administration et.al. that we are talking about has
	three generic components:
		The delegation point particulars, e.g. the domain
		The description of the publication method, e.g. nameservers
		Authorized contacts for each.

Because the situation is covered in the first sentence. Or there is
an implied linkage in the second. Either the protocol will be able
to "manage" nameservers, regardless of delegation data Or, you are mandating
that "orpahn" nameserver data SHOULD exist w/o an associated delegation
data. I would expect that, operationally, there would be times when
namserver data would exist w/o any association to other delegation
information. (Very temporary)  At no time should delegation particulars or
nameserver data exist without accompanying authorized contact data.

--bill

From: Bill Manning <[email-masked]>
Subject: 2 points
To: [email-masked] (Hollenbeck, Scott)
Date: Wed, 7 Feb 2001 19:10:54 -0800 (PST)
Cc: [email-masked] ([email-masked]')
Sender: [email-masked]

% [10] All registrars MUST be authorized to register objects in the registry.

	All <approved/authorized> registrars

% [11] The protocol MUST provide services to manage name servers associated
% with multiple domains.  No name server data SHOULD exist in the registry
% without an associated parent domain.

	I'd loose the second sentence. 

% 
% <Scott/>

-- 
--bill

From: Bill Manning <[email-masked]>
Subject: draft-ops-ip-config-management-reqmnts-00.txt
To: [email-masked], [email-masked]
Date: Wed, 7 Feb 2001 08:35:32 -0800 (PST)
Sender: [email-masked]

Burt just raised this expired draft in the IETF policy working group.
He is intending to make this an Informational RFC... so, if folks think
this is important, they might want to comment to Burt &/or the Authors.

	------------------------------------------------------

   Requirements for Configuration Management of IP-based networks
...
1.1 Motivation, Scope and Goals of this document

    Over the past several months, a number of IETF working groups have
    introduced new technologies which offer integrated and
    differentiated services.  To support these new technologies,
    working group members found that they had new requirements for
    configuration of these technologies. One of these new requirements
    was for the provisioning (configuration) of behavior at the
    network level
...

-- 
--bill

Date: Tue, 6 Feb 2001 12:35:40 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: =?iso-8859-2?q?J=F6rg_Bauer=2FDenic?= <[email-masked]>
cc: "Brian W. Spolarich" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

There are several (in my opinion, good) reasons that nameservers are
considered seperate entities from the domains in which they are
registered.

The first is related to the way DNS works.  In the zone files of the TLDs
there are entries for each name server (I don't work for any TLD mind you
... I'm just saying this from what I know of DNS, and the details may be
inaccurate) which serve as glue records so that each TLD name server can
find authortiative access for subdomains (the SLDs that actually have real
entries for each domain).  These glue records are non-authoritative, but
necassary and make DNS pretty messy (annoying things can happen if a TLD
glue record is out of sync with the authoritative record of the real name
servers).  Thus it makes sense to have nameservers recorded at the same
level as the domains themselves so that there is a more natural mapping
from the registry to the zone files.

Second, is the requirements registries often put on a domain (at least the
way NSI was).  For a domain to be registered requires at least two valid
nameservers.  This means the nameservers have to be registered before the
domain itself is (as seperate entities).

A third, less technical, reason is minimizing data redundancy and
simplifying domain administration.  As a registrant I may want to register
10,000 domains all on the same physical DNS server.  Rather than
registering 10,000 (or 20,000 for each domain) name servers, I just 
register two for my two main name servers under one of the domains and
then register all the domains under these name servers.  Of course this
can be done if name servers are a domain attribute (you just set the
attributes all to be those two name servers); this is just an argument for
why the domain and the nameserver are not as closely coupled as being a
domain attribute would suggest (and its much more natural for a domain to
refer to another DB entity as an attribute, than to refer to an attribute
of another domain as one of its attributes -- this would be analogous to
refering to another record in a table through a key rather than refering
to a sub-record in another record -- sorry if my convoluted language has
gotten out of hand).

Regards,
Sheer 

On Tue, 6 Feb 2001, [iso-8859-2] Jörg Bauer/Denic wrote:

> On 05.02.2001 20:29 "Brian W. Spolarich" <[email-masked]> wrote:
> >
> >   As a registrant, the thing that I care about is that the nameservers
> that
> > I registered with my domain don't change unless I explicity authorize the
> > change.
> >
> >   I'm wondering if the problem here is the idea of having separate
> > nameserver and domain objects.  In my mind, the nameserver is an
> attribute
> > of the domain, and doesn't have any independent identity.  What problem
> does
> > having the nameservers as separate entities solve?
> >
> 
> That´s exact the way we do it here in Germany.
> We dont´t know anything about Nameserver Objects and i still can´t see it
> as a requirement.
> 
> --
> ----------------------------------+-------------------------------------------
> 
> Joerg Bauer                       | eMail : [email-masked]
> DENIC eG                          | Fon   : +49 69 272 35 180
> Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
> D-60329 Frankfurt                 |
> ----------------------------------+-------------------------------------------
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: 2 points
Date: Wed, 7 Feb 2001 22:17:37 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 10:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: 2 points
> 
> 
> % [10] All registrars MUST be authorized to register objects 
> in the registry.
> 
> 	All <approved/authorized> registrars
> 
> % [11] The protocol MUST provide services to manage name 
> servers associated
> % with multiple domains.  No name server data SHOULD exist in 
> the registry
> % without an associated parent domain.
> 
> 	I'd loose the second sentence. 

Why?  The functional implication is that you can end up with A records in a
zone without NS records that refer to those A records.  I've been told that
this won't cause server software like BIND to choke, but it's not optimal.

<Scott/>

From: [email-masked]
To: <[email-masked]>
Date: Thu, 8 Feb 2001 09:05:56 +0700
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

As somebody (James?) has pointed out,
there are many applications of this protocol.
It is not a good idea to restrict the protocol for DNS *only*.
For example, the protocol can be used to provide
information such as:
- cell phone database
- URL redirection, Web site directory
- SMS
- paging
- etc. etc.

However, if we go for broader term/application, we
may not get this protocol up and running quickly.
How about if DNS is used as a case/example of
this protocol usage?

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>
Subject: Re: Agenda for Interim Meeting
Date: Wed, 7 Feb 2001 16:27:42 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

What room will the meeting be in?

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]
----- Original Message ----- 
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 07, 2001 5:11 AM
Subject: RE: Agenda for Interim Meeting

> This looks reasonable.  With limited time it might be wise to identify a set
> of macro-level EPP discussion topics before the meeting.
> 
> <Scott/>
> 
> > -----Original Message-----
> > From: Edward Lewis [mailto:[email-masked]]
> > Sent: Monday, February 05, 2001 11:17 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Agenda for Interim Meeting
> > 
> > 
> > Here's the proposal I sent earlier:
> > 
> >      Agenda bashing: (short)
> >      WG status: (short)
> >      The EPP proposal
> >      Other proposals
> >      Discussion of forming a design team
> > 
> > Comments?
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Wed, 7 Feb 2001 12:13:12 -0500 
Sender: [email-masked]

(Sorry if this is a duplicate message for anyone -- I sent it to the list
earlier today, but it doesn't appear to have been redistributed yet.)

Good point.  I'd like to keep the first sentence of the current wording in
it's own requirement, though, because it deals with client privileges.  I'd
also like to suggest a rewording of your rewording because the "MUST be able
to track changes" phrase sounds (to me) like a requirement for keeping state
information in the protocol.  Would you (and everyone else) be OK with this:

[10] All registrars MUST be authorized to register objects in the registry.

[11] The protocol MUST provide services to manage name servers associated
with multiple domains.  No name server data SHOULD exist in the registry
without an associated parent domain.

<Scott/>

> -----Original Message-----
> From: James Seng/Personal [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 9:28 AM
> To: Hollenbeck, Scott; [email-masked]
> Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
> 
> 
> Well, when you face with a problem like this such as
> 
> a) Mass changing of IP of Nameservers
> b) Consistency of Name servers
> c) Delete of parent Domain Name
> etc
> 
> Rather than publishing the design (ie nameserver object + name object
> and their relationship), you could specify the problem and 
> make that as
> a requirement.
> 
> In this case, this requirement
> 
>   [10] All registrars MUST be authorized to register objects in the
>   registry.  Name server registration MUST be limited to the registrar
>   of the name server's parent domain.  Unauthorized attempts 
> to register
>   a name server in a parent domain administered by another registrar
>   MUST be explicitly rejected.
> 
> would become
> 
>   [10] The Protocol MUST be able to track changes in 
> nameservers across
>   all domain names which is associated with it. No nameserver data
>   SHOULD exist in the registry if the parent domain names has cease to
>   exist.
> 
> -James Seng
> 
> ----- Original Message -----
> From: "Hollenbeck, Scott" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 07, 2001 6:15 AM
> Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
> 
> 
> > FWIW we had quite a lengthy name server management discussion on the
> old RRP
> > list some months ago, and truth be told we never came to complete
> agreement.
> > There are positive and negative aspects of managing name servers as
> either
> > top-level objects or as attributes of other objects, such 
> as domains.
> >
> > The attribute idea makes sense in the context of managing a small
> number of
> > domains, but it gets unwieldy from a management perspective when a
> name
> > server is hosting thousands or millions of domains.  Cross-registrar
> > coordination is also tricky if top level server objects and domain
> objects
> > can be managed by different registrars -- how do things 
> work if domain
> > foo.com must be deleted by one registrar, but another registrar has
> > management authority for ns1.foo.com?  If domain foo.com 
> gets deleted,
> is it
> > a good idea to publish an "orphan" glue record for ns1.foo.com?
> >
> > Anyway, the current requirements language was thought by me 
> to be the
> most
> > reasonable compromise based on operational experience.
> >
> > <Scott/>
> 
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Wed, 7 Feb 2001 10:26:52 -0500 
Sender: [email-masked]

Good point.  I'd like to keep the first sentence of the current wording in
it's own requirement, though, because it deals with client privileges.  I'd
also like to suggest a rewording of your rewording because the "MUST be able
to track changes" phrase sounds (to me) like a requirement for keeping state
information in the protocol.  Would you (and everyone else) be OK with this:

[10] All registrars MUST be authorized to register objects in the registry.

[11] The protocol MUST provide services to manage name servers associated
with multiple domains.  No name server data SHOULD exist in the registry
without an associated parent domain.

<Scott/>

> -----Original Message-----
> From: James Seng/Personal [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 9:28 AM
> To: Hollenbeck, Scott; [email-masked]
> Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
> 
> 
> Well, when you face with a problem like this such as
> 
> a) Mass changing of IP of Nameservers
> b) Consistency of Name servers
> c) Delete of parent Domain Name
> etc
> 
> Rather than publishing the design (ie nameserver object + name object
> and their relationship), you could specify the problem and 
> make that as
> a requirement.
> 
> In this case, this requirement
> 
>   [10] All registrars MUST be authorized to register objects in the
>   registry.  Name server registration MUST be limited to the registrar
>   of the name server's parent domain.  Unauthorized attempts 
> to register
>   a name server in a parent domain administered by another registrar
>   MUST be explicitly rejected.
> 
> would become
> 
>   [10] The Protocol MUST be able to track changes in 
> nameservers across
>   all domain names which is associated with it. No nameserver data
>   SHOULD exist in the registry if the parent domain names has cease to
>   exist.
> 
> -James Seng
> 
> ----- Original Message -----
> From: "Hollenbeck, Scott" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 07, 2001 6:15 AM
> Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
> 
> 
> > FWIW we had quite a lengthy name server management discussion on the
> old RRP
> > list some months ago, and truth be told we never came to complete
> agreement.
> > There are positive and negative aspects of managing name servers as
> either
> > top-level objects or as attributes of other objects, such 
> as domains.
> >
> > The attribute idea makes sense in the context of managing a small
> number of
> > domains, but it gets unwieldy from a management perspective when a
> name
> > server is hosting thousands or millions of domains.  Cross-registrar
> > coordination is also tricky if top level server objects and domain
> objects
> > can be managed by different registrars -- how do things 
> work if domain
> > foo.com must be deleted by one registrar, but another registrar has
> > management authority for ns1.foo.com?  If domain foo.com 
> gets deleted,
> is it
> > a good idea to publish an "orphan" glue record for ns1.foo.com?
> >
> > Anyway, the current requirements language was thought by me 
> to be the
> most
> > reasonable compromise based on operational experience.
> >
> > <Scott/>
> 
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Agenda for Interim Meeting
Date: Wed, 7 Feb 2001 08:11:55 -0500 
Sender: [email-masked]

This looks reasonable.  With limited time it might be wise to identify a set
of macro-level EPP discussion topics before the meeting.

<Scott/>

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Monday, February 05, 2001 11:17 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Agenda for Interim Meeting
> 
> 
> Here's the proposal I sent earlier:
> 
>      Agenda bashing: (short)
>      WG status: (short)
>      The EPP proposal
>      Other proposals
>      Discussion of forming a design team
> 
> Comments?

From: "James Seng/Personal" <[email-masked]>
To: "Mike Lampson" <[email-masked]>, <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Thu, 8 Feb 2001 01:23:53 +0800
Sender: [email-masked]

In my previous life, I work on BioInformatics Technology. We deal with
large amount of data generated from genome project. Unfortunately, these
data are scattered in all over the network, university network,
commerical network, using varity of database backend, providing
different kind of interface, using varity of data schema. No one can
agree.

Yes, it is kind of nightmare. But if you think about it, it is no
different from the problem we facing now, with domain names object
scattered in various registries, no standard interface, no fix data
schema etc. No one can agree.

We probably not qualified to solve their problems. But do not think only
Domain Names have these problem. The implication of this provreg could
be very little or very huge.

ps: Looking back..Imaging if HTTP/HTML is design with requirements that
"URL MUST reference to physic information"...I wonder how Internet would
look like now.

-James Seng

----- Original Message -----
From: "Mike Lampson" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 07, 2001 11:29 PM
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

> > I am suggesting that
> >
> > a. Quite a lot of other domain names registries have not read it.
> > b. It is probably still incomplete and need more work.
>
> This is likely true.  However, do we care as long as we consider that:
>
> 1) It is only useful for Registries who want an API for Registrants,
> Registrars or Resellers?  (Registries with only a single GUI and/or
web page
> interface won't care.)
>
> 2) It is truly extensible and enhancements can be added as these other
> Registries seek to adopt a common data management model and discover
> limitations in this interface?
>
> I'm not saying we shouldn't build as much capability into this system
from
> day 1.  However, we should work with the specific requirements
identified by
> those with the most interest and need for a common protocol -- namely
the
> existing participants on this list.
>
> By the way, keep YOUR comments coming.  Let's just make sure that this
> process continues to move forward as quickly as possible.
>
> Cheers,
>
> _Mike
> --
> Mike Lampson
> The Registry at Info Avenue, LLC
> (803) 802-6584
>
> ----- Original Message -----
> From: "James Seng/Personal" <[email-masked]>
> To: "Sheer El-Showk" <[email-masked]>; "Brian W Spolarich"
> <[email-masked]>
> Cc: "Patrick" <[email-masked]>; "Kent Crispin" <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, February 07, 2001 9:38 AM
> Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
>
>
> > Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I
> > never objected to Scott's GRRP Requirements I-D as a starting group.
So
> > I make it in plain English: It is a good start.
> >
> > I am suggesting that
> >
> > a. Quite a lot of other domain names registries have not read it.
> > b. It is probably still incomplete and need more work.
> >
> > -James Seng
> >
> > > If it is, then I am definately in agreement with the general
> > sentiment.  I
> > > don't think we should leave domain name authority in the hands of
the
> > > registrars ... that's an implementation issue (ie per registry)
and
> > > should certainly not be enforced by the protocol.  I don't think,
> > however,
> > > that this is enough ground to say that Scott's doc is a bad basis
for
> > a WG
> > > (I havn't actually looked over the revised version enough to say
> > whether I
> > > like it or not).
> >
> >
>

Date: Wed, 07 Feb 2001 10:29:44 -0500
From: Mike Lampson <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
To: [email-masked]
Sender: [email-masked]

> I am suggesting that
>
> a. Quite a lot of other domain names registries have not read it.
> b. It is probably still incomplete and need more work.

This is likely true.  However, do we care as long as we consider that:

1) It is only useful for Registries who want an API for Registrants,
Registrars or Resellers?  (Registries with only a single GUI and/or web page
interface won't care.)

2) It is truly extensible and enhancements can be added as these other
Registries seek to adopt a common data management model and discover
limitations in this interface?

I'm not saying we shouldn't build as much capability into this system from
day 1.  However, we should work with the specific requirements identified by
those with the most interest and need for a common protocol -- namely the
existing participants on this list.

By the way, keep YOUR comments coming.  Let's just make sure that this
process continues to move forward as quickly as possible.

Cheers,

_Mike
--
Mike Lampson
The Registry at Info Avenue, LLC
(803) 802-6584

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: "Sheer El-Showk" <[email-masked]>; "Brian W Spolarich"
<[email-masked]>
Cc: "Patrick" <[email-masked]>; "Kent Crispin" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, February 07, 2001 9:38 AM
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

> Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I
> never objected to Scott's GRRP Requirements I-D as a starting group. So
> I make it in plain English: It is a good start.
>
> I am suggesting that
>
> a. Quite a lot of other domain names registries have not read it.
> b. It is probably still incomplete and need more work.
>
> -James Seng
>
> > If it is, then I am definately in agreement with the general
> sentiment.  I
> > don't think we should leave domain name authority in the hands of the
> > registrars ... that's an implementation issue (ie per registry) and
> > should certainly not be enforced by the protocol.  I don't think,
> however,
> > that this is enough ground to say that Scott's doc is a bad basis for
> a WG
> > (I havn't actually looked over the revised version enough to say
> whether I
> > like it or not).
>
>

To: "James Seng/Personal" <[email-masked]>
cc: "Sheer El-Showk" <[email-masked]>, "Brian W. Spolarich" <[email-masked]>, "Patrick" <[email-masked]>, "Kent Crispin" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting] 
Date: Wed, 07 Feb 2001 10:26:15 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I
> never objected to Scott's GRRP Requirements I-D as a starting group. So
> I make it in plain English: It is a good start.

Progress. Late, after significant smoke and little light, but an improvement.

> I am suggesting that
> 
> a. Quite a lot of other domain names registries have not read it.

So? The readership levels for the alternatives is even less compelling.

> b. It is probably still incomplete and need more work.

A given, which could have been verified by writing Scott, or any AD who
didn't last-call it on first reading.

Eric

From: "James Seng/Personal" <[email-masked]>
To: "Sheer El-Showk" <[email-masked]>, "Brian W. Spolarich" <[email-masked]>
Cc: "Patrick" <[email-masked]>, "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Wed, 7 Feb 2001 22:38:27 +0800
Sender: [email-masked]

Maybe I wasn't clear (*sigh* I got misunderstood a lot here), but I
never objected to Scott's GRRP Requirements I-D as a starting group. So
I make it in plain English: It is a good start.

I am suggesting that

a. Quite a lot of other domain names registries have not read it.
b. It is probably still incomplete and need more work.

-James Seng

> If it is, then I am definately in agreement with the general
sentiment.  I
> don't think we should leave domain name authority in the hands of the
> registrars ... that's an implementation issue (ie per registry) and
> should certainly not be enforced by the protocol.  I don't think,
however,
> that this is enough ground to say that Scott's doc is a bad basis for
a WG
> (I havn't actually looked over the revised version enough to say
whether I
> like it or not).

From: "James Seng/Personal" <[email-masked]>
To: "Patrick" <[email-masked]>, "Urs Eppenberger" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Wed, 7 Feb 2001 22:28:57 +0800
Sender: [email-masked]

objects may have kind of "ownership". Who has the right to say who
owns what object and how it is been used? By associating with parent
object may be one a good idea but it does not really work when the child
object may have multiple parent object (as in this case of nameserver
object).

IMHO, authentication are needed for each different objects for different
purposes (read, write, reference etc). irregardless whether you refer to
domain names, nameservers, contact etc. each of them probably have very
funny relationship and ownership.

No, this is not a requirement. It is a design approach to the same
problem.

-James Seng

> I'm sorry, maybe because i'm not English, but I do not understand
> this.
>
> The problem remains in my POV : if someone claims to ``own'' a
> nameserver, how do you authentify that claim ?
> You do a reverse lookup on the name, and obtain an IP. And then ?
> How do you know it is correct or not ?
>
> Sorry for asking, I just do not understand.
> But it is true that the hostname can be the key. Still we need
> attributes attached to it I think.
>
> Patrick.

From: "James Seng/Personal" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Wed, 7 Feb 2001 22:28:17 +0800
Sender: [email-masked]

Well, when you face with a problem like this such as

a) Mass changing of IP of Nameservers
b) Consistency of Name servers
c) Delete of parent Domain Name
etc

Rather than publishing the design (ie nameserver object + name object
and their relationship), you could specify the problem and make that as
a requirement.

In this case, this requirement

  [10] All registrars MUST be authorized to register objects in the
  registry.  Name server registration MUST be limited to the registrar
  of the name server's parent domain.  Unauthorized attempts to register
  a name server in a parent domain administered by another registrar
  MUST be explicitly rejected.

would become

  [10] The Protocol MUST be able to track changes in nameservers across
  all domain names which is associated with it. No nameserver data
  SHOULD exist in the registry if the parent domain names has cease to
  exist.

-James Seng

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 07, 2001 6:15 AM
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

> FWIW we had quite a lengthy name server management discussion on the
old RRP
> list some months ago, and truth be told we never came to complete
agreement.
> There are positive and negative aspects of managing name servers as
either
> top-level objects or as attributes of other objects, such as domains.
>
> The attribute idea makes sense in the context of managing a small
number of
> domains, but it gets unwieldy from a management perspective when a
name
> server is hosting thousands or millions of domains.  Cross-registrar
> coordination is also tricky if top level server objects and domain
objects
> can be managed by different registrars -- how do things work if domain
> foo.com must be deleted by one registrar, but another registrar has
> management authority for ns1.foo.com?  If domain foo.com gets deleted,
is it
> a good idea to publish an "orphan" glue record for ns1.foo.com?
>
> Anyway, the current requirements language was thought by me to be the
most
> reasonable compromise based on operational experience.
>
> <Scott/>

Date: Wed, 7 Feb 2001 11:36:03 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver as object/entity or not ?
Organization: Gandi
Sender: [email-masked]

On Tue, Feb 06, 2001 at 09:19:59AM -0800, Kent Crispin took time to write:
> If you have nameserver objects, then you have in effect created 
> potentially conflicting ownership/authentication domains, and this 
> seems to me a very fundamental problem.  (That is, a domain can be "owned"
> by A, while the nameservers for the domain may be owned by "B".)  If 
> only domains can be owned objects, then there are no possible conflicts 
> (at least in the registry DB).

You have the exact same problems in other cases too, like for
contacts (handle) : domain owned by A who uses contact owned by B.

Patrick.

Date: Wed, 7 Feb 2001 11:32:10 +0100
From: Patrick <[email-masked]>
To: Sheer El-Showk <[email-masked]>
Cc: "Brian W. Spolarich" <[email-masked]>, James Seng/Personal <[email-masked]>, Kent Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Organization: Gandi
Sender: [email-masked]

On Tue, Feb 06, 2001 at 10:17:38AM -0500, Sheer El-Showk took time to write:
> posting.  What he was complaining about was that the authority to register
> a nameserver under a domain resided with the Registrar which held the
> domain, not the registrant.  As a registrant I may register domain D1 with

Like the authority to change nameservers of a domain resides with
(through) the Registrar used to register the domain name.

> registrar R1, but want to register nameserver N1 within D1 (this is an 
> important distinction -- the domain of nameservers for a particular
> domain is not restricted, eg foobar.com can have ns1.foobar.tv as its
> nameserver, but any nameservers being registered _within_ a domain
> must be registered by the source of authority for the domain -- the
> registrant or the registrar, eg only the owner of foobar.com should be 
> able to register the nameserver ns1.foobar.com as a nameserver) with

That is exactly what needs to be done, I agree.

> registrar R2.  James was saying that there should be some kind of token of
> authority (a PGP key?? ;->) that allows me as a registrant to do
> authoritative things for my domain (like register a nameserver under
> it) through any registrar, not just the one with which I registered the
> domain.

I do not understand why here we try to let the registrant do things
wirthout going through a Registrar. Why make the registration of
nameserver a different case ?

The same problem exist in other part : like for contacts in the thick
registry. How do you handle them ? Someone register a contact through
a given Registrar. To help avoid the actual handle problems (each
different for a Registrar), they should be unique. Who can change
them ? Through wich Registrar ?

> If it is, then I am definately in agreement with the general sentiment.  I
> don't think we should leave domain name authority in the hands of the
> registrars ... that's an implementation issue (ie per registry) and

Other than that I really welcome a global setup where registrant
could make changes directly, without going through a Registrar, or
using whatever Registrar they want. But if you go that route, you must
consider all cases (change of ownership, change of contacts, change
of Registar, change of nameservers, etc...).
It seems to me a difficult case, but really interesting.

However going that way can really fast lead to this question : what
purpose has the Registrar if a Registrant can do anything he wants
directly to the Registry without using a Registrar ? Or by choosing
any Registrar to do modifications by himself.

Would RRP (or its successor) be also a RegisTRANT-RegisTRY protocol ?

Regards,

Patrick.

Date: Wed, 7 Feb 2001 11:24:11 +0100
From: Patrick <[email-masked]>
To: Urs Eppenberger <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Organization: Gandi
Sender: [email-masked]

On Wed, Feb 07, 2001 at 08:57:33AM +0100, Urs Eppenberger took time to write:
> --On Montag, 5. Februar 2001 20:38 Uhr +0100 Patrick <[email-masked]>
> wrote:
> 
> > Right... because you do not use ns1.foobar.com and ns2.foobar.com as
> > nameserver. In your case, someone just polluted the database.
> > As soon as your domain use ns{1,2}.foobar.com, you are hijacked...
> > 
> > That is inconvenient, since when the true owner will want to register
> > them for its true use, the Registry might not allow him, since they
> > already exist (with bogus data). How do you control who can change
> > the IP ?
> 
> You can get easy around this hijack problem. Just use the host name as the
> object handle (or database key). Reverselookup must work. In such a case
> you as holder of foobar.com has authority over *.foobar.com, generally you
> can walk over to that guy and knock him. So, if a 'wrong' owner registered
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what does that mean ?
> a bogus hijack-nameserver, that wrong owner sits close. You most probably
> have administrative control in your company over such a situation and there
> is no need for the registry or for the protocol to ensure a correct
> behaviour inside third party organisations.

I'm sorry, maybe because i'm not English, but I do not understand
this.

The problem remains in my POV : if someone claims to ``own'' a
nameserver, how do you authentify that claim ?
You do a reverse lookup on the name, and obtain an IP. And then ?
How do you know it is correct or not ?

Sorry for asking, I just do not understand.
But it is true that the hostname can be the key. Still we need
attributes attached to it I think.

Patrick.

Date: Tue, 6 Feb 2001 12:35:40 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: =?iso-8859-2?q?J=F6rg_Bauer=2FDenic?= <[email-masked]>
cc: "Brian W. Spolarich" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

There are several (in my opinion, good) reasons that nameservers are
considered seperate entities from the domains in which they are
registered.

The first is related to the way DNS works.  In the zone files of the TLDs
there are entries for each name server (I don't work for any TLD mind you
... I'm just saying this from what I know of DNS, and the details may be
inaccurate) which serve as glue records so that each TLD name server can
find authortiative access for subdomains (the SLDs that actually have real
entries for each domain).  These glue records are non-authoritative, but
necassary and make DNS pretty messy (annoying things can happen if a TLD
glue record is out of sync with the authoritative record of the real name
servers).  Thus it makes sense to have nameservers recorded at the same
level as the domains themselves so that there is a more natural mapping
from the registry to the zone files.

Second, is the requirements registries often put on a domain (at least the
way NSI was).  For a domain to be registered requires at least two valid
nameservers.  This means the nameservers have to be registered before the
domain itself is (as seperate entities).

A third, less technical, reason is minimizing data redundancy and
simplifying domain administration.  As a registrant I may want to register
10,000 domains all on the same physical DNS server.  Rather than
registering 10,000 (or 20,000 for each domain) name servers, I just 
register two for my two main name servers under one of the domains and
then register all the domains under these name servers.  Of course this
can be done if name servers are a domain attribute (you just set the
attributes all to be those two name servers); this is just an argument for
why the domain and the nameserver are not as closely coupled as being a
domain attribute would suggest (and its much more natural for a domain to
refer to another DB entity as an attribute, than to refer to an attribute
of another domain as one of its attributes -- this would be analogous to
refering to another record in a table through a key rather than refering
to a sub-record in another record -- sorry if my convoluted language has
gotten out of hand).

Regards,
Sheer 

On Tue, 6 Feb 2001, [iso-8859-2] Jörg Bauer/Denic wrote:

> On 05.02.2001 20:29 "Brian W. Spolarich" <[email-masked]> wrote:
> >
> >   As a registrant, the thing that I care about is that the nameservers
> that
> > I registered with my domain don't change unless I explicity authorize the
> > change.
> >
> >   I'm wondering if the problem here is the idea of having separate
> > nameserver and domain objects.  In my mind, the nameserver is an
> attribute
> > of the domain, and doesn't have any independent identity.  What problem
> does
> > having the nameservers as separate entities solve?
> >
> 
> That´s exact the way we do it here in Germany.
> We dont´t know anything about Nameserver Objects and i still can´t see it
> as a requirement.
> 
> --
> ----------------------------------+-------------------------------------------
> 
> Joerg Bauer                       | eMail : [email-masked]
> DENIC eG                          | Fon   : +49 69 272 35 180
> Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
> D-60329 Frankfurt                 |
> ----------------------------------+-------------------------------------------
> 

Date: Tue, 6 Feb 2001 10:17:38 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
cc: Patrick <[email-masked]>, James Seng/Personal <[email-masked]>, Kent Crispin <[email-masked]>, [email-masked]
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

Actually, all this is missing the point of (James') the original
posting.  What he was complaining about was that the authority to register
a nameserver under a domain resided with the Registrar which held the
domain, not the registrant.  As a registrant I may register domain D1 with
registrar R1, but want to register nameserver N1 within D1 (this is an 
important distinction -- the domain of nameservers for a particular
domain is not restricted, eg foobar.com can have ns1.foobar.tv as its
nameserver, but any nameservers being registered _within_ a domain
must be registered by the source of authority for the domain -- the
registrant or the registrar, eg only the owner of foobar.com should be 
able to register the nameserver ns1.foobar.com as a nameserver) with
registrar R2.  James was saying that there should be some kind of token of
authority (a PGP key?? ;->) that allows me as a registrant to do
authoritative things for my domain (like register a nameserver under
it) through any registrar, not just the one with which I registered the
domain.

James, is that right?

If it is, then I am definately in agreement with the general sentiment.  I
don't think we should leave domain name authority in the hands of the
registrars ... that's an implementation issue (ie per registry) and
should certainly not be enforced by the protocol.  I don't think, however,
that this is enough ground to say that Scott's doc is a bad basis for a WG
(I havn't actually looked over the revised version enough to say whether I
like it or not).

Sorry for that complex clarification.  Hope it helps.

Regards,
Sheer

On Mon, 5 Feb 2001, Brian W. Spolarich wrote:

> | If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then
> | basically anyone can hijack my domain (pointing www.foobar.com to
> | whatever IP, etc...)
> |
> | Thus the nameservers must be only registered by the Registrar who has
> | registered foobar.com, and the Registrar must ensure that only
> | someone with authority on foobar.com (contacts) can create
> | *.foobar.com
> |
> | There is no conflict possible in that case.
> | A given nameserver can only be registered once (even if it is used in
> | many domains) through only a given Registrar.
> 
>   Okay, I get it. :-)  I figured it was something like that, but was having
> a hard time with the language.
> 
>   I don't see as strong of a coupling between the hostnames associated with
> the authoritative nameservers for a domain and the hijacking problem.  It is
> ultimately what shows up in the NS records associated with the domain that
> matters.  I might choose to delegate foobar.com to ns1.myisp.net and
> ns2.myisp.net.  If someone registers nameservers ns1.foobar.com and
> ns2.foobar.com in the registry this is inconvenient and annoying, but not
> really a hijcaking issue.
> 
>   In addition, I'm not sure that this coupling will work well in a very
> distributed context.  Lets say that I own 'foobar.com' today, registered
> through registrar 'spumco' and I have two nameservers running,
> ns1.foobar.com and ns2.foobar.com.  I want to register 'foobar.biz' and
> 'foobar.info', using my current nameservers, ns{1,2}.foobar.com.
> 
>   In order to complete the domain registration I'll have to register my
> nameservers into the .biz and .info registries.  Registrar 'spumco', who
> performed the 'foobar.com' registration, doesn't offer registrations with
> .biz and .info, so I go to registrar 'blammo'.
> 
>   Does this mean that I cannot register my nameservers through 'blammo' with
> .biz because 'spumco' holds the registration for 'foobar' in .com?
> 
>   This seems problematic.
> 
>   As a registrant, the thing that I care about is that the nameservers that
> I registered with my domain don't change unless I explicity authorize the
> change.
> 
>   I'm wondering if the problem here is the idea of having separate
> nameserver and domain objects.  In my mind, the nameserver is an attribute
> of the domain, and doesn't have any independent identity.  What problem does
> having the nameservers as separate entities solve?
> 
>   -bws
> 

Date: Tue, 6 Feb 2001 15:18:06 +0100
From: Patrick <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
Cc: J?rg Bauer/Denic <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Nameserver as object/entity or not ?
Organization: Gandi
Sender: [email-masked]

On Tue, Feb 06, 2001 at 08:58:03AM -0500, Brian W. Spolarich took time to write:
> 
> | ThatÂ´s exact the way we do it here in Germany.
> | We dontÂ´t know anything about Nameserver Objects and i still canÂ´t see it
> | as a requirement.
> 
>   As Patrick pointed out, one advantage to keeping separate NS objects is that
> if one needs to change the address of a given server, only one record needs to be
> updated (i.e. normalization).  It would be interesting to know how often this is
> used.

>From experience, I can tell you that it is used. I was working before
in an ISP. One day we had to change our Internet connexion, which
changed the IP of our nameservers, thus the need to change the
properties of all domains using these nameservers.
I'm working in a Registrar now, and it happens that customer ask us
to change 50 or 100 domains at the same time because they change
nameservers or they change IP of one nameserver.

Let me give also another attribute that we can have for a nameserver
: the property, ie who owns it.
It happens that sometimes people are using nameservers for a domain
by mistake (ie not the correct nameserver). Then the given nameserver, not
configured for the domain, is still asked for information by other
nameservers around the world.

That is lame delegation, ok, no big deal.
But like one of our customer asked some times ago, there can be a lot
of things like that, putting charge on the nameserver. The customer
wanted to know if we (the Registrar) could remove the given
nameserver from the list of nameserver used by domains they do not
handle.
Problem : how do we authentify a request like that ? 
The customer in question wanted just to give us a fax on company
letterhead stating : such and such nameserver are ours, please be
sure they are only used for domains such and such.

However we have no (easy/automated/foolproof) way of verifying that
was is written on the document is true.

I do not know if it is useful, but having an attribute 'owned by'
might be of interest. 

It strikes me that there is also the whole thing with DNSSEC.
AFAIK (which is little) about that, nameserver have keys, and other
must know them. How do you distribute keys ? If the nameserver is in object
in the Registry database, you can associate with it its key to be
used by whoever needs them. Just an idea.

-- 
Patrick.

From: "Brian W. Spolarich" <[email-masked]>
To: =?utf-8?Q?J=C3=B6rg_Bauer/Denic?= <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Tue, 6 Feb 2001 08:58:03 -0500
Importance: Normal
Sender: [email-masked]

| ThatÂ´s exact the way we do it here in Germany.
| We dontÂ´t know anything about Nameserver Objects and i still canÂ´t see it
| as a requirement.

  As Patrick pointed out, one advantage to keeping separate NS objects is that
if one needs to change the address of a given server, only one record needs to be
updated (i.e. normalization).  It would be interesting to know how often this is
used.

Date: Wed, 07 Feb 2001 08:57:33 +0100
From: Urs Eppenberger <[email-masked]>
To: [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Sender: [email-masked]

--On Montag, 5. Februar 2001 20:38 Uhr +0100 Patrick <[email-masked]>
wrote:

> Right... because you do not use ns1.foobar.com and ns2.foobar.com as
> nameserver. In your case, someone just polluted the database.
> As soon as your domain use ns{1,2}.foobar.com, you are hijacked...
> 
> That is inconvenient, since when the true owner will want to register
> them for its true use, the Registry might not allow him, since they
> already exist (with bogus data). How do you control who can change
> the IP ?

You can get easy around this hijack problem. Just use the host name as the
object handle (or database key). Reverselookup must work. In such a case
you as holder of foobar.com has authority over *.foobar.com, generally you
can walk over to that guy and knock him. So, if a 'wrong' owner registered
a bogus hijack-nameserver, that wrong owner sits close. You most probably
have administrative control in your company over such a situation and there
is no need for the registry or for the protocol to ensure a correct
behaviour inside third party organisations.

Urs.

Date: Wed, 07 Feb 2001 07:55:54 +0100
From: Urs Eppenberger <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver as object/entity or not ?
Sender: [email-masked]

--On Dienstag, 6. Februar 2001 9:19 Uhr -0800 Kent Crispin
<[email-masked]> wrote:

> If you have nameserver objects, then you have in effect created 
> potentially conflicting ownership/authentication domains, and this 
> seems to me a very fundamental problem.  (That is, a domain can be "owned"
> by A, while the nameservers for the domain may be owned by "B".)  If 
> only domains can be owned objects, then there are no possible conflicts 
> (at least in the registry DB).

Hello Kent et al

We at SWITCH (registry for TLD .ch and .li) have three objects: contact,
domain and host.  See www.nic.ch/batch for a manual which has a nicer
picture with the data model.

As Bill pointed out, having these three objects makes changes easier,
because in many cases you need only change one single object (IP Adress of
a host, Fax Number of a contact).

Kent wrote about 'ownership' of these objects. We handle it like this:

object      contains                              owned by
contact     person data (name, e-mail,...)        the person itself
domain      pointers to holder/hosts              holder
host        hostmaster,IP adresses (if needed)    hostmaster

The owner has the right to change attributes. This works quite well. It
hasa drawbacks, especially in the case of domains, where the holder often
just does not care since a ISP does all the work for him. But many domain
holders are very happy to be in full control.

PROVREG should support such a data model. Scotts proposal does.

Urs.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Tue, 6 Feb 2001 17:15:55 -0500 
Sender: [email-masked]

FWIW we had quite a lengthy name server management discussion on the old RRP
list some months ago, and truth be told we never came to complete agreement.
There are positive and negative aspects of managing name servers as either
top-level objects or as attributes of other objects, such as domains.

The attribute idea makes sense in the context of managing a small number of
domains, but it gets unwieldy from a management perspective when a name
server is hosting thousands or millions of domains.  Cross-registrar
coordination is also tricky if top level server objects and domain objects
can be managed by different registrars -- how do things work if domain
foo.com must be deleted by one registrar, but another registrar has
management authority for ns1.foo.com?  If domain foo.com gets deleted, is it
a good idea to publish an "orphan" glue record for ns1.foo.com?

Anyway, the current requirements language was thought by me to be the most
reasonable compromise based on operational experience.

<Scott/>

To: Kent Crispin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Nameserver as object/entity or not ? 
Date: Tue, 06 Feb 2001 16:13:14 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Kent,

I concure. Making nameservers into first class objects isn't a given, as
the dependency relationship between nameservers objects and domain objects
mandates a contention mechanism.

Performing bulk ops on domain objects using a nameserver object as a key
is a convience funtion, nice but no more necesary than any other built-in
iterator/aggregator operator.

The edge cases that occur to me are deletion, when a nameserver object has
no domains object dependencies, and creation. Neither special case requires
a general promotion of the nameserver object to a first class object.

Cheers,
Eric

From: "James Seng/Personal" <[email-masked]>
To: "Bill Manning" <[email-masked]>, "Brian W. Spolarich" <[email-masked]>
Cc: "Patrick" <[email-masked]>, <[email-masked]>
Subject: Re: Nameserver as object/entity or not ?
Date: Wed, 7 Feb 2001 04:54:23 +0800
Sender: [email-masked]

This is a very reasonable requirement. If the original requirement is to
overcome this problem, then I suggest rewording it to something like
what Bill said below.

-James Seng

----- Original Message -----
From: "Bill Manning" <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
Cc: "Patrick" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 06, 2001 11:57 PM
Subject: Re: Nameserver as object/entity or not ?

> %
> % | >From experience, I can tell you that it is used. I was working
before
> % | in an ISP. One day we had to change our Internet connexion, which
> % | changed the IP of our nameservers, thus the need to change the
> % | properties of all domains using these nameservers.
> % | I'm working in a Registrar now, and it happens that customer ask
us
> % | to change 50 or 100 domains at the same time because they change
> % | nameservers or they change IP of one nameserver.
>
> A case in point.  A server was recently renumbered and the host record
> at the registrar was modified.  This server was/is hosting a number
> of distinct zone entries.  Apparently the internal protocol tracked
> the new number at a number of levels but did not work across the
board.
> This server also serves as a server for a number of ccTLDs and the
"glue"
> records for this server at those ccTLDs was -NOT- automatically
updated...
> leading to "lame" server indications.   So the protocol ought to
ensure
> that when a "host" record is modified, that it can be tracked
throughout
> the system.
>
> --
> --bill

From: "James Seng/Personal" <[email-masked]>
To: "Sheer El-Showk" <[email-masked]>, "Brian W. Spolarich" <[email-masked]>
Cc: "Patrick" <[email-masked]>, "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Wed, 7 Feb 2001 04:51:24 +0800
Sender: [email-masked]

Actually I was watching this lively discussion so I didnt want to
interrupt. :-) But yea, Sheer got the my point.

This is one place whereby certain policy (however reasonable it seem)
leak into the requirements/protocols.

-James Seng

----- Original Message -----
From: "Sheer El-Showk" <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
Cc: "Patrick" <[email-masked]>; "James Seng/Personal"
<[email-masked]>; "Kent Crispin" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, February 06, 2001 11:17 PM
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

> Actually, all this is missing the point of (James') the original
> posting.  What he was complaining about was that the authority to
register
> a nameserver under a domain resided with the Registrar which held the
> domain, not the registrant.  As a registrant I may register domain D1
with
> registrar R1, but want to register nameserver N1 within D1 (this is an
> important distinction -- the domain of nameservers for a particular
> domain is not restricted, eg foobar.com can have ns1.foobar.tv as its
> nameserver, but any nameservers being registered _within_ a domain
> must be registered by the source of authority for the domain -- the
> registrant or the registrar, eg only the owner of foobar.com should be
> able to register the nameserver ns1.foobar.com as a nameserver) with
> registrar R2.  James was saying that there should be some kind of
token of
> authority (a PGP key?? ;->) that allows me as a registrant to do
> authoritative things for my domain (like register a nameserver under
> it) through any registrar, not just the one with which I registered
the
> domain.
>
> James, is that right?
>
> If it is, then I am definately in agreement with the general
sentiment.  I
> don't think we should leave domain name authority in the hands of the
> registrars ... that's an implementation issue (ie per registry) and
> should certainly not be enforced by the protocol.  I don't think,
however,
> that this is enough ground to say that Scott's doc is a bad basis for
a WG
> (I havn't actually looked over the revised version enough to say
whether I
> like it or not).
>
> Sorry for that complex clarification.  Hope it helps.
>
> Regards,
> Sheer
>
> On Mon, 5 Feb 2001, Brian W. Spolarich wrote:
>
> > | If anyone can register ns1.foobar.com & ns2.foobar.com (with IP)
then
> > | basically anyone can hijack my domain (pointing www.foobar.com to
> > | whatever IP, etc...)
> > |
> > | Thus the nameservers must be only registered by the Registrar who
has
> > | registered foobar.com, and the Registrar must ensure that only
> > | someone with authority on foobar.com (contacts) can create
> > | *.foobar.com
> > |
> > | There is no conflict possible in that case.
> > | A given nameserver can only be registered once (even if it is used
in
> > | many domains) through only a given Registrar.
> >
> >   Okay, I get it. :-)  I figured it was something like that, but was
having
> > a hard time with the language.
> >
> >   I don't see as strong of a coupling between the hostnames
associated with
> > the authoritative nameservers for a domain and the hijacking
problem.  It is
> > ultimately what shows up in the NS records associated with the
domain that
> > matters.  I might choose to delegate foobar.com to ns1.myisp.net and
> > ns2.myisp.net.  If someone registers nameservers ns1.foobar.com and
> > ns2.foobar.com in the registry this is inconvenient and annoying,
but not
> > really a hijcaking issue.
> >
> >   In addition, I'm not sure that this coupling will work well in a
very
> > distributed context.  Lets say that I own 'foobar.com' today,
registered
> > through registrar 'spumco' and I have two nameservers running,
> > ns1.foobar.com and ns2.foobar.com.  I want to register 'foobar.biz'
and
> > 'foobar.info', using my current nameservers, ns{1,2}.foobar.com.
> >
> >   In order to complete the domain registration I'll have to register
my
> > nameservers into the .biz and .info registries.  Registrar 'spumco',
who
> > performed the 'foobar.com' registration, doesn't offer registrations
with
> > .biz and .info, so I go to registrar 'blammo'.
> >
> >   Does this mean that I cannot register my nameservers through
'blammo' with
> > .biz because 'spumco' holds the registration for 'foobar' in .com?
> >
> >   This seems problematic.
> >
> >   As a registrant, the thing that I care about is that the
nameservers that
> > I registered with my domain don't change unless I explicity
authorize the
> > change.
> >
> >   I'm wondering if the problem here is the idea of having separate
> > nameserver and domain objects.  In my mind, the nameserver is an
attribute
> > of the domain, and doesn't have any independent identity.  What
problem does
> > having the nameservers as separate entities solve?
> >
> >   -bws
> >
>
>
>
>
>

Date: Tue, 6 Feb 2001 09:19:59 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Nameserver as object/entity or not ?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Feb 06, 2001 at 10:02:47AM -0500, Brian W. Spolarich wrote:
> | I'm working in a Registrar now, and it happens that customer ask us
> | to change 50 or 100 domains at the same time because they change
> | nameservers or they change IP of one nameserver.
> 
>   This is a good point, and my mindset tends to not be focused on
> service-provider concerns as much as registrant concerns (somewhat ironic
> given I used to work for a rather large ISP).  ISPs who renumbered would
> have an impossible time if they had to coordinate a massive batch of updates
> to the registration entries for all of their customer domains for which they
> were providing nameservice.
> 
>   I would say that this concern alone would warrant a requirement that the
> nameserver entities be managed separately.

Though apparently there are registries that do not provide this 
service, and things seem to work...

In any case, what you describe is a requirement that there be a way to
manipulate all records that include a particular nameserver.  It is not
a requirement that nameserver objects should exist -- that is an 
implementation detail.

If you have nameserver objects, then you have in effect created 
potentially conflicting ownership/authentication domains, and this 
seems to me a very fundamental problem.  (That is, a domain can be "owned"
by A, while the nameservers for the domain may be owned by "B".)  If 
only domains can be owned objects, then there are no possible conflicts 
(at least in the registry DB).

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

From: Bill Manning <[email-masked]>
Subject: Re: Nameserver as object/entity or not ?
To: [email-masked] (Brian W. Spolarich)
Date: Tue, 6 Feb 2001 07:57:30 -0800 (PST)
Cc: [email-masked] (Patrick), [email-masked]
Sender: [email-masked]

% 
% | >From experience, I can tell you that it is used. I was working before
% | in an ISP. One day we had to change our Internet connexion, which
% | changed the IP of our nameservers, thus the need to change the
% | properties of all domains using these nameservers.
% | I'm working in a Registrar now, and it happens that customer ask us
% | to change 50 or 100 domains at the same time because they change
% | nameservers or they change IP of one nameserver.

A case in point.  A server was recently renumbered and the host record
at the registrar was modified.  This server was/is hosting a number
of distinct zone entries.  Apparently the internal protocol tracked
the new number at a number of levels but did not work across the board.
This server also serves as a server for a number of ccTLDs and the "glue"
records for this server at those ccTLDs was -NOT- automatically updated...
leading to "lame" server indications.   So the protocol ought to ensure 
that when a "host" record is modified, that it can be tracked throughout
the system.

-- 
--bill

From: "Brian W. Spolarich" <[email-masked]>
To: "Patrick" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Nameserver as object/entity or not ?
Date: Tue, 6 Feb 2001 10:02:47 -0500
Importance: Normal
Sender: [email-masked]

| >From experience, I can tell you that it is used. I was working before
| in an ISP. One day we had to change our Internet connexion, which
| changed the IP of our nameservers, thus the need to change the
| properties of all domains using these nameservers.
| I'm working in a Registrar now, and it happens that customer ask us
| to change 50 or 100 domains at the same time because they change
| nameservers or they change IP of one nameserver.

  This is a good point, and my mindset tends to not be focused on
service-provider concerns as much as registrant concerns (somewhat ironic
given I used to work for a rather large ISP).  ISPs who renumbered would
have an impossible time if they had to coordinate a massive batch of updates
to the registration entries for all of their customer domains for which they
were providing nameservice.

  I would say that this concern alone would warrant a requirement that the
nameserver entities be managed separately.

| I do not know if it is useful, but having an attribute 'owned by'
| might be of interest.
|
| It strikes me that there is also the whole thing with DNSSEC.
| AFAIK (which is little) about that, nameserver have keys, and other
| must know them. How do you distribute keys ? If the nameserver is
| in object in the Registry database, you can associate with it its key
| to be used by whoever needs them. Just an idea.

  This is a good point and I think raises an important larger question:  is
the goal of this WG to _only_ develop an interoperability platform for
registrar and registry interactions using existing techniques and models, or
to perhaps improve upon those models and techniques?

  -bws

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Tue, 6 Feb 2001 08:04:01 -0500
Importance: Normal
Sender: [email-masked]

Is it safe to say that Name Servers are being discussed in two different
roles here?

1- As a domain to be registered, and
2- As an attribute of a different domain being registered.

???

So in the requirement that we are discussing:

|   [10] All registrars MUST be authorized to register objects in the
|   registry.  Name server registration MUST be limited to the registrar
|   of the name server's parent domain.  Unauthorized attempts to register
|   a name server in a parent domain administered by another registrar
|   MUST be explicitly rejected.

This is really talking about role # 1.  And role # 2 happens when I already
have the "handle" of the domain (which happens to be the Name Server) when I
register a different domain.

For example, I register a new domain: foo.biz.  When I do that, I specify
ns(1,2).old-domain.com as the name servers.  Now only *I* can register
ns(1,2).foo.biz as new domains, which will BTW be my new name servers.

Now my friend "Bob" wants to register foo.info, he registers it using
ns(1,2).foo.biz as the name servers, which I say is okay.  Here, he using
the name servers as attributes of his new domain, he certainly is allowed to
use them in this fashion.  He is not allowed to register a new domain :
bob.foo.biz - that's what [10] is trying to prevent (I think).

I hope this is right, if not, I need further explaination.  Thanks!

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jörg Bauer/Denic
Sent: Tuesday, February 06, 2001 4:28 AM
To: Brian W. Spolarich
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim
Meeting]

On 05.02.2001 20:29 "Brian W. Spolarich" <[email-masked]> wrote:
>
>   As a registrant, the thing that I care about is that the nameservers
that
> I registered with my domain don't change unless I explicity authorize the
> change.
>
>   I'm wondering if the problem here is the idea of having separate
> nameserver and domain objects.  In my mind, the nameserver is an
attribute
> of the domain, and doesn't have any independent identity.  What problem
does
> having the nameservers as separate entities solve?
>

That´s exact the way we do it here in Germany.
We dont´t know anything about Nameserver Objects and i still can´t see it
as a requirement.

--
----------------------------------+-----------------------------------------
--

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-----------------------------------------
--

Subject: Antwort: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
To: "Brian W. Spolarich" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" <[email-masked]>
Date: Tue, 6 Feb 2001 10:27:37 +0100
Sender: [email-masked]

On 05.02.2001 20:29 "Brian W. Spolarich" <[email-masked]> wrote:
>
>   As a registrant, the thing that I care about is that the nameservers
that
> I registered with my domain don't change unless I explicity authorize the
> change.
>
>   I'm wondering if the problem here is the idea of having separate
> nameserver and domain objects.  In my mind, the nameserver is an
attribute
> of the domain, and doesn't have any independent identity.  What problem
does
> having the nameservers as separate entities solve?
>

That´s exact the way we do it here in Germany.
We dont´t know anything about Nameserver Objects and i still can´t see it
as a requirement.

--
----------------------------------+-------------------------------------------

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-------------------------------------------

Date: Mon, 5 Feb 2001 20:38:15 +0100
From: Patrick <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
Cc: James Seng/Personal <[email-masked]>, Kent Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Organization: Gandi
Sender: [email-masked]

On Mon, Feb 05, 2001 at 02:29:58PM -0500, Brian W. Spolarich took time to write:
>   I don't see as strong of a coupling between the hostnames associated with
> the authoritative nameservers for a domain and the hijacking problem.  It is
> ultimately what shows up in the NS records associated with the domain that
> matters.  I might choose to delegate foobar.com to ns1.myisp.net and
> ns2.myisp.net.  If someone registers nameservers ns1.foobar.com and
> ns2.foobar.com in the registry this is inconvenient and annoying, but not
> really a hijcaking issue.

Right... because you do not use ns1.foobar.com and ns2.foobar.com as
nameserver. In your case, someone just polluted the database.
As soon as your domain use ns{1,2}.foobar.com, you are hijacked...

That is inconvenient, since when the true owner will want to register
them for its true use, the Registry might not allow him, since they
already exist (with bogus data). How do you control who can change
the IP ?

>   In addition, I'm not sure that this coupling will work well in a very
> distributed context.  Lets say that I own 'foobar.com' today, registered
> through registrar 'spumco' and I have two nameservers running,
> ns1.foobar.com and ns2.foobar.com.  I want to register 'foobar.biz' and
> 'foobar.info', using my current nameservers, ns{1,2}.foobar.com.
> 
>   In order to complete the domain registration I'll have to register my
> nameservers into the .biz and .info registries.  Registrar 'spumco', who

No. You register nameserver with IP in Registry only for nameserver
in the TLDs handled by Registry.
That is Registry for .biz SHOULD not have IP of ns1.foobar.com
In your case you do not have to register ns{1,2}.foobar.com into .biz
and .info Registries. You can merely register them if the registry
has nameserver handle, but you specifically DO NOT assign an IP
address to them (the Registrar should take care of that)

>   As a registrant, the thing that I care about is that the nameservers that
> I registered with my domain don't change unless I explicity authorize the
> change.

That is the case, since you can register nameserver only in a given
TLD and only through a given Registrar. That is once only in all
cases.

>   I'm wondering if the problem here is the idea of having separate
> nameserver and domain objects.  In my mind, the nameserver is an attribute
> of the domain, and doesn't have any independent identity.  What problem does
> having the nameservers as separate entities solve?

If you use nameserver in the domain, you need glue records, ie the
Registry needs to know the IP address of these nameservers.

If you consider the nameserver as an object (attributes : a name and
many IP), with an handle for example (like at NSI now), many domains
can use the same nameserver object. 
If its IP change you have one change to do (in the nameserver
object). Otherwise you will need to change the IP of the nameserver
in all domain names using this nameserver. That is why things are
separate I think.

Patrick.

From: "Brian W. Spolarich" <[email-masked]>
To: "Patrick" <[email-masked]>
Cc: "James Seng/Personal" <[email-masked]>, "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Mon, 5 Feb 2001 14:29:58 -0500
Importance: Normal
Sender: [email-masked]

| If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then
| basically anyone can hijack my domain (pointing www.foobar.com to
| whatever IP, etc...)
|
| Thus the nameservers must be only registered by the Registrar who has
| registered foobar.com, and the Registrar must ensure that only
| someone with authority on foobar.com (contacts) can create
| *.foobar.com
|
| There is no conflict possible in that case.
| A given nameserver can only be registered once (even if it is used in
| many domains) through only a given Registrar.

  Okay, I get it. :-)  I figured it was something like that, but was having
a hard time with the language.

  I don't see as strong of a coupling between the hostnames associated with
the authoritative nameservers for a domain and the hijacking problem.  It is
ultimately what shows up in the NS records associated with the domain that
matters.  I might choose to delegate foobar.com to ns1.myisp.net and
ns2.myisp.net.  If someone registers nameservers ns1.foobar.com and
ns2.foobar.com in the registry this is inconvenient and annoying, but not
really a hijcaking issue.

  In addition, I'm not sure that this coupling will work well in a very
distributed context.  Lets say that I own 'foobar.com' today, registered
through registrar 'spumco' and I have two nameservers running,
ns1.foobar.com and ns2.foobar.com.  I want to register 'foobar.biz' and
'foobar.info', using my current nameservers, ns{1,2}.foobar.com.

  In order to complete the domain registration I'll have to register my
nameservers into the .biz and .info registries.  Registrar 'spumco', who
performed the 'foobar.com' registration, doesn't offer registrations with
.biz and .info, so I go to registrar 'blammo'.

  Does this mean that I cannot register my nameservers through 'blammo' with
.biz because 'spumco' holds the registration for 'foobar' in .com?

  This seems problematic.

  As a registrant, the thing that I care about is that the nameservers that
I registered with my domain don't change unless I explicity authorize the
change.

  I'm wondering if the problem here is the idea of having separate
nameserver and domain objects.  In my mind, the nameserver is an attribute
of the domain, and doesn't have any independent identity.  What problem does
having the nameservers as separate entities solve?

  -bws

From: "Brian W. Spolarich" <[email-masked]>
To: "Martin Oldfield" <[email-masked]>
Cc: "James Seng/Personal" <[email-masked]>, "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Mon, 5 Feb 2001 14:18:03 -0500
Importance: Normal
Sender: [email-masked]

| I think saying objects here is a great improvement. However, to be
| pedantic if I wanted to set up a registry for pet registrations then I
| wouldn't want it to include any domain names.
|
| Would it be possible to explicitly cast the thing in two halves: the
| one is general and says `Protocol MUST support registration of objects
| of multiple types'; the other is domain specific and says `The objects
| supported must include domain names, nameservers, and domain
| contacts'.

  You're correct, but I think there's a difference between the protocol
specification and the capabilities of a given registry.  That is:

  - The protocol MUST support registrations of domain name objects.

  - A particular server implementing the protocol MAY provide domain name
registration services.

  Whatever else the thing does, it better do domain names. :-)

  -bws

Date: Mon,  5 Feb 2001 19:10:36 +0000 (GMT)
To: "Brian W. Spolarich" <[email-masked]>
Cc: "James Seng/Personal" <[email-masked]>, "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Brian" == Brian W Spolarich <[email-masked]> writes:

--> snip <--

    Brian> 3.4 Object Registration

    Brian>   [1] Protocol MUST support registration of objects of
    Brian>   multiple types,
    Brian> including domain names, nameservers, and domain contacts.

I think saying objects here is a great improvement. However, to be
pedantic if I wanted to set up a registry for pet registrations then I 
wouldn't want it to include any domain names.

Would it be possible to explicitly cast the thing in two halves: the
one is general and says `Protocol MUST support registration of objects
of multiple types'; the other is domain specific and says `The objects
supported must include domain names, nameservers, and domain
contacts'.

Then if people want to set up all sorts of other crazy registries
there's a clear point-of-departure.

--> snip <--

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Mon, 5 Feb 2001 20:05:37 +0100
From: Patrick <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
Cc: James Seng/Personal <[email-masked]>, Kent Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Organization: Gandi
Sender: [email-masked]

On Mon, Feb 05, 2001 at 01:55:20PM -0500, Brian W. Spolarich took time to write:
> |   [10] All registrars MUST be authorized to register objects in the
> |   registry.  Name server registration MUST be limited to the registrar
> |   of the name server's parent domain.  Unauthorized attempts to register
> |   a name server in a parent domain administered by another registrar
> |   MUST be explicitly rejected.
> |
> | One of the conflicting Reqs which I am sure Scott understand. Conflict
> | Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1
> | and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar
> | R2? And who to say that the ISP must and only must use one registrar to
> | work around this?
> 
>   I guess I'm dense, but I don't understand requirement 3.4[10] or James'
> response.  Can someone provide a concrete example of the problem that this
> requirement is trying to avoid?

Here is my try :
I register domain foobar.com handled by nameserver ns1.foobar.com and
ns2.foobar.com
(note : nameserver in domain name)

If anyone can register ns1.foobar.com & ns2.foobar.com (with IP) then
basically anyone can hijack my domain (pointing www.foobar.com to
whatever IP, etc...)

Thus the nameservers must be only registered by the Registrar who has
registered foobar.com, and the Registrar must ensure that only
someone with authority on foobar.com (contacts) can create
*.foobar.com

There is no conflict possible in that case.
A given nameserver can only be registered once (even if it is used in
many domains) through only a given Registrar.

Patrick.

Date: Mon, 5 Feb 2001 10:51:44 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: WG starting point - WG query
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Feb 05, 2001 at 11:07:06AM -0500, Eric Brunner-Williams in Portland Maine wrote:
[...]
>>         1.  Shall the working group take Scott's Requirements document and 
>> Scott's protocol specification is direct input, and then seek to refine them?
> 
> Hum.

Hum also.

> > Or:
> > 
> >          2.  Shall the working group start from scratch and seek full 
> > development of Requirements and full development of a protocol 
> > specification, including possible choice among competing specifications?
> 
> Non-hum.

Non-hum, also.  

I hate to be a "me-too", but even if it turns out that there are 
significant changes to Scott's draft, we are still miles ahead to start 
from there.

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

From: "Brian W. Spolarich" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>, "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
Date: Mon, 5 Feb 2001 13:55:20 -0500
Importance: Normal
Sender: [email-masked]

|   [1] The protocol MUST provide services to register Internet domain
|   names.
|
| Cool, suppose I dont use it for DNS? (Some of the registration we doing
| are not DNS based). And I believe Verisign/NSI _may_ consider using this
| for their PKI and ENUM stuff. Scott may confirm or deny (or remain
| silence) on this.

  This doesn't preclude the protocol from providing services to register
other kinds of objects. :-)

  As I read the requirements document 7.5[1,2] does encompass this need,
although the document places less emphasis on this than the MUSTs associated
with DNS registrations.

  I don't see why the specification and implementation cannot be generic
enough to encompass registration and association of other objects.

  I think its important that schema extensibility should be part of an
initial specification and implementations, and I can buy the argument that
the draft is a bit too DNS-focused (although in reality the problem that
this protocol is initially trying to solve is related to interoperability
for DNS registries and registrars.

  How about an organization like this:

  3.4  Object Registration

  [1]	Protocol MUST support registration of objects of multiple types,
including domain names, nameservers, and domain contacts.

  [2] Protocol MUST permit a starting and ending time, and SHOULD support
indefinite object registrations.

  [3] When an object has been successfully registered, protocol MAY return
an expiration date.

  [4] Per-registry unique TX ids and OIDs.

  [5] Object attributes which are telephone numbers must conform to
international standards.

  3.4.1 DNS-Related Objects

  <DNS-specific reqs>

  One thing that seems to be missing from the reqs is a description of the
non-object-related operations, such as protocol version, server information,
etc.  In the context of registering multiple object types you'd probably
want to also have an operation that would list the available classes of
objects that one can register and their attributes.

|   [5] 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 Internet Protocol version 4 (IPv4) or
|   version 6 (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 TLD is
|   itself a valid TLD.
|
| Supposing I am a DNS registry who accepts names but associate it with
| something else rather than DNS? (e.g. I only do URL forwarding?) There
| are registries out that who is doing so.

  If you're doing URL forwarding then you (as the registrar) are providing
authoriative DNS for the domain holder, and you're going to have to register
name servers.  Or am I missing something here?

|   [10] All registrars MUST be authorized to register objects in the
|   registry.  Name server registration MUST be limited to the registrar
|   of the name server's parent domain.  Unauthorized attempts to register
|   a name server in a parent domain administered by another registrar
|   MUST be explicitly rejected.
|
| One of the conflicting Reqs which I am sure Scott understand. Conflict
| Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1
| and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar
| R2? And who to say that the ISP must and only must use one registrar to
| work around this?

  I guess I'm dense, but I don't understand requirement 3.4[10] or James'
response.  Can someone provide a concrete example of the problem that this
requirement is trying to avoid?

  -bws

Date: Mon, 5 Feb 2001 13:35:08 -0500
To: "Christopher Ambler" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Agenda for Interim Meeting
Cc: <[email-masked]>
Sender: [email-masked]

At 1:12 PM -0500 2/5/01, Christopher Ambler wrote:
>May I presume that the design team is not limited to those who
>show up for the meeting?

This is correct.

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

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>
Subject: Re: Agenda for Interim Meeting
Date: Mon, 5 Feb 2001 10:12:21 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

May I presume that the design team is not limited to those who
show up for the meeting? 

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]
----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 05, 2001 8:16 AM
Subject: Agenda for Interim Meeting

> Here's the proposal I sent earlier:
> 
>      Agenda bashing: (short)
>      WG status: (short)
>      The EPP proposal
>      Other proposals
>      Discussion of forming a design team
> 
> Comments?
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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, 5 Feb 2001 10:07:50 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>
Subject: Re: Agenda for Interim Meeting
Sender: [email-masked]

Ed,

I won't be at the interm meeting but I would like to be on a design team
if one is formed. I have been owrking on implementing scott's epp drafts.

-rick

>      Discussion of forming a design team

Date: Mon, 05 Feb 2001 09:31:21 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Agenda for Interim Meeting
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:16 AM 2/5/2001 -0500, Edward Lewis wrote:
>Here's the proposal I sent earlier:
>
>      Agenda bashing: (short)
>      WG status: (short)
>      The EPP proposal
>      Other proposals
>      Discussion of forming a design team

Typically, design teams form themselves.  They are homogeneous, with closed 
membership.

I suggest that the mailing list try to develop a list of concerns about the 
EPP proposal, before the meeting, so that the meeting can focus on 
discussing ways to resolve the concerns.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Mon, 05 Feb 2001 09:13:56 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: [email-masked]
Sender: [email-masked]

At 11:23 AM 2/5/2001 -0500, Edward Lewis wrote:
>I've spent quite a few hours on email this weekend just on this topic.  I
>fail to see how this discussion is helping us get to the protocol.

The failure to see is the concern.  The change to the charter was 
substantive.

The material removed was put into the draft charter based on considerable 
IETF experience, SPECIFICALLY BECAUSE IT HELPS THE WORKING GROUP PRODUCE A 
PROTOCOL and IN A TIMELY FASHION.

The matter of ensuring working group focus is not a small point.  It is at 
least as important as ensuring proper consensus processes.  In my opinion 
it is, in fact, more difficult!

Had you gotten feedback from Patrik to make the change, that would be 
another matter.

Instead you got private statements of concern, did not consult the mailing 
list, and reacted to other people's fears, making a change in spite of this 
being contrary to a reasonable consensus on this list.

I fully appreciate and respect the concerns you felt about the private 
comments and about expediting the IESG consideration.  I even encourage you 
to keep them.  The question is what was done with the concerns.

Given the timing you were faced with, trying to expedite matters is 
laudable.  However the changes were really contrary to the history of the 
list discussion.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Mon, 5 Feb 2001 11:23:54 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I would like this to be the last discussion on this prior an IESG
action/reponse on this.  (I appologize in advance for being testy about
this.)

First - why is there a second draft.

On Jan 17th or so, I was talking to an IESG member at a workshop and found
out that the IESG hadn't seen the charter yet.  The following day was a
one-week- before-meeting deadline to have IESG members submit items for
discussion at the next meeting.  As a result of this I pinged Patrik about
our charter.  I also mentioned that some other feedback I received
questioning the mention of drafts and coverage about security.  I promised
Patrik an alternate charter in case it was needed.

Once I got to a place where I could work and get net access (a few days
later), I made three changes - one to remove the mention of the drafts by
name, one to put "extensibility" in to the charter, and one to beef up the
security.  I wanted to get this to Patrik in time for the IESG meeting.  At
that point there wasn't time to get mail list comments on what I consider
three small changes.  (Please don't reply to complain that I shouldn't just
go on my considerations - evidently the inclusion/exclusion of the names of
the drafts is a big deal to some.)

I sent the second charter to Patrik (and copied Jaap).  The next thing I
see is the first charter on ietf-announce.  I haven't heard directly from
Patrik on this, it is possible he has already thrown out the second
charter.  I don't know.  At worst, he has both.

Second - what's next.

It's in the IESG's hands.  I've gotten no indications about the next step.
When I know, the mail list will know.

Third - why I'm tiring on this.

I've spent quite a few hours on email this weekend just on this topic.  I
fail to see how this discussion is helping us get to the protocol.

We already have a requirements document that seems to satisfy list
participants.  If we were a WG, then it would be in last call by now - but
we are not a WG.

There are two items now for us.  One is to start consideration of the
protocol.  The other is to make sure we have as wide-spread consensus as we
can get.

At 10:47 AM -0500 2/5/01, Eric Brunner-Williams in Portland Maine wrote:
>Ed,
>
>Responding to several of your issues raised over the weekend:
>
>> The charter mentions DNS administration to set the context of the work, it
>> itself is not a work item.
>
>This is what I assumed.
>
>> The reason I removed the mention of the draft is that we are not here to
>> bless a particular protocol generated outside the working group, but rather
>> to generate a protocol in full view of the IETF.
>
>I see two issues here -- agency and process.
>
>Agency -- The draft charter shows two co-chairs, Ed and Jaap. Was this
>change of draft charter discussed by both? The draft charter was discussed
>at San Diego and references to Scott's prior drafts were present then, and
>not remarkable. What changed?
>
>Process -- This has been covered by others, unlike another activity for
>which a NDA existed, Scott's drafts have been in full public view.
>
>> Right now I am basically waiting for feedback from the IESG.
>
>The scope of IESG review is limited, as is its effect. I'll crawl out on a
>limb and _predict_ the IESG reviewer(s) won't:
>	a) require folding whois and provreg (despite the superficial
>	   appearence of common underlying data and access mechanisms),
>	b) require an ab initio folding of DNS provreg with other possible
>	   provregs, (despite the superficial appearence of common underlying
>	   data types and access mechanisms), and
>	c) require cosmetic rewriting of self-evident existing requirements.
>
>Cheers,
>Eric

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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, 5 Feb 2001 11:16:46 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Agenda for Interim Meeting
Cc: [email-masked]
Sender: [email-masked]

Here's the proposal I sent earlier:

     Agenda bashing: (short)
     WG status: (short)
     The EPP proposal
     Other proposals
     Discussion of forming a design team

Comments?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Dave Crocker <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: WG starting point - WG query 
Date: Mon, 05 Feb 2001 11:07:06 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> So I am personally requesting feedback from the others on this list, 
> concerning consensus about use of Scott's existing work:

I concur with the proposition that extensive community review has taken
place (since -43 for some, since -48 for others, and at -49 and on -announce
and now -provreg), and with the proposition that Scott's requirements and
protocol drafts have general support.

>          The terms of a working group charter need to have consensus of the 
> proto-working group.  In other words, it is not just produced by the chair 
> and the IESG.  It has to have support by those who will be participating in 
> the working group.

If it were otherwise there would be an action item to the poisson list.

[necessity and authority to make WG work-product alterations from any initial
 text, deleted for space.]

> So my question to the working group:
> 
>          1.  Shall the working group take Scott's Requirements document and 
> Scott's protocol specification is direct input, and then seek to refine them?

Hum.

> Or:
> 
>          2.  Shall the working group start from scratch and seek full 
> development of Requirements and full development of a protocol 
> specification, including possible choice among competing specifications?

Non-hum.

> In my opinion, alternative #2 usually costs a working group no less than 
> 6-12 months EXTRA.  Taking as much as 2 years EXTRA is not unusual!

Possibly understated, given the uniqueness of working in a politicised
area. It took the W3C's P3P activity the first two+ years of its life to
scope "privacy" and "preferences", and its third year to deliver a very
modest work.

Cheers,
Eric

To: [email-masked]
cc: [email-masked]
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Date: Mon, 05 Feb 2001 10:47:24 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

Responding to several of your issues raised over the weekend:

> The charter mentions DNS administration to set the context of the work, it
> itself is not a work item.

This is what I assumed.

> The reason I removed the mention of the draft is that we are not here to
> bless a particular protocol generated outside the working group, but rather
> to generate a protocol in full view of the IETF.

I see two issues here -- agency and process.

Agency -- The draft charter shows two co-chairs, Ed and Jaap. Was this
change of draft charter discussed by both? The draft charter was discussed
at San Diego and references to Scott's prior drafts were present then, and
not remarkable. What changed?

Process -- This has been covered by others, unlike another activity for
which a NDA existed, Scott's drafts have been in full public view.

> Right now I am basically waiting for feedback from the IESG.

The scope of IESG review is limited, as is its effect. I'll crawl out on a
limb and _predict_ the IESG reviewer(s) won't:
	a) require folding whois and provreg (despite the superficial
	   appearence of common underlying data and access mechanisms),
	b) require an ab initio folding of DNS provreg with other possible
	   provregs, (despite the superficial appearence of common underlying
	   data types and access mechanisms), and
	c) require cosmetic rewriting of self-evident existing requirements.

Cheers,
Eric

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Fw: WG Review: Provisioning Registry Protocol (provreg)
Date: Mon, 5 Feb 2001 08:48:30 -0500
Importance: Normal
Sender: [email-masked]

>That has been discussed before.  Existing and
>new registries and registrars want this NOW.

I agree with Dave.  There is a need to get this nailed down quickly, and not
just from the Registries and Registrars point of view.  What about all those
poor product development teams trying to create a product that implements
this protocol?  It's like shooting at a target that is over the horizon (you
can do it, but it's real hard).

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Dave Crocker
Sent: Friday, February 02, 2001 9:00 PM
To: James Seng/Personal
Cc: [email-masked]; Patrik Faltstrom
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)

At 09:35 AM 2/3/2001 +0800, James Seng/Personal wrote:
>Dave,
>
> > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote:
> > >I would like to object this proposed charter for provreg. Its scope
>has
> > >been so specific defined for DNS only and has no mention of anything
> > >beyond DNS.
> >
> > feature, not bug.
>
>It depends who you speaking to...To me, it is a bug.

My statement is based on experience with IETF processes, observation of
other standards processes and experience with product development.  It
seems to be one of the empirical truths about project success, especially
when an open group process is involved.

Start with the simplest, most specific deliverable that will be
useful.  Then evolve.

>However, I can not understand is what is the hurry for the WG to get
>this out quickly?

That has been discussed before.  Existing and new registries and registrars
want this NOW.

>If it is about new gTLD registry, any of the new gTLD registry who have
>not started work implementing their system now is crazy. I dont think
>any of them will wait for the result of the WG (Sept?) before starting
>work. For this, we are already too late.

For their initial use, yes.  But some of them have already spoken, here, to
validate the urgency of their need.

>Either way, IMHO, we are already too late in a non-standardised world.

James, unfortunately that is one of the usual argument for taking forever.

>Hence, it is better to work on a GOOD and long term technical solution

Again, that is unfortunately a frequently-heard comment in standards arenas
that is obviously well-intentioned, but turns out to be
counter-productive.  It is one of the ironies of this sort of standards
work.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: WG starting point - WG query
Date: Mon, 5 Feb 2001 08:44:23 -0500
Importance: Normal
Sender: [email-masked]

>         1.  Shall the working group take Scott's Requirements
>             document and Scott's protocol specification is
>             direct input, and then seek to refine them?

I have no problems with going forward with Scott's input.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Dave Crocker
Sent: Sunday, February 04, 2001 12:40 PM
To: [email-masked]
Subject: WG starting point - WG query
Importance: High

At 10:40 AM 2/4/2001 -0500, Hollenbeck, Scott wrote:
>Let me be clear about what I mean: the requirements draft has been out for
>broad IETF review for 10+ months.  If people are only now taking notice
>because we are forming a WG, it would be more productive to stop
complaining
>and get comments in _now_ than to insist that there hasn't been ample time
>for review.

And let ME underscore that the Requirements document very much HAS been
reviewed by others.

         When it came out, did many people assume that it was biased
towards NSI?  Yes.

         When they read it did they change their minds?  Yes.

         Did the same thing happen with the protocol specification?  Yes.

         Does this mean that starting with those documents means that the
working group would have no work to do?  Not at all.

The philosophical difference that is creating the current set of tensions
is whether this IETF working group should

         a) move very aggressively, and

         b) whether it can take advantage of pre-existing work by Scott to
finish much more quickly would otherwise be possible.

         -----

So I am personally requesting feedback from the others on this list,
concerning consensus about use of Scott's existing work:

         My sense is that the Requirements document has already received
extensive community review and has general support.

         My sense is that Scott's protocol specification has already
received extensive community review and has general support.

         The terms of a working group charter need to have consensus of the
proto-working group.  In other words, it is not just produced by the chair
and the IESG.  It has to have support by those who will be participating in
the working group.

         Taking existing documents as a starting point for a working group
is an entirely acceptable practise in the IETF... IF there is consensus to
do so.  The benefit is making progress MUCH more quickly.

         This does not prevent making changes.  When taking existing
documents, the point of the working group is to REFINE things.  Hence, the
working group takes over the document(s) and may make whatever changes it
deems appropriate.

         Language in the charter often specifically cites such documents
and limits the nature of the changes, in order to ensure better WG
focus.  Hence, the charter language is intended to create a bias against
big changes.  However let me repeat that strong working group consensus
retains authority to make whatever changes the working group deems
appropriate.

So my question to the working group:

         1.  Shall the working group take Scott's Requirements document and
Scott's protocol specification is direct input, and then seek to refine
them?

Or:

         2.  Shall the working group start from scratch and seek full
development of Requirements and full development of a protocol
specification, including possible choice among competing specifications?

In my opinion, alternative #2 usually costs a working group no less than
6-12 months EXTRA.  Taking as much as 2 years EXTRA is not unusual!

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Interim Meeting
Date: Sun, 4 Feb 2001 17:19:30 -0500 
Sender: [email-masked]

This is the last opportunity I'll have to respond for what may be a few
days.  I'm in the middle of a home move, and I have to take myself offline
for a while.

I don't understand why my position is unclear.  It's included in the thread
below.

<Scott/> 

-----Original Message-----
From: James Seng/Personal [mailto:[email-masked]]
Sent: Sunday, February 04, 2001 10:58 AM
To: Hollenbeck, Scott; [email-masked]
Subject: Re: Interim Meeting

Scott,

Claim what you like about the IETF process. I cannot deny that you have
follow the process and I thank you for that.

But the facts remains that a lot of registries have not read your I-D.
So the question is "Are you interested in their feedback?" or "Are you
more interested to follow process and get your I-D thru?"

-James Seng

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, February 04, 2001 11:40 PM
Subject: RE: Interim Meeting

> James,
>
> The fact that the requirements document was published as an I-D speaks
for
> itself WRT the intended review community.  If my desire was for review
only
> by the customers of VeriSign-GRS it wouldn't have been published as an
I-D.
>
>
> What I have said is that this document has been available for review
to the
> IETF community at large since March 2000.  It is completely incorrect
for
> anyone to say that they haven't had an opportunity to review this
draft.
> Assertions to the contrary are baseless.
>
> Let me be clear about what I mean: the requirements draft has been out
for
> broad IETF review for 10+ months.  If people are only now taking
notice
> because we are forming a WG, it would be more productive to stop
complaining
> and get comments in _now_ than to insist that there hasn't been ample
time
> for review.
>
> <Scott/>

Date: Sun, 04 Feb 2001 09:39:42 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: WG starting point - WG query
Sender: [email-masked]

At 10:40 AM 2/4/2001 -0500, Hollenbeck, Scott wrote:
>Let me be clear about what I mean: the requirements draft has been out for
>broad IETF review for 10+ months.  If people are only now taking notice
>because we are forming a WG, it would be more productive to stop complaining
>and get comments in _now_ than to insist that there hasn't been ample time
>for review.

And let ME underscore that the Requirements document very much HAS been 
reviewed by others.

         When it came out, did many people assume that it was biased 
towards NSI?  Yes.

         When they read it did they change their minds?  Yes.

         Did the same thing happen with the protocol specification?  Yes.

         Does this mean that starting with those documents means that the 
working group would have no work to do?  Not at all.

The philosophical difference that is creating the current set of tensions 
is whether this IETF working group should

         a) move very aggressively, and

         b) whether it can take advantage of pre-existing work by Scott to 
finish much more quickly would otherwise be possible.

         -----

So I am personally requesting feedback from the others on this list, 
concerning consensus about use of Scott's existing work:

         My sense is that the Requirements document has already received 
extensive community review and has general support.

         My sense is that Scott's protocol specification has already 
received extensive community review and has general support.

         The terms of a working group charter need to have consensus of the 
proto-working group.  In other words, it is not just produced by the chair 
and the IESG.  It has to have support by those who will be participating in 
the working group.

         Taking existing documents as a starting point for a working group 
is an entirely acceptable practise in the IETF... IF there is consensus to 
do so.  The benefit is making progress MUCH more quickly.

         This does not prevent making changes.  When taking existing 
documents, the point of the working group is to REFINE things.  Hence, the 
working group takes over the document(s) and may make whatever changes it 
deems appropriate.

         Language in the charter often specifically cites such documents 
and limits the nature of the changes, in order to ensure better WG 
focus.  Hence, the charter language is intended to create a bias against 
big changes.  However let me repeat that strong working group consensus 
retains authority to make whatever changes the working group deems appropriate.

So my question to the working group:

         1.  Shall the working group take Scott's Requirements document and 
Scott's protocol specification is direct input, and then seek to refine them?

Or:

         2.  Shall the working group start from scratch and seek full 
development of Requirements and full development of a protocol 
specification, including possible choice among competing specifications?

In my opinion, alternative #2 usually costs a working group no less than 
6-12 months EXTRA.  Taking as much as 2 years EXTRA is not unusual!

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Sun, 4 Feb 2001 12:30:34 -0500
To: "James Seng/Personal" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim Meeting
Cc: <[email-masked]>
Sender: [email-masked]

At 10:58 AM -0500 2/4/01, James Seng/Personal wrote:
>But the facts remains that a lot of registries have not read your I-D.
>So the question is "Are you interested in their feedback?" or "Are you
>more interested to follow process and get your I-D thru?"

Once the WG is formed, I plan to wait at least two weeks after we are
official before issueing a WG last call - which lasts two weeks itself.
(For folks worried about delays, there is no need for the requirements
document to be "official" before progress on the protocol can be made.)

As far as getting registries and registrars involved, this is not *just* an
IETF or provreg responsibility.  I am making sure we make every effort to
be as open as possible about the activities as we can be.  I am also trying
to get as many folks aware of this work as I can.

If anyone is afraid that there is an entity that should be involved in
provreg, but is not paying attention to provreg, there are two things you
can do.  One is to contact that entity and tell them of provreg.  The other
is to bring it to my attention and I'll see if I can get a message to the
entity.

PS - Regarding "getting feedback" versus "getting the ID thru", please look
in the archives for the thread "Draft provreg charter", starting "Tue, 26
Dec 2000 09:28:34 -0800."  We've hashed this issue a couple of times
already.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sun, 4 Feb 2001 12:06:42 -0500
To: Dave Crocker <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: moving on, was Re: Fw: WG Review: ...
Cc: Edward Lewis <[email-masked]>, <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

As much as I hate to cut off communication on a topic, I don't think the
revent thread on the charter is in any way is helping us arrive at
protocol.  In fact, I might go so far as to say that this thread has gone
off-topic for the mailing list.

All I can say here is that we have already had a discussion on the charter,
and it has not yet been approved by the IESG.  I am waiting for feedback
from the IESG before anything else can be done on this matter.  Further
discussion on this is just like spinning tires in mud.

Let's get back to discussions on the requirements document (if there is any
more to be held).  I assume there is consensus that the requirements
document should be admitted to the WG (once we are official).

Suggestions for the Feb 20 meeting agenda are welcome.

I'd also like to hear thoughts about organizing a design team (whether we
should, size, shape, nominees perhaps).

I think it is about time we begin to look at the EPP document.  Does the
latest EPP draft meet the latest draft of requirements?  Is there an
objection to including EPP in the WG set of documents?

If there is an alternative proposal to be considered, please identify it.

If there are other documents that should be added to the WG, please
identify them.  (The definitions document will likely be one.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sun, 4 Feb 2001 12:14:16 -0500
To: "James Seng/Personal" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim Meeting
Cc: "'provreg List'" <[email-masked]>
Sender: [email-masked]

At 7:08 AM -0500 2/4/01, James Seng/Personal wrote:
>20th Feb is an interim meeting, not IETF meeting. Interim meetings for
>WG are not encouraged but not against the rules if approved by the ADs.

I finally located the following URL (I was looking in the wrong place) that
should be read by anyone with questions about the form of the interim
meeting:

        http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt

I should have included this in my previous message ('scheduling
challenged') as the basis for my words.

We do have AD permission to hold the meeting.  Without that I would not
have been able to have the announcement appear on ietf-announce.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "James Seng/Personal" <[email-masked]>
To: "Kent Crispin" <[email-masked]>, <[email-masked]>
Subject: Re: Interim Meeting
Date: Mon, 5 Feb 2001 00:07:37 +0800
Sender: [email-masked]

> Scott said:
>
>   "If anyone has issues with it I wish they would make them known..."
>
> What, specifically, are your issues with it?

As I said, I rather the individual registries bring this to the WG
rather than myself since my views may not accurately reflects their
needs.

But since you asked, here are some issues.

3.4 Object Registration

  [1] The protocol MUST provide services to register Internet domain
  names.

Cool, suppose I dont use it for DNS? (Some of the registration we doing
are not DNS based). And I believe Verisign/NSI _may_ consider using this
for their PKI and ENUM stuff. Scott may confirm or deny (or remain
silence) on this.

  [5] 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 Internet Protocol version 4 (IPv4) or
  version 6 (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 TLD is
  itself a valid TLD.

Supposing I am a DNS registry who accepts names but associate it with
something else rather than DNS? (e.g. I only do URL forwarding?) There
are registries out that who is doing so.

  [10] All registrars MUST be authorized to register objects in the
  registry.  Name server registration MUST be limited to the registrar
  of the name server's parent domain.  Unauthorized attempts to register
  a name server in a parent domain administered by another registrar
  MUST be explicitly rejected.

One of the conflicting Reqs which I am sure Scott understand. Conflict
Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1
and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar
R2? And who to say that the ISP must and only must use one registrar to
work around this?

IMHO, it is better to define an "authorization access" to an object
rather than putting explicit work around.

Okay..more fun in object association but I wont go on...till next time.

-James Seng

From: "James Seng/Personal" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: Interim Meeting
Date: Sun, 4 Feb 2001 23:58:05 +0800
Sender: [email-masked]

Scott,

Claim what you like about the IETF process. I cannot deny that you have
follow the process and I thank you for that.

But the facts remains that a lot of registries have not read your I-D.
So the question is "Are you interested in their feedback?" or "Are you
more interested to follow process and get your I-D thru?"

-James Seng

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, February 04, 2001 11:40 PM
Subject: RE: Interim Meeting

> James,
>
> The fact that the requirements document was published as an I-D speaks
for
> itself WRT the intended review community.  If my desire was for review
only
> by the customers of VeriSign-GRS it wouldn't have been published as an
I-D.
>
>
> What I have said is that this document has been available for review
to the
> IETF community at large since March 2000.  It is completely incorrect
for
> anyone to say that they haven't had an opportunity to review this
draft.
> Assertions to the contrary are baseless.
>
> Let me be clear about what I mean: the requirements draft has been out
for
> broad IETF review for 10+ months.  If people are only now taking
notice
> because we are forming a WG, it would be more productive to stop
complaining
> and get comments in _now_ than to insist that there hasn't been ample
time
> for review.
>
> <Scott/>
>
> -----Original Message-----
> From: James Seng/Personal [mailto:[email-masked]]
> Sent: Sunday, February 04, 2001 10:23 AM
> To: Hollenbeck, Scott; [email-masked]
> Subject: Re: Interim Meeting
>
>
> Scott,
>
> I am not against the interim meeting and in fact, I think it is a good
> idea. It is a pity (or perhaps lucky) I wont be able to attend it.
>
> Your reqs spec has been published as an individual I-D, largely
ignored
> by the other community because they see it as primarly NSI focus with
> your registrars. I know you it wasnt meant to be but that is the
> perspective share by others.
>
> Now, if it is a WG I-D, i think we need to go out and correct the
> perspection that it is not just an NSI I-D. It is beyond that and it
is
> going to come back haunt them if they dont take note now.
>
> Your I-D will make great input to this going-to-be WG. But as an WG
I-D,
> I think it is safe to safe to say that we need more reviews beyond
your
> registrars. I am sure the other registries have their comments too so
> why not hear them out?
>
> Unless of course you mean you couldnt care less about what the rest of
> the registries thinks...in that case, I shall rest my case.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Interim Meeting
Date: Sun, 4 Feb 2001 10:40:21 -0500 
Sender: [email-masked]

James,

The fact that the requirements document was published as an I-D speaks for
itself WRT the intended review community.  If my desire was for review only
by the customers of VeriSign-GRS it wouldn't have been published as an I-D.

What I have said is that this document has been available for review to the
IETF community at large since March 2000.  It is completely incorrect for
anyone to say that they haven't had an opportunity to review this draft.
Assertions to the contrary are baseless.

Let me be clear about what I mean: the requirements draft has been out for
broad IETF review for 10+ months.  If people are only now taking notice
because we are forming a WG, it would be more productive to stop complaining
and get comments in _now_ than to insist that there hasn't been ample time
for review.

<Scott/> 

-----Original Message-----
From: James Seng/Personal [mailto:[email-masked]]
Sent: Sunday, February 04, 2001 10:23 AM
To: Hollenbeck, Scott; [email-masked]
Subject: Re: Interim Meeting

Scott,

I am not against the interim meeting and in fact, I think it is a good
idea. It is a pity (or perhaps lucky) I wont be able to attend it.

Your reqs spec has been published as an individual I-D, largely ignored
by the other community because they see it as primarly NSI focus with
your registrars. I know you it wasnt meant to be but that is the
perspective share by others.

Now, if it is a WG I-D, i think we need to go out and correct the
perspection that it is not just an NSI I-D. It is beyond that and it is
going to come back haunt them if they dont take note now.

Your I-D will make great input to this going-to-be WG. But as an WG I-D,
I think it is safe to safe to say that we need more reviews beyond your
registrars. I am sure the other registries have their comments too so
why not hear them out?

Unless of course you mean you couldnt care less about what the rest of
the registries thinks...in that case, I shall rest my case.

Date: Sun, 4 Feb 2001 07:34:32 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Interim Meeting
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Feb 04, 2001 at 11:23:19PM +0800, James Seng/Personal wrote:
[...]
> Your reqs spec has been published as an individual I-D, largely ignored
> by the other community because they see it as primarly NSI focus with
> your registrars. I know you it wasnt meant to be but that is the
> perspective share by others.

That is probably true.

> Now, if it is a WG I-D, i think we need to go out and correct the
> perspection that it is not just an NSI I-D. It is beyond that and it is
> going to come back haunt them if they dont take note now.
> 
> Your I-D will make great input to this going-to-be WG. But as an WG I-D,
> I think it is safe to safe to say that we need more reviews beyond your
> registrars. I am sure the other registries have their comments too so
> why not hear them out?

Scott said:

  "If anyone has issues with it I wish they would make them known..."

What, specifically, are your issues with it?

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

From: "James Seng/Personal" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: Interim Meeting
Date: Sun, 4 Feb 2001 23:23:19 +0800
Sender: [email-masked]

Scott,

I am not against the interim meeting and in fact, I think it is a good
idea. It is a pity (or perhaps lucky) I wont be able to attend it.

Your reqs spec has been published as an individual I-D, largely ignored
by the other community because they see it as primarly NSI focus with
your registrars. I know you it wasnt meant to be but that is the
perspective share by others.

Now, if it is a WG I-D, i think we need to go out and correct the
perspection that it is not just an NSI I-D. It is beyond that and it is
going to come back haunt them if they dont take note now.

Your I-D will make great input to this going-to-be WG. But as an WG I-D,
I think it is safe to safe to say that we need more reviews beyond your
registrars. I am sure the other registries have their comments too so
why not hear them out?

Unless of course you mean you couldnt care less about what the rest of
the registries thinks...in that case, I shall rest my case.

-James Seng

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, February 04, 2001 10:13 PM
Subject: RE: Interim Meeting

> James,
>
> I know full well when the next IETF meeting is scheduled.  Our interim
WG
> (even proto-WG) meeting will be held under IETF guidelines, making it
an
> IETF-affiliated meeting.
>
> The requirements draft has now been published for 10+ months in
complete
> conformance with IETF policies.  If anyone has issues with it I wish
they
> would make them known, for there's surely been plenty of time
available.
>
> <Scott/>
>
> -----Original Message-----
> From: James Seng/Personal [mailto:[email-masked]]
> Sent: Sunday, February 04, 2001 7:09 AM
> To: Hollenbeck, Scott; 'provreg List'
> Subject: Re: Interim Meeting
>
>
> > Nothing is ever decided with finality at face-to-face IETF
meetings --
> > consensus decisions are made using mailing lists like this one.
Those
> of us
> > who have asked for an interim meeting want to get down to critical
> review of
> > the EPP proposals, and to that end I think we need to do the
following
> > between now and 21+ February:
>
> 20th Feb is an interim meeting, not IETF meeting. Interim meetings for
> WG are not encouraged but not against the rules if approved by the
ADs.
>
> > 1. We come to some semblance of closure on the requirements.  The
> updated
> > draft was posted almost two weeks ago, and I haven't seen any
> discussion
> > since.  Does that mean I got it right this time?  ;-)
>
> I think the right answer is people are still coming to terms with this
> WG and trying to understand the consequences. It would be too early to
> say that you got it right.
>
> RIPE have done a good job promoting this in Amsterdam to the European
> NICs. There would be a APRICOT meeting end of Feb where Asia NICs
would
> usually attend. I will try do some "awareness promotion" there so we
> could get Asia NICs to join the work here. Their feedback is equally
> important.
>
> Yes, this means I wont be able to attend to interim meeting because of
> APRICOT. Guess this means one less 'trouble-maker' there. How lucky
:-)
>
> ps: The current requirements probably not suitable for them but I
shall
> leave it to them to explain why.
>
> pss: There are other kind of registries who would be interested in
this
> work. They should be appropriately be informed. IP, keywords and URN
> comes to mind immediately. And probably ENUM/E164, if ITU could get
> their head around to understand it.
>
> -James Seng
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Interim Meeting
Date: Sun, 4 Feb 2001 09:13:58 -0500 
Sender: [email-masked]

James,

I know full well when the next IETF meeting is scheduled.  Our interim WG
(even proto-WG) meeting will be held under IETF guidelines, making it an
IETF-affiliated meeting.

The requirements draft has now been published for 10+ months in complete
conformance with IETF policies.  If anyone has issues with it I wish they
would make them known, for there's surely been plenty of time available.

<Scott/> 

-----Original Message-----
From: James Seng/Personal [mailto:[email-masked]]
Sent: Sunday, February 04, 2001 7:09 AM
To: Hollenbeck, Scott; 'provreg List'
Subject: Re: Interim Meeting

> Nothing is ever decided with finality at face-to-face IETF meetings --
> consensus decisions are made using mailing lists like this one.  Those
of us
> who have asked for an interim meeting want to get down to critical
review of
> the EPP proposals, and to that end I think we need to do the following
> between now and 21+ February:

20th Feb is an interim meeting, not IETF meeting. Interim meetings for
WG are not encouraged but not against the rules if approved by the ADs.

> 1. We come to some semblance of closure on the requirements.  The
updated
> draft was posted almost two weeks ago, and I haven't seen any
discussion
> since.  Does that mean I got it right this time?  ;-)

I think the right answer is people are still coming to terms with this
WG and trying to understand the consequences. It would be too early to
say that you got it right.

RIPE have done a good job promoting this in Amsterdam to the European
NICs. There would be a APRICOT meeting end of Feb where Asia NICs would
usually attend. I will try do some "awareness promotion" there so we
could get Asia NICs to join the work here. Their feedback is equally
important.

Yes, this means I wont be able to attend to interim meeting because of
APRICOT. Guess this means one less 'trouble-maker' there. How lucky :-)

ps: The current requirements probably not suitable for them but I shall
leave it to them to explain why.

pss: There are other kind of registries who would be interested in this
work. They should be appropriately be informed. IP, keywords and URN
comes to mind immediately. And probably ENUM/E164, if ITU could get
their head around to understand it.

-James Seng

From: "James Seng/Personal" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'provreg List'" <[email-masked]>
Subject: Re: Interim Meeting
Date: Sun, 4 Feb 2001 20:08:51 +0800
Sender: [email-masked]

> Nothing is ever decided with finality at face-to-face IETF meetings --
> consensus decisions are made using mailing lists like this one.  Those
of us
> who have asked for an interim meeting want to get down to critical
review of
> the EPP proposals, and to that end I think we need to do the following
> between now and 21+ February:

20th Feb is an interim meeting, not IETF meeting. Interim meetings for
WG are not encouraged but not against the rules if approved by the ADs.

> 1. We come to some semblance of closure on the requirements.  The
updated
> draft was posted almost two weeks ago, and I haven't seen any
discussion
> since.  Does that mean I got it right this time?  ;-)

I think the right answer is people are still coming to terms with this
WG and trying to understand the consequences. It would be too early to
say that you got it right.

RIPE have done a good job promoting this in Amsterdam to the European
NICs. There would be a APRICOT meeting end of Feb where Asia NICs would
usually attend. I will try do some "awareness promotion" there so we
could get Asia NICs to join the work here. Their feedback is equally
important.

Yes, this means I wont be able to attend to interim meeting because of
APRICOT. Guess this means one less 'trouble-maker' there. How lucky :-)

ps: The current requirements probably not suitable for them but I shall
leave it to them to explain why.

pss: There are other kind of registries who would be interested in this
work. They should be appropriately be informed. IP, keywords and URN
comes to mind immediately. And probably ENUM/E164, if ITU could get
their head around to understand it.

-James Seng

From: "James Seng/Personal" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Date: Sun, 4 Feb 2001 20:07:47 +0800
Sender: [email-masked]

Dave,

> At 05:17 PM 2/3/2001 -0500, Edward Lewis wrote:
> >The reason I removed the mention of the draft is that we are not here
to
> >bless a particular protocol generated outside the working group, but
rather
> >to generate a protocol in full view of the IETF.  Scott's proposals
are
> >fine starting points, but if there happens to be a better proposal
out
> >there, we aren't going to stop it.
>
> 1.  If there happened to be a better proposal, then we would have
heard
> about it by now.

I really really have to disagree with you here as much as I hate to do
so.

There is definately other proposal out there. There is no such thing as
one solution for a particular problem. If the intention of this WG is to
make Scott I-D into an RFC, honestly, there is *NO NEED* for the WG. All
Scott needs to do is to submit it to the IESG for review.

There is no better proposal now, yes. But there is none other either
which makes the choice scarely. It is like voting for the president with
one candidate. And there are no other proposal now because others who
may be interested in this area either (a) have not heard of it (b)
trying to look for it (i have to hunt for it. for goodness sake, i cant
even find the archive until someone else posted it), (c) they may be
still drafting it.

And yes, i am writing a proposal. But I like to see if we can get any
consensus on the requirements first.

-James Seng

Date: Sat, 03 Feb 2001 20:31:51 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: Edward Lewis <[email-masked]>, <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 11:19 PM 2/3/2001 -0500, Edward Lewis wrote:
>I don't know if the IESG would rather us be starting
>from documents existing prior to the WG formation, or would rather us have
>a charter indicating a clean slate.

Typically the IESG reacts to choices by the working group, rather than 
attempting to do proactive management.  This involves a precept of the 
IETF, which is that working groups are largely expected to know what is 
needed for them to accomplish their tasks.

I do not recall seeing any traffic on the list that objected to citing the 
document.  As I noted, in fact the document has substantial support.  (I'll 
be more explicit:  I know of folks who would have been delighted to shoot 
it down.  They studied the thing carefully and decided that it was fine.)

So was the removal based on feedback from the AD, IESG, or what?

>I am doing the best I can to make sure we don't jump the gun on the
>process, fail to invite as much comment on this protocol as is needed, and
>yet still get a timely specification done within the IETF.

One cannot fault such sentiments.  They are entirely appropriate.  The 
reason I am pursuing this, however, is that IETF fairness and openness 
permit more management flexibility than is often appreciated, and the 
reason for the flexibility is to assist in making forward progress, 
especially when there is a sense of urgency.

As I've noted, there is nothing unusual or inappropriate about citing a 
particular draft as a basis, given good support and a clear understanding 
that the working group is ultimately empowered to make whatever changes it 
deems appropriate.  This does not fail to invite comment.  Rather, it 
focuses it.

At any rate, we have both stated our views thoroughly.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Sat, 3 Feb 2001 23:19:11 -0500
To: Dave Crocker <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: Edward Lewis <[email-masked]>, <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 6:20 PM -0500 2/3/01, Dave Crocker wrote:
>What changed?

Right now I am basically waiting for feedback from the IESG.  I see the
point of having documents by name and I see the point of not having the
documents by name.  I don't know if the IESG would rather us be starting
from documents existing prior to the WG formation, or would rather us have
a charter indicating a clean slate.  In either case, I have a charter
written.

In my mail on the topic of the charter and meeting schedule, I am trying to
lay out the possibilities.  There has been no other proposal and I know of
no other proposal.  I don't expect there to be another proposal.  The
urgency for a quickly defined protocol has always been there, has been
discussed ad infinitum, and is still recognized.  There is no reason to
think anyone wants to draw out the process.

I am doing the best I can to make sure we don't jump the gun on the
process, fail to invite as much comment on this protocol as is needed, and
yet still get a timely specification done within the IETF.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sat, 03 Feb 2001 15:20:22 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

Edward,

At 05:17 PM 2/3/2001 -0500, Edward Lewis wrote:
>The reason I removed the mention of the draft is that we are not here to
>bless a particular protocol generated outside the working group, but rather
>to generate a protocol in full view of the IETF.  Scott's proposals are
>fine starting points, but if there happens to be a better proposal out
>there, we aren't going to stop it.

1.  If there happened to be a better proposal, then we would have heard 
about it by now.

2.  As I noted earlier, the existing specification has already received 
quite a bit of diverse review... and support.  That does not mean it needs 
no changes.  Rather it means that there is good reason to believe that it 
is a solid base, from which relatively minor changes are likely.  Yes, this 
all depends upon group consensus, but there is good evidence that consensus 
exists for using it as the base.

3.  There is extensive history with having an IETF working group charter 
explicitly cite that a particular draft proposal will be used as a 
base.  Yes, there are times when a working group starts with an empty slate 
and does all the work from scratch; but it is often true that a detailed 
proposal exists and has strong enough support to be used as the base.  This 
is one of those cases.  That was why I put the language in the original 
draft charter.

4.  So as I noted earlier, inviting proposals now is going to have only the 
effect of adding delay.

>Yes, there exists the possibility that other proposals may come along.

"May" come along.    If there were a raging debate about paradigms and 
choices and if there were multiple detailed specifications, citing one in 
the charter would be inappropriate.  That is not the case, here.

>But if the consensus is that there is a deadline

1.  I thought that we had seen multiple confirmations on the list of some 
urgency.

2.  The milestone dates were chosen to be aggressive, based both on the 
sense of urgency and the sense that Scott's proposal had strong support as 
a base.

What changed?

> >In point of fact, Scott's proposal has already received quite extensive
> >review from, from very different perspectives, and the consensus seems to
> >be that it is an excellent starting point.
>
>This makes it (the requirements draft) a shoo-in as a WG document.  It is
>also less likely that there will be an alternative requirements draft
>coming in that could delay consensus on the requirements.

I am pressing this issue forcefully for a basic concern about working group 
management.  The charter is a contract and the language of the charter is 
often very useful for helping to eliminate distracting discussion.  Hence, 
the charter can be very useful for ensuring group focus.

By eliminating the citation of Scott's draft as the base you are inviting 
several months of design theory debates.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: "'provreg List'" <[email-masked]>, "Edward Lewis" <[email-masked]>
Subject: Re: Interim Meeting
Date: Sat, 3 Feb 2001 15:06:22 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

> >I said it before, and I'll say it again - I want a travel assistant! :-)
> 
> You already have one.  ITN, Travelocity, etc.

Not the same as, "Hey, Fred, I need to be at Dulles for a meeting on
the 20th, bracket it by a day on either side, would you, and I'd like
to come back in the late afternoon if possible?"

Sure, it's decadent, but I can dream...

Christopher

Date: Sat, 03 Feb 2001 14:59:35 -0800
To: "Christopher Ambler" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Interim Meeting
Cc: "'provreg List'" <[email-masked]>, "Edward Lewis" <[email-masked]>
Sender: [email-masked]

At 02:06 PM 2/3/2001 -0800, Christopher Ambler wrote:
>What's BWI? Baltimore?

Baltimore/Washington International.  Perhaps halfway between the two 
cities.  Effectively the same distance, to the east of Washington, as 
Dulles is to the West.

In other words, a pain, but viable.

By contrast, the fare I quoted earlier goes into Dulles.

>I said it before, and I'll say it again - I want a travel assistant! :-)

You already have one.  ITN, Travelocity, etc.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Sat, 3 Feb 2001 17:23:17 -0500
To: "Christopher Ambler" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim Meeting
Cc: "'provreg List'" <[email-masked]>, "Edward Lewis" <[email-masked]>
Sender: [email-masked]

At 5:06 PM -0500 2/3/01, Christopher Ambler wrote:
>What's BWI? Baltimore?

BWI is Baltimore/Washington International.  If you use the airport
designation "WAS" for WashingtonDC, you get three airports - Dulles, BWI,
and National/Reagan.  Others may find that some routes are much cheaper to
one of the three than the others.  In particular, BWI is a main airport for
Southwest and as a result (of competition) generally has lower fares within
the US than Dulles.

For those overseas, Southwest flies only within the US and has no
international (to us) partners.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sat, 3 Feb 2001 17:18:31 -0500
To: Bill Manning <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: [email-masked] (Eric Brunner-Williams in Portland Maine), [email-masked], [email-masked], [email-masked] (Patrik Faltstrom)
Sender: [email-masked]

The charter mentions DNS administration to set the context of the work, it
itself is not a work item.

At 5:41 PM -0500 2/2/01, Bill Manning wrote:
>% Ed,
>%
>% The scope expressed in this charter draft mentions:
>% 	administration of the DNS, DNS Registries, Registrars, Registrants,
>% 	plurality of mid-level access modes (multiple DNS registries, and
>% 	multiple DNS registrars), R2R application interaction and other
>% 	rational boilerplate,
>%
>% and fails to mention:
>% 	whois (any varient)
>%
>% and declines to put non-DNS registration interests ahead of DNS
>registration.
>%
>% In my view these are attractive features of this charter, and I understand
>% from Mr. Seng's earlier repeated comments that he does not.
>%
>% If anything, the focus of the work will be sharpened by having to recharter
>% upon completion of DNS Registrataion work, if in fact there is a need for a
>% standard in some related or extended area(s).
>%
>% Cheers,
>% Eric
>
>	Hum... perhaps the charter is a bit too broad. IMHO,
>	"administration of the DNS" is way outside a registration
>	protocol.  DNS has an existing OPS wg  (DNSOPS) and has existing
>	protocols for performing DNS administration...
>
>
>
>--
>--bill

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sat, 3 Feb 2001 17:17:08 -0500
To: Dave Crocker <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 5:59 PM -0500 2/2/01, Dave Crocker wrote:
>Removing the reference to Scott's draft is a very serious mistake,
>PRECISELY for the reason noted above:  If someone has an alternative draft,
>they have not come forward with it.  Inviting people to START on new drafts
>is an excellent way to ensure that this working group take MUCH longer to
>do something useful.

The reason I removed the mention of the draft is that we are not here to
bless a particular protocol generated outside the working group, but rather
to generate a protocol in full view of the IETF.  Scott's proposals are
fine starting points, but if there happens to be a better proposal out
there, we aren't going to stop it.

Yes, there exists the possibility that other proposals may come along.  But
if the consensus is that there is a deadline and there is an acceptable
proposal available, a "promising" future proposal may be dismissed if it
will not meet the deadline.

>In point of fact, Scott's proposal has already received quite extensive
>review from, from very different perspectives, and the consensus seems to
>be that it is an excellent starting point.

This makes it (the requirements draft) a shoo-in as a WG document.  It is
also less likely that there will be an alternative requirements draft
coming in that could delay consensus on the requirements.  The WG
discussion on it will likely be quick.  It is possible that we could go to
last call within a month of being a WG (allowing time for any other input
to be made under the mantle of a WG).

I haven't seen nearly as much consensus on EPP yet, but at least Scott has
a laid out plan.  We have a good starting point.

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

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "'provreg List'" <[email-masked]>, "Edward Lewis" <[email-masked]>
Subject: Re: Interim Meeting
Date: Sat, 3 Feb 2001 14:06:15 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

> As far as airfare from Seattle (sorry, Chris, I couldn't resist the challenge):
> 
> Southwest air flights:
> 244/133 on Feb 19 (leaves SeaTac 1pm, change in KC, lands BWI 10:45pm)
> 113/2359 on Feb 21 (leaves BWI 7:55am, change in Phoenix, lands S/T 3:40pm)
> 
> Total cost: $431 (including taxes), no Sat stayover needed.  (I just got
> these prices on there web site.)  BWI is about 60 miles from the meeting.

Challenges rock, no apology necessary.

I found a convoluted fare that would take me from my meeting in LA
directly to DC (just not taking the trip home to Seattle first) a day
early, and put in for it. We shall see.

What's BWI? Baltimore?

I said it before, and I'll say it again - I want a travel assistant! :-)

Christopher

Date: Sat, 3 Feb 2001 16:56:37 -0500
To: "'provreg List'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Interim Meeting
Cc: [email-masked]
Sender: [email-masked]

I want to emphasize what Scott posted on this thread:

>  Nothing is ever decided with finality at face-to-face IETF meetings --
>  consensus decisions are made using mailing lists like this one.

The meeting will have a posted agenda, one has already been proposed on the
list (check the archives).  The meeting will also have minutes, just as all
regular IETF meetings do.

Recall that we are 'calendar squeezed' for this meeting.  Many of us are
involved in other activities - ICANN and APRICOT meet between now and the
IETF.

As far as scheduling the meeting - The DC location was chosen after
consideration in a thread.  (Again, check the archives.)  I started the
motion to set the meeting in place on Jan. 20, the first day after I heard
that our charter had been sent to the IESG.  The latest we would be allowed
to hold a meeting would be Feb 23, or we'd be running to close to the IETF
main meeting (not to mention APRICOT and ICANN conflicts).  Given that we
wanted as much notice possible, that pretty much put us around Feb 20.

As far as airfare from Seattle (sorry, Chris, I couldn't resist the challenge):

Southwest air flights:
244/133 on Feb 19 (leaves SeaTac 1pm, change in KC, lands BWI 10:45pm)
113/2359 on Feb 21 (leaves BWI 7:55am, change in Phoenix, lands S/T 3:40pm)

Total cost: $431 (including taxes), no Sat stayover needed.  (I just got
these prices on there web site.)  BWI is about 60 miles from the meeting.

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

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Jaap Akkerhuis" <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: "'provreg List'" <[email-masked]>
Subject: Re: Interim Meeting 
Date: Sat, 3 Feb 2001 11:27:02 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

This is one of those rare times that I agree with Dave. (my availability for extra days
notwithstanding, as my time is almost 100% booked these days, Dave's point to
add an extra day is, I believe, spot on).

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]

> (And apologies to one and all for this extended thread.  Obviously it is a 
> pet topic of mine and I am trying to promote it more broadly.)

Date: Sat, 03 Feb 2001 11:09:38 -0800
To: Jaap Akkerhuis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Interim Meeting 
Cc: "'provreg List'" <[email-masked]>
Sender: [email-masked]

At 05:30 PM 2/3/2001 +0100, Jaap Akkerhuis wrote:

>     I managed to find a United $500 fare from san jose, but it took
>     some digging.
>
>You don't want ty know about prices in Europe.

Although the current event is not a counter-example example, it is often 
true that prices between Europe (or even Asia) and the US are cheaper than 
WITHIN the U.S!  Market forces can be SO interesting sometimes.

But more generally, I would have wished that the meeting were at least 2 
days, simply because the travel time and money are so expensive.  Again, it 
is far too late to change the current plans, but it is worth remembering.

>     Yes, we DO need an agenda.  In addition, I suggest that the
>     cost of attending the meeting is high enough to warrant working
>     a longer day.  So I suggest changing the time from 10-5 to be
>     9-6 or 8:30-6pm (or even 6:30pm.)
>
>For people from Europe, this is too late. My flight leaves around
>18:00 (6 pm for americans). We could have a (informal) session the
>eveming beforea allthough the jet-lag might be a problem...

Departure times vary.  While it is important that the schedule not exclude 
people excessively, it is frequently true that some people arrive late or 
leave early.  Many flights to Europe depart at 8-10pm, for 
example.  (Hmmm.  That might not be true from Chicago, or Dallas, it occurs 
to me.  I am probably remember Easter U.S.)

So, your point is well taken.  In any event, I was simply trying to suggest 
that we extend the hours as much as we can.  The group needs consensus on 
the specific choices for starting and stopping.

Your suggestion that the current meeting hold an informal discussion the 
night before is excellent!

>     If we do an interim meeting in the US again, I'll suggest that
>     we meet in Chicago or Dallas, starting at 1:30pm, and all of
>
>For non-American attendees this might not be an option. We should
>minimize on interim meetings anyway.

We should, indeed.

I have done enough long-haul flight to be entirely empathetic with your 
concerns.  (But then, flying long-haul for a one-day meeting is quite 
daunting, since I prefer a few days to adjust, before doing real work.)

However, long-haul flights usually arrive in the morning, with customs, 
etc., usually meaning that one is free of the airport no later than about 
11am.  That would leave enough time to check into the hotel and take a 
break, before the meeting.

(And apologies to one and all for this extended thread.  Obviously it is a 
pet topic of mine and I am trying to promote it more broadly.)

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

To: Dave Crocker <[email-masked]>
cc: "Christopher Ambler" <[email-masked]>, "'provreg List'" <[email-masked]>
Subject: Re: Interim Meeting 
Date: Sat, 03 Feb 2001 17:30:36 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    I managed to find a United $500 fare from san jose, but it took
    some digging.

You don't want ty know about prices in Europe.

    Yes, we DO need an agenda.  In addition, I suggest that the
    cost of attending the meeting is high enough to warrant working
    a longer day.  So I suggest changing the time from 10-5 to be
    9-6 or 8:30-6pm (or even 6:30pm.)

For people from Europe, this is too late. My flight leaves around
18:00 (6 pm for americans). We could have a (informal) session the
eveming beforea allthough the jet-lag might be a problem...

    If we do an interim meeting in the US again, I'll suggest that
    we meet in Chicago or Dallas, starting at 1:30pm, and all of
    the following day.  That will give almost 2 full days of meeting,
    for the cost of one over-night, to North American-based attendees.
    However folks will mostly already have their tickets, so I
    won't suggest making a change for the 20 Feb. meeting.

For non-American attendees this might not be an option. We should
minimize on interim meetings anyway.

	jaap

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: "'provreg List'" <[email-masked]>
Subject: Re: Interim Meeting
Date: Fri, 2 Feb 2001 21:56:24 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

As we all know, airfares change, literally, every minute. $1100 is still
pretty steep, but more manageable. I've been checking online (as well
as asking my mother, a travel agent, to monitor for me) every couple
of hours or so.

One more reason to hire an assistant... looking for a job, Dave? :-)

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]
----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Christopher Ambler" <[email-masked]>
Cc: "'provreg List'" <[email-masked]>
Sent: Friday, February 02, 2001 9:47 PM
Subject: Re: Interim Meeting

> At 04:46 PM 2/2/2001 -0800, Christopher Ambler wrote:
> >The best I found from other west coast cities (LA, SFO) was $555, but none
> >of the iteneraries matched up on a commuter hop from Seattle when I checked,
> >and by the time I found one, the fare was gone. Such is life.
> >
> >The laughter from our CFO when I told her the fare was $2300 was just a 
> >bit embarrassing :-)
> 
> 
> As it should have been.
> 
> The following took about 5 minutes to uncover at itn.net, using Instant 
> Itinerary:
> 
> 
> Seattle (SEA) to Washington (IAD) Monday, Feb 19
> 
> United Airlines 736 Boeing 757-200
> Feb 19   6:00 am  SEA  Feb 19   9:31 am  DEN
> 
> United Airlines 970 Boeing 777
> Feb 19 10:30 am  DEN  Feb 19   3:36 pm  IAD
> 
> 
> Washington (IAD) to Seattle (SEA) Wednesday, Feb 21
> 
> United Airlines 435 Boeing 737-300
> Feb 21   2:05 pm  IAD  Feb 21   4:02 pm  DEN
> 
> United Airlines 291 Boeing 737-300
> Feb 21   5:05 pm  DEN  Feb 21   6:59 pm  SEA
> 
> 
>   Total Airfare (including taxes)  USD    1171.00
> 
> 
> 
> 
> 
> 
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg Consulting   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
> 

Date: Fri, 02 Feb 2001 21:47:15 -0800
To: "Christopher Ambler" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Interim Meeting
Cc: "'provreg List'" <[email-masked]>
Sender: [email-masked]

At 04:46 PM 2/2/2001 -0800, Christopher Ambler wrote:
>The best I found from other west coast cities (LA, SFO) was $555, but none
>of the iteneraries matched up on a commuter hop from Seattle when I checked,
>and by the time I found one, the fare was gone. Such is life.
>
>The laughter from our CFO when I told her the fare was $2300 was just a 
>bit embarrassing :-)

As it should have been.

The following took about 5 minutes to uncover at itn.net, using Instant 
Itinerary:

Seattle (SEA) to Washington (IAD) Monday, Feb 19

United Airlines 736 Boeing 757-200
Feb 19   6:00 am  SEA  Feb 19   9:31 am  DEN

United Airlines 970 Boeing 777
Feb 19 10:30 am  DEN  Feb 19   3:36 pm  IAD

Washington (IAD) to Seattle (SEA) Wednesday, Feb 21

United Airlines 435 Boeing 737-300
Feb 21   2:05 pm  IAD  Feb 21   4:02 pm  DEN

United Airlines 291 Boeing 737-300
Feb 21   5:05 pm  DEN  Feb 21   6:59 pm  SEA

  Total Airfare (including taxes)  USD    1171.00

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Fri, 02 Feb 2001 18:35:54 -0800
To: "James Seng/Personal" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 10:09 AM 2/3/2001 +0800, James Seng/Personal wrote:
>You know, it is very difficult to disagree with you :-)

oh?.  i need to get you to talk with some people involved with the ICANN 
process...

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "James Seng/Personal" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Date: Sat, 3 Feb 2001 10:09:32 +0800
Sender: [email-masked]

Dave,

You know, it is very difficult to disagree with you :-)

-James Seng

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: <[email-masked]>; "Patrik Faltstrom" <[email-masked]>
Sent: Saturday, February 03, 2001 10:00 AM
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)

> At 09:35 AM 2/3/2001 +0800, James Seng/Personal wrote:
> >Dave,
> >
> > > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote:
> > > >I would like to object this proposed charter for provreg. Its
scope
> >has
> > > >been so specific defined for DNS only and has no mention of
anything
> > > >beyond DNS.
> > >
> > > feature, not bug.
> >
> >It depends who you speaking to...To me, it is a bug.
>
> My statement is based on experience with IETF processes, observation
of
> other standards processes and experience with product development.  It
> seems to be one of the empirical truths about project success,
especially
> when an open group process is involved.
>
> Start with the simplest, most specific deliverable that will be
> useful.  Then evolve.
>
>
> >However, I can not understand is what is the hurry for the WG to get
> >this out quickly?
>
> That has been discussed before.  Existing and new registries and
registrars
> want this NOW.
>
>
> >If it is about new gTLD registry, any of the new gTLD registry who
have
> >not started work implementing their system now is crazy. I dont think
> >any of them will wait for the result of the WG (Sept?) before
starting
> >work. For this, we are already too late.
>
> For their initial use, yes.  But some of them have already spoken,
here, to
> validate the urgency of their need.
>
>
> >Either way, IMHO, we are already too late in a non-standardised
world.
>
> James, unfortunately that is one of the usual argument for taking
forever.
>
> >Hence, it is better to work on a GOOD and long term technical
solution
>
> Again, that is unfortunately a frequently-heard comment in standards
arenas
> that is obviously well-intentioned, but turns out to be
> counter-productive.  It is one of the ironies of this sort of
standards work.
>
> d/
>
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg Consulting   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
>

Date: Fri, 02 Feb 2001 18:00:12 -0800
To: "James Seng/Personal" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 09:35 AM 2/3/2001 +0800, James Seng/Personal wrote:
>Dave,
>
> > At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote:
> > >I would like to object this proposed charter for provreg. Its scope
>has
> > >been so specific defined for DNS only and has no mention of anything
> > >beyond DNS.
> >
> > feature, not bug.
>
>It depends who you speaking to...To me, it is a bug.

My statement is based on experience with IETF processes, observation of 
other standards processes and experience with product development.  It 
seems to be one of the empirical truths about project success, especially 
when an open group process is involved.

Start with the simplest, most specific deliverable that will be 
useful.  Then evolve.

>However, I can not understand is what is the hurry for the WG to get
>this out quickly?

That has been discussed before.  Existing and new registries and registrars 
want this NOW.

>If it is about new gTLD registry, any of the new gTLD registry who have
>not started work implementing their system now is crazy. I dont think
>any of them will wait for the result of the WG (Sept?) before starting
>work. For this, we are already too late.

For their initial use, yes.  But some of them have already spoken, here, to 
validate the urgency of their need.

>Either way, IMHO, we are already too late in a non-standardised world.

James, unfortunately that is one of the usual argument for taking forever.

>Hence, it is better to work on a GOOD and long term technical solution

Again, that is unfortunately a frequently-heard comment in standards arenas 
that is obviously well-intentioned, but turns out to be 
counter-productive.  It is one of the ironies of this sort of standards work.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: RE: Interim Meeting
Date: Fri, 2 Feb 2001 20:40:25 -0500 
Sender: [email-masked]

Nothing is ever decided with finality at face-to-face IETF meetings --
consensus decisions are made using mailing lists like this one.  Those of us
who have asked for an interim meeting want to get down to critical review of
the EPP proposals, and to that end I think we need to do the following
between now and 21+ February:

1. We come to some semblance of closure on the requirements.  The updated
draft was posted almost two weeks ago, and I haven't seen any discussion
since.  Does that mean I got it right this time?  ;-)

2. We identify macro issues with the base EPP specification (based on the
requirements and whatever else matters), and maybe the domain, host, and
contact specifications.  There are some things that I want to change based
on our requirements discussions, such as transaction identifiers and domain
expiration.  If we can reach quick agreement on any issues before the
meeting, that's great.  Issues that need more in-depth discussion get tabled
for discussion at the interim meeting.

3. We produce a concise list of issues to be discussed at the interim
meeting to form the bulk of the agenda.

4. We hold the meeting, and discuss each issue until we reach some logical
conclusion (I can probably hold the room for more time if needed, but I
would need to know that pretty soon).  Depending on how things go we make
some tentative decisions about next steps.

5. Meeting notes and next step thoughts are posted to this list ASAP after
we finish (will someone volunteer to take and post detailed notes?).

6. Document editing starts on 21 February based on interim meeting
discussions, and the new draft(s) are published ASAP.

7. We discuss the results of the interim meeting, the new drafts, and next
steps on this list.

<Scott/> 

-----Original Message-----
From: Christopher Ambler [mailto:[email-masked]]
Sent: Friday, February 02, 2001 6:45 PM
To: 'provreg List'
Subject: Re: Interim Meeting

[snip]

What is the agenda for this meeting, will anything be decided (I suspect
not)?

From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: "Patrik Faltstrom" <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Date: Sat, 3 Feb 2001 09:35:20 +0800
Sender: [email-masked]

Dave,

> At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote:
> >I would like to object this proposed charter for provreg. Its scope
has
> >been so specific defined for DNS only and has no mention of anything
> >beyond DNS.
>
> feature, not bug.

It depends who you speaking to...To me, it is a bug.

> start with a narrow focus.  do something useful quickly.  then come
back
> and expand the scope.
>
> The more general the scope, the longer the cycle to delivery something
useful.

I agree.

However, I can not understand is what is the hurry for the WG to get
this out quickly?

If it is about new gTLD registry, any of the new gTLD registry who have
not started work implementing their system now is crazy. I dont think
any of them will wait for the result of the WG (Sept?) before starting
work. For this, we are already too late.

If it is just pure market pressure to have this, well, the answer is
fairly simple. Different registries are already using different system
ranging from taking it via by hand, by email, by webpage, to more
automated one, RRP or some variant of RRP.

For those high-tech ones which uses automated system, moving to a new
standard takes a lot of time so it wont happen overnight. For those
still on low-tech, investment to create whatever specify here is going
be very high for them which means potential opportunity for those who
can get a solution to them.

Either way, IMHO, we are already too late in a non-standardised world.
Hence, it is better to work on a GOOD and long term technical solution
then something half-baked push out quickly for an immediated need which
no longer exist.

Am I missing something?

-James Seng

From: "James Seng/Personal" <[email-masked]>
To: "Edward Lewis" <[email-masked]>
Cc: "Paul George" <[email-masked]>, <[email-masked]>
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)
Date: Sat, 3 Feb 2001 09:23:49 +0800
Sender: [email-masked]

Yes, you may say you have generally agreement in this mailing list,
apparently comprises of a lot of people in the domain names industry (me
included).

However, I do wish to state my position that I still think the charter
focus is too focus on domain names registration only. But one person
should not stop you from submitting it to the IESG.

-James Seng

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: "Paul George" <[email-masked]>; <[email-masked]>
Sent: Saturday, February 03, 2001 6:07 AM
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)

> In summary - let's say we are in raging agreement as far as what the
> charter should be.  As far as what was put into the ietf-announce
message,
> that will be fixed one way or another.  (I may have sent the updated
one in
> too close to the conference call, so the older one was processed.)
Keep in
> mind that the IESG has the last say, so I can't guarantee anything,
but at
> this point I am willing to trust that the IESG will "do the right
thing
> (tm)."
>
> At 4:08 PM -0500 2/2/01, James Seng/Personal wrote:
> >Go take a look at the annoucement made by the IESG. It is obviously
not
> >there so somehow, somewhere, someone make a mistake.
> >
> >No, it is not too late to give them an update copy. In fact, there is
no
> >such thing as too late.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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.
>
>

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: "'provreg List'" <[email-masked]>
Subject: Re: Interim Meeting
Date: Fri, 2 Feb 2001 16:46:28 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

> I managed to find a United $500 fare from san jose, but it took some digging.

The best I found from other west coast cities (LA, SFO) was $555, but none
of the iteneraries matched up on a commuter hop from Seattle when I checked,
and by the time I found one, the fare was gone. Such is life.

> If we do an interim meeting in the US again, I'll suggest that we meet in 
> Chicago or Dallas, starting at 1:30pm, and all of the following day.  That 
> will give almost 2 full days of meeting, for the cost of one over-night, to 
> North American-based attendees.  However folks will mostly already have 
> their tickets, so I won't suggest making a change for the 20 Feb. meeting.

Chicago, being a hub, would be most excellent. And please, let's try to
make it at least 45 days advance notice, if at all possible? The laughter
from our CFO when I told her the fare was $2300 was just a bit
embarrassing :-)

Christopher

Date: Fri, 02 Feb 2001 16:01:18 -0800
To: "Christopher Ambler" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Interim Meeting
Cc: "'provreg List'" <[email-masked]>
Sender: [email-masked]

At 03:45 PM 2/2/2001 -0800, Christopher Ambler wrote:
>As of that date, the best air fare from the west coast (Seattle) was 
>$1400. It is
>now $2300, and there is little chance of a fare sale.

I managed to find a United $500 fare from san jose, but it took some digging.

>What is the agenda for this meeting, will anything be decided (I suspect not)?

Yes, we DO need an agenda.  In addition, I suggest that the cost of 
attending the meeting is high enough to warrant working a longer day.  So I 
suggest changing the time from 10-5 to be 9-6 or 8:30-6pm (or even 6:30pm.)

If we do an interim meeting in the US again, I'll suggest that we meet in 
Chicago or Dallas, starting at 1:30pm, and all of the following day.  That 
will give almost 2 full days of meeting, for the cost of one over-night, to 
North American-based attendees.  However folks will mostly already have 
their tickets, so I won't suggest making a change for the 20 Feb. meeting.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: Interim Meeting
Date: Fri, 2 Feb 2001 15:45:06 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

As of that date, the best air fare from the west coast (Seattle) was $1400. It is
now $2300, and there is little chance of a fare sale.

Often, 30 days is not sufficient for a reasonable air fare, especially when there's
no Saturday stay involved.

What is the agenda for this meeting, will anything be decided (I suspect not)?

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]
----- Original Message ----- 
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jörg Bauer/Denic'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 31, 2001 3:56 AM
Subject: RE: Interim Meeting

Meeting details were sent to this list on Monday 22 January:

http://www.cafax.se/ietf-provreg/maillist/2001-01/msg00188.html

<Scott/>

> -----Original Message-----
> From: Jörg Bauer/Denic [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2001 4:01 AM
> To: [email-masked]
> Subject: Interim Meeting
> 
> 
> 
> Are we having a interim Meeting at 20.Feb. ???
> 
> Could anybody post exact Place/Date ????

From: Bill Manning <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
To: [email-masked] (Eric Brunner-Williams in Portland Maine)
Date: Fri, 2 Feb 2001 14:41:01 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked] (Patrik Faltstrom), [email-masked]
Sender: [email-masked]

% Ed,
% 
% The scope expressed in this charter draft mentions:
% 	administration of the DNS, DNS Registries, Registrars, Registrants,
% 	plurality of mid-level access modes (multiple DNS registries, and
% 	multiple DNS registrars), R2R application interaction and other
% 	rational boilerplate,
% 
% and fails to mention:
% 	whois (any varient)
% 
% and declines to put non-DNS registration interests ahead of DNS registration.
% 
% In my view these are attractive features of this charter, and I understand
% from Mr. Seng's earlier repeated comments that he does not.
% 
% If anything, the focus of the work will be sharpened by having to recharter
% upon completion of DNS Registrataion work, if in fact there is a need for a
% standard in some related or extended area(s).
% 
% Cheers,
% Eric

	Hum... perhaps the charter is a bit too broad. IMHO, 
	"administration of the DNS" is way outside a registration
	protocol.  DNS has an existing OPS wg  (DNSOPS) and has existing
	protocols for performing DNS administration...

-- 
--bill

To: [email-masked]
cc: [email-masked], "Patrik Faltstrom" <[email-masked]>, [email-masked]
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg) 
Date: Fri, 02 Feb 2001 18:15:32 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

The scope expressed in this charter draft mentions:
	administration of the DNS, DNS Registries, Registrars, Registrants,
	plurality of mid-level access modes (multiple DNS registries, and
	multiple DNS registrars), R2R application interaction and other
	rational boilerplate,

and fails to mention:
	whois (any varient)

and declines to put non-DNS registration interests ahead of DNS registration.

In my view these are attractive features of this charter, and I understand
from Mr. Seng's earlier repeated comments that he does not.

If anything, the focus of the work will be sharpened by having to recharter
upon completion of DNS Registrataion work, if in fact there is a need for a
standard in some related or extended area(s).

Cheers,
Eric

Date: Fri, 02 Feb 2001 14:59:47 -0800
To: <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 08:41 PM 2/2/2001 +0800, James Seng/Personal wrote:
>I would like to object this proposed charter for provreg. Its scope has
>been so specific defined for DNS only and has no mention of anything
>beyond DNS.

feature, not bug.

start with a narrow focus.  do something useful quickly.  then come back 
and expand the scope.

The more general the scope, the longer the cycle to delivery something useful.

At 03:22 PM 2/2/2001 -0500, Edward Lewis wrote:
>At 3:02 PM -0500 2/2/01, James Seng wrote:
> >It also have references to Scott Hollenback I-Ds. While Scott have good
> >I-Ds, referencing it to the WG charter is IMHO a bad idea. It will
> >discourage others to come forward with their proposal.
>
>The updated charter does not reference the drafts.  Below is the latest
>one.  I don't know whether the charter below will replace the one on the
>ietf-announce list, but in any case, I certainly agree that the references
>to the drafts should be removed.

Removing the reference to Scott's draft is a very serious mistake, 
PRECISELY for the reason noted above:  If someone has an alternative draft, 
they have not come forward with it.  Inviting people to START on new drafts 
is an excellent way to ensure that this working group take MUCH longer to 
do something useful.

In point of fact, Scott's proposal has already received quite extensive 
review from, from very different perspectives, and the consensus seems to 
be that it is an excellent starting point.

More strangely, the published draft has prose that restricts the work to 
requirements, but specifies deliverables as specification of data objects, 
and the like.  It also does not have milestone dates.

Having the charter focus on requirements is another good way to ensure that 
the useful work of producing a protocol will take longer.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg Consulting   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Fri, 2 Feb 2001 17:07:34 -0500
To: "James Seng/Personal" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)
Cc: "Paul George" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

In summary - let's say we are in raging agreement as far as what the
charter should be.  As far as what was put into the ietf-announce message,
that will be fixed one way or another.  (I may have sent the updated one in
too close to the conference call, so the older one was processed.)  Keep in
mind that the IESG has the last say, so I can't guarantee anything, but at
this point I am willing to trust that the IESG will "do the right thing
(tm)."

At 4:08 PM -0500 2/2/01, James Seng/Personal wrote:
>Go take a look at the annoucement made by the IESG. It is obviously not
>there so somehow, somewhere, someone make a mistake.
>
>No, it is not too late to give them an update copy. In fact, there is no
>such thing as too late.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "James Seng/Personal" <[email-masked]>
To: "Paul George" <[email-masked]>, <[email-masked]>
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)
Date: Sat, 3 Feb 2001 05:08:08 +0800
Sender: [email-masked]

Go take a look at the annoucement made by the IESG. It is obviously not
there so somehow, somewhere, someone make a mistake.

No, it is not too late to give them an update copy. In fact, there is no
such thing as too late.

-James Seng

----- Original Message -----
From: "Paul George" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 03, 2001 4:59 AM
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)

> Okay, so why are there differences?  Are they looking at an older
version?
> Is there a problem with giving them the new version?  Please forgive
my
> ignorance, I thought this one was the version they were
considering.....
>
> Paul George
> SARAF Software Solutions
>
>
> -----Original Message-----
> From: James Seng/Personal [mailto:[email-masked]]
> Sent: Friday, February 02, 2001 3:53 PM
> To: Paul George; [email-masked]
> Subject: Re: WG Review: Provisioning Registry Protocol (provreg)
>
>
> Not in the charter published by the IESG.
>
> -James Seng
>
> ----- Original Message -----
> From: "Paul George" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, February 03, 2001 4:38 AM
> Subject: RE: WG Review: Provisioning Registry Protocol (provreg)
>
>
> > James, I don't understand.  The charter states:
> >
> >
> >      "Subsequent versions of the specification will
> >       extend the protocol to exchange other
> >       information needed to organize the Internet,
> >       such as IP address allocations."
> >
> >
> > I think we are merely *starting* with DNS because of the time
> constraints of
> > the new TLDs, but the protocol can clearly be extended at a later
time
> to
> > include all kinds of registration environments.  I don't see the
> problem.
> > (?)
> >
> > Paul George
> > SARAF Software Solutions
> >
> >
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]On
> > Behalf Of James Seng/Personal
> > Sent: Friday, February 02, 2001 7:42 AM
> > To: [email-masked]
> > Cc: Patrik Faltstrom
> > Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)
> >
> >
> > I would like to object this proposed charter for provreg. Its scope
> has
> > been so specific defined for DNS only and has no mention of anything
> > beyond DNS.
> >
> > I propose shortening the charter and balancing it slightly. If it is
> out
> > of line, feel free to shoot it.
> >
> > ---
> > Registration of Domain Names Service (DNS) involves various objects
> > transfer from multiple Registrars to a back-end Registry database.
> > Conversely, there is a desire to standardized the process allowing
> > multiple Registrars to access multiple Registries database which may
> > differ in operational models. Such registration procotcol has many
> > benefits which may tranverse beyond domain names objects.
> >
> > This working group will investigate the requirements for a
> registration
> > protocol of objects between two or more entities and to developed
such
> a
> > provision protocol that satisfied these requirements.
> >
> > The group will consider support for multiple operational choices,
such
> > as for transport and security; it will create no new transport or
> > security protocols.  The group may consider use of the new protocol
> for
> > diverse registration and update scenarios, in order to understand
> > limitations and possible extensions that are appropriate.
> Specification
> > for user interface access, such as by a web front end, is beyond the
> > scope of this working group.
> >
> > The Action Item(s) for the Working Group are
> >
> > 1. An Informational RFC specifying the requirements of the Provision
> >    Registration protocol.
> >
> > 2. An Informational RFC specifying the objects exchange during the
> >    registration process for the Domain Name; at a minimum includes:
> >    domain names, IP address and contact details for registrant.
> >
> > 3. A Standard RFC specifying the Provision Registration Protocol.
> >    This document should have specification for domain names
> >    object registration but also include extension capability for
> >    non-domain names objects.
> >
> > Goals and Milestones:
> >
> > ....
> >
> > -James Seng
> >
> > --- Original Message ---
> > A new IETF working group has been proposed in the Applications Area.
> > The IESG has not made any determination as yet.
> >
> > The following Description was submitted, and is provided for
> > informational purposes only:
> >
> > Provisioning Registry Protocol (provreg)
> > ----------------------------------------
> >
> >  Current Status: Proposed Working Group
> >
> >
> >  Mailing Lists:
> >      General Discussion:[email-masked]
> >      To Subscribe:      [email-masked]
> >          In Body:       subscribe ietf-provreg
> >      Archive:           http://www.cafax.se/ietf-provreg/maillist/
> >
> > Description of Working Group:
> >
> > Administration of Domain Name Service (DNS) registration
increasingly
> > distinguishes between the operation of a "back-end" registry data
base
> > service for registrations, versus "front-end" support services by
> > registrars who interact with registrants and with the registry.
> > Especially for various Top-Level Domains, the desire is to permit
> > multiple registrars to share access to the database.  Conversely,
> there
> > is a desire to allow a registrar to access multiple registries via
the
> > same protocol, even if the registries differ in operational models.
> >
> > This working group will develop a specification of the requirements
> and
> > limitations for a protocol that enables a registrar to access
multiple
> > registries and will develop a  protocol that satisfies those
> > requirements. The protocol will permit interaction between a
> > registrar's own application and registry applications.
> >
> > The initial specification will allow multiple registrars to register
> > and maintain domain names within multiple Top Level Domains (TLDs).
> The
> > specification should be flexible enough to support the different
> > operational models of registries.  The specification should allow
> > extension to support other registration data, such as address
> > allocation and contact information. The working group will use as
> input
> > the "Generic Registry-Registrar Protocol Requirements"
> > (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
> > Protocol presentation, documented in (draft-hollenbeck-epp-nn).
> >
> > The group will consider support for multiple operational choices,
such
> > as for transport and security; it will create no new transport or
> > security protocols.  The group may consider use of the new protocol
> for
> > diverse registration and update scenarios, in order to understand
> > limitations and possible extensions that are appropriate.
> Specification
> > for user interface access, such as by a web front end, is beyond the
> > scope of this working group.
> >
> > Documentation from the working group will:
> >
> > * Specify the objects exchanged between the registry repository
> > and registrars, the relationships among the objects, and the
protocol
> > for exchanging objects between a registrar and the registry; at a
> > minimum the objects will include:  domain name, IP address, and
> contact
> > details for registrants
> >
> > * Describe appropriate mechanisms for security during registrar
access
> >
> > * List useful examples of registrar access transactions
> >
> >
>
>

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)
Date: Fri, 2 Feb 2001 15:59:28 -0500
Importance: Normal
Sender: [email-masked]

Okay, so why are there differences?  Are they looking at an older version?
Is there a problem with giving them the new version?  Please forgive my
ignorance, I thought this one was the version they were considering.....

Paul George
SARAF Software Solutions

-----Original Message-----
From: James Seng/Personal [mailto:[email-masked]]
Sent: Friday, February 02, 2001 3:53 PM
To: Paul George; [email-masked]
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)

Not in the charter published by the IESG.

-James Seng

----- Original Message -----
From: "Paul George" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 03, 2001 4:38 AM
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)

> James, I don't understand.  The charter states:
>
>
>      "Subsequent versions of the specification will
>       extend the protocol to exchange other
>       information needed to organize the Internet,
>       such as IP address allocations."
>
>
> I think we are merely *starting* with DNS because of the time
constraints of
> the new TLDs, but the protocol can clearly be extended at a later time
to
> include all kinds of registration environments.  I don't see the
problem.
> (?)
>
> Paul George
> SARAF Software Solutions
>
>
>
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]On
> Behalf Of James Seng/Personal
> Sent: Friday, February 02, 2001 7:42 AM
> To: [email-masked]
> Cc: Patrik Faltstrom
> Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)
>
>
> I would like to object this proposed charter for provreg. Its scope
has
> been so specific defined for DNS only and has no mention of anything
> beyond DNS.
>
> I propose shortening the charter and balancing it slightly. If it is
out
> of line, feel free to shoot it.
>
> ---
> Registration of Domain Names Service (DNS) involves various objects
> transfer from multiple Registrars to a back-end Registry database.
> Conversely, there is a desire to standardized the process allowing
> multiple Registrars to access multiple Registries database which may
> differ in operational models. Such registration procotcol has many
> benefits which may tranverse beyond domain names objects.
>
> This working group will investigate the requirements for a
registration
> protocol of objects between two or more entities and to developed such
a
> provision protocol that satisfied these requirements.
>
> The group will consider support for multiple operational choices, such
> as for transport and security; it will create no new transport or
> security protocols.  The group may consider use of the new protocol
for
> diverse registration and update scenarios, in order to understand
> limitations and possible extensions that are appropriate.
Specification
> for user interface access, such as by a web front end, is beyond the
> scope of this working group.
>
> The Action Item(s) for the Working Group are
>
> 1. An Informational RFC specifying the requirements of the Provision
>    Registration protocol.
>
> 2. An Informational RFC specifying the objects exchange during the
>    registration process for the Domain Name; at a minimum includes:
>    domain names, IP address and contact details for registrant.
>
> 3. A Standard RFC specifying the Provision Registration Protocol.
>    This document should have specification for domain names
>    object registration but also include extension capability for
>    non-domain names objects.
>
> Goals and Milestones:
>
> ....
>
> -James Seng
>
> --- Original Message ---
> A new IETF working group has been proposed in the Applications Area.
> The IESG has not made any determination as yet.
>
> The following Description was submitted, and is provided for
> informational purposes only:
>
> Provisioning Registry Protocol (provreg)
> ----------------------------------------
>
>  Current Status: Proposed Working Group
>
>
>  Mailing Lists:
>      General Discussion:[email-masked]
>      To Subscribe:      [email-masked]
>          In Body:       subscribe ietf-provreg
>      Archive:           http://www.cafax.se/ietf-provreg/maillist/
>
> Description of Working Group:
>
> Administration of Domain Name Service (DNS) registration increasingly
> distinguishes between the operation of a "back-end" registry data base
> service for registrations, versus "front-end" support services by
> registrars who interact with registrants and with the registry.
> Especially for various Top-Level Domains, the desire is to permit
> multiple registrars to share access to the database.  Conversely,
there
> is a desire to allow a registrar to access multiple registries via the
> same protocol, even if the registries differ in operational models.
>
> This working group will develop a specification of the requirements
and
> limitations for a protocol that enables a registrar to access multiple
> registries and will develop a  protocol that satisfies those
> requirements. The protocol will permit interaction between a
> registrar's own application and registry applications.
>
> The initial specification will allow multiple registrars to register
> and maintain domain names within multiple Top Level Domains (TLDs).
The
> specification should be flexible enough to support the different
> operational models of registries.  The specification should allow
> extension to support other registration data, such as address
> allocation and contact information. The working group will use as
input
> the "Generic Registry-Registrar Protocol Requirements"
> (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
> Protocol presentation, documented in (draft-hollenbeck-epp-nn).
>
> The group will consider support for multiple operational choices, such
> as for transport and security; it will create no new transport or
> security protocols.  The group may consider use of the new protocol
for
> diverse registration and update scenarios, in order to understand
> limitations and possible extensions that are appropriate.
Specification
> for user interface access, such as by a web front end, is beyond the
> scope of this working group.
>
> Documentation from the working group will:
>
> * Specify the objects exchanged between the registry repository
> and registrars, the relationships among the objects, and the protocol
> for exchanging objects between a registrar and the registry; at a
> minimum the objects will include:  domain name, IP address, and
contact
> details for registrants
>
> * Describe appropriate mechanisms for security during registrar access
>
> * List useful examples of registrar access transactions
>
>

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Paul George" <[email-masked]>, <[email-masked]>
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)
Date: Fri, 2 Feb 2001 15:58:53 -0500
Importance: Normal
Sender: [email-masked]

I too am left scratching my head.

<  -----Original Message-----
<  From: [email-masked] [mailto:[email-masked]]On
<  Behalf Of Paul George
<  Sent: Friday, February 02, 2001 3:38 PM
<  To: [email-masked]
<  Subject: RE: WG Review: Provisioning Registry Protocol (provreg)
<
<
<  James, I don't understand.  The charter states:
<
<
<       "Subsequent versions of the specification will
<        extend the protocol to exchange other
<        information needed to organize the Internet,
<        such as IP address allocations."
<
<
<  I think we are merely *starting* with DNS because of the time
<  constraints of
<  the new TLDs, but the protocol can clearly be extended at a later time to
<  include all kinds of registration environments.  I don't see the problem.
<  (?)
<
<  Paul George
<  SARAF Software Solutions
<
<
<
<  -----Original Message-----
<  From: [email-masked] [mailto:[email-masked]]On
<  Behalf Of James Seng/Personal
<  Sent: Friday, February 02, 2001 7:42 AM
<  To: [email-masked]
<  Cc: Patrik Faltstrom
<  Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)
<
<
<  I would like to object this proposed charter for provreg. Its scope has
<  been so specific defined for DNS only and has no mention of anything
<  beyond DNS.
<
<  I propose shortening the charter and balancing it slightly. If it is out
<  of line, feel free to shoot it.
<
<  ---
<  Registration of Domain Names Service (DNS) involves various objects
<  transfer from multiple Registrars to a back-end Registry database.
<  Conversely, there is a desire to standardized the process allowing
<  multiple Registrars to access multiple Registries database which may
<  differ in operational models. Such registration procotcol has many
<  benefits which may tranverse beyond domain names objects.
<
<  This working group will investigate the requirements for a registration
<  protocol of objects between two or more entities and to developed such a
<  provision protocol that satisfied these requirements.
<
<  The group will consider support for multiple operational choices, such
<  as for transport and security; it will create no new transport or
<  security protocols.  The group may consider use of the new protocol for
<  diverse registration and update scenarios, in order to understand
<  limitations and possible extensions that are appropriate.  Specification
<  for user interface access, such as by a web front end, is beyond the
<  scope of this working group.
<
<  The Action Item(s) for the Working Group are
<
<  1. An Informational RFC specifying the requirements of the Provision
<     Registration protocol.
<
<  2. An Informational RFC specifying the objects exchange during the
<     registration process for the Domain Name; at a minimum includes:
<     domain names, IP address and contact details for registrant.
<
<  3. A Standard RFC specifying the Provision Registration Protocol.
<     This document should have specification for domain names
<     object registration but also include extension capability for
<     non-domain names objects.
<
<  Goals and Milestones:
<
<  ....
<
<  -James Seng
<
<  --- Original Message ---
<  A new IETF working group has been proposed in the Applications Area.
<  The IESG has not made any determination as yet.
<
<  The following Description was submitted, and is provided for
<  informational purposes only:
<
<  Provisioning Registry Protocol (provreg)
<  ----------------------------------------
<
<   Current Status: Proposed Working Group
<
<
<   Mailing Lists:
<       General Discussion:[email-masked]
<       To Subscribe:      [email-masked]
<           In Body:       subscribe ietf-provreg
<       Archive:           http://www.cafax.se/ietf-provreg/maillist/
<
<  Description of Working Group:
<
<  Administration of Domain Name Service (DNS) registration increasingly
<  distinguishes between the operation of a "back-end" registry data base
<  service for registrations, versus "front-end" support services by
<  registrars who interact with registrants and with the registry.
<  Especially for various Top-Level Domains, the desire is to permit
<  multiple registrars to share access to the database.  Conversely, there
<  is a desire to allow a registrar to access multiple registries via the
<  same protocol, even if the registries differ in operational models.
<
<  This working group will develop a specification of the requirements and
<  limitations for a protocol that enables a registrar to access multiple
<  registries and will develop a  protocol that satisfies those
<  requirements. The protocol will permit interaction between a
<  registrar's own application and registry applications.
<
<  The initial specification will allow multiple registrars to register
<  and maintain domain names within multiple Top Level Domains (TLDs). The
<  specification should be flexible enough to support the different
<  operational models of registries.  The specification should allow
<  extension to support other registration data, such as address
<  allocation and contact information. The working group will use as input
<  the "Generic Registry-Registrar Protocol Requirements"
<  (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
<  Protocol presentation, documented in (draft-hollenbeck-epp-nn).
<
<  The group will consider support for multiple operational choices, such
<  as for transport and security; it will create no new transport or
<  security protocols.  The group may consider use of the new protocol for
<  diverse registration and update scenarios, in order to understand
<  limitations and possible extensions that are appropriate.  Specification
<  for user interface access, such as by a web front end, is beyond the
<  scope of this working group.
<
<  Documentation from the working group will:
<
<  * Specify the objects exchanged between the registry repository
<  and registrars, the relationships among the objects, and the protocol
<  for exchanging objects between a registrar and the registry; at a
<  minimum the objects will include:  domain name, IP address, and contact
<  details for registrants
<
<  * Describe appropriate mechanisms for security during registrar access
<
<  * List useful examples of registrar access transactions
<
<

From: "James Seng/Personal" <[email-masked]>
To: "Paul George" <[email-masked]>, <[email-masked]>
Subject: Re: WG Review: Provisioning Registry Protocol (provreg)
Date: Sat, 3 Feb 2001 04:52:52 +0800
Sender: [email-masked]

Not in the charter published by the IESG.

-James Seng

----- Original Message -----
From: "Paul George" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 03, 2001 4:38 AM
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)

> James, I don't understand.  The charter states:
>
>
>      "Subsequent versions of the specification will
>       extend the protocol to exchange other
>       information needed to organize the Internet,
>       such as IP address allocations."
>
>
> I think we are merely *starting* with DNS because of the time
constraints of
> the new TLDs, but the protocol can clearly be extended at a later time
to
> include all kinds of registration environments.  I don't see the
problem.
> (?)
>
> Paul George
> SARAF Software Solutions
>
>
>
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]On
> Behalf Of James Seng/Personal
> Sent: Friday, February 02, 2001 7:42 AM
> To: [email-masked]
> Cc: Patrik Faltstrom
> Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)
>
>
> I would like to object this proposed charter for provreg. Its scope
has
> been so specific defined for DNS only and has no mention of anything
> beyond DNS.
>
> I propose shortening the charter and balancing it slightly. If it is
out
> of line, feel free to shoot it.
>
> ---
> Registration of Domain Names Service (DNS) involves various objects
> transfer from multiple Registrars to a back-end Registry database.
> Conversely, there is a desire to standardized the process allowing
> multiple Registrars to access multiple Registries database which may
> differ in operational models. Such registration procotcol has many
> benefits which may tranverse beyond domain names objects.
>
> This working group will investigate the requirements for a
registration
> protocol of objects between two or more entities and to developed such
a
> provision protocol that satisfied these requirements.
>
> The group will consider support for multiple operational choices, such
> as for transport and security; it will create no new transport or
> security protocols.  The group may consider use of the new protocol
for
> diverse registration and update scenarios, in order to understand
> limitations and possible extensions that are appropriate.
Specification
> for user interface access, such as by a web front end, is beyond the
> scope of this working group.
>
> The Action Item(s) for the Working Group are
>
> 1. An Informational RFC specifying the requirements of the Provision
>    Registration protocol.
>
> 2. An Informational RFC specifying the objects exchange during the
>    registration process for the Domain Name; at a minimum includes:
>    domain names, IP address and contact details for registrant.
>
> 3. A Standard RFC specifying the Provision Registration Protocol.
>    This document should have specification for domain names
>    object registration but also include extension capability for
>    non-domain names objects.
>
> Goals and Milestones:
>
> ....
>
> -James Seng
>
> --- Original Message ---
> A new IETF working group has been proposed in the Applications Area.
> The IESG has not made any determination as yet.
>
> The following Description was submitted, and is provided for
> informational purposes only:
>
> Provisioning Registry Protocol (provreg)
> ----------------------------------------
>
>  Current Status: Proposed Working Group
>
>
>  Mailing Lists:
>      General Discussion:[email-masked]
>      To Subscribe:      [email-masked]
>          In Body:       subscribe ietf-provreg
>      Archive:           http://www.cafax.se/ietf-provreg/maillist/
>
> Description of Working Group:
>
> Administration of Domain Name Service (DNS) registration increasingly
> distinguishes between the operation of a "back-end" registry data base
> service for registrations, versus "front-end" support services by
> registrars who interact with registrants and with the registry.
> Especially for various Top-Level Domains, the desire is to permit
> multiple registrars to share access to the database.  Conversely,
there
> is a desire to allow a registrar to access multiple registries via the
> same protocol, even if the registries differ in operational models.
>
> This working group will develop a specification of the requirements
and
> limitations for a protocol that enables a registrar to access multiple
> registries and will develop a  protocol that satisfies those
> requirements. The protocol will permit interaction between a
> registrar's own application and registry applications.
>
> The initial specification will allow multiple registrars to register
> and maintain domain names within multiple Top Level Domains (TLDs).
The
> specification should be flexible enough to support the different
> operational models of registries.  The specification should allow
> extension to support other registration data, such as address
> allocation and contact information. The working group will use as
input
> the "Generic Registry-Registrar Protocol Requirements"
> (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
> Protocol presentation, documented in (draft-hollenbeck-epp-nn).
>
> The group will consider support for multiple operational choices, such
> as for transport and security; it will create no new transport or
> security protocols.  The group may consider use of the new protocol
for
> diverse registration and update scenarios, in order to understand
> limitations and possible extensions that are appropriate.
Specification
> for user interface access, such as by a web front end, is beyond the
> scope of this working group.
>
> Documentation from the working group will:
>
> * Specify the objects exchanged between the registry repository
> and registrars, the relationships among the objects, and the protocol
> for exchanging objects between a registrar and the registry; at a
> minimum the objects will include:  domain name, IP address, and
contact
> details for registrants
>
> * Describe appropriate mechanisms for security during registrar access
>
> * List useful examples of registrar access transactions
>
>

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Review: Provisioning Registry Protocol (provreg)
Date: Fri, 2 Feb 2001 15:38:13 -0500
Importance: Normal
Sender: [email-masked]

James, I don't understand.  The charter states:

     "Subsequent versions of the specification will
      extend the protocol to exchange other
      information needed to organize the Internet,
      such as IP address allocations."

I think we are merely *starting* with DNS because of the time constraints of
the new TLDs, but the protocol can clearly be extended at a later time to
include all kinds of registration environments.  I don't see the problem.
(?)

Paul George
SARAF Software Solutions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of James Seng/Personal
Sent: Friday, February 02, 2001 7:42 AM
To: [email-masked]
Cc: Patrik Faltstrom
Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)

I would like to object this proposed charter for provreg. Its scope has
been so specific defined for DNS only and has no mention of anything
beyond DNS.

I propose shortening the charter and balancing it slightly. If it is out
of line, feel free to shoot it.

---
Registration of Domain Names Service (DNS) involves various objects
transfer from multiple Registrars to a back-end Registry database.
Conversely, there is a desire to standardized the process allowing
multiple Registrars to access multiple Registries database which may
differ in operational models. Such registration procotcol has many
benefits which may tranverse beyond domain names objects.

This working group will investigate the requirements for a registration
protocol of objects between two or more entities and to developed such a
provision protocol that satisfied these requirements.

The group will consider support for multiple operational choices, such
as for transport and security; it will create no new transport or
security protocols.  The group may consider use of the new protocol for
diverse registration and update scenarios, in order to understand
limitations and possible extensions that are appropriate.  Specification
for user interface access, such as by a web front end, is beyond the
scope of this working group.

The Action Item(s) for the Working Group are

1. An Informational RFC specifying the requirements of the Provision
   Registration protocol.

2. An Informational RFC specifying the objects exchange during the
   registration process for the Domain Name; at a minimum includes:
   domain names, IP address and contact details for registrant.

3. A Standard RFC specifying the Provision Registration Protocol.
   This document should have specification for domain names
   object registration but also include extension capability for
   non-domain names objects.

Goals and Milestones:

....

-James Seng

--- Original Message ---
A new IETF working group has been proposed in the Applications Area.
The IESG has not made any determination as yet.

The following Description was submitted, and is provided for
informational purposes only:

Provisioning Registry Protocol (provreg)
----------------------------------------

 Current Status: Proposed Working Group

 Mailing Lists:
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
         In Body:       subscribe ietf-provreg
     Archive:           http://www.cafax.se/ietf-provreg/maillist/

Description of Working Group:

Administration of Domain Name Service (DNS) registration increasingly
distinguishes between the operation of a "back-end" registry data base
service for registrations, versus "front-end" support services by
registrars who interact with registrants and with the registry.
Especially for various Top-Level Domains, the desire is to permit
multiple registrars to share access to the database.  Conversely, there
is a desire to allow a registrar to access multiple registries via the
same protocol, even if the registries differ in operational models.

This working group will develop a specification of the requirements and
limitations for a protocol that enables a registrar to access multiple
registries and will develop a  protocol that satisfies those
requirements. The protocol will permit interaction between a
registrar's own application and registry applications.

The initial specification will allow multiple registrars to register
and maintain domain names within multiple Top Level Domains (TLDs). The
specification should be flexible enough to support the different
operational models of registries.  The specification should allow
extension to support other registration data, such as address
allocation and contact information. The working group will use as input
the "Generic Registry-Registrar Protocol Requirements"
(draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
Protocol presentation, documented in (draft-hollenbeck-epp-nn).

The group will consider support for multiple operational choices, such
as for transport and security; it will create no new transport or
security protocols.  The group may consider use of the new protocol for
diverse registration and update scenarios, in order to understand
limitations and possible extensions that are appropriate.  Specification
for user interface access, such as by a web front end, is beyond the
scope of this working group.

Documentation from the working group will:

* Specify the objects exchanged between the registry repository
and registrars, the relationships among the objects, and the protocol
for exchanging objects between a registrar and the registry; at a
minimum the objects will include:  domain name, IP address, and contact
details for registrants

* Describe appropriate mechanisms for security during registrar access

* List useful examples of registrar access transactions

Date: Fri, 2 Feb 2001 15:22:21 -0500
To: "James Seng" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 3:02 PM -0500 2/2/01, James Seng wrote:
>It also have references to Scott Hollenback I-Ds. While Scott have good
>I-Ds, referencing it to the WG charter is IMHO a bad idea. It will
>discourage others to come forward with their proposal.

The updated charter does not reference the drafts.  Below is the latest
one.  I don't know whether the charter below will replace the one on the
ietf-announce list, but in any case, I certainly agree that the references
to the drafts should be removed.

>If the WG intention is only to reach a point whereby it is a DNS
>specific registration protocol, as description in the charter which you
>submit to the IESG, I will put up a motion *AGAINST* the formation of
>this WG at all.

I doubt that the intention of the participants in the WG is to only go so
far as a DNS registration protocol.  I was just mentioning that as a
possibility.  The IESG has final say on the scope of the WG.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Provisioning Registry Protocol (ProvReg)

-------------------------------

  CHAIR(S):
         Edward Lewis <[email-masked]>
         Jaap Akkerhuis <[email-masked]>

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström <[email-masked]>
         Ned Freed <[email-masked]>

  AREA ADVISOR:
         Patrik Fältström <[email-masked]>

  MAILING LISTS:
  General Discussion: [email-masked]
  To Subscribe: [email-masked]
    In Body: subscribe ietf-provreg
  Archive: http://www.cafax.se/ietf-provreg/maillist/

DESCRIPTION OF WORKING GROUP:

Administration of Domain Name Service (DNS) registration increasingly
distinguishes between the operation of a "back-end" registry data base
service for registrations, versus "front-end" support services by
registrars who interact with registrants and with the registry.  Especially
for various Top-Level Domains, the desire is to permit multiple registrars
to share access to the database.  Conversely, there is a desire to allow a
registrar to access multiple registries via the same protocol, even if the
registries differ in operational models.

This working group will develop a specification of the requirements and
limitations for a protocol that enables a registrar to access multiple
registries and will develop a protocol that satisfies those requirements.
The protocol will permit interaction between a registrar's own application
and registry applications.

The initial specification will allow multiple registrars to register and
maintain domain names within multiple Top Level Domains (TLDs).  Subsequent
versions of the specification will extend the protocol to exchange other
information needed to organize the Internet, such as IP address allocations.
The specification should be flexible enough to support the different
operational models of registries.  The specification should allow extension
to support other registration data, such as address allocation and contact
information.

The group will consider support for multiple operational choices, such as
for transport and security; it will create no new transport or security
protocols.  The group may consider use of the new protocol for diverse
registration and update scenarios, in order to understand limitations and
possible extensions that are appropriate.  Specification for user interface
access, such as by a web front end, is beyond the scope of this working group.

Documentation from the working group will:

*       Specify the objects exchanged between the registry repository and
registrars, the relationships among the objects, and the protocol for
exchanging objects between a registrar and the registry; at a minimum the
objects will include: domain name, IP address, and contact details for
registrants

*       Describe appropriate mechanisms for security during registrar access,
including authentication and authoriztion of the participants, confidentiality
of data where needed and allowed

*       List useful examples of registrar access transactions

GOALS AND MILESTONES:
Jan, 2001       WG charter

Feb, 2001       Working group agreement on functional requirements for protocol

Apr, 2001       Initial specification of provreg protocol

Jun, 2001       Second draft specification

Sep, 2001       Submit draft for standards track

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Fri, 2 Feb 2001 14:50:58 -0500
To: "James Seng/Personal" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Cc: <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Sender: [email-masked]

At 7:41 AM -0500 2/2/01, James Seng/Personal wrote:
>I would like to object this proposed charter for provreg. Its scope has
>been so specific defined for DNS only and has no mention of anything
>beyond DNS.

The most recent charter I sent upwards is slightly different than that
distributed.  In particular, the newer charter has this text:

>The initial specification will allow multiple registrars to register and
>maintain domain names within multiple Top Level Domains (TLDs).  Subsequent
>versions of the specification will extend the protocol to exchange other
>information needed to organize the Internet, such as IP address allocations.

The first sentence is old, I left it in for context.  The second sentence
should already address your concerns.

I think that there are a few goals of the proposed WG:
   1) Make a mechanism for registrar-registry exchange of domain name info
      in the short term.
   2) Make the mechanism extensible for other regsitration information.

I think the agenda before the IESG already addresses these issues.

A note on charters.  The purpose of the charter is to set the scope of the
effort, not to judge the quality of the effort.  It is possible that this
WG only arrives at the initial specification, that is a mechanism that is
DNS specific (but extensible).  A follow-on working group might be formed
to handle the next set of specifications.  It is also possible this
proto-WG's charter is amended as we approach the initial goal to include
the extensions.  IETF WG's are not intended to be long term.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Fri, 2 Feb 2001 09:36:37 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: James Seng/Personal <[email-masked]>
cc: [email-masked], Patrik Faltstrom <[email-masked]>
Subject: Re: Fw: WG Review: Provisioning Registry Protocol (provreg)
Sender: [email-masked]

I like this new charter; I think it is more clear than the original and
more readable.

Aren't we too far along in the process (ie we've already submitted the
charter to  IETF for approval) to try and change the charter now?

Sheer

On Fri, 2 Feb 2001, James Seng/Personal wrote:

> I would like to object this proposed charter for provreg. Its scope has
> been so specific defined for DNS only and has no mention of anything
> beyond DNS.
> 
> I propose shortening the charter and balancing it slightly. If it is out
> of line, feel free to shoot it.
> 
> ---
> Registration of Domain Names Service (DNS) involves various objects
> transfer from multiple Registrars to a back-end Registry database.
> Conversely, there is a desire to standardized the process allowing
> multiple Registrars to access multiple Registries database which may
> differ in operational models. Such registration procotcol has many
> benefits which may tranverse beyond domain names objects.
> 
> This working group will investigate the requirements for a registration
> protocol of objects between two or more entities and to developed such a
> provision protocol that satisfied these requirements.
> 
> The group will consider support for multiple operational choices, such
> as for transport and security; it will create no new transport or
> security protocols.  The group may consider use of the new protocol for
> diverse registration and update scenarios, in order to understand
> limitations and possible extensions that are appropriate.  Specification
> for user interface access, such as by a web front end, is beyond the
> scope of this working group.
> 
> The Action Item(s) for the Working Group are
> 
> 1. An Informational RFC specifying the requirements of the Provision
>    Registration protocol.
> 
> 2. An Informational RFC specifying the objects exchange during the
>    registration process for the Domain Name; at a minimum includes:
>    domain names, IP address and contact details for registrant.
> 
> 3. A Standard RFC specifying the Provision Registration Protocol.
>    This document should have specification for domain names
>    object registration but also include extension capability for
>    non-domain names objects.
> 
> Goals and Milestones:
> 
> ....
> 
> -James Seng
> 
> --- Original Message ---
> A new IETF working group has been proposed in the Applications Area.
> The IESG has not made any determination as yet.
> 
> The following Description was submitted, and is provided for
> informational purposes only:
> 
> Provisioning Registry Protocol (provreg)
> ----------------------------------------
> 
>  Current Status: Proposed Working Group
> 
> 
>  Mailing Lists:
>      General Discussion:[email-masked]
>      To Subscribe:      [email-masked]
>          In Body:       subscribe ietf-provreg
>      Archive:           http://www.cafax.se/ietf-provreg/maillist/
> 
> Description of Working Group:
> 
> Administration of Domain Name Service (DNS) registration increasingly
> distinguishes between the operation of a "back-end" registry data base
> service for registrations, versus "front-end" support services by
> registrars who interact with registrants and with the registry.
> Especially for various Top-Level Domains, the desire is to permit
> multiple registrars to share access to the database.  Conversely, there
> is a desire to allow a registrar to access multiple registries via the
> same protocol, even if the registries differ in operational models.
> 
> This working group will develop a specification of the requirements and
> limitations for a protocol that enables a registrar to access multiple
> registries and will develop a  protocol that satisfies those
> requirements. The protocol will permit interaction between a
> registrar's own application and registry applications.
> 
> The initial specification will allow multiple registrars to register
> and maintain domain names within multiple Top Level Domains (TLDs). The
> specification should be flexible enough to support the different
> operational models of registries.  The specification should allow
> extension to support other registration data, such as address
> allocation and contact information. The working group will use as input
> the "Generic Registry-Registrar Protocol Requirements"
> (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
> Protocol presentation, documented in (draft-hollenbeck-epp-nn).
> 
> The group will consider support for multiple operational choices, such
> as for transport and security; it will create no new transport or
> security protocols.  The group may consider use of the new protocol for
> diverse registration and update scenarios, in order to understand
> limitations and possible extensions that are appropriate.  Specification
> for user interface access, such as by a web front end, is beyond the
> scope of this working group.
> 
> Documentation from the working group will:
> 
> * Specify the objects exchanged between the registry repository
> and registrars, the relationships among the objects, and the protocol
> for exchanging objects between a registrar and the registry; at a
> minimum the objects will include:  domain name, IP address, and contact
> details for registrants
> 
> * Describe appropriate mechanisms for security during registrar access
> 
> * List useful examples of registrar access transactions
> 

From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>
Cc: "Patrik Faltstrom" <[email-masked]>
Subject: Fw: WG Review: Provisioning Registry Protocol (provreg)
Date: Fri, 2 Feb 2001 20:41:45 +0800
Sender: [email-masked]

I would like to object this proposed charter for provreg. Its scope has
been so specific defined for DNS only and has no mention of anything
beyond DNS.

I propose shortening the charter and balancing it slightly. If it is out
of line, feel free to shoot it.

---
Registration of Domain Names Service (DNS) involves various objects
transfer from multiple Registrars to a back-end Registry database.
Conversely, there is a desire to standardized the process allowing
multiple Registrars to access multiple Registries database which may
differ in operational models. Such registration procotcol has many
benefits which may tranverse beyond domain names objects.

This working group will investigate the requirements for a registration
protocol of objects between two or more entities and to developed such a
provision protocol that satisfied these requirements.

The group will consider support for multiple operational choices, such
as for transport and security; it will create no new transport or
security protocols.  The group may consider use of the new protocol for
diverse registration and update scenarios, in order to understand
limitations and possible extensions that are appropriate.  Specification
for user interface access, such as by a web front end, is beyond the
scope of this working group.

The Action Item(s) for the Working Group are

1. An Informational RFC specifying the requirements of the Provision
   Registration protocol.

2. An Informational RFC specifying the objects exchange during the
   registration process for the Domain Name; at a minimum includes:
   domain names, IP address and contact details for registrant.

3. A Standard RFC specifying the Provision Registration Protocol.
   This document should have specification for domain names
   object registration but also include extension capability for
   non-domain names objects.

Goals and Milestones:

....

-James Seng

--- Original Message ---
A new IETF working group has been proposed in the Applications Area.
The IESG has not made any determination as yet.

The following Description was submitted, and is provided for
informational purposes only:

Provisioning Registry Protocol (provreg)
----------------------------------------

 Current Status: Proposed Working Group

 Mailing Lists:
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
         In Body:       subscribe ietf-provreg
     Archive:           http://www.cafax.se/ietf-provreg/maillist/

Description of Working Group:

Administration of Domain Name Service (DNS) registration increasingly
distinguishes between the operation of a "back-end" registry data base
service for registrations, versus "front-end" support services by
registrars who interact with registrants and with the registry.
Especially for various Top-Level Domains, the desire is to permit
multiple registrars to share access to the database.  Conversely, there
is a desire to allow a registrar to access multiple registries via the
same protocol, even if the registries differ in operational models.

This working group will develop a specification of the requirements and
limitations for a protocol that enables a registrar to access multiple
registries and will develop a  protocol that satisfies those
requirements. The protocol will permit interaction between a
registrar's own application and registry applications.

The initial specification will allow multiple registrars to register
and maintain domain names within multiple Top Level Domains (TLDs). The
specification should be flexible enough to support the different
operational models of registries.  The specification should allow
extension to support other registration data, such as address
allocation and contact information. The working group will use as input
the "Generic Registry-Registrar Protocol Requirements"
(draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning
Protocol presentation, documented in (draft-hollenbeck-epp-nn).

The group will consider support for multiple operational choices, such
as for transport and security; it will create no new transport or
security protocols.  The group may consider use of the new protocol for
diverse registration and update scenarios, in order to understand
limitations and possible extensions that are appropriate.  Specification
for user interface access, such as by a web front end, is beyond the
scope of this working group.

Documentation from the working group will:

* Specify the objects exchanged between the registry repository
and registrars, the relationships among the objects, and the protocol
for exchanging objects between a registrar and the registry; at a
minimum the objects will include:  domain name, IP address, and contact
details for registrants

* Describe appropriate mechanisms for security during registrar access

* List useful examples of registrar access transactions

To: [email-masked]
Subject: Mail bounces.
From: Lars-Johan Liman <[email-masked]>
Date: Fri, 02 Feb 2001 12:40:10 +0100
Lines: 17
Sender: [email-masked]

Due to a new kind of paranoia in the latest version of sendmail, the
mailserver for the DNSOP maillist bounced a few messages during the
last 24 h.

If you sent a message, and either received a bounce message, or can't
find it in the mail archive
http://www.cafax.se/ietf-provreg/maillist/, then please re-send.

Sorry.

				Best regards,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman		! E-mail: [email-masked]
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------

From: "Brian W. Spolarich" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Unique handle (was RE: Merging RRP and Whois)
Date: Thu, 1 Feb 2001 09:08:37 -0500
Importance: Normal
Sender: [email-masked]

| >  Dumb question:  Instead of inventing new identifiers or bending
| > existing ones in perhaps ungraceful ways, why not use a URL as the
| > identifier?
|
| As with email, I've had URL which is not active anymore.
| (Actually, it is now owned by somebody else!)
| How do you authenticate the owner of a URL?
| I have a domain (thus the URL) that does not belong to me
| anymore.

  Sorry if I was unclear.  I wasn't talking about a URL in the sense of
something you (necessarily) type in your web browser.  I was thinking a bit
more generically of using an existing identifier scheme instead of inventing
a new one.

  If you were do to provreg on top of LDAP you could do something like:

ldap://registry.internic.net/cn=Brian%20W.%20Spolarich,o=WALID,%20Inc.,c=US

  according to RFC2255.  The escaped spaces are ugly, but ohwell.

  Authenticating to the provreg service can be handled by any of the
established means:  x.509 certs, PGP keys, passwords, or whatever.

  As Bill Manning points out, there are a lot of broad shoulders to stand on
here.

  -bws

From: Bill Manning <[email-masked]>
Subject: Re: Unique "Handles"?
To: [email-masked]
Date: Wed, 31 Jan 2001 15:05:27 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked], [email-masked]
Sender: [email-masked]

% 
% On 30 Jan 01, at 15:42, Bill Manning wrote:
% 
% > 	Er... not really. I've had email addresses that
% > 	have been revolked and reassigned to new people.
% > 	Email addresses are not the persistant indentifer 
% > 	you are looking for. 
% 
% That's ok, Bill. All you have to do is change/modify/
% update your (nic) handle / identifier.
% (Just like updating a host/NS record in the database.)
% Note: how long does it have to be presistant?

	Er, how does the registrar know that I am me
	if I can't validate myself since the email "handle"
	no longer works?

% Or... we can go with a digital certificate.
% (That may be too complicate since some countries may
% restrict access to certain cryptography algorithms.)
% 
% Or ... find something else.

	Like a PGP key... :)

% 
% 
% -- budi
% --
% Homepage: <http://budi.insan.co.id>
% my presentation materials, papers, scrapbook, ... and more
% What's your "web.id"? Register your web.id @ http://www.idnic.net.id
% 

-- 
--bill

From: Bill Manning <[email-masked]>
Subject: Re: Interim Meeting Reminder
To: [email-masked] (Edward Lewis)
Date: Wed, 31 Jan 2001 13:35:15 -0800 (PST)
Cc: [email-masked] ([email-masked]'), [email-masked]
Sender: [email-masked]

 As long as we are still very much in the requirements definition phases
of this stuff, I'd like to think that we can "stand on the shoulders"
of others prior art.

	NSIs work (Thanks Scott)
	The RIPE/RA work (cast'o'hundreds)
	rwhois (thanks scott & mark)
	dns (cast'o'thousands)
	
and perhaps some stuff folks have not considered:

	rescap
	idn (dns-wise)

Just a couple of thoughts.

-- 
--bill

Subject: Antwort: Unique handle (was RE: Merging RRP and Whois)
To: [email-masked]
From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" <[email-masked]>
Date: Thu, 1 Feb 2001 10:33:03 +0100
Sender: [email-masked]

On 01.02.2001 00:07 [email-masked] wrote:
>
> >  Dumb question:  Instead of inventing new identifiers or bending
> > existing ones in perhaps ungraceful ways, why not use a URL as the
> > identifier?
>
> As with email, I've had URL which is not active anymore.
> (Actually, it is now owned by somebody else!)
> How do you authenticate the owner of a URL?
> I have a domain (thus the URL) that does not belong to me
> anymore.

What do you thinks of URN´s (not yet a full standart, as far as i know)

something like
     urn:registry:whois.denic.de:person:joerg_bauer

with the following meenings:
urn:registry:      Namespace for registries
whois.denic.de:    Whois information to the object
person:            type of object
joerg_bauer:    identifier inside the registry

I know that with this approach i´m again mixing rrp and whois.
Maybe it is an better idea to say rrp.denic.de for an interface to rrp.

--
----------------------------------+-------------------------------------------

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-------------------------------------------

From: [email-masked]
To: <[email-masked]>
Date: Thu, 1 Feb 2001 06:07:49 +0700
Subject: Unique handle (was RE: Merging RRP and Whois)
Sender: [email-masked]

>  Dumb question:  Instead of inventing new identifiers or bending
> existing ones in perhaps ungraceful ways, why not use a URL as the
> identifier?  

As with email, I've had URL which is not active anymore.
(Actually, it is now owned by somebody else!)
How do you authenticate the owner of a URL?
I have a domain (thus the URL) that does not belong to me
anymore.

I still think that using email address as *part of* [NIC] handle
(not the whole handle) is a good idea.
If you change your email address, that's ok
as long as that handle is associated with the new address.
It's just a string right?

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: [email-masked]
To: Bill Manning <[email-masked]>
Date: Thu, 1 Feb 2001 06:07:49 +0700
Subject: Re: Unique "Handles"?
CC: [email-masked], [email-masked]
Sender: [email-masked]

On 30 Jan 01, at 15:42, Bill Manning wrote:

> 	Er... not really. I've had email addresses that
> 	have been revolked and reassigned to new people.
> 	Email addresses are not the persistant indentifer 
> 	you are looking for. 

That's ok, Bill. All you have to do is change/modify/
update your (nic) handle / identifier.
(Just like updating a host/NS record in the database.)
Note: how long does it have to be presistant?

If you are acting as a role, eg. using [email-masked]
then you want to delegate the role to the new hostmaster,
don't you?

Our original concern was to have a unique identifier
that spans to many databases (so that we avoid clashes), no?
The possibility to have identifiers clash can be reduced.

So my unique handle maybe 
"budi.alliance.globalnetlink.com.budi.rahardjo.indonesia"
(email adress is *part of* unique handle)
My beef...: it's too long! But then again, it might
be easier to memorize than BR#72X%$@! ;-)
Maybe we don't have to memorize it either.

Or... we can go with a digital certificate.
(That may be too complicate since some countries may
restrict access to certain cryptography algorithms.)

Or ... find something else.

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id