RE: My personal comments on the requirements.

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

>--------------
>  >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?:

[AC]Yes it would be overkill to do it in both BEEP and the protocol. But i 
still think it should be part of the requirements. If BEEP is used with the 
proposed protocol than BEEP will meet the negociation requirement. If BEEP 
is not used, the protocol should include this kind of negociation.

What do you think ?


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

[AC] This number is used for security measure while transferting domain 
objects between registrars. If this number is easily guessed it could be a 
security problem. Unless i've misunderstood the use of this identifier. 
That's why i thought it would be nice to have a random part in this number.


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

[AC] Yes you are correct, i've missed that definition :-( sorry.


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

[AC] I saw Patrick's response. I understand the need.

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

[AC] For each objects, registries may require additionnal fields. I'd like 
to see what other ccTLDs or gTLDs needs for the contact object or for other 
objects. I do not say that the objects are incomplete but i think that it 
should not be too restrictive. This way if such a need arise, than the 
protocol will not need an update to support a new field for the contact object.


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

[AC] That's fine with me.

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

[AC] If tagging it is not a requirement it may be omited in the 
specification and it would still meet the requirements. The goal of 
requirements his to state what the protocol specification must meet in 
order to achieve the specified task.

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

[AC] If IDN uses ACE format, it would still fit in the UTF-8 requirement 
since ASCII remains the same within UTF-8. I like the idea of Patrick. 
English MUST be use and local language in UTF-8 MAY be used for all 
elements other than domain name, and domain name should be expressed as 
UTF-8 (for now) and a new protocol version could deal with the result of 
the IDN wg when they will be done if it could not be done with UTF-8. For 
the way data is expressed (Patrick stated an example for sweden) it would 
be nice to have feeback from other countries.

If whois protocol is revised, it would be interesting to have an 
internationalized version of it. But it is not in the scope of this list. ;-)

______________________________________________________________________
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