[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
cc: ietf-provreg@cafax.se
From: Jaap Akkerhuis <jaap@sidn.nl>
Date: Fri, 12 Jan 2001 15:48:45 +0100
Sender: owner-ietf-provreg@cafax.se
Subject: Some more comments on your grrp-reqs-05.txt (second try)


Hi Scott,

Some comments over the last part of the draft.

	jaap


About 3.12 Lock status Indicators

At 3.12.[1] there is quite a list of indicators the MUST be
provided. It might well be possible that some of these states are
in fact mandated by the policies of the registry. Further more, it
is all concentrated on ``the domain''. Does this mean the domain
it self, the data associated with this or both?

We (.nl) do have
several types of lock states:

	a) domain holder might non-be changed but name server
	   changes are allowed and domain is published

	b) domain might not be transferred between registrars but other
	   changes are allowed

	c) domain is reserved by the registry (things like .co.nl,
	   .com.nl etc.)

	d) domain is blocked for registration (things like
	   killthequeen.nl etc.)

	e) more you don't want to know about


Maybe a MAY should be used in the second sentence.

8.2.[1] ... SHOULD operate without human intervention.

This going to be difficult for registries which have heavy policies.
Some registries might have policies that requires human intervention.
For instance, it might be necessary that information is needed
which cannot be serviced by the protocol. As an example, the registry
might need to check a Dun & Broadsheet document if only commercial
entities are aloud in .com.XX or a trademark ownership proof for
a .tm.XX. For these type of registries it will be difficult to do
that. But maybe the SHOULD here covers that.

8.4

I would leave out the Zulu stuff. That is way too much an American
culture thing. So drop it also from the time format. BTW, Isn't
there already an IETF standard how time formats are described (ntp
RFC)?

Home | Date list | Subject list