RE: Generalizing the terminology

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

Thanks for your detailed comments, Catherine.

While I understand people's comments about the requirements draft being very
domain name centric, it was explicitly done that way to define requirements
for a specific, narrow, manageable initial focus: domain names and data
associated with domain names.  As-is, I don't think there's anything in the
draft that precludes protocol extension to non-domain resources (to use
Catherine's term).

Not too long ago the idea of developing new requirements drafts for
non-domain resources was suggested by someone.  I'd much prefer that route
over trying to make the current requirements draft into something that it
wasn't meant to be from the start.

I agree that it would be a good idea to define the term "status" in the
context of a domain name before using it elsewhere in the document.

<Scott/>

> -----Original Message-----
> From: Catherine Murphy [mailto:cathym@arin.net]
> Sent: Thursday, February 08, 2001 12:44 PM
> To: ietf-provreg@cafax.se
> Subject: Generalizing the terminology
> 
> 
> 
> I would like to offer the following specific revisions in an 
> attempt to
> reduce the domain name emphasis of the draft. I know that some of the
> recent discussion has already affected the draft, but this 
> mark-up goes
> against the most recent posting of 
> draft-hollenbeck-grrp-reqs-06.txt.  As
> a general comment, I think the document is well thought out and very
> thorough. Scott has done a great job getting this started. I 
> also realize
> that some of my points have already been made. My goal is to offer
> specific alternatives to the existing text. Only the text containing
> proposed changes is included below; everything else has been 
> <snip'd>. 
> 
> ---------------------------------------------
> Cathy Murphy <cathym@arin.net>
> Principal Software Engineer
> American Registry for Internet Numbers (ARIN)
> +1 703 227 9875
> 
> << Based on draft-hollenbeck-grrp-reqs-06.txt (January 19, 2001) >>
> 
> 1.1 Definitions, Acronyms, and Abbreviations
> 
>   [NEW] Resource: A generic term used to describe an object that is
>   the primary focus of a registration process. An example of a 
>   resource is a domain name or an IP address block. Supporting 
>   objects such as contact information are not resources.
> 
>   << If you don't agree with having something along the lines 
>      of this new definition, don't bother reading further. 
>      Most of the changes revolve around this specific term.  >>
> 
>   Registrant: An entity that registers resources in a registry
>                                        ^^^^^^^^^
>   through the services provided by a registrar.  Registrants include
>   individuals, organizations, and corporations.
> 
>   Registrar: An entity that provides front-end resource registration
>                                                ^^^^^^^^
>   services to registrants, providing a public interface to registry
>   services.
> 
>   Registry: An entity that provides back-end resource registration
>                                              ^^^^^^^^
>   services to registrars, managing a central repository of information
>   for a specific portion of that resource, e.g., a given TLD. 
>  A domain 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              
>    ^^^^^^
>   name registry is typically responsible for publication and 
> distribution 
>   ^^^^
>   of TLD zone files used by the Domain Name System.
> 
> 2.2 System Functions
> 
>   Registrars access a registry through a protocol to register objects
>   and perform object management functions.  Required functions include
>   session management; object creation, update, renewal, and deletion;
>   object query; and object transfer.
> 
>   A domain name registry generates DNS zone files for the 
> TLDs it serves. 
>   ^^^^^^^^^^^^^ 
>   These zone files are created and distributed to a series of 
> name servers
>   that provide the foundation for the domain name system.
> 
>   Registries MUST provide a whois search capability that 
> provides basic
>              ^^^^
>   query services for the objects managed by the registry.  ...
> 
> 3.4 Object Registration
> 
>   [1] The protocol MUST provide services to register Internet domain
>   names.
> 
>   << Why? If the protocol is being used for non-domain name resources,
>      this particular requirement seems excessively 
> restrictive, perhaps
>      appropriate for a domain name extension to the "generic" RRP. >>
> 
>   [2] The protocol MUST permit a starting and ending time for a 
>   resource registration to be negotiated, thereby ...
>   ^^^^^^^^
> 
>   [3] When a resource has been successfully registered, ...
>              ^^^^^^^^
> 
>   [5] If the resource being registered is a domain name, the protocol 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   MUST provide services to register name servers.  ...
> 
>   << Since there has already been extensive discussion about 
>      nameservers being objects versus attributes, I will not 
>      comment further here except to re-iterate that this 
>      portion of the protocol is somewhat distinct to domain
>      name registries. >>
>  
> 3.5 Object Association
> 
>   [3] The protocol MUST provide services to associate contacts with
>   resources. Associated contacts name MUST be identified by type.
>   ^^^^^^^^^
>   Contact types that MAY be associated with a resource include
>                                               ^^^^^^^^
>   "registrant", "technical", "administrative", and "billing".  A
>   registry MAY support a subset of these contact types.
> 
>   << Also, "abuse" >>
> 
> 3.6 Object Update
> 
>   [1] The protocol MUST provide services to update information
>   associated with registered resources.  Resource update
>                              ^^^^^^^^^   ^^^^^^^^
>   services MUST allow changes to status, associated name servers, and
>   associated contacts.
> 
>   << As far as I can tell, this is the first mention of status. 
>      I would like to see the definition of status, which is not
>      defined until 3.12, either moved up or explicitly referenced. 
>      When I first read this, my immediate thought was "Huh? Did I 
>      miss something? What's a status?" >> 
> 
>   [2] If the registry includes registration of associated 
> nameservers, 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   the protocol MUST provide services to update information
>   associated with registered name servers.  Name server 
> update services
>   MUST allow change to IP addresses and server name.
> 
> 3.7 Object Transfer
> 
>   << A general comment about object transfer: this entire section is
>      very specific to how domain names are transferred and does not 
>      relate well at all to when and how IP networks may be 
> transferred. 
>      I cannot speak to how other possible users of the GRRP might work
>      transfers, but I will propose other, more generic text for this 
>      section in another message thread. Or, this section 
> could be left 
>      in the protocol but identified as being domain name specific
>      requirements only. >> 
> 
> 3.8 Object Renewal/Extension
> 
>   [1] The protocol MUST provide services to renew or extend 
> the validity
>   period of registered resources.  If applicable, ...
>                        ^^^^^^^^^
> 
> 3.9 Object Deletion
> 
>   [1] The protocol MUST provide services to remove a resource from
>   the registry.                                      ^^^^^^^^
> 
>   [2] If the registry contains nameserver objects, the protocol MUST 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   provide services to remove a name server from the registry.
> 
>   << A nit: since this is the protocol, shouldn't these say something
>      like "An implementation of the protocol MUST provide"... >>
> 
> 3.10 Object Existence Query
> 
>   [1] The protocol MUST provide services to determine if a resource
>   exists in the registry. ...                              ^^^^^^^^
> 
> 3.11 Object Information Query
> 
>   [1] The protocol MUST provide services to retrieve information
>   describing a resource from the registry.  Returned information MUST
>                ^^^^^^^^
>   include the identifier of the current sponsoring registrar, the
>   identifier of the registrar that originally registered the 
> resource, 
>                                                              ^^^^^^^^
>   the creation date and time, the expiration date and time 
> (if any), the
>   date and time of the last successful update (if any), the identifier
>   of the registrar that performed the last update, the date 
> and time of
>   last successful transfer request or completed transfer (if any), the
>   current status of the resource, the most recent authorization
>                         ^^^^^^^^
>       << another pesky status reference w/o definition yet >>
> 
>   identifier, contact identifiers associated with the resource, and, 
>                                                       ^^^^^^^^     ^
>   if applicable, the associated name servers registered to 
> the resource.  
>   ^^^^^^^^^^^^^^     ^^^^^^^^^^              
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>   The most recent authorization identifier MUST be returned 
> only to the 
>   current sponsoring registrar.
> 
> 3.12 Domain Status Indicators
> 
>   [1] The protocol MUST provide status indicators that identify the
>   operational state of a resource. ...  
>                          ^^^^^^^^
>   [3] A resource MAY have multiple statuses at any given time.  Some
>         ^^^^^^^^
>   statuses MAY be mutually exclusive.
>