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

[MICHAEL YOUNG]

Exactly, but there already seems to be a fair bit of debate already on
which of those scenarios should play out.

I think/believe if we catalogue and prioritize the requirements that have
already been gathered in various documents, a natural consensus may fall
out as to what path needs to be followed.

This thread feels a bit like a debate over the best way to layout the
foundation of a house, without a set plan on the size of the house or how
many rooms it should have.

Overall planning aside for a second, my past experience in dealing with
legacy infrastructure leads me to think the second scenario is probably
the fastest path to solving for the immediate IDN issues. I think the IDN
issues should take top priority on a list of current requirements.

-M


On 11-03-04 3:33 PM, "Jay Daley" <jay at nzrs.net.nz> wrote:

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