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

[Dave Piscitello]

Saying that one is going to replace a protocol is often an unfortunate
choice of words, especially in an environment where flag day events are not
desirable. 

I'd characterize the current activity as seeking a successor to a protocol
that is suited to meet numerous directory service applications and thus able
to augment the existing Whois service with new features. The directory
service protocol/framework would be developed in the appropriate standards
venue (IETF), and the features would be determined in the appropriate policy
environment (ICANN, RIR, and whatever other organization might choose to use
the protocol). 

Specifically,

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

I don't see a case for item (3). I think items (2) is the correct
interpretation of the activity (think IPv4 transition to IPv6). I don't see
a need for (1) WHOIS protocol to change if (2) occurs.


On 3/7/11 12:12 AM, "MICHAEL YOUNG" <myoung at ca.afilias.info> wrote:

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