RE: comments on your grrp-reqs-05.txt (second try)

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Thanks, Jaap.  I'll answer your questions etc. below.

<Scott/>

> -----Original Message-----
> From: Jaap Akkerhuis [mailto:jaap@sidn.nl]
> Sent: Monday, January 08, 2001 7:34 AM
> To: Hollenbeck, Scott
> Cc: ietf-provreg@cafax.se
> Subject: comments on your grrp-reqs-05.txt (second try)
> 
> 
> 
> 
> Scott,
> 
> Here are promised comments on the draft. I'm afraid it is not
> complete, it goes up to page 13 (section 3.9). I do have some
> comments about the rest but they are still sketchy and not really
> worked out.  But I believe that for now there are enough things
> which need attention.
> 
> I'm aware that some have already been discussed and are maybe a
> repeat. Others might be more questions about (mine) improper
> interpretation. For some I will try to formulate some replacement.
> text, but, not being an American native speaker, they might not be
> as precise as desired. Therefore I will add the motivation in the
> hope that the meaning my remarks become clear.
> 
> Regards,
> 
> 	jaap
> 
> About 2.2 System Functions
> 
> This section describes also whois is services that the registry
> might provide. I would suggest to some text in the style of:
> 
> 	Details about the functionality of this whois functions
> 	are is not covered in this document.

Agreed, I'll add such text.

> 
> About 3.1 Session Management
> 
> Since is a high level description it might be wise to make some
> statement about what happens when the session is premature aborted.
> Something in the line of:
> 
> 	[7] The protocol MUST have a way to deal with premature
> 	aborted sessions. For example, roll back of the current
> 	transaction.

Agreed, I'll add such text.

> About 3.3 Transaction identification
> 
> I'm worried about the role that this has in the protocol. It might
> be that it is just my view, but I consider that the registration
> of a domain name, the change of a nameserver, the transfer of a
> name to another registrar, etc, each separate transactions. And to
> have some kind of idea per transaction is not bad (For example,
> when the session is interrupted during the transaction).
> 
> However, the way it is used (See 3.7, Object Transfer) it seems to
> me that this ID is actually an encoding for a domainname-registrar
> pair. It only changes when this relation ship changes. Correct me
> if I'm wrong and please explain the role in the protocol.

The idea here is that there needs to be a registry-unique "key" that can be
used to unambiguously identify every transaction performed by the server on
behalf of a client.  Both client and server know the "key", so both have
information that can be used to reconcile client-server activity.  No client
knows the "keys" associated with the transactions of any other client.

This uniqueness plays into my motivation for using these identifiers in the
transfer process.  While a thick registry may have end-customer information
that can be used to authenticate transfer requests, a thin registry may not.
The protocol has to provide a transfer mechanism that works equally well in
both environments.

The transaction identifier is known to the sponsoring client and the server.
If the client (registrar) also provides the identifier to the registrant,
the registrant can take the identifier to a second registrar (who won't know
the identifier by any other means) to facilitate a transfer.  If the
protocol requires this identifier to process transfer actions, transfer
mistakes or unauthorized transfers should be minimized.

> 3.4.[2]
> 
> This has been discussed before. I just want to add that in .nl (and
> as far as I now in .de land) there is no expiration date. For
> nl.domains is a maintenance fee (quarterly, .de monthly I believe).
> Of course if that payment is stopped, the domainname expires
> automatically. So that is a form of expiration, but I find it
> difficult to put it in wording.

Yes, the next version of the draft will clearly note that domains do not
necessarily have an explicit expiration date.  I don't want to get anywhere
near trying to explain in this document how expiration might happen due to
billing issues, and I think everyone will agree that it's out of scope.

> 3.4.[3]
> 
> 	``A request  Must have a transaction identifier ... ''
> 
> If it is a request for a new domain, should the registrar generate
> this? It looks like a bootstrapping problem to me, I'm confused
> but might just not understand. Also

I think I need to reword this text to make it clear that an identifier MUST
be associated with the transaction, but how it happens is up to the protocol
designers.

> 	``The transaction identifier MUST be returned to the 
> registrant ...''
> 
> This sounds as a requirement to how the registrar operates and is
> outside the scope the registry/registrar protocol. At least, I
> haven't seen how the protocol can enforce this.

