Generalizing the terminology

[Catherine Murphy <cathym@arin.net>]

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.