My personal comments on the requirements.

[André Cormier <Andre.Cormier@viagenie.qc.ca>]

I got interested in this at last IETF in San Diego.

Here are my "humble" comments on the requirement documents. I think they
might be of interest. I've provided only the sections that i have
commented. We can spread different threads as needed to discuss them if
any of you agrees with these.

My comments starts with "AC: ".

Regards

André

 >1. Introduction
 >  This document is being discussed on the "rrp" mailing list.  To join
 >  the list, send a message to <majordomo@NSIRegistry.net> with the words
 >  "subscribe rrp" in the body of the message.  There is a web site for
 >  the list archives at <http://www.NSIRegistry.net/maillist/rrp>.
AC: Do not forget to point to the new mailing list...
--------------
 >3.2 Identification and Authentication
 >
AC: 2 new items proposed. New protocols allow for negociation of the
AC: authentication mechanism. This protocol one should be open enough to allow
AC: such negociation.
AC: [3] The protocol MUST provide services to allow the negociatoin of the
AC: authentication mechanism that will be used to authenticate registrar 
clients.
AC: [4] The protocol MUST provide services to advertise authentication 
mechanism
AC: supported by both the server and the client.
--------------
 >3.3 Transaction Identification
AC: I suggest we add a paragraph to clearly state that this number MUST be 
randomly
AC: generated so it would be nearly impossible for someone to guess what will
AC: be the identifier used by another registrar.
AC: [3] The unique transaction identifier MUST be randomly generated so it
AC: would be nearly impossible for someone to guess what number as been 
assigned
AC: to a registrar.
--------------
3.4 Object Registration
 >  [4] 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 (IP) 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.
AC: The protocol MUST allow the identification of the type of address. This
AC: way we will be able to add IPv6 addresses when the time will come. I do not
AC: say that we should include AAAA and A6 records. We should define a way that
AC: enables us to tag the type of address so it would be possible to 
register AAAA
AC: and A6 records in the future. We should support IPv6 to have less impact
AC: when the time will come.
 >  [5] The protocol MUST consider that the name server associated with a
 >  domain might not be registered in the same domain or even in a TLD for
 >  which the registry is authoritative.  This means that IP addresses for
 >  name servers whose parent domain exists in another TLD MUST be
 >  registered only in the registry that is authoritative for the TLD of
 >  the name server.  Glue records (DNS "A" records) MUST NOT be created
 >  for DNS NS records for which the registry is not authoritative.
AC: I do not think this is protocol related. It will be the registry 
application that
AC: will create the DNS zone file and glue records. It should not be state as a
AC: requirement. I caan easily see that as a comment in the protocol 
definition draft
AC: and a pointer to a companion document for best current practices.
 >  [6] The protocol MUST provide services to register contact information
 >  describing human and organizational entities.  Contact registration
 >  MUST NOT be limited to a specific period of time.  Contact
 >  registration MUST include a name (individual name, organization name,
 >  or both), address (including street address, city, state or province
 >  (if applicable), postal code, and country), telephone number, and e-
 >  mail address.  A facsimile telephone number MAY be provided.
AC: The protocol MUST allow for registry specific field for all objects managed
AC: by the protocol. Those field should be state as optional by the 
protocol but
AC: MAY be forced mandatory by the registry with the use of error codes stating
AC: that a specific field is required.
 >  [9] A registry MUST provide services to support a configurable grace
 >  period during which time a request to register a domain name or other
 >  billable object can be undone without harm.
AC: I think this should be The protocol MUST provides services... If it is the
AC: registry than it's not protocol related but policy issue or implementation
AC: issue and does not belong in that document.
--------------
3.5 Object Association
 >  [2] The protocol MUST provide services to associate IP addresses with
 >  name servers.  A name server MAY have multiple IP addresses.  An IP
 >  address MAY be associated with multiple name servers.
AC: The same comment apply here for IP address type. We should provide means
AC: to tag IP address type so it would be possible to add IPv6 addresses.
--------------
3.7 Object Transfer
 >  [5] A transfer request MUST include a new transaction identifier.  The
 >  new transaction identifier MUST be returned to the registrant by the
 >  registrar to facilitate authorization of future transfer requests.
AC: The same comment for this number. It should random as i said earlier.

 >  [10] A registry MUST provide a default transfer action in case of
 >  registrar inaction.  If a registry-specified period of time elapses
 >  without explicit approval, rejection, or cancellation, a registry MUST
 >  perform the default transfer action on behalf of the requesting
 >  registrar.
AC: This should not be in the requirements unless the action period MUST be
AC: speficied in the protocol or domain name object. If the action period 
is not
AC: part of the protocol than it is implementation issue or policy related and
AC: therefore should not be expressed in this document.
--------------
3.10 Object Deletion
 >  [1] The protocol MUST provide services to remove a domain name from
 >  the registry.  Deleting a domain name MUST also delete all child name
 >  servers.  A domain name MUST NOT be deleted if child name servers are
 >  being used to host other domain names.
AC: The first phrase should be left intact but the rest should be removed.
AC: This is an important issue but not really protocol related. I think that
AC: maybe another document should be written as implementation guide to state
AC: important issues related to domain name registration and DNS zone file
AC: creation. It is not the protocol that updates the database but the
AC: registry application. This applications uses the protocol to exchange
AC: with clients. This document defines functional requirements for the 
protocol,
AC: not the registry application. I really think that another document should
AC: be written for registries and registrars that will implement the 
protocol. It
AC: should be done as a companion document.

 >  [2] The protocol MUST provide services to remove a name server from
 >  the registry.  Name servers MUST be referenced by fully-qualified
 >  name.  A name server MUST NOT be deleted if it is being used to host a
 >  domain name.
AC: Same comment as above.

 >  [3] The protocol MUST provide services to remove a contact from the
 >  registry.  Contacts MUST be referenced by registry identifier.  A
 >  contact MUST NOT be deleted if it is associated with a domain.
AC: Same comment as above.
--------------
9. Internationalization Considerations
   [1] Current Internet standards restrict the encoding of Internet host
   and domain names to a subset of the 7-bit US-ASCII character set.
   Registries and registrars now serve customers whose native languages
   require encodings other than US-ASCII, which automatically disallows
   use of those languages when registering host and domain names.
   Support for internationalized host and domain names will greatly
   increase world-wide usability of a generic registry registrar
   protocol, so standards for internationalized host and domain names
   MUST be considered during the protocol design process.
AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable
AC: the use of internationalized data.


______________________________________________________________________
André Cormier                     | Téléphone : (418) 656-9254
2875 boul. Laurier                | Télécopie : (418) 266-5539
Bureau 300                        |
Sainte-Foy, (Québec) G1V 2M2      | Andre.Cormier@viagenie.qc.ca
Canada                            | Radio : VA2UNX, VA2ACE
----------------------------------------------------------------------
Internet Engineering Standards/Normes d'ingénierie Internet
                 http://www.normos.org
----------------------------------------------------------------------
PGP: D434 547D 712A E44F C978  4673 BD50 A248 C262 CB06