RE: My personal comments on the requirements.

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

André,

I think we're in agreement on all of the comments you've provided.  I can
reword requirements as described, and I can add a requirement to allow for a
registry-specific contact field if that's OK with everyone else.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: André Cormier [mailto:Andre.Cormier@viagenie.qc.ca]
Sent: Wednesday, December 27, 2000 12:20 AM
To: Provreg (E-mail)
Subject: RE: My personal comments on the requirements.



>--------------
>  >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 =
=3D
>to allow
>AC: such negociation.
>AC: [3] The protocol MUST provide services to allow the negociatoin of =
=3D
>the
>AC: authentication mechanism that will be used to authenticate =3D
>registrar=3D20
>clients.
>AC: [4] The protocol MUST provide services to advertise =
authentication=3D20
>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=20
still think it should be part of the requirements. If BEEP is used with =
the=20
proposed protocol than BEEP will meet the negociation requirement. If =
BEEP=20
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 =3D
>be=3D20
>randomly
>AC: generated so it would be nearly impossible for someone to guess =
=3D
>what will
>AC: be the identifier used by another registrar.
>AC: [3] The unique transaction identifier MUST be randomly generated =
so =3D
>it
>AC: would be nearly impossible for someone to guess what number as =
been =3D
>
>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=20
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.  =
=3D
>Name
>  >  server registration MUST NOT be limited to a specific period of =
=3D
>time.
>  >  Name servers registered within the registry's authoritative TLDs =
=3D
>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 =
=3D
>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. =
=3D
>This
>AC: way we will be able to add IPv6 addresses when the time will come. =
=3D
>I do not
>AC: say that we should include AAAA and A6 records. We should define a =
=3D
>way that
>AC: enables us to tag the type of address so it would be possible =
to=3D20
>register AAAA
>AC: and A6 records in the future. We should support IPv6 to have less =
=3D
>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 =3D
>a
>  >  domain might not be registered in the same domain or even in a =
TLD =3D
>for
>  >  which the registry is authoritative.  This means that IP =
addresses =3D
>for
>  >  name servers whose parent domain exists in another TLD MUST be
>  >  registered only in the registry that is authoritative for the TLD =
=3D
>of
>  >  the name server.  Glue records (DNS "A" records) MUST NOT be =3D
>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=3D20
>application that
>AC: will create the DNS zone file and glue records. It should not be =
=3D
>state as a
>AC: requirement. I caan easily see that as a comment in the =
protocol=3D20
>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 =3D
>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 =
=3D
>name,
>  >  or both), address (including street address, city, state or =3D
>province
>  >  (if applicable), postal code, and country), telephone number, and =
=3D
>e-
>  >  mail address.  A facsimile telephone number MAY be provided.
>AC: The protocol MUST allow for registry specific field for all =
objects =3D
>managed
>AC: by the protocol. Those field should be state as optional by =
the=3D20
>protocol but
>AC: MAY be forced mandatory by the registry with the use of error =
codes =3D
>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=20
to see what other ccTLDs or gTLDs needs for the contact object or for =
other=20
objects. I do not say that the objects are incomplete but i think that =
it=20
should not be too restrictive. This way if such a need arise, than the=20
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 =
=3D
>grace
>  >  period during which time a request to register a domain name or =
=3D
>other
>  >  billable object can be undone without harm.
>AC: I think this should be The protocol MUST provides services... If =
it =3D
>is the
>AC: registry than it's not protocol related but policy issue or =3D
>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 =
=3D
>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 =
=3D
>means
>AC: to tag IP address type so it would be possible to add IPv6 =3D
>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=20
specification and it would still meet the requirements. The goal of=20
requirements his to state what the protocol specification must meet in=20
order to achieve the specified task.

>--------------
>9. Internationalization Considerations
>    [1] Current Internet standards restrict the encoding of Internet =
=3D
>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 =
=3D
>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=20
since ASCII remains the same within UTF-8. I like the idea of Patrick.=20
English MUST be use and local language in UTF-8 MAY be used for all=20
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=20
the IDN wg when they will be done if it could not be done with UTF-8. =
For=20
the way data is expressed (Patrick stated an example for sweden) it =
would=20
be nice to have feeback from other countries.

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