If the identifier is needed to authorize a transfer (which I believe is a
Good Thing), the identifier has to get to the client (new registrar) who
issues a transfer request.  The protocol can enforce this by not processing
a transfer action without the identifier, but perhaps this requirement
should be changed to not touch on registrar-registrant interaction.

> 3.4.[4] & 3.4.[5] Name servers & Glue records
> 
> Yes, I do agree that the protocol MUST be able to use nameservers
> with out-of-zone nameservers (example.com might have 
> ns1.nameserver.net
> as nameserver). But the fact that one should not have glue records
> for is actually not part of the protocol requirements. It is more
> part of how to run a proper nameserver. Maybe, instead of the
> wording about the glue records, we should have a reference to one
> or more of the current RFCs which  deal with the care and feeding
> of nameserver? Something like:
> 
> 	Glue records for out of zone nameservers MUST not be in the
> 	zonefile, according to RFC XXXX.
> 
> might probably be enough.

I need to defer to Patrik here since the original text was added at his
request.  One of my original instructions from the IESG was to stay away
from describing _how_ the protocol should do anything in this document, and
instead describe _what_ the protocol needs to do, leaving the "how" to the
protocol design documents.  I could generalize this requirement a bit to say
something like "Glue records for out of zone nameservers MUST be managed
according to current DNS standards" (which says _what_ must happen, but not
_how_ it happens), but I think Patrik had some specific reasons for wanting
this text more explicit.  Patrik?

