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

[Jay Daley]

Hi Michael

That's a good process but we need to separate out designing a new service from replacing the WHOIS.  We could end up with one of three scenarios:

- no change to WHOIS
- new directory service while existing WHOIS remains
- WHOIS changes significantly

cheers
Jay


On 5/03/2011, at 3:16 AM, MICHAEL YOUNG wrote:

> Hi Dave,
> 
> Ok that email was hovering on needing chapters and an index! :-)
> 
> Let me boil it down a little bit to simple terms, because I think I am
> observing a misunderstanding that anyone is on really different pages here.
> 
> 
> 1) I think we all agree some work is overdue on Whois,particularly around
> IDN issues.
> 2) I think we all can agree that the exhaustive list of "to do" items in
> Whois from various past efforts, could be clarified and maybe set in a
> prioritized list.  Since I don't see any single document that tells us
> exactly what we should get working on and in what order. If anyone has
> such a document that all the stakeholders in Whois (already in consensus)
> then please put it to the list!
> 
> Assuming such a document does not yet exist, I suggest:
> 
> That there are plenty of documents where we can pull a list of work
> requirements from without reinventing the wheel, Steve or Dave, perhaps
> you could collect them and post them to this list.  Then in San Fran, we
> can take a shot at itemizing them, and prioritizing them and flagging
> anything that anyone feels is missing.
> 
> Requirements in my mind are derived from both real world needs and
> technical best practises/intentions.  So in a really good project, I
> usually see a list of requirements from end users/consumers and a list of
> requirements from the engineers that have to develop and operate the
> system. Sounds like we have both scattered across multiple documents, and
> just need to spend a bit of time consolidating them into a common
> document, listed in a prioritization that everyone(all stakeholders) can
> agree to.  
> 
> Once that happens, it becomes relatively easy to start planning work and
> move forward. That's when I think the tech folks can get down to a "robust
> debate" on the best way to execute on/implement the work :-)
> 
> Michael
> 
> 
> 
> On 11-03-04 8:40 AM, "Dave Piscitello" <dave.piscitello at icann.org> 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.
>> 
>> 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.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> tech-whois mailing list
>> tech-whois at icann.org
>> https://mm.icann.org/mailman/listinfo/tech-whois
> 
> 


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