Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

["Brian W. Spolarich" <briansp@walid.com>]

|   [1] The protocol MUST provide services to register Internet domain
|   names.
|
| Cool, suppose I dont use it for DNS? (Some of the registration we doing
| are not DNS based). And I believe Verisign/NSI _may_ consider using this
| for their PKI and ENUM stuff. Scott may confirm or deny (or remain
| silence) on this.

  This doesn't preclude the protocol from providing services to register
other kinds of objects. :-)

  As I read the requirements document 7.5[1,2] does encompass this need,
although the document places less emphasis on this than the MUSTs associated
with DNS registrations.

  I don't see why the specification and implementation cannot be generic
enough to encompass registration and association of other objects.

  I think its important that schema extensibility should be part of an
initial specification and implementations, and I can buy the argument that
the draft is a bit too DNS-focused (although in reality the problem that
this protocol is initially trying to solve is related to interoperability
for DNS registries and registrars.

  How about an organization like this:

  3.4  Object Registration

  [1]	Protocol MUST support registration of objects of multiple types,
including domain names, nameservers, and domain contacts.

  [2] Protocol MUST permit a starting and ending time, and SHOULD support
indefinite object registrations.

  [3] When an object has been successfully registered, protocol MAY return
an expiration date.

  [4] Per-registry unique TX ids and OIDs.

  [5] Object attributes which are telephone numbers must conform to
international standards.

  3.4.1 DNS-Related Objects

  <DNS-specific reqs>

  One thing that seems to be missing from the reqs is a description of the
non-object-related operations, such as protocol version, server information,
etc.  In the context of registering multiple object types you'd probably
want to also have an operation that would list the available classes of
objects that one can register and their attributes.

|   [5] The protocol MUST provide services to register name servers.  Name
|   server registration MUST NOT be limited to a specific period of time.
|   Name servers registered within the registry's authoritative TLDs MUST
|   be registered with a valid Internet Protocol version 4 (IPv4) or
|   version 6 (IPv6) address.  A name server MAY be registered with
|   multiple IP addresses.  An IP address MAY be shared among multiple
|   name servers using distinct server names. Name servers that exist in
|   TLDs other than those for which the registry is authoritative MUST be
|   registered without an IP address providing that the server TLD is
|   itself a valid TLD.
|
| Supposing I am a DNS registry who accepts names but associate it with
| something else rather than DNS? (e.g. I only do URL forwarding?) There
| are registries out that who is doing so.

  If you're doing URL forwarding then you (as the registrar) are providing
authoriative DNS for the domain holder, and you're going to have to register
name servers.  Or am I missing something here?

|   [10] All registrars MUST be authorized to register objects in the
|   registry.  Name server registration MUST be limited to the registrar
|   of the name server's parent domain.  Unauthorized attempts to register
|   a name server in a parent domain administered by another registrar
|   MUST be explicitly rejected.
|
| One of the conflicting Reqs which I am sure Scott understand. Conflict
| Case: Domain D1 with Nameservers NS1, NS2 registered thru Registrar R1
| and Domain D2 with also Nameservers NS1, NS2 registered thru Registrar
| R2? And who to say that the ISP must and only must use one registrar to
| work around this?

  I guess I'm dense, but I don't understand requirement 3.4[10] or James'
response.  Can someone provide a concrete example of the problem that this
requirement is trying to avoid?

  -bws