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

[Dave Piscitello]

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.

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

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

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