RE: comments on last draft

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

Thanks for your comments, Olivier.  I'll address them below.

<Scott/>

>-----Original Message-----
>From: Olivier Guillard [mailto:Olivier.Guillard@nic.fr]
>Sent: Tuesday, April 10, 2001 12:12 PM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se; tech@nic.fr
>Subject: comments on last draft
>
>
>Dear Scott and all,
>
>Afnic is the .fr registry. We have read this draft:
>http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-01.txt
>with a great interest.
>
>We thank you for this job that contribute harmonizing
>practises.
>
>We wished to ask you some questions and express ideas
>about certain chapters found in this document either
>because we don't understand them or because they doesn't
>matche our practises.
>
>For an easier reading:
>
>Each point is framed by a ** REM ***...
>The chapters titles are given
>The particular suggestions added in the original text are underlined
>                                                          ^^^^^^^^^^
>Regards,
>
>
>Olivier
>
>
>1. Introduction
>---------------
>
>** BEGIN REMARK ***************************************************
>
>Thin Registry: A registry in which some element of the social information
>               associated with registered entities is distributed between
>               a shared registry and the registrars served by the registry.
>
>Thin Registry: A registry in which all elements of the social
information...
>                                   ^^^
>
>just a comment here: there is no definition for those registries that
>                     validate information (social and/or technical)
>					 stored and published for a given
TLD.
>					 
>
>** END REMARK ***************************************************

I'm OK with the suggested change; I can't think of any social information
that we maintain in the thin VeriSign registry as an example.  There's no
additional definition for a "validating" registry because I didn't see
validation as a model discriminator.

>3.4.2 Object Registration
>-------------------------
>
>** BEGIN REMARK ***************************************************
>
>  [3] 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 IPv4 or IPv6 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's TLD is itself a valid TLD.
>
>.fr db don't need independant name server objects today. We understand
>that name servers objects can be useful, but only in certain environment
>and only if their maintenance are associated with relevant policie
>usage (like contacting the techs that maintain domains served by a
>nameserver being suppressed for example). 
>
>Anyway, the time spent to check the integrity of existing datas under
>certain environment does not justify today the implementation of such
>a feature, for us, it shouldn't be a requirement.
>
>Morover, if it's implemented, we don't see why the IP address should be
>required. It is only necessary when a given NS serves a zone under which
>it's referenced.
>
>For example:
>
>If exemple.fr is served by ns.exemple.fr, then we need the IP of
>ns.exemple.fr as glue.
>If exemple.fr is also served by ns.example.com or ns.dupont.fr it's
>not our buisness to announce the IP address of those hosts, so why
>ask for this information? (we check that these NS are properly
>resolved before announcing exemple.fr)
>
>We would suggest a "SHOULD" and a "MAY" here:
>
>  [3] The protocol SHOULD (or even MAY) 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 MAY be registered with a valid
>                                ^^^
>  IPv4 or IPv6 address.
>
>
>** END REMARK ***************************************************

I think we've covered this particular requirement very thoroughly in another
thread.  I disagree with the change from MUST to SHOULD or MAY in the first
sentence; we know for a fact that there are registries that require this
feature.  The second MUST will be changed to a SHOULD with an explanation of
when it has to happen.

>** BEGIN REMARK ***************************************************
>
>  [4] The protocol MUST provide services to manage name servers that MAY
>  be associated with multiple domains.
>
>Why again (see above)?
>
>  [4] The protocol MAY provide services to manage name servers that MAY
>                   ^^^
>  be associated with multiple domains.
>
>
>Something like:
>
>"The protocol MAY provide services to manage multiple domain name
maintaining."
>
>Would be another way of maintaining multiple domain changes
>
>
>** END REMARK ***************************************************

See my response above.  There is no requirement for a registry that doesn't
need this feature (or other server management features) to use it.

>3.4.3 Object Association
>------------------------
>
>** BEGIN REMARK ***************************************************
>
>  [2] The protocol MUST provide services to associate IP addresses with
>      name servers. Name servers MAY have multiple IP addresses.  An IP
>      address MAY be associated with multiple name servers.
>
>Once again, we don't see why IP addresses of NS should be required.
>
>--->  A name server MAY NOT be associated to any IP address.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>** END REMARK ***************************************************

Again, this is a required feature for some other registries.  If AFNIC
doesn't need it, you won't be required to use it.

>** BEGIN REMARK ***************************************************
>
>  [4] Some managed objects represent shared resources that MAY be
>  referenced by multiple registrars.  Requests to associate a known
>  shared resource object with another registered object MUST NOT be
>  limited to the registrar that sponsors the registered objects.  For
>  example, server ns1.example.com (managed by registrar X) MAY be
>  associated with both domain example.com (managed by registrar X) and
>  domain test.com (managed by registrar Y). Registrar X maintains
>  administrative control over domain example.com and server
>  ns1.example.com, and registrar Y maintains administrative control over
>  domain test.com.  Registrar Y does not have administrative control
>  over server ns1.example.com.
>
>A question here: what happens to test.com if example.com is removed?
>
>And another more important one:
>Who is responsible for the db integrity?
>
>
>** END REMARK ***************************************************

