Whoisfix BOF 51st IETF / Minutes

[Dave Crocker <dcrocker@xxxxxxxxxxxxxxx>]

Folks,

Here are the excellent notes that Ted took, unchanged.  The polling cited 
at the end of the notes includes the list of possible task items suggested 
by attendees.

If there are no objections to these notes by this Friday, I'll post them to 
the IETF secretariat.

d/


Whoisfix BOF 51st IETF
Chaired by Eric Brunner-Williams and Dave Crocker August 9, 2001
Reported by Ted Hardie

Actions taken:  Mailing list for further work set as ietf-whois@xxxxxxx

                Agreed that charter needed revision.

                A set of initial candidate problems established and
                ranked Agreement reached that if those problems could
                not be solved on port 43 while maintaining backward
                compatibility, the group would cease as a whois group,
                potentially reusing the work to create a new protocol

Meeting Review:

The meeting began with agenda bashing; there were no changes to the 
published agenda as a result of the discussion

Dave started general discussion by noting that the scope of the effort is 
to "fix" whois, not ehance or extend it to be a replacement for LDAP or 
other mechanisms.  The key requirements that chairs see lie in satisfying 
the needs of Regional registries, Domain name registries (ccTLD and gTLD), 
and network operators.  Out of scope are trademark issues, law enforcement, 
and similar political fodder.

The charter given by the chairs when requesting the BOF further limits the 
scope to enabling technical changes to whois queries and does not and will 
not discuss policy related to keeping certain records or populating the 
data used to respond to whois queries.

The basic goals identified by the chairs are:

1) Standardize structured query format

2) Produce  mechanisms to allow for query redirection and server-server queries

3)Maintain interoperability among old clients, old servers, new clients and 
new servers

Initial timetable:
Sep 01:  Initial spec
Revisions Jan 2002
Spring: Done

With that background Marjann presented how they use whois and noted that 
APNIC uses a version of the RIPE NCC code for similar purposes, to whit: 
track IP and ASN allocation, maintain contact info, and maintain both 
reverse and forward domain name data.  Data are populated both by the RIPE 
NCC and the domain holders.  In addition, RIPE uses whois as part of its 
routing registry (RIPEDB), which registers some forms of routing info; this 
is based on RPSL a syntactically rich form which allows users to produce 
router configurations and which contains route object maintainer contact 
information.

The query language is structured (RPSL for the routing registry, 
attribute/value pairs for the IP data), but this is transparent to the 
user; the data are kept in databases and whois is an access method rather 
than a data description language.  The RIPE NCC server can act like a 
client, but the interaction is pure referral and provides no state for the 
interaction.

The domain data maintained by RIPE was initially on reverse domains for 
in-addr.arpa, but it can and has been used for forward data on behalf of 
cctlds.  More and more ccTLDs are moving out of the RIPE database; now only 
the top level domains are in RIPE, but referrals can be made to whois 
servers maintained by the individual ccTLDs.

Cathy Murphy then presented the ARIN whois use, which is similar to that of 
RIPE.  Notes that the principal issue facing them is scaling; the service 
runs at the saturation point of the servers involved.  Ran at 20 million a 
month at the beginning of 2000, moved up to 35 million by the end of the 
year, and then jumped when new servers were added.
Before the addition the query rate 14.54 queries/sec; post-addition it ran 
up to July 20q/sec.  Cathy also noted that her users have requested 
referral whois.  Users want referral whois.

Randy Bush then discussed use, noting that many ccTLDs run RIPE; and that 
ISPs commonly use the RADB and IRR.  There is a large community using a 
traditional "dumb" port 43 (i.e. no RPSL structure) for contact data.  He 
is aware of four software families: RIPE, ARIN (Forked from NSI), NSI, and 
RADB.  Andy Linton noted some ccTLDs (e.g.
New Zealand) have rolled their own.

Jaap then gave a brief report on the whois service for the Dutch ccTLD, 
noting that it limited each host to 500 queries a day queries . It is often 
used simply to test whether a name exists, so they have developed a 
light-weight response which notes only the state: exists, doesn't exist, is 
blocked.

George Michaelson noted that the APNIC has a confederation structure, which 
is reflected in the whois data; different members use different formats, 
which may be in country-specific character sets.
Nakayama-san noted as part of this that the Japanese data is in shift-JIS, 
with a note on how to obtain English versions.  As with other whois 
services, a clear concern in the APNIC reason is "grazing", the use of 
whois to obtain data on members, but a distinction is clear to the APNIC 
members that some forms (e.g. Geoff Houston's data association grazing) are 
valid.

Randy then gave a presentation of NIC handle info in the whois data at ARIN 
and RIPE, which notes that different registries have different identities 
attached to the same identifier, despite a hack that tries to use 
REGISTRY-handle method for associating data to the original handle.  This 
is partly because of RIPE's method of doing referential integrity (dumping 
the other database into their own).

