RE: My personal comments on the requirements.

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

Thanks for your comments, André.  I'd like to respond and suggest some
alternative re-wordings if I may; my responses, suggestions, and rationale
are included below preceded by "[SAH]".

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: André Cormier [mailto:Andre.Cormier@viagenie.qc.ca]
Sent: Friday, December 22, 2000 1:49 PM
To: Provreg (E-mail)
Subject: My personal comments on the requirements.


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=E9

 >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...

[SAH] Yes, of course.

--------------
 >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=20
clients.
AC: [4] The protocol MUST provide services to advertise authentication=20
mechanism
AC: supported by both the server and the client.

[SAH] I don't have a problem with the basic idea here, but I'd like to
suggest that this doesn't need to be a MUST in the protocol itself.  Other
layers can do this as well; for example, BEEP offers just such a negotiation
mechanism and I think it would be overkill to do the negotiation within both
BEEP and another application layer protocol.  Would this re-wording be
acceptable?:

"[3] The protocol or another layered protocol MUST provide services to
negotiate an authentication mechanism acceptable to both the server and the
client."

I don't think the advertisement requirement is necessary if the mechanism
must be negotiated.  Some kind of information exchange has to happen as part
of the negotiation process.

--------------
 >3.3 Transaction Identification
AC: I suggest we add a paragraph to clearly state that this number MUST =
be=20
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.

[SAH] Actually, I prefer the text proposed by Geva last week that says that
each transaction must be "identified in a permanent and globally unique
manner".  Requiring randomization gets into "how" the protocol should behave
instead of describing "what" it should do.

--------------
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=20
register AAAA
AC: and A6 records in the future. We should support IPv6 to have less =
impact
AC: when the time will come.

[SAH] Section 1.1 states that the term "IP Address" means either or both
IPv4 or IPv6 address.  I'll modify the text in this section to clearly state
that support for both IPv4 and IPv6 addresses is required without specifying
how that support should be provided.

 >  [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=20
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=20
definition draft
AC: and a pointer to a companion document for best current practices.

[SAH] This text was added quite some time ago at the urging of our Area
Director.  I'll defer to Patrik to decide if we should remove this text or
reword it so that it's clearly not a protocol requirement.  Patrik?

 >  [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=20
protocol but
AC: MAY be forced mandatory by the registry with the use of error codes =
stating
AC: that a specific field is required.

[SAH] Can you be more specific about the purpose of this new field?  I'd
much prefer to enumerate required information vs. providing some kind of
unformatted registry-specific field.

 >  [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.

[SAH] I'd prefer to pull this requirement out of the document than to
require protocol support for something that isn't negotiated between
registrar and registry but is rather a registry policy issue.  OK to pull it
out?

--------------
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.

[SAH] I'd like to address this by again clearly stating required support for
both IPv4 and IPv6 address.  Tagging describes "how" that support is
provided, and is thus something that I think would be more appropriately
addressed in a protocol specification.

--------------
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.

[SAH] Actually I think this requirement should be removed because it
describes a "how" and not a "what".

 >  [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=20
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.

[SAH] I agree, so I'd like to remove this requirement.

--------------
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=20
protocol. It
AC: should be done as a companion document.

[SAH] Agreed, so I'll remove the text.

 >  [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.

[SAH] Agreed.

 >  [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.

[SAH] Agreed.

--------------
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.

[SAH] I'd prefer to reword the last sentence than to explicitly require
UTF-8 because it again addresses "how" to solve a particular problem.  How
about changing this:

"so standards for internationalized host and domain names MUST be considered
during the protocol design process"

to this:

"so standards for exchanging internationalized information MUST be
considered during the protocol design process"

I think that covers more than domain and host names without requiring a
specific solution.