If example.com is removed, server ns1.example.com will have to removed or
renamed.  test.com will have to be updated to note the change.  Each
client/registrar is responsible for the integrity of the objects they
sponsor.

>3.4.5 Object Transfer
>---------------------
>
>** BEGIN REMARK ***************************************************
>
>  [2] The protocol MUST provide services to transfer social information
>  objects among authorized registrars.
>
>This point is sensitive, because personal information do not have the
>same status in each country. For example we have implemented a red list
>for domains belonging to individuals.
>
>
>** END REMARK ***************************************************

Agreed -- how this is managed will be a registry policy matter.

>** BEGIN REMARK ***************************************************
>
>  [6] The protocol MUST provide services that allow the original
>  sponsoring registrar to approve or reject a requested object transfer.
>  Requests to approve or reject the transfer of registered objects MUST
>  be limited to the registrar that currently sponsors the registered
>  object.  Unauthorized attempts to approve or reject the transfer of a
>  registered object MUST be explicitly rejected.
>
>For how long? What happens if the registrant WANTS to transfer his/her
>domain and the current registrar doesn't? is there any grace period?
>
>the real point is: where is the user here?
>
>** END REMARK ***************************************************

"How long" and grace periods are a registry policy matter.  It will be up to
each registry to figure out what works for them.

>3.4.7 Object Deletion
>---------------------
>** BEGIN REMARK ***************************************************
>
>All sub chapters
>----------------
>
>whois responsible for the db integrity?
>
>
>** END REMARK ***************************************************

Each client is responsible for the integrity of the objects they sponsor.

>3.4.8 Object Existence 
>----------------------
>
>** BEGIN REMARK ***************************************************
>
>  [2] The protocol MUST provide services to determine if a name server
>  exists in the registry.  Name servers MUST be searchable by fully
>  qualified name.
>
>->  [2] The protocol MAY provide services to determine if a name server
>                     ^^^
>see above
>
>** END REMARK ***************************************************

See my responses above as well.

>** BEGIN REMARK ***************************************************
>
>  [3] The protocol MUST provide services to determine if a social
>  information object exists in the registry.  Social information MUST be
>  searchable by a registry-unique identifier.
>
>What if this information is not connected to any domain name object?
>For example, I personally think that it should be cleaned up and in
>all cases NOT published anymore (issue to manage in 3.4.8)
>
>** END REMARK ***************************************************

A registry or registrar could certainly clean up contacts with no active
associations, but I don't think that's protocol requirement.

>3.4.9 Object Information Query
>------------------------------
>
>** BEGIN REMARK ***************************************************
>
>  [2] The protocol MUST provide services to retrieve information
>  describing a name server from the registry. 
>
>->  [2] The protocol MAY provide services to retrieve information...
>                     ^^^
>
>see above
>
>
>** END REMARK ***************************************************

Me too, see above.

>** BEGIN REMARK ***************************************************
>
>  [3] The protocol MUST provide services to retrieve social information
>  from the registry.  Returned information MUST include identification
>  attributes (which MAY include name, address, telephone numbers, and
>  e-mail address), the identifier of the registrar that originally
>  registered the information, the creation date and time, 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
>  most recent authorization information and identifiers describing
>                                            ^^^^^^^^^^^^^^^^^^^^^^
>  domain names associated with the social information
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>** END REMARK ***************************************************

This gets into another thread that's currently open on the mailing list,
that of queries returning what Klaus has called "reverse" associations.  I
don't believe that such a feature is proper in a provisioning protocol, but
it is appropriate for a query protocol or reporting service.

>3.5 Domain Status Indicators
>----------------------------
>
>** BEGIN REMARK ***************************************************
>
>SUGGESTION:
>
>One of the states could be "validation process". A domain name
>could then be pending waiting for (for example) an intermediate
>service or a third party validation.
>
>It would allow to implement the following (page 19):
>
>"However, intermediate services that preserve the integrity of the protocol
>MAY be provided. For example, an intermediate service that determines if a
>registrant is authorized to register a name in a TLD MAY be provided."
>
>
>** END REMARK ***************************************************

Could be, but the states listed in the draft are only suggestions, not a
list that MUST be implemented.  The suggested "newly created" state could
also be used to indicate that something (such as validation) is going on
between creation and activation.

>7.6 Security
>------------
>
>** BEGIN REMARK ***************************************************
>
>  [1] Transactional privacy and integrity services MUST be available at
>  some protocol layer.
>
>  [2] This document describes requirements for basic user identification
>  and authentication services.  A generic protocol MAY include
>  additional security services to protect against the attacks described
>  here, or a generic protocol MUST depend on other-layered protocols to
>  provide additional security services.
>
>==> What do "basic user identification and authentication services"
>consist of? Why isn't AUTHENTICATION at least as important as PRIVACY
>and INTEGRITY (presence of MUST key word)?
>
>** END REMARK ***************************************************

Identification and authentication requirements are described in section 3.2,
and there are indeed MUSTs used to describe them.