Subject: RE: Presentation of Ed Lewis
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Geva Patz'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Sat, 30 Dec 2000 20:23:34 -0500

Isn't breadth of perspective something that we as WG can ensure?  We've been
moving along quite well for the last two weeks before Patrik introduced Ed.
Personally, I think it's a good idea to have a chair whose background isn't
closely aligned with any particular registry or registrar model.

Scott Hollenbeck
VeriSign Global Registry Services 

-----Original Message-----
From: Geva Patz [mailto:[email-masked]]
Sent: Saturday, December 30, 2000 12:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Presentation of Ed Lewis

On Sat, Dec 30, 2000 at 05:39:02PM +0100, Patrik Fältström wrote:

Patrik,

> I just want you to know that I as AD has accepted the proposal from 
> Ed that he become the proposed chair in the draft charter which you 
> are working on on this mailing list.

I have no problem at all with this, but I would suggest (subject,
of course, to the availaibilty of volunteers) that a co-chair be 
nominated with a background in the ccTLDs, too. As I mentioned at the
BOF, and as a couple of posters have mentioned on the list, there's a
broader range of issues out there that don't necessarily manifset themselves
in the current crop of gTLDs (most of which run along similar or identical
lines). It's important (in my view, at least; and, it would seem, in the
view of a number of others) to make sure that any standard that our work
ends up producing has broad applicability across the Internet. 

I'd therefore really like to see a co-chair with ccTLD background who
can help ensure that the WG stays on track with a broader focus.
This isn't in any way meant to be a slight against Ed or his ability
as potential chair, but I do believe that breadth of perspective would
be very useful here.

Volunteers, anyone? :)

-- Geva

Date: Sat, 30 Dec 2000 21:49:21 +0100
To: Geva Patz <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Presentation of Ed Lewis
Sender: [email-masked]

At 12.55 -0500 00-12-30, Geva Patz wrote:
>I have no problem at all with this, but I would suggest (subject,
>of course, to the availaibilty of volunteers) that a co-chair be
>nominated with a background in the ccTLDs, too.

Sure, if that is the wish of the community.

I wanted though to mention that Ed, and none of the co-chairs of the 
BOF, is the one that for now (at least) is the one which will 
announce what he think is consensus of this mailing list.

    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-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Sat, 30 Dec 2000 12:55:04 -0500
From: Geva Patz <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Presentation of Ed Lewis
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Sat, Dec 30, 2000 at 05:39:02PM +0100, Patrik Fältström wrote:

Patrik,

> I just want you to know that I as AD has accepted the proposal from 
> Ed that he become the proposed chair in the draft charter which you 
> are working on on this mailing list.

I have no problem at all with this, but I would suggest (subject,
of course, to the availaibilty of volunteers) that a co-chair be 
nominated with a background in the ccTLDs, too. As I mentioned at the
BOF, and as a couple of posters have mentioned on the list, there's a
broader range of issues out there that don't necessarily manifset themselves
in the current crop of gTLDs (most of which run along similar or identical
lines). It's important (in my view, at least; and, it would seem, in the
view of a number of others) to make sure that any standard that our work
ends up producing has broad applicability across the Internet. 

I'd therefore really like to see a co-chair with ccTLD background who
can help ensure that the WG stays on track with a broader focus.
This isn't in any way meant to be a slight against Ed or his ability
as potential chair, but I do believe that breadth of perspective would
be very useful here.

Volunteers, anyone? :)

-- Geva

Date: Sat, 30 Dec 2000 17:39:02 +0100
To: <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Presentation of Ed Lewis
Sender: [email-masked]

I just want you to know that I as AD has accepted the proposal from 
Ed that he become the proposed chair in the draft charter which you 
are working on on this mailing list.

Ed is because of that the person which will try to get the charter 
more specific and submitted to myself.

Given that you all accept him of course.

    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-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Sat, 30 Dec 2000 11:34:02 -0500
To: Edward Lewis <[email-masked]>, "Christopher Ambler" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: Draft provreg charter
Cc: <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:39 PM 12/29/2000 -0500, Edward Lewis wrote:
>The effort to define a generic registrar registry protocol has been
>underway for some time now, seeking input from various groups.  Little or
>no interest has been expressed until now, hence the compressed schedule
>presented in the charter.  Interest and attendence at the BOF meeting in
>San Diego was much greater than anticipated.

Well IMHO it was totally expected... what possible interest would there be 
in a generic RRP if there were no new TLD's issued?  The progressive 
members ccTLD community has been waiting for this as well ..timing is 
everything and the critical mass now exists.

>Although the hope is that the existing documents are in good shape, the
>desire is to generate a protocol that is beneficial to all involved and in
>a timely manner.  Although we would like to have quick results, arriving at
>a solid protocol is more important than the schedule.

Well I'm not sure I agree here.. there is a genuine dilemma here caused by 
ICANN process <suprise>. Whereas it is clear that there was no critical 
mass for a XRRP until new TLD's were issued but now there is a serious 
problem of time to market among the new registry entrants and the desire of 
the registrar community NOT to have competing standards out there.

That is just as important as a solid protocol...and the business of our 
registrars will be seriously impaired if we have multiple proposals out 
there or we stall and delay.

>  Bare in mind that
>delays in achieving the protocol specification may have an impact on the
>registry to registrar business model for some time.

Well I don't know about your business model but that is unacceptable to 
mine. I cant speak for my TUCOWS friends but I cant imagine they want this 
process dragged out.

  We cant have any delays here for any number of reasons including the 
public expatiation that these new TLD's have been created and need to be 
put in place and the need to prove to ICANN  that the "proof of concept" 
will work.

>With this in mind, what is the feeling about:
>Apr, 2001       WG agreement on functional requirements for protocol
>May, 2001       Initial specification of provreg protocol

I would accelerate this to Requirements by Feb , by April have the 
specification ready and by IETF 50 we think about wraping things up.

>This allows for a face to face meeting at the next IETF (providing the WG
>is formed) before the deadline for the two documents.  But, please,
>continue to provide comments on the existing documents in a timely fashion.

Well I'm going to propose that we discuss with our Area Director Patrik the 
possibility of some off-site meetings to accelerate the requirements and 
design process. This is standard procedure within the  IETF when a 
consensus within the WG exists that such meetings are necessary. The list 
is always the central focus of the WG but such off sites have the advantage 
of focusing attention on the problem among a highly motivated group of 
participants. These meetings have worked with great success in the past and 
given the unique situation here and the market pressures for new registries 
to be up and running is a short period of time I believe this is a good idea.

The reason I'm suggesting this is my belief that there is already rough 
consensus on what this protocol looks like (transport a XML something) and 
the core problems are defining the schemas , preparing them for an IANA 
registration procedure ( see  draft-mealling-iana-xmlns-registry-00.txt) , 
and deciding on a transport and security model ( I favor BEEP) since I'm 
sure no one wants to invent a new transport or security model for this.

Extensibility in this model is achieved by the abstraction of the XML 
objects from the transport layer and the detailed description of the 
business rules associated with the XML objects. Clearly the business rules 
for TLD registration would be different from IP address requests, telephone 
numbers or teachers accessing a registry of student records etc.

Indeed there may be different business rules between TLD registries. Our 
colleagues at .DE have been correct to point out that what is required for 
a gTLD is not necessarily what is needed by a ccTLD.  European privacy 
rules being what they are. Indeed the requirements for .COM registration 
might change over time as new gTLD are issued and Verisign looks to "add 
value" in new ways. Such value adds would eventually be reflected in the 
"extensible" registration procedure.

So .. even though the WG has not been approved and we are still debating 
charter and requirements issues ..is there interest in some structured 
off-site meetings?   Washington DC perhaps :-)

Date: Sat, 30 Dec 2000 10:18:16 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Patrik Fältström'" <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
From: André Cormier <[email-masked]>
Subject: RE: My personal comments on the requirements.
Sender: [email-masked]

Sorry for the late reply, i am away for the holliday and it is difficult to 
read my mail often.

At 12:07 2000-12-27 -0500, Hollenbeck, Scott wrote:
>OK then, how about leaving 9-[1] as-is to cover domain and host names and
>adding a new requirement for internationalized meta-data:
>
>[2] The protocol MUST allow exchange of meta-data associated with objects in
>formats consistent with current internationalized character encoding
>standards.

I think this would be fine.

>Scott Hollenbeck
>VeriSign Global Registry Services
>
>-----Original Message-----
>From: Patrik Fältström [mailto:[email-masked]]
>Sent: Tuesday, December 26, 2000 2:09 PM
>To: AndrÈ Cormier; Provreg (E-mail)
>Subject: Re: My personal comments on the requirements.
>
>
>At 13.49 -0500 00-12-22, AndrÈ Cormier wrote:
> >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.
> >   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.
> >   Support for internationalized host and domain names will greatly
> >   increase world-wide usability of a generic registry registrar
> >   protocol, so standards for internationalized host and domain names
> >   MUST be considered during the protocol design process.
> >AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable
> >AC: the use of internationalized data.
>
>The information in section 9 should be syncronized with what happens
>in the IDN working group -- BUT, I would like to differ between two
>different types of data:
>
>    - The Domain Names themselves
>    - Other meta-data which goes along with the domainname, such as the
>      street address of the admin contact etc, which can include not only
>      non-ascii characters but also the address in a different format than
>      what is default by the registry. Example: Street name and number is
>      in the US written as "<number> <street name>" while in Sweden the
>      order is the inverse "<street name> <number>".
>
>To start with, the meta information should be able to be both in
>"english" ascii and in the native characters using Unicode, but the
>domainname definition should wait for the IDN definition (it might be
>that the domainname should be in some ACE encoding, already
>nameprepped -- or equivalent).
>
>    paf

______________________________________________________________________
André Cormier                     | Téléphone : (418) 656-9254
2875 boul. Laurier                | Télécopie : (418) 266-5539
Bureau 300                        |
Sainte-Foy, (Québec) G1V 2M2      | [email-masked]
Canada                            | Radio : VA2UNX, VA2ACE
----------------------------------------------------------------------
Internet Engineering Standards/Normes d'ingénierie Internet
                 http://www.normos.org
----------------------------------------------------------------------
PGP: D434 547D 712A E44F C978  4673 BD50 A248 C262 CB06

Date: Fri, 29 Dec 2000 16:39:03 -0500
To: "Christopher Ambler" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Draft provreg charter
Cc: <[email-masked]>, [email-masked]
Sender: [email-masked]

The effort to define a generic registrar registry protocol has been
underway for some time now, seeking input from various groups.  Little or
no interest has been expressed until now, hence the compressed schedule
presented in the charter.  Interest and attendence at the BOF meeting in
San Diego was much greater than anticipated.

Although the hope is that the existing documents are in good shape, the
desire is to generate a protocol that is beneficial to all involved and in
a timely manner.  Although we would like to have quick results, arriving at
a solid protocol is more important than the schedule.  Bare in mind that
delays in achieving the protocol specification may have an impact on the
registry to registrar business model for some time.

With this in mind, what is the feeling about:
Apr, 2001       WG agreement on functional requirements for protocol
May, 2001       Initial specification of provreg protocol

This allows for a face to face meeting at the next IETF (providing the WG
is formed) before the deadline for the two documents.  But, please,
continue to provide comments on the existing documents in a timely fashion.

At 2:40 AM -0500 12/29/00, Christopher Ambler wrote:
>Less than a month to go from a functional req to an initial spec? Are you
>being
>optimistic, or presuming that the initial spec won't stray much from the
>existing one, hence a shorter timeframe?

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

"It takes years of training to know when to do nothing" - Dogbert

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: Draft provreg charter
Date: Thu, 28 Dec 2000 23:40:53 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

>The specification will allow multiple registrars to register domain names 
>within a single Top Level Domain (TLD). The working group will use as input 
>the Extensible Provisioning Protocol presentation, documented in 
><draft-hollenbeck-epp-00.txt>.

Suggest that in addition to "register," we also call out "modify, delete, ...?"

Additionally, I think the specification that it is within a single TLD is already
obsolete, as the operating NSI system allows for more than one, no?

>Feb, 2001       Working group agreement on functional requirements for protocol
>Feb, 2001       Initial specification of provreg protocol

Less than a month to go from a functional req to an initial spec? Are you being
optimistic, or presuming that the initial spec won't stray much from the
existing one, hence a shorter timeframe?

Christopher

Date: Wed, 27 Dec 2000 13:36:27 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Karl Auerbach'" <[email-masked]>, [email-masked]
From: Richard Shockey <[email-masked]>
Subject: RE: Comments on overall direction
Sender: [email-masked]

At 09:23 AM 12/27/2000 -0500, Hollenbeck, Scott wrote:
>While I know of at least one company that would be thrilled to see
>requirements for millions of domain name owners to become PKI-capable (or
>even just the subset who wish to request transfers),

I bet :-)

>  I have to echo the
>point raised by Dave concerning deployment and adoption.  I'm sure there are
>domain name holders who would understand and welcome such developments, but
>people aren't exactly falling over each other to install applications that
>provide cryptographic services.
>
>I don't disagree that transactional integrity is essential, but we may have
>different ideas on where that integrity service needs to be available or
>applied.  I believe that we have a far better chance to produce a widely
>accepted protocol if we do our best to keep the protocol itself extremely
>simple, and using a layered approach to add services that make sense in
>particular operational environments.
>
>Scott Hollenbeck
>VeriSign Global Registry Services

I just want to echo my agreement with Scott here.. I think he and Dave are 
correct here.

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

Date: Wed, 27 Dec 2000 13:33:51 -0500
To: =?iso-8859-1?Q?Andr=E9?= Cormier <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: My personal comments on the requirements.
Sender: [email-masked]

>>
>>[SAH] I don't have a problem with the basic idea here, but I'd like to
>>suggest that this doesn't need to be a MUST in the protocol itself.  Other
>>layers can do this as well; for example, BEEP offers just such a negotiation
>>mechanism and I think it would be overkill to do the negotiation within both
>>BEEP and another application layer protocol.  Would this re-wording be
>>acceptable?:
>
>[AC]Yes it would be overkill to do it in both BEEP and the protocol. But i 
>still think it should be part of the requirements. If BEEP is used with 
>the proposed protocol than BEEP will meet the negociation requirement. If 
>BEEP is not used, the protocol should include this kind of negociation.
>
>What do you think ?

Well I think you are correct... and that is one reason I would encourage us 
to look at the BEEP framework as the transport for this protocol 
application ..though I'm told there may be some limitations on its use 
during the pre-sale search mechanism that puts heavy stress on the registry.

>>"[3] The protocol or another layered protocol MUST provide services to
>>negotiate an authentication mechanism acceptable to both the server and the
>>client."
>>
>>I don't think the advertisement requirement is necessary if the mechanism
>>must be negotiated.  Some kind of information exchange has to happen as part
>>of the negotiation process.

BEEP offers this as a option ..another reason to consider its adoption ...

>>[SAH] Can you be more specific about the purpose of this new field?  I'd
>>much prefer to enumerate required information vs. providing some kind of
>>unformatted registry-specific field.
>
>[AC] For each objects, registries may require additionnal fields. I'd like 
>to see what other ccTLDs or gTLDs needs for the contact object or for 
>other objects. I do not say that the objects are incomplete but i think 
>that it should not be too restrictive. This way if such a need arise, than 
>the protocol will not need an update to support a new field for the 
>contact object.

I'd like to see some additional information on what registries are thinking 
about this. I'm beginning to believe that certain registries may have 
different requirements than others. The needs of .de are clearly different 
from .com or .biz for that matter ..this goes to extensibility again.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, =?iso-8859-1?Q?Andr=C8_Cormier?= <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
Subject: RE: My personal comments on the requirements.
Date: Wed, 27 Dec 2000 12:07:25 -0500
Sender: [email-masked]

OK then, how about leaving 9-[1] as-is to cover domain and host names and
adding a new requirement for internationalized meta-data:

[2] The protocol MUST allow exchange of meta-data associated with objects in
formats consistent with current internationalized character encoding
standards.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tuesday, December 26, 2000 2:09 PM
To: AndrÈ Cormier; Provreg (E-mail)
Subject: Re: My personal comments on the requirements.

