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

[Jaap Akkerhuis <jaap@sidn.nl>]

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.


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.

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.

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.

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

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

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.

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.

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

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?

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

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.

3.5.[1]

Remark to 2nd sentence: Some registry require minimal two nameserver
(but that is policy).

3.5.[2]

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

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?

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.

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?

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.

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.

3.8. Renewal/Extensions

As said by 3.4.[2], some registry policies have automatic extensions,
so this need some rethinking.

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.