Re: [gnso-dow123] oPOC proposal re Whois

[Ross Rader <ross@xxxxxxxxxx>]

Steve Metalitz wrote:
> The following is offered as a head start on tomorrow's Task Force
> discussion.   
>  
> The proposal recently put forward by Ross strikes me as a useful
> contribution that is worth further discussion.  However, a number of
> issues need to be clarified. 
>
>  

Thanks for the thoughtful list of questions Steve - happy to elaborate.

> 1.         The key phrase in the proposal - "primary operational point
> of contact  (oPOC)" - is left undefined.  How this phrase is defined
> could well be determinative of the acceptability of the proposal.  

These terms were picked as being "self-evident", but I can see where 
some explanation is required. The intent is that at the time of 
registration, that the registrant specify contact details for the 
person(s) or entity(ies) responsible for the operation of the domain 
name. It is useful to think of this new contact type as a merger of the 
three previous contact types. The analogy given during the drafting 
sessions was that the registrant is like the building owner, and the 
operational point of contact is like the building superintendent. When a 
water main breaks in the parking garage, its useful to know the contact 
information for the person - the opoc - who can shut it off.

>  
>
> 2.         The relationship between the existing categories -
> administrative or technical contact - and the new category - oPOC - is
> unclear.  The second pre-supposition in the third paragraph of the
> overview suggests that the same data would be collected as today.
> (Actually the RAA does not address what information is collected, only
> what information is displayed and/or submitted to the registry.)  Would
> the registrant simply be asked to designate one of the two existing
> categories of contacts as the oPOC?  I note that there is a proposal
> later in the document to address this issue in the Inter-registrar
> Transfer Policy but not elsewhere.  

The operational point of contact is intended to replace the existing 
contact types (except the registrant).

>  
>
> 3.         Where would this proposal leave bulk access or third-party
> providers of Whois data"  (Pre-supposition 1 seems to suggest they would
> no longer exist.)  

What is presupposition 1? The proposal is silent on the issue of bulk 
access. No changes are proposed to the current mechanisms for accessing 
whois either (which would include 3rd party users).

>  
>
> 4.         Leaving aside how the admin and tech contacts become the
> oPOC, my comparison of the proposal to what data registrars must publish
> now (Art. 3.3.1 of RAA) is that the following items no longer would be
> required to be published:
>
>  
>
> *       postal address of registered name holder
> *       fax numbers for contacts
> *       creation and expiration date
>
>  
>
> Is this correct?    What about nameserver IP addresses, which are now
> generally included in Whois output though that is not specified in RAA
> (it seems under the proposal that these would be available from registry
> but not registrar?)?  

This list is correct. These, and the nameserver IP addresses, would be 
considered optional for publication under this proposal.

>  
>
> 5.         Can more detail be provided about the concern with
> publication of additional data by registries (as some registry
> agreements now require)?  Issue 3 under "Motivations" refers to "legal,
> operational and technical confusion" - please explain.  

There are no operational or technical reasons for registrars to provide 
registries with customer contact information for publication in a 
publicly accessible database. Further, the information in these 
databases is often out of sync, leading to registrant and 3rd party 
confusion (expiry dates are the most frequent source of this type of 
confusion.).

>  
>
> 6.         Re the section on correcting inaccurate Whois data, would a
> time limit for any step be specified?  

I think specific minimum time periods are always useful to ensure that 
the intended targets are met. This document doesn't specify what timely 
means, but a final policy recommendation should.

>  
>
> 7.         Re point (d) of this section, what if the inaccuracy involves
> some element of the Whois data other than the e-mail address? 

This proposal only deals with contactability, not data accuracy. The 
intention is to ensure that through some means, that someone can be 
contacted. However, if one good piece of contact data is mandated, this 
can easily be used as a bootstrap for any future accuracy requirements.

>  
>
> 8.         In this section, is the "standardized mechanism" intended to
> refer to WDPRS or a refinement/expansion of WDPRS, and is the intent to
> rule out any obligation to respond to notices of alleged inaccuracy
> received in any other way?  

The proposal is silent regarding the method of implementation, except to 
state that the mechanism be standardized. This would rule out use of 
non-standard mechanisms.

>  
>
> 9.         The issues listed under "Motivations" all seem worthy of
> discussion.  The opening of that section seems to suggest that all would
> need to be resolved before the proposal could be implemented.  Is that
> the intention of the authors of the proposal?  

That paragraph should be made more clear. The intent of the statement 
was actually that some of the issues we discussed definitely needed to 
be dealt with as part of the policy development discussion, some as part 
of implementation and some, perhaps at a future date. For instance, 
issue #4 could be dealt with outside of this discussion, but should 
certainly be looked at as part of the whois discussion at some point 
(hopefully sooner than later). I think there's a consensus view on the 
question of which items need definitive answers prior to ratifying 
policy on the matter - the task force should definitely have a 
conversation on this particular point.

Hope this helps.

-ross