Eric then noted that discussions within PROVREG have produced a document, 
draft-rader-dnwhois-defn-00.txt, which may be useful but likely will need 
to be split into a provreg area and a whois area.

Dave presented issues/desiderata for queries: a standardized query format, 
possibly expressed as a regularized query "template", so that independent 
of the content a common query format can be used; constrained XML mentioned 
as a format (later rejected; see below).
Dave then went through the related issues for responses: a structured 
output with standard labels, registered response codes, and the ability to 
redirect or refer.

Randy questioned the need for redirect/referral as a method of raising the 
question of how to develop the requirements; Patrik followed up by pointing 
out the transition issues and noting that we need strong indications of why 
individual fixes are needed so we can do the cost/benefit analysis of which 
changes and fixes get applied.

The first justification put forward was for structured output, as an aid to 
parsing; John Klensin replied that the current limits of the protocol are 
such that expecting to be able to process output from a whois query raises 
risks, and that it might be better to use a new port.

After discussion among John, Randy, and the room, it was agreed that it 
would be safe if the queries were not posed to arbitrary whois servers, but 
to an enumerated set which adhered to a published standard (such as the 
RFC2622 RPSL syntax).  This is one way around the transition issue as well.

Mark Kosters noted that this is a well known slope, and that the next thing 
will be a request for client capabilities; further steps and ultimate 
destination are also well known.  John and Randy agreed that a strict 
management of further feature creep is necessary, as is the avoidance of 
generics in the enumerated list (as in, all ccTLD whois servers).

Authentication and a well known format round out this update; Greg Block 
notes that once you have rounded it out it sounds a lot less like 
whois.  Mark Kosters further added that the original whois' function was as 
a public service with general availability.  The service this restricted 
set describes is not parallel, as it creates closed islands.  Randy 
disagreed, asserting that well-specified formats and enumerated serves gave 
a pretty broad scope, though any to any functionality is lost; consider a 
grocery format with an enumerated list of grocery servers-it can be used by 
anyone with the ability to parse the grocery format and access to the named 
servers as one example.

Dave then  proposed a process approach to the rest of the BOF:

Part one:  what problem do you want fixed?
Part two: what minimal approach would solve part one?
Part three:  rank these problems
Part four: partition the ranking statements and list the ones that we
        think we can do on port 43.

If there are requirements that we cannot do on port 43, we go to another 
port for all of the work this group may do.

Patrik noted that he does not like "or" or "if" in charters.  Dave agrees 
that this is appropriate and that if cannot happen on port 43, the group 
will report that it cannot complete and a new group *might* be chartered 
for a different port, but this group would shut down.

The group discussed this approach; there was discussion among Jordan, 
Bruce, Neil and others on whether we are "updating whois" or meeting the 
need for a protocol that solves a specific set of problems; while it was 
agreed that backwards compatibility does constrain possible solutions 
consensus seemed to be that if it is not restricted to port 43, there will 
be no progress.

Dave then stated his belief that we had ripped the current charter apart, 
and that it will need revision, but he hopes that we try to stay in this 
kind of time frame to encourage progress.  Some challenge on the 
practicality of this approach by Randy, but this would be cleaned up before 
resubmission to area directors.

Eric and Dave then reviewed other working groups salient to this work: 
provreg, idn, *ng, security?  Bill Manning noted that there are also people 
still revising and enhancing rwhois protocols and that it would be useful 
to coordinate with them.

Patrik rose to make the point that whois might not be the right tool for 
retrieving data and performing data calculation; he believe that because 
those clients try to machine parsing they have risks.  He suggests that 
those reports would be better produced by the people who have the data, 
rather than via whois.  Eric agreed that good stewardship is an alternate 
to good grazing, but it outside the scope of a working group to do more 
than encourage good stewardship

A discussion of candidates for the problem list was then held, with the 
following results:

Andy Newton:  Privacy and access control.
This was seen as mainly the work of the applications suing whois, but 
agreed that error codes for things like "Use exceeded" might be useful

Randy Bush: nic handle identity
Moderate interest by the group, with the synchronization element seen as 
probably out of scope.

Jordon: need for referrals.
        Strong interest by the group.

Bruce: standardized format for specified query
        Agreement by the group

George: backwards and forwards compatibility
        Agreed to survey existing implementations; attempt not to create 
incompatibilities.

Werner: whois query in URL format.
        Some exist, and this is a current APPs area requirement

Max: don't make it comment or use XML, as it won't be human readable
        Agreed with some objections.

Andy Newton:  should be transcribable query format.
        Agreed

Hans:  Coordination with ICANN policy requirements proposed and then withdrawn.


----------
Dave Crocker  <mailto:dcrocker@xxxxxxxxxxxxxxx>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464