At 13.49 -0500 00-12-22, AndrÈ Cormier wrote:
>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.
>   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.
>   Support for internationalized host and domain names will greatly
>   increase world-wide usability of a generic registry registrar
>   protocol, so standards for internationalized host and domain names
>   MUST be considered during the protocol design process.
>AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable
>AC: the use of internationalized data.

The information in section 9 should be syncronized with what happens 
in the IDN working group -- BUT, I would like to differ between two 
different types of data:

   - The Domain Names themselves
   - Other meta-data which goes along with the domainname, such as the
     street address of the admin contact etc, which can include not only
     non-ascii characters but also the address in a different format than
     what is default by the registry. Example: Street name and number is
     in the US written as "<number> <street name>" while in Sweden the
     order is the inverse "<street name> <number>".

To start with, the meta information should be able to be both in 
"english" ascii and in the native characters using Unicode, but the 
domainname definition should wait for the IDN definition (it might be 
that the domainname should be in some ACE encoding, already 
nameprepped -- or equivalent).

   paf

Date: Wed, 27 Dec 2000 07:35:07 -0800
To: Karl Auerbach <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Comments on overall direction
Cc: <[email-masked]>
Sender: [email-masked]

At 02:07 AM 12/27/00 -0800, Karl Auerbach wrote:
> > It would help to have a description of an existing service that has similar
> > scale and scope, that uses a similar mechanism.
>
>A bill of lading.  It's a technique that's been in use since about the
>year 1500.

Sorry for my serious lack of completeness.  I mean Internet-based service, 
or the technological equivalent.

>It's not a big extension to conceive of a digitally signed object that
>represents an instruction to perform some action on some asset - such as a
>domain name.  Indeed, we are part way there with the PGP signed domain
>update forms that we use today.

PGP is used in very small scale, in Internet terms.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Wed, 27 Dec 2000 07:26:50 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Karl Auerbach <[email-masked]>
cc: <[email-masked]>
Subject: Re: Comments on overall direction
Sender: [email-masked]

Karl,

On Wed, 27 Dec 2000, Karl Auerbach wrote:

> It's not a big extension to conceive of a digitally signed object that
> represents an instruction to perform some action on some asset - such as a
> domain name.  Indeed, we are part way there with the PGP signed domain
> update forms that we use today.

CORE's protocol does this, PGP signed MIME. Its ok but in my experence the
utility of this mechanism was not all that great. There are certainly
better ways provide the same today. Besides CORE had the requirement
because of other encription issues. Today those barriers are gone and end
to end encription shold be used where ever possable.

In short, we tried your suggestion and I found it to be not that usefull
and burdonsome.

-rick

Date: Wed, 27 Dec 2000 10:20:30 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Dave Crocker'" <[email-masked]>, [email-masked]
From: Marc Blanchet <[email-masked]>
Subject: RE: Draft provreg charter
Sender: [email-masked]

Suggested change to charter (related to the support of the different models 
of registries (thin, thick, ...):

From:
The specification will allow multiple registrars to register domain names
within a single Top Level Domain (TLD). The working group will use as input
the Extensible Provisioning Protocol presentation, documented in
<draft-hollenbeck-epp-00.txt>.

To:

The specification will allow multiple registrars to register domain names
within a single Top Level Domain (TLD). The specification should be 
flexible enough
to support the different operational models of registries (eg: thin, thick, 
...). The working group
will use as input the Extensible Provisioning Protocol presentation, 
documented in
<draft-hollenbeck-epp-00.txt>.

Marc.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Andr=E9_Cormier=27?= <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
Subject: RE: My personal comments on the requirements.
Date: Wed, 27 Dec 2000 09:44:13 -0500
Sender: [email-masked]

André,

I think we're in agreement on all of the comments you've provided.  I can
reword requirements as described, and I can add a requirement to allow for a
registry-specific contact field if that's OK with everyone else.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: André Cormier [mailto:[email-masked]]
Sent: Wednesday, December 27, 2000 12:20 AM
To: Provreg (E-mail)
Subject: RE: My personal comments on the requirements.

>--------------
>  >3.2 Identification and Authentication
>  >
>AC: 2 new items proposed. New protocols allow for negociation of the
>AC: authentication mechanism. This protocol one should be open enough =
=3D
>to allow
>AC: such negociation.
>AC: [3] The protocol MUST provide services to allow the negociatoin of =
=3D
>the
>AC: authentication mechanism that will be used to authenticate =3D
>registrar=3D20
>clients.
>AC: [4] The protocol MUST provide services to advertise =
authentication=3D20
>mechanism
>AC: supported by both the server and the client.
>
>[SAH] I don't have a problem with the basic idea here, but I'd like to
>suggest that this doesn't need to be a MUST in the protocol itself.  =
Other
>layers can do this as well; for example, BEEP offers just such a =
negotiation
>mechanism and I think it would be overkill to do the negotiation =
within both
>BEEP and another application layer protocol.  Would this re-wording be
>acceptable?:

[AC]Yes it would be overkill to do it in both BEEP and the protocol. =
But i=20
still think it should be part of the requirements. If BEEP is used with =
the=20
proposed protocol than BEEP will meet the negociation requirement. If =
BEEP=20
is not used, the protocol should include this kind of negociation.

What do you think ?

>"[3] The protocol or another layered protocol MUST provide services to
>negotiate an authentication mechanism acceptable to both the server =
and the
>client."
>
>I don't think the advertisement requirement is necessary if the =
mechanism
>must be negotiated.  Some kind of information exchange has to happen =
as part
>of the negotiation process.
>
>--------------
>  >3.3 Transaction Identification
>AC: I suggest we add a paragraph to clearly state that this number =
MUST =3D
>be=3D20
>randomly
>AC: generated so it would be nearly impossible for someone to guess =
=3D
>what will
>AC: be the identifier used by another registrar.
>AC: [3] The unique transaction identifier MUST be randomly generated =
so =3D
>it
>AC: would be nearly impossible for someone to guess what number as =
been =3D
>
>assigned
>AC: to a registrar.
>
>[SAH] Actually, I prefer the text proposed by Geva last week that says =
that
>each transaction must be "identified in a permanent and globally =
unique
>manner".  Requiring randomization gets into "how" the protocol should =
behave
>instead of describing "what" it should do.

[AC] This number is used for security measure while transferting domain =

objects between registrars. If this number is easily guessed it could =
be a=20
security problem. Unless i've misunderstood the use of this identifier. =

That's why i thought it would be nice to have a random part in this =
number.

>--------------
>3.4 Object Registration
>  >  [4] The protocol MUST provide services to register name servers.  =
=3D
>Name
>  >  server registration MUST NOT be limited to a specific period of =
=3D
>time.
>  >  Name servers registered within the registry's authoritative TLDs =
=3D
>MUST
>  >  be registered with a valid Internet Protocol (IP) address.  A =
name
>  >  server MAY be registered with multiple IP addresses.  An IP =
address
>  >  MAY be shared among multiple name servers using distinct server =
=3D
>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.
>AC: The protocol MUST allow the identification of the type of address. =
=3D
>This
>AC: way we will be able to add IPv6 addresses when the time will come. =
=3D
>I do not
>AC: say that we should include AAAA and A6 records. We should define a =
=3D
>way that
>AC: enables us to tag the type of address so it would be possible =
to=3D20
>register AAAA
>AC: and A6 records in the future. We should support IPv6 to have less =
=3D
>impact
>AC: when the time will come.
>
>[SAH] Section 1.1 states that the term "IP Address" means either or =
both
>IPv4 or IPv6 address.  I'll modify the text in this section to clearly =
state
>that support for both IPv4 and IPv6 addresses is required without =
specifying
>how that support should be provided.

[AC] Yes you are correct, i've missed that definition :-( sorry.

>  >  [5] The protocol MUST consider that the name server associated =
with =3D
>a
>  >  domain might not be registered in the same domain or even in a =
TLD =3D
>for
>  >  which the registry is authoritative.  This means that IP =
addresses =3D
>for
>  >  name servers whose parent domain exists in another TLD MUST be
>  >  registered only in the registry that is authoritative for the TLD =
=3D
>of
>  >  the name server.  Glue records (DNS "A" records) MUST NOT be =3D
>created
>  >  for DNS NS records for which the registry is not authoritative.
>AC: I do not think this is protocol related. It will be the =
registry=3D20
>application that
>AC: will create the DNS zone file and glue records. It should not be =
=3D
>state as a
>AC: requirement. I caan easily see that as a comment in the =
protocol=3D20
>definition draft
>AC: and a pointer to a companion document for best current practices.
>
>[SAH] This text was added quite some time ago at the urging of our =
Area
>Director.  I'll defer to Patrik to decide if we should remove this =
text or
>reword it so that it's clearly not a protocol requirement.  Patrik?

[AC] I saw Patrick's response. I understand the need.

>  >  [6] The protocol MUST provide services to register contact =3D
>information
>  >  describing human and organizational entities.  Contact =
registration
>  >  MUST NOT be limited to a specific period of time.  Contact
>  >  registration MUST include a name (individual name, organization =
=3D
>name,
>  >  or both), address (including street address, city, state or =3D
>province
>  >  (if applicable), postal code, and country), telephone number, and =
=3D
>e-
>  >  mail address.  A facsimile telephone number MAY be provided.
>AC: The protocol MUST allow for registry specific field for all =
objects =3D
>managed
>AC: by the protocol. Those field should be state as optional by =
the=3D20
>protocol but
>AC: MAY be forced mandatory by the registry with the use of error =
codes =3D
>stating
>AC: that a specific field is required.
>
>[SAH] Can you be more specific about the purpose of this new field?  =
I'd
>much prefer to enumerate required information vs. providing some kind =
of
>unformatted registry-specific field.

[AC] For each objects, registries may require additionnal fields. I'd =
like=20
to see what other ccTLDs or gTLDs needs for the contact object or for =
other=20
objects. I do not say that the objects are incomplete but i think that =
it=20
should not be too restrictive. This way if such a need arise, than the=20
protocol will not need an update to support a new field for the contact =
object.

>  >  [9] A registry MUST provide services to support a configurable =
=3D
>grace
>  >  period during which time a request to register a domain name or =
=3D
>other
>  >  billable object can be undone without harm.
>AC: I think this should be The protocol MUST provides services... If =
it =3D
>is the
>AC: registry than it's not protocol related but policy issue or =3D
>implementation
>AC: issue and does not belong in that document.
>
>[SAH] I'd prefer to pull this requirement out of the document than to
>require protocol support for something that isn't negotiated between
>registrar and registry but is rather a registry policy issue.  OK to =
pull it
>out?

[AC] That's fine with me.

>--------------
>3.5 Object Association
>  >  [2] The protocol MUST provide services to associate IP addresses =
=3D
>with
>  >  name servers.  A name server MAY have multiple IP addresses.  An =
IP
>  >  address MAY be associated with multiple name servers.
>AC: The same comment apply here for IP address type. We should provide =
=3D
>means
>AC: to tag IP address type so it would be possible to add IPv6 =3D
>addresses.
>
>[SAH] I'd like to address this by again clearly stating required =
support for
>both IPv4 and IPv6 address.  Tagging describes "how" that support is
>provided, and is thus something that I think would be more =
appropriately
>addressed in a protocol specification.

[AC] If tagging it is not a requirement it may be omited in the=20
specification and it would still meet the requirements. The goal of=20
requirements his to state what the protocol specification must meet in=20
order to achieve the specified task.

>--------------
>9. Internationalization Considerations
>    [1] Current Internet standards restrict the encoding of Internet =
=3D
>host
>    and domain names to a subset of the 7-bit US-ASCII character set.
>    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.
>    Support for internationalized host and domain names will greatly
>    increase world-wide usability of a generic registry registrar
>    protocol, so standards for internationalized host and domain names
>    MUST be considered during the protocol design process.
>AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to =
=3D
>enable
>AC: the use of internationalized data.
>
>[SAH] I'd prefer to reword the last sentence than to explicitly =
require
>UTF-8 because it again addresses "how" to solve a particular problem.  =
How
>about changing this:
>
>"so standards for internationalized host and domain names MUST be =
considered
>during the protocol design process"
>
>to this:
>
>"so standards for exchanging internationalized information MUST be
>considered during the protocol design process"
>
>I think that covers more than domain and host names without requiring =
a
>specific solution.

[AC] If IDN uses ACE format, it would still fit in the UTF-8 =
requirement=20
since ASCII remains the same within UTF-8. I like the idea of Patrick.=20
English MUST be use and local language in UTF-8 MAY be used for all=20
elements other than domain name, and domain name should be expressed as =

UTF-8 (for now) and a new protocol version could deal with the result =
of=20
the IDN wg when they will be done if it could not be done with UTF-8. =
For=20
the way data is expressed (Patrick stated an example for sweden) it =
would=20
be nice to have feeback from other countries.

If whois protocol is revised, it would be interesting to have an=20
internationalized version of it. But it is not in the scope of this =
list. ;-)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Dave Crocker'" <[email-masked]>, [email-masked]
Subject: RE: Draft provreg charter
Date: Wed, 27 Dec 2000 09:39:24 -0500
Sender: [email-masked]

Dave,

I think we'd like to have the group chartered in January 2001, not 2005. ;-)

I see some extra words in the third paragraph, which I would suggest
rewording as follows:

"The group will consider support for multiple operational choices, such as
for transport and security, and may consider use of the 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:"

I'd like to list some specific object identification targets in the first
documentation bullet if possible.   Leaving it open-ended makes it difficult
to determine when the group has finished it's work.  At a minimum, I think
we need to address domain name, host, and contact provisioning.  IP
addresses, ASNs, and telephone numbers have also been mentioned.  Do we want
to tackle those as formal working group deliverables?

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Tuesday, December 26, 2000 12:29 PM
To: [email-masked]
Subject: Draft provreg charter

Folks,

Here is a draft of the working group charter.  (Sorry for the delay.)  It 
reflects the changes I typed during the BOF, and string changes from 
'domreg' to 'provreg'.

d/

Provisioning Registry Protocol  (ProvReg)
------------------------------

  CHAIR(S):

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström
         Ned Freed

  AREA ADVISOR:

  MAILING LISTS:
General Discussion:
To Subscribe:
    In Body:             subscribe
    Alternate:
Archive:

DESCRIPTION OF WORKING GROUP:

Administration of Domain Name Service (DNS) registration increasingly 
distinguishes between the operation of a data base for registrations, 
called the registry, versus the  "front-end" sales and support services by 
registrars who interact with registrants and with the "back-end" 
registry.  Especially for various Top-Level Domains, the desire is to 
permit multiple registrars to share access to the database.  This working 
group will develop a protocol for registrar access to the registry. The 
protocol will permit interaction between a registrar's own application and 
the data base service running a domain name service registry repository.

The specification will allow multiple registrars to register domain names 
within a single Top Level Domain (TLD). The working group will use as input 
the Extensible Provisioning Protocol presentation, documented in 
<draft-hollenbeck-epp-00.txt>.

The group will consider support for multiple operational choices, such as 
for transport and security, and may consider use the protocol for other for 
other registration and update 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, their relationships to each other, and the protocol for 
exchanging objects between a registrar and the registry

*       Describe appropriate mechanisms for security and protection during 
registrar access

*       List useful examples of registrar access transactions

GOALS AND MILESTONES:
Jan, 2005       Working group chartered

Feb, 2001       Working group agreement on functional requirements for
protocol

Feb, 2001       Initial specification of provreg protocol

May, 2001       Second draft specification

Sep, 2001       Submit provreg draft for standards track

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Wed, 27 Dec 2000 00:19:56 -0500
To: "Provreg (E-mail)" <[email-masked]>
From: André Cormier <[email-masked]>
Subject: RE: My personal comments on the requirements.
Sender: [email-masked]