> 3.4.[6] contact information
> 
> I have the feeling that the required contact information might be
> too detailed in certain cases. If the registry/registrar relation
> is very thin it is possible that just information over the registrar
> might be sufficient. (But then one can argues thses also have a
> name, address etc. so it won't hurt.

True, but the protocol has to support both thick and thin models.  It's
important to distinguish between what the protocol has to do to support
multiple models, and how each registry may use the protocol.  Section 2.4
says that an underlying assumption is that a registry may choose to
implement a subset of the required protocol features, and this is one area
where I think registries will choose to do things differently based on local
policies.

> 3.4.[7] telephone numbers must conform to international standards
> 
> ``The good thing about standards is that there are so many to choose
> from'' (Andy Tanenbaum). Maybe we should have a reference to a
> specific standard. (The ENUM RFC uses I-TU E.164 if not mistaken).

Agreed, but this gets into "how" vs. "what".  I'd prefer to keep this
requirement as-is, leaving the specific reference to the protocol documents.

> 3.4.[8] identifiers
> 
> The mention of ``contact identifier'' remembers me of NIC-handles.
> I'm also not so sure that all the mentioned identifiers are actually
> necessary in an actual protocol. Maybe the MUST should become a
> MAY?

I think there has to be some kind of unique key associated with every
object.

> 3.4.[9]  grace period
> S
> This requirement borders on policy issues. Some policies for updating
> certain objects might not allow for a grace period (but then, I
> realize, you can always set the period to 0).

Agreed, this requirement will not be in the next version.

> 3.4.[10]
> 
> I looked at this form various points to try to get the 
> meaning of this.
> I'm afraid I don't get it. The first sentence is fine:
> 
> 	``All registrars MUST be authorized to register 
> S
> and seems obvious to me (Wasn't this the gaol of the protocol?).
> But the bit about nameservers registration is unclear to me.  Does
> this say that registrar X, Y and Z are not a low to share a nameserver
> (possible hosted by registrar A?). I'm probably just confused.

No, this text shouldn't be interpreted as not allowing "sharing" of a name
server once it has been registered.  That's perfectly OK.  The intention is
to describe which registrar can register and manage name servers within a
registered domain.

> 3.5.[1]
> 
> Remark to 2nd sentence: Some registry require minimal two nameserver
> (but that is policy).

Agreed, and that's why there's nothing in the document to describes minimums
or maximums.

> 3.5.[2]
> 
> The last two sentence, state more a fact then that it is a 
> requirement.
> They might just as easily be dropped.

I think they need to be here to ensure that the protocol provides features
to allow this kind of behavior, which is supported by the DNS.

> BTW, it is the policy of the .nl registry that, to avoid clutter
> and unnecessary glue records in the zone file, that one should not
> have the same nameserver under multiple names. I also believe that
> this is the strongly advised to do so in one of the ``how to run
> nameservers'' RFC. Maybe a reference should be supplied?

This is one of those areas of distinction between what the protocol needs to
do to support multiple models and how a registry might implement the
protocol.  I'd prefer to see a "how" reference in the protocol documents.

> 3.5.[4]
> 
> (Especially the last sentence of) This item actually deals more
> with how to run nameservices then with the Registry/registrar
> relations.  I'm not sure whether this should actually be in this
> document.

This requirement is the one that says that the protocol must allow
registrars to reference name servers registered by other registrars.

> 3.6.[4]
> 
> Seems for me stating the obvious. But maybe is het necessary for
> legal reasons or has it to deal with 3.4.[10] which I didn't get?

Obvious, yes, but we can't forget obvious requirements.

> 3.7 Object Transfer
> 
> I have serious problems with this section. It seems to me to
> concentrate on transfer between registrars. However, it doesn't seem
> to deal with transfer of objects between registrant (domain name
> holders). Or maybe I'm too much focused on the word ``transfer''.
> One might actually say that the last case (transfer between
> registrants) is actually an update of an object. Is that the case?
> Actually one can draw a matrix the way things might be transferred:
> 
>           registrant A      registrant B
>         ---------------------------------
> 	|                |               | registrar X
>         ----------------------------------
>         |                |               | registrar Y
>         ----------------------------------
> 
> So I guess what is meant transfer is in a vertical direction, while
> transfer in horizontal direction is actually covered by update.
> Maybe some form of introduction it this style is needed somewhere
> in the document.

Nothing in this document addresses registrant-registry or
registrant-registrar behavior, except the mention of transaction identifier
management (which I can change).  I believe these interactions are out of
scope.

> Sections 3.7.[1] - 3.7.[7] describe the basics of the transfer of
> the objects between registrars. Apart from that, it does something
> else in the mean time. It actually defines policy matter: The
> original sponsoring registrar is able to block the transfer. Either
> (implicitly) by never releasing the current transaction identifier
> or directly by using 3.7.[7].
> 
> Whether or not a registrar is able to block such a transfer is a
> policy matter. Currently it is not allowed in the .nl registry (and
> as far as I know in .den either). Some time ago it was possible to
> do this in .nl, but on request of various registrars and given the
> experience gained, this is no longer the case. It turned out that
> when there were conflicts between registrant A and registrar X and
> A wanted to switched to registrar Y, X basically could take the
> domain from A hostage. Often the registry was dragged into the
> conflict to decide whether of not the domain was correctly taken
> ``hostage'', often was forced to take a side in the conflict. The
> conflicts can be arbitrary. Non-payment by A for services provided
> by X, non-delivery of services by X paid for by X, or just petty
> complaints, the dog of A has bitten the cat of X. You name it, we
> seem it all.
> 
> The task for a registry is to registry names. Even for conflicts
> whether or not someone has the right on a certain domain name is,
> for most registries not part of their job. For that are dispute
> arbitration thingies or courts of law. So to be dragged into
> arbitrary conflicts is even worse. Therefore we abolished this
> blocking. Other registries might have a different policies.
> 
> Anyway, I tried to reformulate 3.7.[1] and further in a policy
> neutral fashion, but failed miserably. But I do hope we can come
> up with something.

This feature has to be in the protocol (it's 100% required in the ICANN gTLD
world), but it sounds like transfer request blocking by the old registrar
should be an optional feature.

> 3.8. Renewal/Extensions
> 
> As said by 3.4.[2], some registry policies have automatic extensions,
> so this need some rethinking.

Yes, agreed, and the next version will put both sections in synch.

> Section 3.9 and 3.11 seems to handle the same type of subjects:
> Queries to the registry. Maybe they should either lumped together
> or at least change the order of 3.10 and 3.9.
> 
> As a general remark, there is some danger that with these queries
> too much information are leaked out of the registry and that it
> might be abused as an alternative for a whois service. These queries
> should be used just in the registration process. A registrar must
> be discouraged using these queries to, for example, search for
> potential customers which are actually served (``sponsored'' is
> the term used in the draft) by competing registrars.

I think the query types need to be separate, but perhaps switching the order
and adding text to better explain the difference would be a good idea.
We've seen a real need in the gTLD world for a very fast "is this object
registered" query that any registrar can perform, and then a potentially
more restricted query to obtain information about a registered object.  I
agree that query abuse is something we need to be aware of, especially in a
thick registry environment where contact information may be maintained.