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

[MICHAEL YOUNG]

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