[tech-whois] A follow up session in San Francisco?

Jay Daley jay at nzrs.net.nz
Fri Mar 4 20:29:58 UTC 2011


Hi Dave

On 5/03/2011, at 2:40 AM, Dave Piscitello wrote:

> Jay hello,
> 
> I have to respectfully disagree with your characterization of requirements,
> which I think is somewhat constrained by the implication that the intended
> application of a successor to WHOIS is for a domain name directory service.
> 
> The requirements for a general purpose directory service have been discussed
> many times. SSAC provided several reports to the GNSO summarizing its
> understanding of what these requirements are when asked by the GNSO. The
> GNSO service requirements cataloged these and other service requirements
> suggested in past WHOIS discussions. This is an ample (perhaps not
> exhaustive) set on which to design a protocol.

WHOIS is relatively unique in that it is in use in gTLDs, ccTLDs, RIRs and registrars as well as being used by the entire user community.  Any set of requirements needs consensus across all these communities.  As a member of the ccTLD constituency I had no idea about the discussions above and I'm pretty sure that the majority of my ccTLD colleagues would say the same.

> I'm also confused by some statements you make.
> 
> might provide capabilities worth considering.
> 
>> Speaking as a technical person I have no idea how any discussion on the
>> suitability of a protocol can take place if the requirements are not nailed
>> down first.
> 
> If we were talking about protocol development in the 1980s or 1990s I would
> agree. Since that time, protocols have largely been designed with
> extensibility in mind. That HTML and XML have this characteristic whereas
> IPv4 did not and we are now forced to brute force a new protocol in its
> place. 

I do not agree with your implied point that extensibility is some form of fundamental requirement that is accepted without discussion and which all existing protocols must be re-engineered to encompass.

>> This is the paragraph where the word "requirements" has disappeared.  For an
>> evaluation to be "purely technical" then it must consider how the protocol
>> meets current requirements.
> 
> If you say to a protocol engineer, "here is a catalog of requirements,
> please show me that your protocol meets them" and the engineer responds
> "here is a protocol and architecture and data model that can be extended to
> support whichever requirements you choose from this catalog and because it
> is extensible it's highly probable it can meet them too" then I don't see
> how we are in conflict over this point.

If we agree a) on the need for extensibility and b) what you describe as the catalog, then I too don't see any conflict.  It is those two steps I want discussion and consensus on.

>> This has clearly not happened in this case - instead the evaluation has
>> consider multiple changes to requirements and how the protocol might address
>> those.  There is no way a claim can be made that was a "purely technical
>> evaluation".
> 
> Sorry, I disagree for the reasons already cited.
> 
>> If chapter and verse is required, then here is a list of new or changed
>> requirements that were considered when evaluating the protocol, thereby taking
>> it out of the realm of "purely technical":
>> 
>> - Authentication and access control mechanism
>> - Query rate limiting mechanism
>> - Standardisation in query, output and error messages
>> - Support for Internationalised registration data and IDNs
> 
> So If I follow your argument, designing a protocol that can support these in
> an extensible framework (wherein you select/de-select the functionality by
> virtue of the service requests you generate from the application/use) is
> entirely incorrect because these might have a policy implication
> post-protocol development?

Before we do any design that enables these, either as core elements of the protocol or as extensions, we have to reach consensus on that as an approach.  

My main point is that any service that includes these is very different from WHOIS and should be considered as a new service independently of WHOIS.  I would be more than happy to support that but not a focus on replacing WHOIS without any evidence as to the need.

>> As explained above, to describe this a "technical WHOIS discussion list" is
>> incorrect and inappropriate.  It is a "requirements for a directory service"
>> discussion and yes that involves all constituencies.
> 
> I again respectfully disagree. I believe the parties involved have been
> diligent in examining this problem in a correct and appropriate manner. I
> believe we have acted precisely in the spirit and manner through which most
> Internet standards and best practices have emerged from the IETF. There is
> no intent to create an ICANN standard here. The fact that ICANN and ARIN
> staff intend to collaborate with other parties who happen to be part of the
> ICANN community is irrelevant to the IETF except for the value add of having
> individuals with a broad understanding of the potential applications of this
> protocol. 
> 
> It's very important to appreciate that the folks involved to date are
> technical staff who participate or have participated in IETF or ISO
> standards. Several have written or contributed to protocol RFCs. They are no
> less qualified to do protocol research and development than anyone in the
> Internet. Having been on the IESG for many years, I am fairly certain that
> the Internet standards community would consider the manner in which this
> body of technical experts is developing a protocol and I will venture that
> any work product from this group would undergo the same technical scrutiny
> as any other submitted work product.
> 
> I'm disappointed that you are so strongly opposed to this activity. I can
> tell you that I am first and foremost and technical individual, and that I
> believe the work this group is tackling is motivated by a strong desire to
> introduce a superior directory service for the betterment of the Internet.
> If it were not the case, I wouldn't be quite so passionate.

Let me try again to separate out the user requirements gathering process from the protocol development process.  

I have no doubt as to the skills, passion, commitment, intelligence, dedication, etc of those technical people engaged in this task who will deliver the protocol development.  

But none of that can overcome the simple fact that we do not have consensus on either the requirements for a new directory service or whether WHOIS should be replaced by that.  Discussion and delivery of that consensus is simply not a purely technical job.

Just to illustrate how deep the lack of consensus is - I know many in the policy world that would argue that a directory service with authentication is not at all superior to WHOIS and would not better the Internet.  

cheers
Jay

> 
> 
> 


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840




More information about the tech-whois mailing list