>--------------
>  >3.2 Identification and Authentication
>  >
>AC: 2 new items proposed. New protocols allow for negociation of the
>AC: authentication mechanism. This protocol one should be open enough =
>to allow
>AC: such negociation.
>AC: [3] The protocol MUST provide services to allow the negociatoin of =
>the
>AC: authentication mechanism that will be used to authenticate =
>registrar=20
>clients.
>AC: [4] The protocol MUST provide services to advertise authentication=20
>mechanism
>AC: supported by both the server and the client.
>
>[SAH] I don't have a problem with the basic idea here, but I'd like to
>suggest that this doesn't need to be a MUST in the protocol itself.  Other
>layers can do this as well; for example, BEEP offers just such a negotiation
>mechanism and I think it would be overkill to do the negotiation within both
>BEEP and another application layer protocol.  Would this re-wording be
>acceptable?:

[AC]Yes it would be overkill to do it in both BEEP and the protocol. But i 
still think it should be part of the requirements. If BEEP is used with the 
proposed protocol than BEEP will meet the negociation requirement. If BEEP 
is not used, the protocol should include this kind of negociation.

What do you think ?

>"[3] The protocol or another layered protocol MUST provide services to
>negotiate an authentication mechanism acceptable to both the server and the
>client."
>
>I don't think the advertisement requirement is necessary if the mechanism
>must be negotiated.  Some kind of information exchange has to happen as part
>of the negotiation process.
>
>--------------
>  >3.3 Transaction Identification
>AC: I suggest we add a paragraph to clearly state that this number MUST =
>be=20
>randomly
>AC: generated so it would be nearly impossible for someone to guess =
>what will
>AC: be the identifier used by another registrar.
>AC: [3] The unique transaction identifier MUST be randomly generated so =
>it
>AC: would be nearly impossible for someone to guess what number as been =
>
>assigned
>AC: to a registrar.
>
>[SAH] Actually, I prefer the text proposed by Geva last week that says that
>each transaction must be "identified in a permanent and globally unique
>manner".  Requiring randomization gets into "how" the protocol should behave
>instead of describing "what" it should do.

[AC] This number is used for security measure while transferting domain 
objects between registrars. If this number is easily guessed it could be a 
security problem. Unless i've misunderstood the use of this identifier. 
That's why i thought it would be nice to have a random part in this number.

>--------------
>3.4 Object Registration
>  >  [4] 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 (IP) 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.
>AC: The protocol MUST allow the identification of the type of address. =
>This
>AC: way we will be able to add IPv6 addresses when the time will come. =
>I do not
>AC: say that we should include AAAA and A6 records. We should define a =
>way that
>AC: enables us to tag the type of address so it would be possible to=20
>register AAAA
>AC: and A6 records in the future. We should support IPv6 to have less =
>impact
>AC: when the time will come.
>
>[SAH] Section 1.1 states that the term "IP Address" means either or both
>IPv4 or IPv6 address.  I'll modify the text in this section to clearly state
>that support for both IPv4 and IPv6 addresses is required without specifying
>how that support should be provided.

[AC] Yes you are correct, i've missed that definition :-( sorry.

>  >  [5] The protocol MUST consider that the name server associated with =
>a
>  >  domain might not be registered in the same domain or even in a TLD =
>for
>  >  which the registry is authoritative.  This means that IP addresses =
>for
>  >  name servers whose parent domain exists in another TLD MUST be
>  >  registered only in the registry that is authoritative for the TLD =
>of
>  >  the name server.  Glue records (DNS "A" records) MUST NOT be =
>created
>  >  for DNS NS records for which the registry is not authoritative.
>AC: I do not think this is protocol related. It will be the registry=20
>application that
>AC: will create the DNS zone file and glue records. It should not be =
>state as a
>AC: requirement. I caan easily see that as a comment in the protocol=20
>definition draft
>AC: and a pointer to a companion document for best current practices.
>
>[SAH] This text was added quite some time ago at the urging of our Area
>Director.  I'll defer to Patrik to decide if we should remove this text or
>reword it so that it's clearly not a protocol requirement.  Patrik?

[AC] I saw Patrick's response. I understand the need.

>  >  [6] The protocol MUST provide services to register contact =
>information
>  >  describing human and organizational entities.  Contact registration
>  >  MUST NOT be limited to a specific period of time.  Contact
>  >  registration MUST include a name (individual name, organization =
>name,
>  >  or both), address (including street address, city, state or =
>province
>  >  (if applicable), postal code, and country), telephone number, and =
>e-
>  >  mail address.  A facsimile telephone number MAY be provided.
>AC: The protocol MUST allow for registry specific field for all objects =
>managed
>AC: by the protocol. Those field should be state as optional by the=20
>protocol but
>AC: MAY be forced mandatory by the registry with the use of error codes =
>stating
>AC: that a specific field is required.
>
>[SAH] Can you be more specific about the purpose of this new field?  I'd
>much prefer to enumerate required information vs. providing some kind of
>unformatted registry-specific field.

[AC] For each objects, registries may require additionnal fields. I'd like 
to see what other ccTLDs or gTLDs needs for the contact object or for other 
objects. I do not say that the objects are incomplete but i think that it 
should not be too restrictive. This way if such a need arise, than the 
protocol will not need an update to support a new field for the contact object.

>  >  [9] A registry MUST provide services to support a configurable =
>grace
>  >  period during which time a request to register a domain name or =
>other
>  >  billable object can be undone without harm.
>AC: I think this should be The protocol MUST provides services... If it =
>is the
>AC: registry than it's not protocol related but policy issue or =
>implementation
>AC: issue and does not belong in that document.
>
>[SAH] I'd prefer to pull this requirement out of the document than to
>require protocol support for something that isn't negotiated between
>registrar and registry but is rather a registry policy issue.  OK to pull it
>out?

[AC] That's fine with me.

>--------------
>3.5 Object Association
>  >  [2] The protocol MUST provide services to associate IP addresses =
>with
>  >  name servers.  A name server MAY have multiple IP addresses.  An IP
>  >  address MAY be associated with multiple name servers.
>AC: The same comment apply here for IP address type. We should provide =
>means
>AC: to tag IP address type so it would be possible to add IPv6 =
>addresses.
>
>[SAH] I'd like to address this by again clearly stating required support for
>both IPv4 and IPv6 address.  Tagging describes "how" that support is
>provided, and is thus something that I think would be more appropriately
>addressed in a protocol specification.

[AC] If tagging it is not a requirement it may be omited in the 
specification and it would still meet the requirements. The goal of 
requirements his to state what the protocol specification must meet in 
order to achieve the specified task.

>--------------
>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.
>    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.
>    Support for internationalized host and domain names will greatly
>    increase world-wide usability of a generic registry registrar
>    protocol, so standards for internationalized host and domain names
>    MUST be considered during the protocol design process.
>AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to =
>enable
>AC: the use of internationalized data.
>
>[SAH] I'd prefer to reword the last sentence than to explicitly require
>UTF-8 because it again addresses "how" to solve a particular problem.  How
>about changing this:
>
>"so standards for internationalized host and domain names MUST be considered
>during the protocol design process"
>
>to this:
>
>"so standards for exchanging internationalized information MUST be
>considered during the protocol design process"
>
>I think that covers more than domain and host names without requiring a
>specific solution.

[AC] If IDN uses ACE format, it would still fit in the UTF-8 requirement 
since ASCII remains the same within UTF-8. I like the idea of Patrick. 
English MUST be use and local language in UTF-8 MAY be used for all 
elements other than domain name, and domain name should be expressed as 
UTF-8 (for now) and a new protocol version could deal with the result of 
the IDN wg when they will be done if it could not be done with UTF-8. For 
the way data is expressed (Patrick stated an example for sweden) it would 
be nice to have feeback from other countries.

If whois protocol is revised, it would be interesting to have an 
internationalized version of it. But it is not in the scope of this list. ;-)

______________________________________________________________________
André Cormier                     | Téléphone : (418) 656-9254
2875 boul. Laurier                | Télécopie : (418) 266-5539
Bureau 300                        |
Sainte-Foy, (Québec) G1V 2M2      | [email-masked]
Canada                            | Radio : VA2UNX, VA2ACE
----------------------------------------------------------------------
Internet Engineering Standards/Normes d'ingénierie Internet
                 http://www.normos.org
----------------------------------------------------------------------
PGP: D434 547D 712A E44F C978  4673 BD50 A248 C262 CB06

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Karl Auerbach'" <[email-masked]>, [email-masked]
Subject: RE: Comments on overall direction
Date: Wed, 27 Dec 2000 09:23:24 -0500
Sender: [email-masked]

While I know of at least one company that would be thrilled to see
requirements for millions of domain name owners to become PKI-capable (or
even just the subset who wish to request transfers), I have to echo the
point raised by Dave concerning deployment and adoption.  I'm sure there are
domain name holders who would understand and welcome such developments, but
people aren't exactly falling over each other to install applications that
provide cryptographic services.

I don't disagree that transactional integrity is essential, but we may have
different ideas on where that integrity service needs to be available or
applied.  I believe that we have a far better chance to produce a widely
accepted protocol if we do our best to keep the protocol itself extremely
simple, and using a layered approach to add services that make sense in
particular operational environments.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Karl Auerbach [mailto:[email-masked]]
Sent: Wednesday, December 27, 2000 5:08 AM
To: [email-masked]
Subject: Re: Comments on overall direction

> At 12:29 PM 12/26/00 -0800, Karl Auerbach wrote:
>
> >3. I am very wary of continuing the current notion of agent-to-agent
> >transfers.  To my mind any transfer should be accomplished via the
> >customer, i.e. that some signed certificate must be handed by the
> >relinquishing agent to the customer for the customer to hand over to the
> >acquiring agent.
>
> It would help to have a description of an existing service that has
similar
> scale and scope, that uses a similar mechanism.

A bill of lading.  It's a technique that's been in use since about the
year 1500.

In recent times, in operating systems the technique has been called a
"capability".

It's not a big extension to conceive of a digitally signed object that
represents an instruction to perform some action on some asset - such as a
domain name.  Indeed, we are part way there with the PGP signed domain
update forms that we use today.

When I ask for my domain to be transfered from agent A to agent B, I tell
agent A to initiate a transfer, A gets a digitally signed certificate of
control from the database/registry, signs it itself, and then hands it to
me.  I sign it.  I, in turn, hand it to agent B who verifies the various
signatures.  Agent B signs it and hands it to the database/registry, which
also verifies everything and, if they check out, performs the transfer.

> >5. The issue of privacy and security seems to be being glossed over - we
> >are talking about databases that will be among the worlds larger bodies
of
> >personally identifiable information - with both strong privacy
> >characteristics and high value to marketing/sales folks.
> >
> >This suggests to me that there ought to be adequate information in the
> >protocols to build unambiguous, timestamped, transaction journals.
>
> "in the protocols"?  Sites can and do do high quality, timestamped
> journaling without special protocol issues.  What specific mechanisms or
> information do you believe affect the protocols?

Timestamps can be faked, that's why there needs to be both client and
server timestamps, and for them to be integrity protected in the packets.

> >It also suggests to me that there be provision for solid identification
> >and authenticatation of all transactions.
>
> so, you want a public key signature on every protocol unit?

Not every PDU - but certainly on every transaction.

		--karl--

Date: Wed, 27 Dec 2000 02:07:34 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: <[email-masked]>
Subject: Re: Comments on overall direction
Sender: [email-masked]

> At 12:29 PM 12/26/00 -0800, Karl Auerbach wrote:
>
> >3. I am very wary of continuing the current notion of agent-to-agent
> >transfers.  To my mind any transfer should be accomplished via the
> >customer, i.e. that some signed certificate must be handed by the
> >relinquishing agent to the customer for the customer to hand over to the
> >acquiring agent.
>
> It would help to have a description of an existing service that has similar
> scale and scope, that uses a similar mechanism.

A bill of lading.  It's a technique that's been in use since about the
year 1500.

In recent times, in operating systems the technique has been called a
"capability".

It's not a big extension to conceive of a digitally signed object that
represents an instruction to perform some action on some asset - such as a
domain name.  Indeed, we are part way there with the PGP signed domain
update forms that we use today.

When I ask for my domain to be transfered from agent A to agent B, I tell
agent A to initiate a transfer, A gets a digitally signed certificate of
control from the database/registry, signs it itself, and then hands it to
me.  I sign it.  I, in turn, hand it to agent B who verifies the various
signatures.  Agent B signs it and hands it to the database/registry, which
also verifies everything and, if they check out, performs the transfer.

> >5. The issue of privacy and security seems to be being glossed over - we
> >are talking about databases that will be among the worlds larger bodies of
> >personally identifiable information - with both strong privacy
> >characteristics and high value to marketing/sales folks.
> >
> >This suggests to me that there ought to be adequate information in the
> >protocols to build unambiguous, timestamped, transaction journals.
>
> "in the protocols"?  Sites can and do do high quality, timestamped
> journaling without special protocol issues.  What specific mechanisms or
> information do you believe affect the protocols?

Timestamps can be faked, that's why there needs to be both client and
server timestamps, and for them to be integrity protected in the packets.

> >It also suggests to me that there be provision for solid identification
> >and authenticatation of all transactions.
>
> so, you want a public key signature on every protocol unit?

Not every PDU - but certainly on every transaction.

		--karl--

Date: Wed, 27 Dec 2000 00:02:35 -0800
To: Karl Auerbach <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Comments on overall direction
Cc: <[email-masked]>
Sender: [email-masked]

At 12:29 PM 12/26/00 -0800, Karl Auerbach wrote:

>3. I am very wary of continuing the current notion of agent-to-agent
>transfers.  To my mind any transfer should be accomplished via the
>customer, i.e. that some signed certificate must be handed by the
>relinquishing agent to the customer for the customer to hand over to the
>acquiring agent.

It would help to have a description of an existing service that has similar 
scale and scope, that uses a similar mechanism.

Absent that, we will need to be clear about the portions of the mechanism 
that you are proposing that will carry significant risk of not being 
deployed or adopted.

>5. The issue of privacy and security seems to be being glossed over - we
>are talking about databases that will be among the worlds larger bodies of
>personally identifiable information - with both strong privacy
>characteristics and high value to marketing/sales folks.
>
>This suggests to me that there ought to be adequate information in the
>protocols to build unambiguous, timestamped, transaction journals.

"in the protocols"?  Sites can and do do high quality, timestamped 
journaling without special protocol issues.  What specific mechanisms or 
information do you believe affect the protocols?

>It also suggests to me that there be provision for solid identification
>and authenticatation of all transactions.

so, you want a public key signature on every protocol unit?

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 26 Dec 2000 09:28:34 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Draft provreg charter
Sender: [email-masked]

Folks,

Here is a draft of the working group charter.  (Sorry for the delay.)  It 
reflects the changes I typed during the BOF, and string changes from 
'domreg' to 'provreg'.

d/

Provisioning Registry Protocol  (ProvReg)
------------------------------

  CHAIR(S):

  APPLICATIONS AREA DIRECTOR(S):
         Patrik Fältström
         Ned Freed

  AREA ADVISOR:

  MAILING LISTS:
General Discussion:
To Subscribe:
    In Body:             subscribe
    Alternate:
Archive:

DESCRIPTION OF WORKING GROUP:

Administration of Domain Name Service (DNS) registration increasingly 
distinguishes between the operation of a data base for registrations, 
called the registry, versus the  "front-end" sales and support services by 
registrars who interact with registrants and with the "back-end" 
registry.  Especially for various Top-Level Domains, the desire is to 
permit multiple registrars to share access to the database.  This working 
group will develop a protocol for registrar access to the registry. The 
protocol will permit interaction between a registrar's own application and 
the data base service running a domain name service registry repository.

The specification will allow multiple registrars to register domain names 
within a single Top Level Domain (TLD). The working group will use as input 
the Extensible Provisioning Protocol presentation, documented in 
<draft-hollenbeck-epp-00.txt>.

The group will consider support for multiple operational choices, such as 
for transport and security, and may consider use the protocol for other for 
other registration and update 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, their relationships to each other, and the protocol for 
exchanging objects between a registrar and the registry

