Dave Crocker
2001-08-13 17:34:06 UTC
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-***@imc.org
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:***@brandenburg.com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.273.6464
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-***@imc.org
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:***@brandenburg.com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.273.6464