*       Describe appropriate mechanisms for security and protection during 
registrar access

*       List useful examples of registrar access transactions

GOALS AND MILESTONES:
Jan, 2005       Working group chartered

Feb, 2001       Working group agreement on functional requirements for protocol

Feb, 2001       Initial specification of provreg protocol

May, 2001       Second draft specification

Sep, 2001       Submit provreg draft for standards track

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Date: Tue, 26 Dec 2000 12:29:22 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: <[email-masked]>
Subject: Comments on overall direction
Sender: [email-masked]

I've just read through the e-mail that came in over the last week.

What struck me is how much it seems tied to existing practices of NSI's
registry.  For example, just because NSI today has registrations in year
units is no reason to think that that must be true for everyone
everywhere.

And what struck me further is how quickly the discussion focused on domain
name registration and forgot that there are other kinds of network
resources that need similar services.

So -- my comments:

1. A nit: I'd like to get rid of this horrid "registrar", "registry",
"registrant" terminology.  There have been more instances than I can count
where discussions went off into the weeds because somebody accidently used
the wrong ending to the string "registr".  Mike O'Dell has suggested
"repository" and "agent" in lieu of "registry" and "registrar".
Personally I like the trio "database", "agent", and "customer".

2. There are many kinds of Internet resources that customers will want to
lay claim to - domain names, IP address blocks, and ASNs come to mind as
some we have today.  The common feature about these is that they can all
be described using the following skeletal paradigm:  (The following is for
illustration, I'm aware that there are more detailed versions.)

        <registration-object>
         <definition-of-thing-being-registered>
           ...
         </definition-of-thing-being-registered>
         <duration-of-registration-info>
           ...
         </duration-of-registration-info>
         <contact-list>
          <admin-contact>
            <contact-info>
               ...
            <contact-info>
          </admin-contact>
          <tech-contact>
            <contact-info>
               ...
            <contact-info>
          </tech-contact>
          <billing-contact>
            <contact-info>
               ...
            <contact-info>
          </billing-contact>
         </contact-list>
        </registration-object>

This suggests several things to me:

   - That we can have a single protocol to handle registrations of all
     kinds of things, not just DNS names.

   - That there is no reason why this package can't also be used between
     all parties to this system - agents-to-database (and
     vice-versa), customers to agents, agents-to-agents,
     databases-to-escrow systems, agents-to-escrow systems.

   - That the protocol should be designed in "chunks".  Thus one chunk
     would support a lockable registration exchange between a customer and
     its selected agent, and also between an agent and the database.  And
     another chunk of protocol would support unlocked query access.  (This
     latter function happens to be a nice alternative to the underdefined
     port 43 mechanism.)

3. I am very wary of continuing the current notion of agent-to-agent
transfers.  To my mind any transfer should be accomplished via the
customer, i.e. that some signed certificate must be handed by the
relinquishing agent to the customer for the customer to hand over to the
acquiring agent.

4. I'm nervous about the inclusion of fancy negotion protocols - such as
have been aluded to with regard to the negotion of expiration timestamps.
My own preference is that the protocols simply have a code to express that
a request has been "rejected due to unacceptable expiration timestamp".
To my mind external channels should be used to convey policies about these
kinds of things.

5. The issue of privacy and security seems to be being glossed over - we
are talking about databases that will be among the worlds larger bodies of
personally identifiable information - with both strong privacy
characteristics and high value to marketing/sales folks.

This suggests to me that there ought to be adequate information in the
protocols to build unambiguous, timestamped, transaction journals.

It also suggests to me that there be provision for solid identification
and authenticatation of all transactions.  I don't care whether this comes
as part of this protocol or as part of a lower layer protocol.  However,
since we are going to have to abide by inconsistant privacy laws I have
this more than sneaking suspicion that implementations are going to have
to resort to call-outs to policy servers - as such we ought to make sure
that these protocols and data representations are amenible to being
filtered by some sort of policy expressions that might come back from such
policy servers.

           --karl--

Date: Tue, 26 Dec 2000 20:09:10 +0100
To: =?iso-8859-1?Q?Andr=C8?= Cormier <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: My personal comments on the requirements.
Sender: [email-masked]

At 13.49 -0500 00-12-22, AndrÈ Cormier wrote:
>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.
>   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.
>   Support for internationalized host and domain names will greatly
>   increase world-wide usability of a generic registry registrar
>   protocol, so standards for internationalized host and domain names
>   MUST be considered during the protocol design process.
>AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable
>AC: the use of internationalized data.

The information in section 9 should be syncronized with what happens 
in the IDN working group -- BUT, I would like to differ between two 
different types of data:

   - The Domain Names themselves
   - Other meta-data which goes along with the domainname, such as the
     street address of the admin contact etc, which can include not only
     non-ascii characters but also the address in a different format than
     what is default by the registry. Example: Street name and number is
     in the US written as "<number> <street name>" while in Sweden the
     order is the inverse "<street name> <number>".

To start with, the meta information should be able to be both in 
"english" ascii and in the native characters using Unicode, but the 
domainname definition should wait for the IDN definition (it might be 
that the domainname should be in some ACE encoding, already 
nameprepped -- or equivalent).

   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-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Tue, 26 Dec 2000 20:04:51 +0100
To: =?iso-8859-1?Q?Andr=C8?= Cormier <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: My personal comments on the requirements.
Sender: [email-masked]

At 13.49 -0500 00-12-22, AndrÈ Cormier wrote:
>  >  [5] The protocol MUST consider that the name server associated with a
>>   domain might not be registered in the same domain or even in a TLD for
>>   which the registry is authoritative.  This means that IP addresses for
>>   name servers whose parent domain exists in another TLD MUST be
>>   registered only in the registry that is authoritative for the TLD of
>>   the name server.  Glue records (DNS "A" records) MUST NOT be created
>>   for DNS NS records for which the registry is not authoritative.
>AC: I do not think this is protocol related. It will be the registry 
>application that
>AC: will create the DNS zone file and glue records. It should not be 
>state as a
>AC: requirement. I caan easily see that as a comment in the protocol 
>definition draft
>AC: and a pointer to a companion document for best current practices.

The problem with glue in some zones or registries which do not belong 
there but in a different zone is what happens when the IP address of 
those glues change. Should one owner of a nameserver remember to talk 
to _every_ registry and change the IP address, or just the one which 
the IP address really belong? If you say it is only a requirement of 
the zone that is generated, what is your thought of why the IP 
address need to be in the database of the registry? What happens if 
that IP address becomes out of date? I.e. if you are a registry, and 
have one Ip address in your database, and you by using DNS find a 
different IP address in DNS, which one will you trust (I hope the one 
in DNS) and why in that case do you need one in the database?

I need more arguments for why the IP address needs to be in more than 
one place, i.e. in the registry which really own the correct TLD for 
the NS, where the glue really should be.

Storing the same information in more than one place is generally (in 
my experience) a bad thing, and always leads to inconsistency between 
records.

    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-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Tue, 26 Dec 2000 10:33:13 -0500
To: "J. William Semich" <[email-masked]>, "'provreg List'" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: Scope [was Re: Expiration times]
Sender: [email-masked]

Forgive me if this made it to the list before ..I've made a couple of 
postings and I'm not sure they made it..I did not get a reflection back.

> >
> >This is a valid point.  At the same time, I think it's important to avoid
> >too much scope creep here too.
><snip>

Please

>Verisign has launched a testbed registry for ENUM type identifiers
>(www.enumworld.com). Scott, would the above proposed provision for a
>"broader range of identifiers" be one way to accommodate ENUM registry
>activity, or would 7.5-[1] be adequate?

Speaking as IETF ENUM Chair I think it would be a bad idea for PROVREG to 
look at this ENUM provisioning ..at this time. What is important for this 
protocol is extensibility.

We do need to stay focused on the task at hand with is domain name 
registration and the needs of customers and some of us new registries to be 
ready in a timely manner.

If we keep extensibility in mind then I think we will have no problems 
..ENUM registrations would be only a "profile" of provreg.

That would indicate that we want to add "application tags" to the XML 
schemas to indicate what application is involved ..obviously IP phone 
number registrations will require an entirely different set data based on a 
entirely different set of business rules

>Bill Semich
>
>.NU Domain

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Andr=E9_Cormier=27?= <[email-masked]>, "Provreg (E-mail)" <[email-masked]>
Subject: RE: My personal comments on the requirements.
Date: Tue, 26 Dec 2000 10:06:52 -0500
Sender: [email-masked]

Thanks for your comments, André.  I'd like to respond and suggest some
alternative re-wordings if I may; my responses, suggestions, and rationale
are included below preceded by "[SAH]".

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: André Cormier [mailto:[email-masked]]
Sent: Friday, December 22, 2000 1:49 PM
To: Provreg (E-mail)
Subject: My personal comments on the requirements.

I got interested in this at last IETF in San Diego.

Here are my "humble" comments on the requirement documents. I think =
they
might be of interest. I've provided only the sections that i have
commented. We can spread different threads as needed to discuss them if
any of you agrees with these.

My comments starts with "AC: ".

Regards

Andr=E9

 >1. Introduction
 >  This document is being discussed on the "rrp" mailing list.  To =
join
 >  the list, send a message to <[email-masked]> with the =
words
 >  "subscribe rrp" in the body of the message.  There is a web site =
for
 >  the list archives at <http://www.NSIRegistry.net/maillist/rrp>.
AC: Do not forget to point to the new mailing list...

[SAH] Yes, of course.

--------------
 >3.2 Identification and Authentication
 >
AC: 2 new items proposed. New protocols allow for negociation of the
AC: authentication mechanism. This protocol one should be open enough =
to allow
AC: such negociation.
AC: [3] The protocol MUST provide services to allow the negociatoin of =
the
AC: authentication mechanism that will be used to authenticate =
registrar=20
clients.
AC: [4] The protocol MUST provide services to advertise authentication=20
mechanism
AC: supported by both the server and the client.

[SAH] I don't have a problem with the basic idea here, but I'd like to
suggest that this doesn't need to be a MUST in the protocol itself.  Other
layers can do this as well; for example, BEEP offers just such a negotiation
mechanism and I think it would be overkill to do the negotiation within both
BEEP and another application layer protocol.  Would this re-wording be
acceptable?:

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

I don't think the advertisement requirement is necessary if the mechanism
must be negotiated.  Some kind of information exchange has to happen as part
of the negotiation process.

--------------
 >3.3 Transaction Identification
AC: I suggest we add a paragraph to clearly state that this number MUST =
be=20
randomly
AC: generated so it would be nearly impossible for someone to guess =
what will
AC: be the identifier used by another registrar.
AC: [3] The unique transaction identifier MUST be randomly generated so =
it
AC: would be nearly impossible for someone to guess what number as been =

assigned
AC: to a registrar.

[SAH] Actually, I prefer the text proposed by Geva last week that says that
each transaction must be "identified in a permanent and globally unique
manner".  Requiring randomization gets into "how" the protocol should behave
instead of describing "what" it should do.

--------------
3.4 Object Registration
 >  [4] 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 (IP) 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.
AC: The protocol MUST allow the identification of the type of address. =
This
AC: way we will be able to add IPv6 addresses when the time will come. =
I do not
AC: say that we should include AAAA and A6 records. We should define a =
way that
AC: enables us to tag the type of address so it would be possible to=20
register AAAA
AC: and A6 records in the future. We should support IPv6 to have less =
impact
AC: when the time will come.

[SAH] Section 1.1 states that the term "IP Address" means either or both
IPv4 or IPv6 address.  I'll modify the text in this section to clearly state
that support for both IPv4 and IPv6 addresses is required without specifying
how that support should be provided.

 >  [5] The protocol MUST consider that the name server associated with =
a
 >  domain might not be registered in the same domain or even in a TLD =
for
 >  which the registry is authoritative.  This means that IP addresses =
for
 >  name servers whose parent domain exists in another TLD MUST be
 >  registered only in the registry that is authoritative for the TLD =
of
 >  the name server.  Glue records (DNS "A" records) MUST NOT be =
created
 >  for DNS NS records for which the registry is not authoritative.
AC: I do not think this is protocol related. It will be the registry=20
application that
AC: will create the DNS zone file and glue records. It should not be =
state as a
AC: requirement. I caan easily see that as a comment in the protocol=20
definition draft
AC: and a pointer to a companion document for best current practices.

[SAH] This text was added quite some time ago at the urging of our Area
Director.  I'll defer to Patrik to decide if we should remove this text or
reword it so that it's clearly not a protocol requirement.  Patrik?

 >  [6] The protocol MUST provide services to register contact =
information
 >  describing human and organizational entities.  Contact registration
 >  MUST NOT be limited to a specific period of time.  Contact
 >  registration MUST include a name (individual name, organization =
name,
 >  or both), address (including street address, city, state or =
province
 >  (if applicable), postal code, and country), telephone number, and =
e-
 >  mail address.  A facsimile telephone number MAY be provided.
AC: The protocol MUST allow for registry specific field for all objects =
managed
AC: by the protocol. Those field should be state as optional by the=20
protocol but
AC: MAY be forced mandatory by the registry with the use of error codes =
stating
AC: that a specific field is required.

[SAH] Can you be more specific about the purpose of this new field?  I'd
much prefer to enumerate required information vs. providing some kind of
unformatted registry-specific field.

 >  [9] A registry MUST provide services to support a configurable =
grace
 >  period during which time a request to register a domain name or =
other
 >  billable object can be undone without harm.
AC: I think this should be The protocol MUST provides services... If it =
is the
AC: registry than it's not protocol related but policy issue or =
implementation
AC: issue and does not belong in that document.

[SAH] I'd prefer to pull this requirement out of the document than to
require protocol support for something that isn't negotiated between
registrar and registry but is rather a registry policy issue.  OK to pull it
out?

--------------
3.5 Object Association
 >  [2] The protocol MUST provide services to associate IP addresses =
with
 >  name servers.  A name server MAY have multiple IP addresses.  An IP
 >  address MAY be associated with multiple name servers.
AC: The same comment apply here for IP address type. We should provide =
means
AC: to tag IP address type so it would be possible to add IPv6 =
addresses.

[SAH] I'd like to address this by again clearly stating required support for
both IPv4 and IPv6 address.  Tagging describes "how" that support is
provided, and is thus something that I think would be more appropriately
addressed in a protocol specification.

--------------
3.7 Object Transfer
 >  [5] A transfer request MUST include a new transaction identifier.  =
The
 >  new transaction identifier MUST be returned to the registrant by =
the
 >  registrar to facilitate authorization of future transfer requests.
AC: The same comment for this number. It should random as i said =
earlier.

[SAH] Actually I think this requirement should be removed because it
describes a "how" and not a "what".

 >  [10] A registry MUST provide a default transfer action in case of
 >  registrar inaction.  If a registry-specified period of time elapses
 >  without explicit approval, rejection, or cancellation, a registry =
MUST
 >  perform the default transfer action on behalf of the requesting
 >  registrar.
AC: This should not be in the requirements unless the action period =
MUST be
AC: speficied in the protocol or domain name object. If the action =
period=20
is not
AC: part of the protocol than it is implementation issue or policy =
related and
AC: therefore should not be expressed in this document.

[SAH] I agree, so I'd like to remove this requirement.

--------------
3.10 Object Deletion
 >  [1] The protocol MUST provide services to remove a domain name from
 >  the registry.  Deleting a domain name MUST also delete all child =
name
 >  servers.  A domain name MUST NOT be deleted if child name servers =
are
 >  being used to host other domain names.
AC: The first phrase should be left intact but the rest should be =
removed.
AC: This is an important issue but not really protocol related. I think =
that
AC: maybe another document should be written as implementation guide to =
state
AC: important issues related to domain name registration and DNS zone =
file
AC: creation. It is not the protocol that updates the database but the
AC: registry application. This applications uses the protocol to =
exchange
AC: with clients. This document defines functional requirements for the =

protocol,
AC: not the registry application. I really think that another document =
should
AC: be written for registries and registrars that will implement the=20
protocol. It
AC: should be done as a companion document.

[SAH] Agreed, so I'll remove the text.

 >  [2] The protocol MUST provide services to remove a name server from
 >  the registry.  Name servers MUST be referenced by fully-qualified
 >  name.  A name server MUST NOT be deleted if it is being used to =
host a
 >  domain name.
AC: Same comment as above.

[SAH] Agreed.

 >  [3] The protocol MUST provide services to remove a contact from the
 >  registry.  Contacts MUST be referenced by registry identifier.  A
 >  contact MUST NOT be deleted if it is associated with a domain.
AC: Same comment as above.

[SAH] Agreed.

--------------
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.
   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.
   Support for internationalized host and domain names will greatly
   increase world-wide usability of a generic registry registrar
   protocol, so standards for internationalized host and domain names
   MUST be considered during the protocol design process.
AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to =
enable
AC: the use of internationalized data.

[SAH] I'd prefer to reword the last sentence than to explicitly require
UTF-8 because it again addresses "how" to solve a particular problem.  How
about changing this:

"so standards for internationalized host and domain names MUST be considered
during the protocol design process"

to this:

"so standards for exchanging internationalized information MUST be
considered during the protocol design process"

I think that covers more than domain and host names without requiring a
specific solution.

Date: Fri, 22 Dec 2000 13:49:29 -0500
To: "Provreg (E-mail)" <[email-masked]>
From: André Cormier <[email-masked]>
Subject: My personal comments on the requirements.
Sender: [email-masked]

I got interested in this at last IETF in San Diego.

Here are my "humble" comments on the requirement documents. I think they
might be of interest. I've provided only the sections that i have
commented. We can spread different threads as needed to discuss them if
any of you agrees with these.

My comments starts with "AC: ".

Regards

André

 >1. Introduction
 >  This document is being discussed on the "rrp" mailing list.  To join
 >  the list, send a message to <[email-masked]> with the words
 >  "subscribe rrp" in the body of the message.  There is a web site for
 >  the list archives at <http://www.NSIRegistry.net/maillist/rrp>.
AC: Do not forget to point to the new mailing list...
--------------
 >3.2 Identification and Authentication
 >
AC: 2 new items proposed. New protocols allow for negociation of the
AC: authentication mechanism. This protocol one should be open enough to allow
AC: such negociation.
AC: [3] The protocol MUST provide services to allow the negociatoin of the
AC: authentication mechanism that will be used to authenticate registrar 
clients.
AC: [4] The protocol MUST provide services to advertise authentication 
mechanism
AC: supported by both the server and the client.
--------------
 >3.3 Transaction Identification
AC: I suggest we add a paragraph to clearly state that this number MUST be 
randomly
AC: generated so it would be nearly impossible for someone to guess what will
AC: be the identifier used by another registrar.
AC: [3] The unique transaction identifier MUST be randomly generated so it
AC: would be nearly impossible for someone to guess what number as been 
assigned
AC: to a registrar.
--------------
3.4 Object Registration
 >  [4] 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 (IP) 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.
AC: The protocol MUST allow the identification of the type of address. This
AC: way we will be able to add IPv6 addresses when the time will come. I do not
AC: say that we should include AAAA and A6 records. We should define a way that
AC: enables us to tag the type of address so it would be possible to 
register AAAA
AC: and A6 records in the future. We should support IPv6 to have less impact
AC: when the time will come.
 >  [5] The protocol MUST consider that the name server associated with a
 >  domain might not be registered in the same domain or even in a TLD for
 >  which the registry is authoritative.  This means that IP addresses for
 >  name servers whose parent domain exists in another TLD MUST be
 >  registered only in the registry that is authoritative for the TLD of
 >  the name server.  Glue records (DNS "A" records) MUST NOT be created
 >  for DNS NS records for which the registry is not authoritative.
AC: I do not think this is protocol related. It will be the registry 
application that
AC: will create the DNS zone file and glue records. It should not be state as a
AC: requirement. I caan easily see that as a comment in the protocol 
definition draft
AC: and a pointer to a companion document for best current practices.
 >  [6] The protocol MUST provide services to register contact information
 >  describing human and organizational entities.  Contact registration
 >  MUST NOT be limited to a specific period of time.  Contact
 >  registration MUST include a name (individual name, organization name,
 >  or both), address (including street address, city, state or province
 >  (if applicable), postal code, and country), telephone number, and e-
 >  mail address.  A facsimile telephone number MAY be provided.
AC: The protocol MUST allow for registry specific field for all objects managed
AC: by the protocol. Those field should be state as optional by the 
protocol but
AC: MAY be forced mandatory by the registry with the use of error codes stating
AC: that a specific field is required.
 >  [9] A registry MUST provide services to support a configurable grace
 >  period during which time a request to register a domain name or other
 >  billable object can be undone without harm.
AC: I think this should be The protocol MUST provides services... If it is the
AC: registry than it's not protocol related but policy issue or implementation
AC: issue and does not belong in that document.
--------------
3.5 Object Association
 >  [2] The protocol MUST provide services to associate IP addresses with
 >  name servers.  A name server MAY have multiple IP addresses.  An IP
 >  address MAY be associated with multiple name servers.
AC: The same comment apply here for IP address type. We should provide means
AC: to tag IP address type so it would be possible to add IPv6 addresses.
--------------
3.7 Object Transfer
 >  [5] A transfer request MUST include a new transaction identifier.  The
 >  new transaction identifier MUST be returned to the registrant by the
 >  registrar to facilitate authorization of future transfer requests.
AC: The same comment for this number. It should random as i said earlier.

 >  [10] A registry MUST provide a default transfer action in case of
 >  registrar inaction.  If a registry-specified period of time elapses
 >  without explicit approval, rejection, or cancellation, a registry MUST
 >  perform the default transfer action on behalf of the requesting
 >  registrar.
AC: This should not be in the requirements unless the action period MUST be
AC: speficied in the protocol or domain name object. If the action period 
is not
AC: part of the protocol than it is implementation issue or policy related and
AC: therefore should not be expressed in this document.
--------------
3.10 Object Deletion
 >  [1] The protocol MUST provide services to remove a domain name from
 >  the registry.  Deleting a domain name MUST also delete all child name
 >  servers.  A domain name MUST NOT be deleted if child name servers are
 >  being used to host other domain names.
AC: The first phrase should be left intact but the rest should be removed.
AC: This is an important issue but not really protocol related. I think that
AC: maybe another document should be written as implementation guide to state
AC: important issues related to domain name registration and DNS zone file
AC: creation. It is not the protocol that updates the database but the
AC: registry application. This applications uses the protocol to exchange
AC: with clients. This document defines functional requirements for the 
protocol,
AC: not the registry application. I really think that another document should
AC: be written for registries and registrars that will implement the 
protocol. It
AC: should be done as a companion document.

 >  [2] The protocol MUST provide services to remove a name server from
 >  the registry.  Name servers MUST be referenced by fully-qualified
 >  name.  A name server MUST NOT be deleted if it is being used to host a
 >  domain name.
AC: Same comment as above.

 >  [3] The protocol MUST provide services to remove a contact from the
 >  registry.  Contacts MUST be referenced by registry identifier.  A
 >  contact MUST NOT be deleted if it is associated with a domain.
AC: Same comment as above.
--------------
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.
   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.
   Support for internationalized host and domain names will greatly
   increase world-wide usability of a generic registry registrar
   protocol, so standards for internationalized host and domain names
   MUST be considered during the protocol design process.
AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable
AC: the use of internationalized data.

______________________________________________________________________
André Cormier                     | Téléphone : (418) 656-9254
2875 boul. Laurier                | Télécopie : (418) 266-5539
Bureau 300                        |
Sainte-Foy, (Québec) G1V 2M2      | [email-masked]
Canada                            | Radio : VA2UNX, VA2ACE
----------------------------------------------------------------------
Internet Engineering Standards/Normes d'ingénierie Internet
                 http://www.normos.org
----------------------------------------------------------------------
PGP: D434 547D 712A E44F C978  4673 BD50 A248 C262 CB06

Date: Thu, 21 Dec 2000 12:48:08 -0800
To: "Provreg (E-mail)" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Sender: [email-masked]

At 11:25 AM -0700 12/21/00, Brian Jarvis wrote:
>  > So you're recommending instituting a "class of service" identifier,
>>  where the default (perhaps) is mandated? You realize that you're
>>  introducing the need for an "IANA function" to register the classes,
>>  as I see it?
>
>I agree that a "class of service" identifier is appropriate.  However,
>in order to ease/eliminate the IANA function, I would prefer it be an OID.

OIDs still need to be registered somewhere to help people understand 
what their semantics are. Using a new IANA registry would probably 
lead to much greater interoperability. At least, that is what we have 
found (painfully) in the PKIX and S/MIME world...

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Geva Patz'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 14:51:58 -0500
Sender: [email-masked]

As I read this again I need one more clarification, please.  Should "domain
name" be added to the first sentence to be clear that the paragraph refers
to domain names?

"The protocol MUST permit a starting and ending time for a domain name
registration to be negotiated"

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 2:30 PM
To: [email-masked]'
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]

On Thu, Dec 21, 2000 at 01:56:40PM -0500, Hollenbeck, Scott wrote:
> I think I misread one piece of your most recent proposal (reading
> "registrars" where you wrote "registries").  The way you characterized the
> requirement mapping in your last paragraph gives me an idea, though - why
> not phrase the requirement like this:

> [2] The protocol MUST allow a registry to implement policies allowing a
> range of domain registration time periods, where registrars MAY choose to
> offer (not necessarily identical) subsets of the range of periods, and
where
> registrants get to choose an element from that subset.

Why not, indeed! (I find it remarkably hard to argue against what
are practically my own words :) I'd perhaps suggest a slight
re-wording to enhance clarity while (I hope) preserving the
semantics of the original wording you suggest above:

[2] The protocol MUST permit a starting and ending time for a
registration to be negotiated, thereby enabling a registry to
implement policies allowing a range of registration validity
periods, and enabling registrars to select a period for each
registration they submit from within the valid range based on
out-of-band negotiation between the registrar and the registrant.
Registries SHOULD be allowed to accept indefiniteily 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. The protocol MUST ensure that, at the successful
conclusion of a registration event, the registrar and registry
have the same, unambiguous, conception of the validity period of
the registration.

The wording of the last sentence probably needs work. What I'm
trying to avoid here is the situation where a registrar, on
1/1/2001, says "Register domain name X from now until 3/1/2001",
and the registry says "OK", and silently rounds the validity
period up to a year. The protocol should either have the registry
respond with "I can't do that!" or "OK, I've registered the name
until 12/31/2001".

I've also resuscitated the rare but necessary case of indefinite
registrations (some ccTLDs use these, as do some non-domain name
identifier registries).

-- Geva

Date: Thu, 21 Dec 2000 14:48:36 -0500
From: Geva Patz <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
Mail-Followup-To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Thu, Dec 21, 2000 at 02:41:44PM -0500, Hollenbeck, Scott wrote:
> I can live with this.  How's this for work on the last sentence:
> 
> "The protocol MUST provide features to ensure that both registry and
> registrar have a mutual understanding of the validity period at the
> conclusion of a successful registration event."

Much better, thanks.

-- Geva

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Geva Patz'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 14:41:44 -0500
Sender: [email-masked]

I can live with this.  How's this for work on the last sentence:

"The protocol MUST provide features to ensure that both registry and
registrar have a mutual understanding of the validity period at the
conclusion of a successful registration event."

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 2:30 PM
To: [email-masked]'
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]

On Thu, Dec 21, 2000 at 01:56:40PM -0500, Hollenbeck, Scott wrote:
> I think I misread one piece of your most recent proposal (reading
> "registrars" where you wrote "registries").  The way you characterized the
> requirement mapping in your last paragraph gives me an idea, though - why
> not phrase the requirement like this:

> [2] The protocol MUST allow a registry to implement policies allowing a
> range of domain registration time periods, where registrars MAY choose to
> offer (not necessarily identical) subsets of the range of periods, and
where
> registrants get to choose an element from that subset.

Why not, indeed! (I find it remarkably hard to argue against what
are practically my own words :) I'd perhaps suggest a slight
re-wording to enhance clarity while (I hope) preserving the
semantics of the original wording you suggest above:

[2] The protocol MUST permit a starting and ending time for a
registration to be negotiated, thereby enabling a registry to
implement policies allowing a range of registration validity
periods, and enabling registrars to select a period for each
registration they submit from within the valid range based on
out-of-band negotiation between the registrar and the registrant.
Registries SHOULD be allowed to accept indefiniteily 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. The protocol MUST ensure that, at the successful
conclusion of a registration event, the registrar and registry
have the same, unambiguous, conception of the validity period of
the registration.

The wording of the last sentence probably needs work. What I'm
trying to avoid here is the situation where a registrar, on
1/1/2001, says "Register domain name X from now until 3/1/2001",
and the registry says "OK", and silently rounds the validity
period up to a year. The protocol should either have the registry
respond with "I can't do that!" or "OK, I've registered the name
until 12/31/2001".

I've also resuscitated the rare but necessary case of indefinite
registrations (some ccTLDs use these, as do some non-domain name
identifier registries).

-- Geva

Date: Thu, 21 Dec 2000 14:30:15 -0500
From: Geva Patz <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
Mail-Followup-To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Thu, Dec 21, 2000 at 01:56:40PM -0500, Hollenbeck, Scott wrote:
> I think I misread one piece of your most recent proposal (reading
> "registrars" where you wrote "registries").  The way you characterized the
> requirement mapping in your last paragraph gives me an idea, though - why
> not phrase the requirement like this:

> [2] The protocol MUST allow a registry to implement policies allowing a
> range of domain registration time periods, where registrars MAY choose to
> offer (not necessarily identical) subsets of the range of periods, and where
> registrants get to choose an element from that subset.

Why not, indeed! (I find it remarkably hard to argue against what
are practically my own words :) I'd perhaps suggest a slight
re-wording to enhance clarity while (I hope) preserving the
semantics of the original wording you suggest above:

[2] The protocol MUST permit a starting and ending time for a
registration to be negotiated, thereby enabling a registry to
implement policies allowing a range of registration validity
periods, and enabling registrars to select a period for each
registration they submit from within the valid range based on
out-of-band negotiation between the registrar and the registrant.
Registries SHOULD be allowed to accept indefiniteily 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. The protocol MUST ensure that, at the successful
conclusion of a registration event, the registrar and registry
have the same, unambiguous, conception of the validity period of
the registration.

The wording of the last sentence probably needs work. What I'm
trying to avoid here is the situation where a registrar, on
1/1/2001, says "Register domain name X from now until 3/1/2001",
and the registry says "OK", and silently rounds the validity
period up to a year. The protocol should either have the registry
respond with "I can't do that!" or "OK, I've registered the name
until 12/31/2001".

I've also resuscitated the rare but necessary case of indefinite
registrations (some ccTLDs use these, as do some non-domain name
identifier registries).

-- Geva

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jordyn A. Buchanan'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 14:02:23 -0500
Sender: [email-masked]

Sure, ensuring that things don't break for other types of objects is a Good
Thing.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Jordyn A. Buchanan [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 12:34 PM
To: Hollenbeck, Scott; [email-masked]'
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]

At 12:05 PM 12/21/2000 -0500, Hollenbeck, Scott wrote:
>Rather than try to enumerate all of the possible object types that might be
>registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested by
>Geva (which I think would then be inconsistent with other specific object
>requirements in 3.4), I'd really prefer to add a requirement to section 7.5
>if people believe that 7.5-[1] talks more to protocol extensibility than
>object extensibility:

Just for clarity, I suggest we enumerate the types of objects we might like 
to register for sanity's sake, and not for inclusion into the requirements 
doc.  Then we can make sure that the requirements match.

Scott's suggestion that we add a statement at the global level about 
extensibility rather than making the object requirements overly generic is 
a good one, and I think the language he proposes is much more clear and 
understandable than a more generic discussion about alphanumeric strings 
with certain qualities.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Geva Patz'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 13:56:40 -0500
Sender: [email-masked]

Geza,

I can come up with some text for section two to describe the object
extensibility goal.  The first sentence described below seems like a good
starting point.

I think I misread one piece of your most recent proposal (reading
"registrars" where you wrote "registries").  The way you characterized the
requirement mapping in your last paragraph gives me an idea, though - why
not phrase the requirement like this:

[2] The protocol MUST allow a registry to implement policies allowing a
range of domain registration time periods, where registrars MAY choose to
offer (not necessarily identical) subsets of the range of periods, and where
registrants get to choose an element from that subset.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 12:45 PM
To: [email-masked]'
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]

On Thu, Dec 21, 2000 at 12:05:59PM -0500, Hollenbeck, Scott wrote:
> Rather than try to enumerate all of the possible object types that might
be
> registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested
by
> Geva (which I think would then be inconsistent with other specific object
> requirements in 3.4), I'd really prefer to add a requirement to section
7.5
> if people believe that 7.5-[1] talks more to protocol extensibility than
> object extensibility:

> "[2] The requirements described in this document are not intended to limit
> the set of objects that may be managed by a generic registry-registrar
> protocol.  A generic protocol MUST include features that allow extension
to
> object types that are not described in this document."

I'll buy that. I'd like to see a reference to the idea somewat earlier in
the document, too, just to emphasize the point (section 2 seems a prime
candidate for such rewriting).

> while creating a new 3.4-[2] that deals with the registration period.  WRT
> to [2] as suggested below, I would really like to understand which
> registries support the registration model as described.  I'm all for
> architectural agility, but I would prefer to work with current real-world
> requirements vs. trying to guess what might be done in the future to avoid
> kruft introduction.

I'm not for the introduction of cruft. Rather, I'm against the 
introduction of arbitrary restictions. Our ultimate goal, after
all, is to create a protocol that will become an Internet standard.
To be useful as a standard, it ought to accommodate a wide range
of registration application with as wide range of policy models (within,
of course, the overall scope of the type of application we're trying to
support). The Internet is large, diverse and global, so if we have any
aspirations to standardhood, we must take the responsibility of serving
that wider audience seriously. 

For an example of the registration model I described, where a registry
implements a policy allowing a range of time periods, where registrars 
choose to offer (not necessarily identical) subsets of the range of
periods, and where registrants get to choose an element from that 
subset, may I refer you to the gTLDs '.com', '.net' or '.org', where
precisely such a mechanism is currently in place. ;)

-- Geva

From: Brian Jarvis <[email-masked]>
To: "'Christopher Ambler'" <[email-masked]>
Cc: "Provreg (E-mail)" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 11:25:18 -0700
Sender: [email-masked]

> > [1] The protocol MUST provide services to register Internet domain
> > names, and SHOULD allow for the registration of other unique
> > alphanumeric identifiers.
> 
> So you're recommending instituting a "class of service" identifier,
> where the default (perhaps) is mandated? You realize that you're
> introducing the need for an "IANA function" to register the classes,
> as I see it?

I agree that a "class of service" identifier is appropriate.  However,
in order to ease/eliminate the IANA function, I would prefer it be an OID.

--the walrus

Date: Thu, 21 Dec 2000 12:44:56 -0500
From: Geva Patz <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
Mail-Followup-To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Thu, Dec 21, 2000 at 12:05:59PM -0500, Hollenbeck, Scott wrote:
> Rather than try to enumerate all of the possible object types that might be
> registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested by
> Geva (which I think would then be inconsistent with other specific object
> requirements in 3.4), I'd really prefer to add a requirement to section 7.5
> if people believe that 7.5-[1] talks more to protocol extensibility than
> object extensibility:

> "[2] The requirements described in this document are not intended to limit
> the set of objects that may be managed by a generic registry-registrar
> protocol.  A generic protocol MUST include features that allow extension to
> object types that are not described in this document."

I'll buy that. I'd like to see a reference to the idea somewat earlier in
the document, too, just to emphasize the point (section 2 seems a prime
candidate for such rewriting).

> while creating a new 3.4-[2] that deals with the registration period.  WRT
> to [2] as suggested below, I would really like to understand which
> registries support the registration model as described.  I'm all for
> architectural agility, but I would prefer to work with current real-world
> requirements vs. trying to guess what might be done in the future to avoid
> kruft introduction.

I'm not for the introduction of cruft. Rather, I'm against the 
introduction of arbitrary restictions. Our ultimate goal, after
all, is to create a protocol that will become an Internet standard.
To be useful as a standard, it ought to accommodate a wide range
of registration application with as wide range of policy models (within,
of course, the overall scope of the type of application we're trying to
support). The Internet is large, diverse and global, so if we have any
aspirations to standardhood, we must take the responsibility of serving
that wider audience seriously. 

For an example of the registration model I described, where a registry
implements a policy allowing a range of time periods, where registrars 
choose to offer (not necessarily identical) subsets of the range of
periods, and where registrants get to choose an element from that 
subset, may I refer you to the gTLDs '.com', '.net' or '.org', where
precisely such a mechanism is currently in place. ;)

-- Geva

Date: Thu, 21 Dec 2000 12:34:10 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Sender: [email-masked]

At 12:05 PM 12/21/2000 -0500, Hollenbeck, Scott wrote:
>Rather than try to enumerate all of the possible object types that might be
>registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested by
>Geva (which I think would then be inconsistent with other specific object
>requirements in 3.4), I'd really prefer to add a requirement to section 7.5
>if people believe that 7.5-[1] talks more to protocol extensibility than
>object extensibility:

Just for clarity, I suggest we enumerate the types of objects we might like 
to register for sanity's sake, and not for inclusion into the requirements 
doc.  Then we can make sure that the requirements match.

Scott's suggestion that we add a statement at the global level about 
extensibility rather than making the object requirements overly generic is 
a good one, and I think the language he proposes is much more clear and 
understandable than a more generic discussion about alphanumeric strings 
with certain qualities.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 12:05:59 -0500
Sender: [email-masked]

Rather than try to enumerate all of the possible object types that might be
registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested by
Geva (which I think would then be inconsistent with other specific object
requirements in 3.4), I'd really prefer to add a requirement to section 7.5
if people believe that 7.5-[1] talks more to protocol extensibility than
object extensibility:

"[2] The requirements described in this document are not intended to limit
the set of objects that may be managed by a generic registry-registrar
protocol.  A generic protocol MUST include features that allow extension to
object types that are not described in this document."

I would prefer to see this kind of global statement in section 7.5 than in
section 3.4 because 3.4 describes object registration only.  If we add such
a statement to 3.4, I think we have to add similar statements to 3.5, 3.6,
3.7, 3.8, 3.9, 3.10, and 3.11 to be consistent.  I'd like to keep 3.4-[1]
limited to domain names as in:

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

while creating a new 3.4-[2] that deals with the registration period.  WRT
to [2] as suggested below, I would really like to understand which
registries support the registration model as described.  I'm all for
architectural agility, but I would prefer to work with current real-world
requirements vs. trying to guess what might be done in the future to avoid
kruft introduction.

I fully agree that any other descriptions in the document that describe a
"how" should be generalized into a "what".  There's also something that
smells like a "how" in section 8.4; I'll fix that.  Identification of other
offending sections is welcome.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 9:31 AM
To: 'provreg List'
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]

On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote:
> 
> Requirement 7.5-[1] already exists to ensure that the protocol allows for
> registration of objects not explicitly specified in the draft, so I think
> the second sentence is redundant.  

I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:,
generic registry-registrar protocol SHOULD provide features
that at a minimum allow for the management of new object types
without requiring revisions to the protocol itself". There's a
subtle difference in sense between this, which basically suggests
that the protocol be extensible, and my proposed rewording of
3.4-[1], which suggests that the protocol should be designed from
the outset to accommodate a broader range of identifiers than
domain names (which the EPP proposal, for instance, does). I
won't re-hash the reasons why we changed the name from `domreg'
to `provreg', but I think it's important to capture those in the
requirements.

> My immediate objection to [2] isn't with the suggested concept, though I
do
> have a philosophical objection to it that we can take that up when we
start
> to talk protocol.  The requirements draft describes functional
requirements,
> which I have interpreted to mean "requirements for _what_ the protocol is
> supposed to do".  I believe the suggested new text is getting into the
> specifics of _how_ the protocol is supposed to solve a particular issue,
and
> is thus out of place in this document.  

A fair point, except that several other parts of the requirements draft
get into exactly such issues. For instance 3.3-[1]:

" Registry operations that create, update, or delete objects MUST be
  associated with a registry-unique transaction identifier.  The
  identifier SHOULD be created using the current date and a combination
  of identification information assigned by and unique to the registry
  (such as a registrar identifier) and information assigned by and
  unique to the registrar requesting the operation (such as a coded
  combination of letters and numbers)." 

On your principle (which certainly has merit), this should probably
be re-worded something along the lines of:

" The protocol MUST allow each transaction to be identified in a 
  permanent and globally unique manner"

There are several other examples elswehere in the text. I think we need
to decide as a group where we'd like the requirements to be, and if we
decide to come down firmly on the side of "what, not how" (which, again,
I don't think is a bad idea), then we'd best go through the draft in 
some detail to make sure that it adheres to that principle.

> I think it would be more appropriate
> to say something along the lines of "a domain name must have a
registration
> period whose value is determined by registry policy".

... except that the value may not be determined by registry
policy, but by registrar policy (or by registrant request).
All registries have a policy, even if only by implication
("we'll register anything"), but that policy doesn't necessarily
determine the value. Consider a registry policy of "We will
register identifiers for any finite length of time, provided
that the time is paid for up front at the rate of $0.03/day".
The only constraints that this imposes is disallowing indefinite
registrations, and setting the resolution of time periods in
days. Now suppose a registrar in that domain has the policy that
"We'll register names for 1 year at $x, 2 years at $y, or 5 years
at $z". That further constrains the periods to the set {1 year; 
2 years; 5 years}, but _still_ doesn't determine the period, until
a registrant choses a specific value. The registrant/registrar
negotiation is (probably) out of our scope, but the idea that the
registrar (optionally) determines the expiration date, which the
registry may reject, is an important one.

So, we could have wording like this:

[1] The protocol MUST provide services to register unique
alphanumeric identifiers, in particluar Internet domain names

[2] Identifiers MUST be registered for an unambiguous period
(which MAY be indefinite if registry policy allows). The protocol
MUST allow registries to specify a start and end time for the
registration period on behalf of the registrant, and MUST allow
the registry, depending on its policy, to confirm the proposed
period, reject it, or specify a default period if the proposal is
omitted.

-- Geva

Date: Thu, 21 Dec 2000 11:25:10 -0500
To: "J. William Semich" <[email-masked]>, "'provreg List'" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Scope [was Re: Expiration times]
Sender: [email-masked]

At 10:21 AM 12/21/2000 -0500, J. William Semich wrote:
>Verisign has launched a testbed registry for ENUM type identifiers
>(www.enumworld.com). Scott, would the above proposed provision for a
>"broader range of identifiers" be one way to accommodate ENUM registry
>activity, or would 7.5-[1] be adequate?

An "ENUM type identifier" is still a domain name--there just happens to be 
a mapping between that domain name and an E.164 number.  Even if the 
requirements only talked about domain names, they'd still cover ENUM.

Jordyn

Date: Thu, 21 Dec 2000 10:21:50 -0500
To: "'provreg List'" <[email-masked]>
From: "J. William Semich" <[email-masked]>
Subject: Re: Scope [was Re: Expiration times]
Sender: [email-masked]

At 10:06 AM 12/21/00 -0500, Jordyn A. Buchanan wrote:
>At 09:31 AM 12/21/2000 -0500, Geva Patz wrote:
>>On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote:
>> >
>> > Requirement 7.5-[1] already exists to ensure that the protocol allows for
>> > registration of objects not explicitly specified in the draft, so I think
>> > the second sentence is redundant.
>>
>>I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:,
>>generic registry-registrar protocol SHOULD provide features
>>that at a minimum allow for the management of new object types
>>without requiring revisions to the protocol itself". There's a
>>subtle difference in sense between this, which basically suggests
>>that the protocol be extensible, and my proposed rewording of
>>3.4-[1], which suggests that the protocol should be designed from
>>the outset to accommodate a broader range of identifiers than
>>domain names (which the EPP proposal, for instance, does). I
>>won't re-hash the reasons why we changed the name from `domreg'
>>to `provreg', but I think it's important to capture those in the
>>requirements.
>
>This is a valid point.  At the same time, I think it's important to avoid 
>too much scope creep here too.  
<snip>

Verisign has launched a testbed registry for ENUM type identifiers
(www.enumworld.com). Scott, would the above proposed provision for a
"broader range of identifiers" be one way to accommodate ENUM registry
activity, or would 7.5-[1] be adequate?

Bill Semich

.NU Domain

Date: Thu, 21 Dec 2000 10:06:37 -0500
To: "'provreg List'" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Scope [was Re: Expiration times]
Sender: [email-masked]

At 09:31 AM 12/21/2000 -0500, Geva Patz wrote:
>On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote:
> >
> > Requirement 7.5-[1] already exists to ensure that the protocol allows for
> > registration of objects not explicitly specified in the draft, so I think
> > the second sentence is redundant.
>
>I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:,
>generic registry-registrar protocol SHOULD provide features
>that at a minimum allow for the management of new object types
>without requiring revisions to the protocol itself". There's a
>subtle difference in sense between this, which basically suggests
>that the protocol be extensible, and my proposed rewording of
>3.4-[1], which suggests that the protocol should be designed from
>the outset to accommodate a broader range of identifiers than
>domain names (which the EPP proposal, for instance, does). I
>won't re-hash the reasons why we changed the name from `domreg'
>to `provreg', but I think it's important to capture those in the
>requirements.

This is a valid point.  At the same time, I think it's important to avoid 
too much scope creep here too.  One thing we should get a handle on is 
"what types of registrations do we want the initial requirements document 
to cover?"  Some specificity on this issue allows us to craft good 
requirements throughout the rest of the document.  We should keep 
extensibility in mind, obviously, because I don't think anyone wants to end 
up with a protocol that only registers domain names, but at the same time 
we don't want to end up with the "generic database update protocol", either.

>[snip]
>There are several other examples elswehere in the text. I think we need
>to decide as a group where we'd like the requirements to be, and if we
>decide to come down firmly on the side of "what, not how" (which, again,
>I don't think is a bad idea), then we'd best go through the draft in
>some detail to make sure that it adheres to that principle.

I agree.  The principle is good, and it should be applied throughout the 
requirements document.

>[snip]
>So, we could have wording like this:
>
>[1] The protocol MUST provide services to register unique
>alphanumeric identifiers, in particluar Internet domain names

As above, can we tighten this up?  I'd suggest wording, but I think we need 
to agree about the scope of our efforts first.  This may determine how we 
think about our approach to the subsequent requirements.

To jump start this conversation, here are things that people have suggested 
we might want the protocol to register:

- Domain names
- IP address ranges
- AS numbers

Should we try to deal with all of these?  Are there things not on this list 
that we want to try to deal with?

Jordyn

Date: Thu, 21 Dec 2000 09:31:08 -0500
From: Geva Patz <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
Reply-To: [email-masked]
Mail-Followup-To: 'provreg List' <[email-masked]>
Sender: [email-masked]

On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote:
> 
> Requirement 7.5-[1] already exists to ensure that the protocol allows for
> registration of objects not explicitly specified in the draft, so I think
> the second sentence is redundant.  

I'm not sure that I agree. 7.5-[1] states (sensibly) that "A:,
generic registry-registrar protocol SHOULD provide features
that at a minimum allow for the management of new object types
without requiring revisions to the protocol itself". There's a
subtle difference in sense between this, which basically suggests
that the protocol be extensible, and my proposed rewording of
3.4-[1], which suggests that the protocol should be designed from
the outset to accommodate a broader range of identifiers than
domain names (which the EPP proposal, for instance, does). I
won't re-hash the reasons why we changed the name from `domreg'
to `provreg', but I think it's important to capture those in the
requirements.

> My immediate objection to [2] isn't with the suggested concept, though I do
> have a philosophical objection to it that we can take that up when we start
> to talk protocol.  The requirements draft describes functional requirements,
> which I have interpreted to mean "requirements for _what_ the protocol is
> supposed to do".  I believe the suggested new text is getting into the
> specifics of _how_ the protocol is supposed to solve a particular issue, and
> is thus out of place in this document.  

A fair point, except that several other parts of the requirements draft
get into exactly such issues. For instance 3.3-[1]:

" Registry operations that create, update, or delete objects MUST be
  associated with a registry-unique transaction identifier.  The
  identifier SHOULD be created using the current date and a combination
  of identification information assigned by and unique to the registry
  (such as a registrar identifier) and information assigned by and
  unique to the registrar requesting the operation (such as a coded
  combination of letters and numbers)." 

On your principle (which certainly has merit), this should probably
be re-worded something along the lines of:

" The protocol MUST allow each transaction to be identified in a 
  permanent and globally unique manner"

There are several other examples elswehere in the text. I think we need
to decide as a group where we'd like the requirements to be, and if we
decide to come down firmly on the side of "what, not how" (which, again,
I don't think is a bad idea), then we'd best go through the draft in 
some detail to make sure that it adheres to that principle.

> I think it would be more appropriate
> to say something along the lines of "a domain name must have a registration
> period whose value is determined by registry policy".

... except that the value may not be determined by registry
policy, but by registrar policy (or by registrant request).
All registries have a policy, even if only by implication
("we'll register anything"), but that policy doesn't necessarily
determine the value. Consider a registry policy of "We will
register identifiers for any finite length of time, provided
that the time is paid for up front at the rate of $0.03/day".
The only constraints that this imposes is disallowing indefinite
registrations, and setting the resolution of time periods in
days. Now suppose a registrar in that domain has the policy that
"We'll register names for 1 year at $x, 2 years at $y, or 5 years
at $z". That further constrains the periods to the set {1 year; 
2 years; 5 years}, but _still_ doesn't determine the period, until
a registrant choses a specific value. The registrant/registrar
negotiation is (probably) out of our scope, but the idea that the
registrar (optionally) determines the expiration date, which the
registry may reject, is an important one.

So, we could have wording like this:

[1] The protocol MUST provide services to register unique
alphanumeric identifiers, in particluar Internet domain names

[2] Identifiers MUST be registered for an unambiguous period
(which MAY be indefinite if registry policy allows). The protocol
MUST allow registries to specify a start and end time for the
registration period on behalf of the registrant, and MUST allow
the registry, depending on its policy, to confirm the proposed
period, reject it, or specify a default period if the proposal is
omitted.

-- Geva

From: "Hollenbeck, Scott" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: RE: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 07:39:13 -0500
Sender: [email-masked]

I have a minor objection to [1] and a fundamental objection to [2].  I'll
explain my minor objection first.

Requirement 7.5-[1] already exists to ensure that the protocol allows for
registration of objects not explicitly specified in the draft, so I think
the second sentence is redundant.  I agree with altering the current second
sentence of 3.4-[1] (the "registration period" sentence) and will propose
new text in a moment.

My immediate objection to [2] isn't with the suggested concept, though I do
have a philosophical objection to it that we can take that up when we start
to talk protocol.  The requirements draft describes functional requirements,
which I have interpreted to mean "requirements for _what_ the protocol is
supposed to do".  I believe the suggested new text is getting into the
specifics of _how_ the protocol is supposed to solve a particular issue, and
is thus out of place in this document.  I think it would be more appropriate
to say something along the lines of "a domain name must have a registration
period whose value is determined by registry policy".

Here's what I propose for new text:

[1] The protocol MUST provide services to register Internet domain names
with a well defined registration period.

[2] The protocol MUST provide minimum and maximum values for a domain name
registration period that allow the period to be determined by registry
policy.

This new text describes "what" the protocol is supposed to do without
getting into "how" it should be implemented, or imposing limits based on any
current policy.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 3:26 PM
To: 'provreg List'
Subject: Expiration times [was Re: domreg BOF Meeting Minutes]

OK, given the chorus of approval on the idea that the
registration period wording  needs to change, here's a proposal
for some specific wording. How about changing this:

< [1] The protocol MUST provide services to register Internet domain
<  names.  The registration period for domain names MUST be measured in
<  years, with a minimum period of one year and a maximum period defined
<  by registry policy.

Into this:

> [1] The protocol MUST provide services to register Internet domain
> names, and SHOULD allow for the registration of other unique
> alphanumeric identifiers.
>
> [2] The protocol MUST allow registrars to specify an optional 
> expiration date for each object registered, and MUST allow 
> registries to accept or reject the proposed expiration date based
> on their local policies. Dates MAY be specified either as
> absolute times or as forward deltas from the time of actual
> registration. 

Notice that I've sneaked a few other things into here, too, besides
the relaxation of the exiration requirement:

* I've hinted at the more general applicability of the protocol in
  the SHOULD clause of [1]

* I've moved the focus of specifying an expiration date from the 
  registry to the registrar, while still allowing the registry to 
  have ultimate policy control over the duration of registrations. 
  This, to my mind, better mirrors the situation in the real world,
  where different registrars offer different periods of initial 
  registration in the same TLD, sometimes for different prices. 

* I've made the expiration date optional, to cater for the case
  where objects are registered indefinitely (rare for domain names,
  common in some other identifier spaces). 

* I've added a hint that protocol designers may wish to consider
  time deltas. This seems to make more sense if you've got registrars
  proposing expiry times, to allow for network delays and clock skews. 
  To illustrate the issue here, consider a registrar asking for a 
  one-year registration from a registry whose policy allows
  registrations only in one-year increments, where the registrar's
  clock is behind the registry's by m minutes, and where network 
  congestion induces an n-minute delay in transmission. Given an 
  absolute time, the registry may reject the request as being (n+m) 
  minutes short of a year.

-- Geva

From: "Ross Wm. Rader" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 04:14:06 -0500
Sender: [email-masked]

> > [1] The protocol MUST provide services to register Internet domain
> > names, and SHOULD allow for the registration of other unique
> > alphanumeric identifiers.
>
> So you're recommending instituting a "class of service" identifier,
> where the default (perhaps) is mandated? You realize that you're
> introducing the need for an "IANA function" to register the classes,
> as I see it?

Which isn't necessarily a bad thing. At the very least it ensures that the
classes aren't inadvertently overlapping, thereby guaranteeing at least a
modicum of consistency. The question is, does this attribute have any real
value?
>
> > * I've made the expiration date optional, to cater for the case
> >   where objects are registered indefinitely (rare for domain names,
> >   common in some other identifier spaces).
>
> I would suggest making it non-optional, but allowing that a specific
> "forever" value be acceptable (subject to rejection by the registry,
> based on local policies, as you've indicated). To be complete, I
> don't like the thought of the default no-info meaning "forever."

Agreed, too much grey...I'm not sure what the current fashion is, but I
certainly prefer explicit statements where possible...

-rwr

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
Date: Thu, 21 Dec 2000 00:42:39 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

> [1] The protocol MUST provide services to register Internet domain
> names, and SHOULD allow for the registration of other unique
> alphanumeric identifiers.

So you're recommending instituting a "class of service" identifier,
where the default (perhaps) is mandated? You realize that you're
introducing the need for an "IANA function" to register the classes,
as I see it?

> [2] The protocol MUST allow registrars to specify an optional 
> expiration date for each object registered, and MUST allow 
> registries to accept or reject the proposed expiration date based
> on their local policies. Dates MAY be specified either as
> absolute times or as forward deltas from the time of actual
> registration. 

Don't you mean MUST on that last one? Either one or the other
MUST be specified. MAY would indicate that neither is an option,
as you say below, but...
 
> * I've made the expiration date optional, to cater for the case
>   where objects are registered indefinitely (rare for domain names,
>   common in some other identifier spaces). 

I would suggest making it non-optional, but allowing that a specific
"forever" value be acceptable (subject to rejection by the registry,
based on local policies, as you've indicated). To be complete, I
don't like the thought of the default no-info meaning "forever."

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]

Date: Wed, 20 Dec 2000 16:17:54 -0500
From: Mike Lampson IARegistry <[email-masked]>
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]
To: "'provreg List'" <[email-masked]>
Sender: [email-masked]

I like the changes being recommended here.  A couple of questions:

1) Should we use "expiration timestamp" instead of "expiration date" for
conciseness?

2) Should the requirements state that if objects require an expiration date
by policy, then those objects {MUST?/SHOULD?} have a policy-defined default
when an expiration timestamp or forward delta is not provided?

Cheers,

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

----- Original Message ----- 
From: "Geva Patz" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Sent: Wednesday, December 20, 2000 3:25 PM
Subject: Expiration times [was Re: domreg BOF Meeting Minutes]

> OK, given the chorus of approval on the idea that the
> registration period wording  needs to change, here's a proposal
> for some specific wording. How about changing this:
> 
> < [1] The protocol MUST provide services to register Internet domain
> <  names.  The registration period for domain names MUST be measured in
> <  years, with a minimum period of one year and a maximum period defined
> <  by registry policy.
> 
> Into this:
> 
> > [1] The protocol MUST provide services to register Internet domain
> > names, and SHOULD allow for the registration of other unique
> > alphanumeric identifiers.
> >
> > [2] The protocol MUST allow registrars to specify an optional 
> > expiration date for each object registered, and MUST allow 
> > registries to accept or reject the proposed expiration date based
> > on their local policies. Dates MAY be specified either as
> > absolute times or as forward deltas from the time of actual
> > registration. 
> 
> Notice that I've sneaked a few other things into here, too, besides
> the relaxation of the exiration requirement:
> 
> * I've hinted at the more general applicability of the protocol in
>   the SHOULD clause of [1]
> 
> * I've moved the focus of specifying an expiration date from the 
>   registry to the registrar, while still allowing the registry to 
>   have ultimate policy control over the duration of registrations. 
>   This, to my mind, better mirrors the situation in the real world,
>   where different registrars offer different periods of initial 
>   registration in the same TLD, sometimes for different prices. 
> 
> * I've made the expiration date optional, to cater for the case
>   where objects are registered indefinitely (rare for domain names,
>   common in some other identifier spaces). 
> 
> * I've added a hint that protocol designers may wish to consider
>   time deltas. This seems to make more sense if you've got registrars
>   proposing expiry times, to allow for network delays and clock skews. 
>   To illustrate the issue here, consider a registrar asking for a 
>   one-year registration from a registry whose policy allows
>   registrations only in one-year increments, where the registrar's
>   clock is behind the registry's by m minutes, and where network 
>   congestion induces an n-minute delay in transmission. Given an 
>   absolute time, the registry may reject the request as being (n+m) 
>   minutes short of a year.
> 
> -- Geva
> 

Date: Wed, 20 Dec 2000 15:25:44 -0500
From: Geva Patz <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Expiration times [was Re: domreg BOF Meeting Minutes]
Reply-To: [email-masked]
Mail-Followup-To: 'provreg List' <[email-masked]>
Sender: [email-masked]

OK, given the chorus of approval on the idea that the
registration period wording  needs to change, here's a proposal
for some specific wording. How about changing this:

< [1] The protocol MUST provide services to register Internet domain
<  names.  The registration period for domain names MUST be measured in
<  years, with a minimum period of one year and a maximum period defined
<  by registry policy.

Into this:

> [1] The protocol MUST provide services to register Internet domain
> names, and SHOULD allow for the registration of other unique
> alphanumeric identifiers.
>
> [2] The protocol MUST allow registrars to specify an optional 
> expiration date for each object registered, and MUST allow 
> registries to accept or reject the proposed expiration date based
> on their local policies. Dates MAY be specified either as
> absolute times or as forward deltas from the time of actual
> registration. 

Notice that I've sneaked a few other things into here, too, besides
the relaxation of the exiration requirement:

* I've hinted at the more general applicability of the protocol in
  the SHOULD clause of [1]

* I've moved the focus of specifying an expiration date from the 
  registry to the registrar, while still allowing the registry to 
  have ultimate policy control over the duration of registrations. 
  This, to my mind, better mirrors the situation in the real world,
  where different registrars offer different periods of initial 
  registration in the same TLD, sometimes for different prices. 

* I've made the expiration date optional, to cater for the case
  where objects are registered indefinitely (rare for domain names,
  common in some other identifier spaces). 

* I've added a hint that protocol designers may wish to consider
  time deltas. This seems to make more sense if you've got registrars
  proposing expiry times, to allow for network delays and clock skews. 
  To illustrate the issue here, consider a registrar asking for a 
  one-year registration from a registry whose policy allows
  registrations only in one-year increments, where the registrar's
  clock is behind the registry's by m minutes, and where network 
  congestion induces an n-minute delay in transmission. Given an 
  absolute time, the registry may reject the request as being (n+m) 
  minutes short of a year.

-- Geva

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes
Date: Wed, 20 Dec 2000 11:46:51 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

Greetings, all. This point is well taken, in that our registry system does not
measure the registration length in years, but instead uses an "expiration
date." While that is currently set to n years past the current date, there's
no reason it has to be.

I can foresee a future in which a .movie domain, for example, might
sell 6-month registrations. Or an annual-event registry might sell
pro-rated registrations for "the rest of the year," all set to expire
on 31 December.

--
Christopher Ambler
CTO, Image Online Design, Inc.
The .Web Internet Domain Registry
[email-masked]

> >  The registration period for domain names MUST be measured in
> >  years, with a minimum period of one year and a maximum period
> >  defined by registry policy.
> 
> Although this captures the current situation in most gTLDs (and
> many ccTLDs) accurately, there's absolutely no reason to make
> the minimum period of a year a high-level requirement. In fact,
> there's a good reason not to: a protocol designed literally
> to this requirement might include a validity counter with a
> resolution in years, making it impossible for registries to
> implement a policy with finer resolution.

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes 
Date: Wed, 20 Dec 2000 17:06:51 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Scott,
    
    I am really hoping that someone (or multiple someones) will
    take the time to point out the specific text that they feel
    encroaches on policy issues.  We've found one situation, minimum
    registration period.  If you know of others please post them
    to the list.

Yes, it was my intention to go over the document and post them all
at once, but I need some time. I discussed some of them with Jorg
Bauer of the German ccTLD. I will ask him to post his objections
as well.

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Ross Wm. Rader'" <[email-masked]>, "'provreg List'" <[email-masked]>
Subject: RE: domreg BOF Meeting Minutes
Date: Wed, 20 Dec 2000 10:59:32 -0500
Sender: [email-masked]

Yes, and the draft currently states that point quite clearly.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Ross Wm. Rader [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 11:02 AM
To: 'provreg List'
Subject: Re: domreg BOF Meeting Minutes

> Bill,
>
> That's a policy decision.  The requirement is intended to define the units
> of measurement, and registry policy should determine the actual minimum
> value.

And maximum I would assume...

-rwr

From: "Ross Wm. Rader" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes
Date: Wed, 20 Dec 2000 11:01:38 -0500
Sender: [email-masked]

> Bill,
>
> That's a policy decision.  The requirement is intended to define the units
> of measurement, and registry policy should determine the actual minimum
> value.

And maximum I would assume...

-rwr

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jaap Akkerhuis'" <[email-masked]>, Geva Patz <[email-masked]>
Cc: "'provreg List'" <[email-masked]>
Subject: RE: domreg BOF Meeting Minutes 
Date: Wed, 20 Dec 2000 10:56:01 -0500
Sender: [email-masked]

Jaap,

I am really hoping that someone (or multiple someones) will take the time to
point out the specific text that they feel encroaches on policy issues.
We've found one situation, minimum registration period.  If you know of
others please post them to the list.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Jaap Akkerhuis [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 10:36 AM
To: Geva Patz
Cc: 'provreg List'
Subject: Re: domreg BOF Meeting Minutes 

Geza,

    On Wed, Dec 20, 2000 at 10:06:48AM -0500, J. William Semich wrote:
    > Many (the majority?) of the ccTLDs require a minimum two-year initial
    > registration period.
    
    Precisely my point. Minimum and maximum initial periods and renewal 
    periods are all policy issues, not protocol issues. The protocol should
    allow policy to be expressed, but shouldn't dictate policy through
    design limitations. We shouldn't even mandate that registrations need
    expire: although the contrary is true only in a small minority of cases,
    we should nonetheless cater for these cases, particularly if we envisage
    the protocol potentially being used to register other classes of objects
    (AS registrations, for instance, don't expire). The protocol should
    allow an expiry date to be specified, but shouldn't require it, and
    certainly shouldn't constrain it to one-year resolution. 

You beat me in time, but this is also my point. In the GRRP draft
are more places where were policy issues are specified as protocol
issues. Talking to the German ccTLD peole, they had the same problem
with the draft; policy issues are mixed with the protocol issues.
It might be natural for someone from NSI/Verisign to mix them in,
but if you have a different policy, one tends to notice this.

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'J. William Semich'" <[email-masked]>, Geva Patz <[email-masked]>, "'provreg List'" <[email-masked]>
Subject: RE: domreg BOF Meeting Minutes
Date: Wed, 20 Dec 2000 10:49:48 -0500
Sender: [email-masked]

Bill,

That's a policy decision.  The requirement is intended to define the units
of measurement, and registry policy should determine the actual minimum
value.  That specific text can certainly be changed to make it more clear
that the intention is to define units and not policy.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: J. William Semich [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 10:07 AM
To: Geva Patz; 'provreg List'
Subject: Re: domreg BOF Meeting Minutes

Many (the majority?) of the ccTLDs require a minimum two-year initial
registration period.

Bill Semich
.NU Domain

At 09:50 AM 12/20/00 -0500, Geva Patz wrote:

<snip>

>Finally, we should probably go through the draft to make
>sure that there aren't any small details in it that aren't
>requirements per se. An example is this sort of thing:
>
>>  The registration period for domain names MUST be measured in
>>  years, with a minimum period of one year and a maximum period
>>  defined by registry policy.
>
>Although this captures the current situation in most gTLDs (and
>many ccTLDs) accurately, there's absolutely no reason to make
>the minimum period of a year a high-level requirement. In fact,
>there's a good reason not to: a protocol designed literally
>to this requirement might include a validity counter with a
>resolution in years, making it impossible for registries to
>implement a policy with finer resolution.
>
>This is the only example that leapt out at me on my first few
>passes, but a closer reading may yield other, similar situations
>where current practice should not be reflected as a requirement.
>
>Geva Patz
>[email-masked]
>
>
Bill Semich
President and Founder
WorldNames, Inc.
http://www.worldnames.net
[email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jaap Akkerhuis'" <[email-masked]>
Cc: "'provreg List'" <[email-masked]>
Subject: RE: domreg BOF Meeting Minutes 
Date: Wed, 20 Dec 2000 10:32:03 -0500
Sender: [email-masked]

Jaap,

Yes, Mark took the notes but they are being reported by me.  What you see
written isn't what Mark wrote.  I recall only two people _saying_ anything
significant about draft discomfort, hence the wording in the minutes.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Jaap Akkerhuis [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 8:42 AM
To: Hollenbeck, Scott
Cc: 'provreg List'
Subject: Re: domreg BOF Meeting Minutes 

Hi,

    Minutes of the domreg BOF
    14 December 2000
    49th IETF
    San Diego, CA
    Reported by Scott Hollenbeck <[email-masked]>

Maybe I'm mistaken, but I actually that Mark Kosters was the official
scribe at this BOF.

You state that:

    One speaker was not comfortable with the requirements etc.

But not only this speaker was not comfortable with the requirements.
Patrick Falstrom did a poll whether there were more uncpomfortable
people. Quite some hands were raised. My wild quess is at least
20. You probably haven't seen it due to the fact that most of these
were seated behind you.

Later this week I will try to send spme of my problems with the
draft to this list.

	jaap

To: Geva Patz <[email-masked]>
cc: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes 
Date: Wed, 20 Dec 2000 16:36:04 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Geza,

    On Wed, Dec 20, 2000 at 10:06:48AM -0500, J. William Semich wrote:
    > Many (the majority?) of the ccTLDs require a minimum two-year initial
    > registration period.
    
    Precisely my point. Minimum and maximum initial periods and renewal 
    periods are all policy issues, not protocol issues. The protocol should
    allow policy to be expressed, but shouldn't dictate policy through
    design limitations. We shouldn't even mandate that registrations need
    expire: although the contrary is true only in a small minority of cases,
    we should nonetheless cater for these cases, particularly if we envisage
    the protocol potentially being used to register other classes of objects
    (AS registrations, for instance, don't expire). The protocol should
    allow an expiry date to be specified, but shouldn't require it, and
    certainly shouldn't constrain it to one-year resolution. 

You beat me in time, but this is also my point. In the GRRP draft
are more places where were policy issues are specified as protocol
issues. Talking to the German ccTLD peole, they had the same problem
with the draft; policy issues are mixed with the protocol issues.
It might be natural for someone from NSI/Verisign to mix them in,
but if you have a different policy, one tends to notice this.

	jaap

From: "Ross Wm. Rader" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes
Date: Wed, 20 Dec 2000 10:30:03 -0500
Sender: [email-masked]

> The protocol should
> allow an expiry date to be specified, but shouldn't require it, and
> certainly shouldn't constrain it to one-year resolution.

Would it not make more sense to define a TTL within the payload that deals
with all time periods? If this is to be truly applicable to all models, we
must ensure that we move forward with the philosophy that this protocol will
be used predominantly in environments which do not yet exist (over the
longer term). It is highly likely that these environments will employ models
that also do not yet exist. Therefore, putting a stake in the ground around
"years" seems to be remarkably short-sighted in my mind. If we accomodate
for TTL's, we can let the applications sort out the expiry models.

Thanks,

-rwr

Ross Wm. Rader
Director, Innovation & Research
Tucows Inc.
t. 416.538.5492

Date: Wed, 20 Dec 2000 10:15:31 -0500
From: Geva Patz <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes
Mail-Followup-To: 'provreg List' <[email-masked]>
Sender: [email-masked]

On Wed, Dec 20, 2000 at 10:06:48AM -0500, J. William Semich wrote:
> Many (the majority?) of the ccTLDs require a minimum two-year initial
> registration period.

Precisely my point. Minimum and maximum initial periods and renewal 
periods are all policy issues, not protocol issues. The protocol should
allow policy to be expressed, but shouldn't dictate policy through
design limitations. We shouldn't even mandate that registrations need
expire: although the contrary is true only in a small minority of cases,
we should nonetheless cater for these cases, particularly if we envisage
the protocol potentially being used to register other classes of objects
(AS registrations, for instance, don't expire). The protocol should
allow an expiry date to be specified, but shouldn't require it, and
certainly shouldn't constrain it to one-year resolution. 

-- Geva

Date: Wed, 20 Dec 2000 10:06:48 -0500
To: Geva Patz <[email-masked]>, "'provreg List'" <[email-masked]>
From: "J. William Semich" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes
Sender: [email-masked]

Many (the majority?) of the ccTLDs require a minimum two-year initial
registration period.

Bill Semich
.NU Domain

At 09:50 AM 12/20/00 -0500, Geva Patz wrote:

<snip>

>Finally, we should probably go through the draft to make
>sure that there aren't any small details in it that aren't
>requirements per se. An example is this sort of thing:
>
>>  The registration period for domain names MUST be measured in
>>  years, with a minimum period of one year and a maximum period
>>  defined by registry policy.
>
>Although this captures the current situation in most gTLDs (and
>many ccTLDs) accurately, there's absolutely no reason to make
>the minimum period of a year a high-level requirement. In fact,
>there's a good reason not to: a protocol designed literally
>to this requirement might include a validity counter with a
>resolution in years, making it impossible for registries to
>implement a policy with finer resolution.
>
>This is the only example that leapt out at me on my first few
>passes, but a closer reading may yield other, similar situations
>where current practice should not be reflected as a requirement.
>
>Geva Patz
>[email-masked]
>
>
Bill Semich
President and Founder
WorldNames, Inc.
http://www.worldnames.net
[email-masked]

Date: Wed, 20 Dec 2000 09:50:40 -0500
From: Geva Patz <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes
Mail-Followup-To: 'provreg List' <[email-masked]>
Sender: [email-masked]

On Tue, Dec 19, 2000 at 03:09:01PM -0500, Hollenbeck, Scott wrote:

> Comments from the floor were generally
> positive about the state of the requirements, though one speaker
> suggested some additional text at the beginning of the I-D to note
> that the requirements were defined for a specific operational model
> and that other models exist.  One speaker was not comfortable with
> the requirements, though he had not provided any specific concerns
> to the mailing list.  In the end it was agreed that a little more
> work is needed to finalize the requirements draft before it can
> be considered complete.

Speaking as at least one of the "one speakers" mentioned above,
let me restate my concern to clarify: As it currently stands,
the requirements capture the current model (multiple registrars,
single registry per repository) well. This isn't, however, the
only possible model. I'm aware of more than one ccTLD that wishes
to implement a replicated registry model, where the repository is
replicated amongst the registrars. It's entirely possible that
one or more of the gTLDs may move in that direction, too. As
technology evolves, it's possible to imagine even a distribued
repository model.

I'm not suggesting that it is the job of this group to design
a replicated registry database. I don't even believe that the
architecture for such a thing needs to be standardized. I do,
however, believe that in our requirements we should make it
explicitly clear that whatever we design should be flexible
enough to accommodate these different models. It would be a shame
to go through all the effort of developing a standard that only
has narrow relevance to one specific model.

Fortunately, relatively little needs to change in the
requirements to accommodate this, most of it early on. I'll have
a go at wording the changes shortly.

While I'm on the requirements, a couple of other comments:

The section on security could do with some expansion. In
particular, it would be a good idea to elaborate somewhat on
the trust assumptions that should underlie any protocol design.
One of the problems with the one protocol proposal that we've
seen so far (draft-hollenbeck-epp-00.txt) is that it assumes
trust between registrar and registry, and between registrant and
reigstrar (and hence, implicitly, registry).

I won't spend much time at this point going into the mechanics
of trust in the EPP proposal, because we're still in the
requirements phase, but the main point I'm trying to make is
that we should state in the requirements that any protocol
design should assume no trust between any pair in {registrant,
registrar, registry}. This implies, for instance, that any
authentication credentials given to the registrant by the
registry to confirm registration (and hence allow updates) should
not be passed in the clear through the registrar. It implies a
certain amount of care in the design of the query operation, to
prevent 'false positives' being given. Again, details such as
these are more protocol design issues than requirements issues,
but I do believe that the 'no trust' assumption (along with
some of its conceptual implications) should be written into
the requirements draft. Once more, I'll try and write up this
proposal into something concrete later.

Finally, we should probably go through the draft to make
sure that there aren't any small details in it that aren't
requirements per se. An example is this sort of thing:

>  The registration period for domain names MUST be measured in
>  years, with a minimum period of one year and a maximum period
>  defined by registry policy.

Although this captures the current situation in most gTLDs (and
many ccTLDs) accurately, there's absolutely no reason to make
the minimum period of a year a high-level requirement. In fact,
there's a good reason not to: a protocol designed literally
to this requirement might include a validity counter with a
resolution in years, making it impossible for registries to
implement a policy with finer resolution.

This is the only example that leapt out at me on my first few
passes, but a closer reading may yield other, similar situations
where current practice should not be reflected as a requirement.

Geva Patz
[email-masked]

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'provreg List'" <[email-masked]>
Subject: Re: domreg BOF Meeting Minutes 
Date: Wed, 20 Dec 2000 14:41:52 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Hi,

    Minutes of the domreg BOF
    14 December 2000
    49th IETF
    San Diego, CA
    Reported by Scott Hollenbeck <[email-masked]>

Maybe I'm mistaken, but I actually that Mark Kosters was the official
scribe at this BOF.

You state that:

    One speaker was not comfortable with the requirements etc.

But not only this speaker was not comfortable with the requirements.
Patrick Falstrom did a poll whether there were more uncpomfortable
people. Quite some hands were raised. My wild quess is at least
20. You probably haven't seen it due to the fact that most of these
were seated behind you.

Later this week I will try to send spme of my problems with the
draft to this list.

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'provreg List'" <[email-masked]>
Subject: domreg BOF Meeting Minutes
Date: Tue, 19 Dec 2000 15:09:01 -0500
Sender: [email-masked]

Minutes of the domreg BOF
14 December 2000
49th IETF
San Diego, CA
Reported by Scott Hollenbeck <[email-masked]>

(Sorry for the repeat -- I'm sending it again to get a copy into the list
archives, which didn't pick up the message sent earlier today.)

The goals and scope of the BOF were described as follows:

This BOF will assess interest in forming a working group to develop a
generic registry-registrar protocol for use in shared registration
systems.  The goal of the BOF is two-fold:

1. To determine if a working group should be formed to develop such a
protocol, and

2. To produce draft goals and an outline for a charter if there is
interest in forming a working group.

The scope of the BOF will be limited to technical issues associated with
protocol development, including:

- Discussion of existing Internet-Draft requirements for a generic
registry-registrar protocol.
- Discussion of interest in forming a working group to develop a
generic protocol.
- Presentation of an existing published protocol proposal.
- Working group goal and charter development.

First presentation document reference:
draft-hollenbeck-grrp-reqs-05.txt

The first presentation covered requirements for a generic protocol for
use in shared registration systems.  The presentation described the
how the need for requirements was identified, how the requirements
were developed, and the state of the requirements today.  At the
conclusion of the presentation the question was asked if the attendees
felt that the requirements draft represented community consensus,
noting that such consensus was apparently reached on the discussion
mailing list two months ago.  Comments from the floor were generally
positive about the state of the requirements, though one speaker
suggested some additional text at the beginning of the I-D to note
that the requirements were defined for a specific operational model
and that other models exist.  One speaker was not comfortable with
the requirements, though he had not provided any specific concerns
to the mailing list.  In the end it was agreed that a little more
work is needed to finalize the requirements draft before it can
be considered complete.

After this presentation the question was asked if there was
sufficient problem definition and interest in forming a working group
to develop a standards track protocol.  After discussion of the
anticipated purpose and expected outcome, the clear opinion of the
group was "yes".

Second presentation document reference:
draft-hollenbeck-epp-00.txt

The second presentation described a protocol proposal that was
developed to meet and exceed the requirements described in the first
presentation.  The presentation described the problem as more than a
domain name registration problem, but as a generic object provisioning
problem.  XML was shown to provide a way to define a simple base
protocol that separates object semantics from the protocol itself.
The presentation described a layered approach to manage transport,
security, and object provisioning.  Comments from the floor were
positive, with several people noting that such a general provisioning
approach is far more desirable than a narrow domain name registration
approach.

The final portion of the BOF was dedicated to brainstorming ideas
about the scope and charter of a working group.  The first point of
agreement was that the focus should not be only on domain name
registration, but on the more general problem of object provisioning.
A person from the floor volunteered a draft charter, and a few minutes
were spent looking at the draft to see if people were generally
comfortable with it.  There was some debate about the amount of time
needed to complete working group tasks, with the general consensus
being that people preferred to try to get work items completed as
quickly as possible.  Some minor changes were made on the floor, and
agreement was reached to continue the discussion on a new working
group mailing list.  It was agreed that both charter development and
requirements completion can proceed in parallel, with the charter
completion date targeted for 5 January 2001.

The name of the working group mailing list was quickly discussed, and
the name "provreg" (for provisioning/registration) was agreed upon.
A person agreed to create the list as quickly as possible, and the
name was announced to all: [email-masked].  Subscription
requests will be managed by [email-masked].

Scott Hollenbeck
VeriSign Global Registry Services

To: [email-masked]
Subject: Logger test nr 1
From: Lars-Johan Liman <[email-masked]>
Date: Thu, 14 Dec 2000 16:44:53 -0800
Sender: Lars-Johan Liman <[email-masked]>
Lines: 1

foo bar baz