Re: draft-campbell-whois-00.txt
Allen Smith <easmith <at> beatrice.rutgers.edu>
2002-02-10 21:42:43 GMT
I apologize about the cross-posting, but this is something that
multiple lists are appropriate for discussing. The applicability of
ietf-whois and uwho should be obvious; the rfci-discuss <at> megacity.org
mailing list is for the http://www.rfc-ignorant.org project, which
(among other things) tries to reduce spam (and other network abuse)
burdens by providing blacklists (blocklists) of domains
(whois.rfc-ignorant.org) and IP addresses (ipwhois.rfc-ignorant.org)
which do not provide proper contact data (to which complaints about
spam and other abuse can be sent). (Even if one does not have time to
send complaints (even via automated means such as spamcop.net), I have
found that blocking those IP address blocks lacking adequate WHOIS
information to be useful in blocking spam in general - there is a
correlation between such and inadequate/nonexistent policies at ISPs
et al versus spam (or versus having an open relay which is used to
transmit spam). There is also the correlation that many spammers,
other than "mainsleaze" companies, tend to want to conceal their
postal addresses to prevent legal papers from being served on them
- Alan Ralsky, with his addresses located in the middle of the Hudson
River (which I am sorry to say his registrar, Joker.com, refuses to do
anything about), is a notorious example.) Given this anti-spam usage,
the RIPE anti-spam WG mailing list is also included.
On Feb 10, 1:35pm, Ed Allen Smith wrote:
> Network Working Group Bruce Campbell
> Internet Draft RIPE NCC
> Expires: May 2002 November 2001
> Updates: RFC954
>
> The basic NICNAME/WHOIS protocol
> draft-campbell-whois-00.txt
> Abstract
>
> This memo defines the basic WHOIS protocol as used on
> the Internet today.
Umm... it seems to have at least as much about policy - namely, claims
as to a lack of requirements of WHOIS service - as it does about the
actual _protocol_ as used today.
> The original reference document for WHOIS[RFC954]] specifies two items.
>
> The first being a simple server<->client question and answer protocol
> known as 'WHOIS', running on port 43 of a given machine. The second
> item specifies a number of requirements for placement of data within
> the 'SRI-NIC' database.
>
> The second item has caused much confusion and quasi-religious debates
> over the years, especially given that the 'SRI-NIC' database has been
> superceded several times.
True. Although there are a number of other RFCs that have implications
for WHOIS databases and their availability, as well as more
implications in RFC954 regarding WHOIS (as opposed to NICNAME) than
you are stating here:
RFC954, in its discussion of looking up records for users in the
SRI-NIC database:
"full name, U.S. mailing address, telephone number, and
network mailbox for DDN users who are registered in the NIC
database"
That portion of the RFC is, however, talking about the NICNAME
database, which while accessible via the same port is supposed to be
used _together_ with the WHOIS database:
"This server, together with the corresponding WHOIS Database
can also deliver online look-up of individuals or their online
mailboxes, network organizations, DDN nodes and associated
hosts, and TAC telephone numbers."
In interpreting this, see, for instance, bcp46:
"In addition, ISPs have a duty to make sure that their contact
information, in Whois, in routing registries [[10]RFC1786] or
in any other repository, is complete, accurate and reachable."
RFC3013:
"In addition, ISPs have a duty to make sure that their contact
information, in Whois, in routing registries [[10]RFC1786] or
in any other repository, is complete, accurate and reachable."
RFC2167:
"Early in the development of the ARPANET, the SRI-NIC
established a centralized Whois database that provided host
and network information about the systems connected to the
network and the electronic mail (email) addresses of the users
on those systems [RFC 954]."
"The original Whois function was to be a central directory of
resources and people on ARPANET."
RFC2167 extends this concept to rwhois.
RFC1834 on Whois++ also contains some information on what standard
whois is supposed to provide:
"NICNAME/WHOIS [HARR85] service is a TCP transaction based
query/response server, running on a few specific central
machines, that provides netwide directory service to Internet
users. The Network Information Center (NIC) maintains the
central NICNAME database and server, defined in [7]RFC 954,
providing online look-up of individuals, network
organizations, key host machines, and other information of
interest to users of the Internet."
And the following required fields from a server:
Individual records
Name Name of the individual required
Organization Name of the organization required
Handle A unique identifier for this required
record on the local server
Last-record-update Date this record was last required
updated
Host records
Hostname Full domain name required
IPAddress Address required
Domain records
Domain-name Domain name registered with required
the Network Information Center
(NIC)
Network-address Network address associated required
with this domain name
Admin-name Name of the Administrative required
Contact for this domain
Admin-address Postal address of the required
Admintistrative Contact for
this domain
Admin-telephone Telephone number of the required
Admintistrative Contact for
this domain
Admin-email Electronic mail address in required
[10]RFC 1822 format for the
Administrative Contact for
this domain
Tech-name Name of the Technical Contact required
for this domain
Tech-address Postal address of the required
Administrative Contact
for this domain
Tech-telephone Telephone number of the required
Technical Contact for this
domain
Tech-email Electronic mail address in required
[11]RFC 822 format for the
Administrative Contact
for this domain
Last-update Last date this record was required
updated
The requirements for an IP-address Registrar (including Local
Registrars as well as IANA, RIPE, APNIC, and ARIN) in RFC2050 are also
of interest:
1. Introduction:
[...]
3) Registration: Provision of a public registry documenting address
space allocation and assignment. This is necessary to ensure
uniqueness and to provide information for Internet trouble shooting
at all levels.
Please note in this the word "public" - the information in question is
to be disclosed to, essentially, whoever asks - and the information
that is needed - that used "for Internet trouble shooting", and that
this is needed information "at all levels". In other words, this RFC
acknowledges that information needs to be provided by any IP address
registry that will enable dealing with Internet problems, and this
information needs to be provided to _anyone_ who needs it to deal with
Internet problems. (Such Internet problems include, for instance,
spam, as acknowledged in other RFCs. They do not, per se, include
Intellectual Property issues, although I am glad of the support of the
Intellectual Property Community for WHOIS data being available (see
http://ipc.songbird.com/whois_paper.html).) A restriction on
disclosure to, for instance, "law enforcement" (as I have seen
proposed by some, such as CDT) is not workable. The postmaster of one
mail-receiving host (e.g., me) has just as much legitimate need for
such information as does the largest ISP, Registry, or Country.
It is in the interest of the Internet community as a whole that the
above goals be pursued. However it should be noted that
"Conservation" and "Routability" are often conflicting goals. All
the above goals may sometimes be in conflict with the interests of
individual end-users or Internet service providers. Careful analysis
and judgement is necessary in each individual case to find an
appropriate compromise.
Registries (including ccTLD registries as well as registries of other
domain names and of IP addresses), ICANN, IANA, et al do not exist for
the sake of their members, of the countries they are in, or anything
else other than in the interest of the Internet community as a
whole. Acting in the interest of that community is their
responsibility. To the degree they fail to disclose sufficient
information for "Internet trouble shooting", in a format accessible by
standard tools (i.e., whois, as specified by RFC954 and further
Internet-accepted documents) and, when such is needed (as in spam),
they are failing to live up to that responsibility.
To the degree possible, as it states, that compromises between the
interests of individuals and the interest of the Internet community as
a whole can be made, without significantly compromising the latter,
they of course should be. For instance, if a private individual with a
DSL line wishes a permanent IP address, it is perfectly reasonable for
them to ask for the ISP's contact information to be used for their
own, especially since dealing with problems is just as likely to be
the job of the ISP as it is of that particular individual. (This would
not be the case if the ISP is not capable (or willing) to deal with
problems, of course. The party in the contact information in WHOIS
must be capable of solving Internet problems.) ICANN's Registrar
agreement is also of interest in this regard:
Any Registered Name Holder that intends to license use of a
domain name to a third party is nonetheless the Registered
Name Holder of record and is responsible for providing its own
full contact information and for providing and updating
accurate technical and administrative contact information
adequate to facilitate timely resolution of any problems that
arise in connection with the Registered Name. A Registered
Name Holder licensing use of a Registered Name according to
this provision shall accept liability for harm caused by
wrongful use of the Registered Name, unless it promptly
discloses the identity of the licensee to a party providing
the Registered Name Holder reasonable evidence of actionable
harm.
I can see another possibility, at least in the case of IP addresses,
namely giving up the IP address block in question (and any fees
associated with it). This is necessary for privacy purposes, in that
the ultimate protection of the privacy of a registrant is if even the
Registry doesn't know who the person is - they thus cannot be
pressured (or otherwise forced, such as through a breakin) to disclose
it under inappropriate circumstances.
[...]
Section 4:
2. Regardless of the source of its address space,
sub-registries (Local IRs, ISPs, etc.) must adhere to the
guidelines of its regional registry. In turn, it must
also ensure that its customers follow those guidelines.
In the relationship between a local IR (e.g., a country IR) and the
regional registry, it is not appropriate for a regional registry to
claim that it has to follow the policies of a local IR, due to "lack
of data ownership" of data in a database, an individual country's
wishes as to data privacy (or data disclosure), etcetrea. The local
IRs are delegated to by the regional registry, not the other way
around.
> 1.2 Aims of this Document
>
> This document aims to provide an accurate definition of the basic WHOIS
> protocol used on the Internet today. It includes observed variations
> on possible queries and answers.
>
> This document does NOT provide definitions of the possibly sensitive
> subjects as follows:
>
> Data that must be registered in any Database
> Data that must be protected by Privacy Concerns
> Output Format of Data
Is there some particular reason why, at the minimum, either the
RIPE-181 or RPSL format should not be available (with others being
available at the option of the database operator)? (I personally favor
requiring RPSL, but realize that not all clients have been migrated to
parse it. Either it or RIPE-181 have the considerable advantage, as
opposed to other proposals such as XML, of being directly humanly
parseable without more than the simplest client interpretation. This
is of immense help for, for instance, client programming and
debugging.)
> Question Format (beyond a requirement for 'help')
>
> The above definitions are defined by the Registry operating a
> particular Database, and the Laws of that Registry's Country.
I suggest deletion of the above two lines, at the minimum. There are a
number of other factors which govern this:
A. Other RFCs, with their requirements for registries, et al;
see above.
B. Requirements of parent registries and of ICANN. The latter
has a section (3.3) in its Registrar Accreditation
Agreement (see
http://www.icann.org/registrars/ra-agreement-17may01.htm);
while a "registrar" and a "registry" do differ, effectively
a Registrar is acting as a Registry in regard to the
database - I regret that this agreement, or similar, is not
a requirement for all Registrars, including for
ccTLDs. (Lest anyone believe that I am being US-centric in
this regard, please be aware that the .us TLD is in the
whois.rfc-ignorant.org blacklist due to the lack of a .us
whois. I no more wish a US Registrar, even one fully
authorized by the US government, to be able to not publish
adequate WHOIS information than I do the Registrar for any
other ccTLD.)
I am, incidentally, curious in regard to the laws of various
countries, whether many (or even all) of them may be gettable around
via a direct requirement for permission of data disclosure in order to
get a domain name or IP address block - especially if such a
requirement is imposed by a "higher authority" such as ICANN/IANA or a
parent registry.
[...]
> 2. Requirements
[...]
> A public 'WHOIS' Server SHOULD have as one of its aliases, a
> hostname of 'whois', eg 'whois.example.com'.
Aliases? Unless you're meaning this in a different sense than I have
customarily seen it used, "alias" implies that this is not the (or a)
"real hostname" of the server in question (i.e., that which will be
returned by a PTR lookup (or will be among those returned by a PTR
lookup) and which is not the domain name for a CNAME record - in
common parlance, "is not a CNAME"). "SHOULD have as one of its
hostnames (or aliases)", perhaps?
> Such a Server MUST respond on the common 'WHOIS' port of
> '43'. [STD2]
Agreed.
> 2.2.1 Server Operator
>
> The Entity or Entities in charge of a given 'WHOIS' Server who is/are
> responsible for the behaviour and operation of a given Server. The
> Server Operator MUST report usage, problems (etc) with the 'WHOIS'
> Server to the Registry responsible for the Database. This implies
> that the Server MUST log usage of the Server in some fashion.
>
> The Server Operator, in addition to abiding by any restrictions set
> by the Registry, may add extra restrictions to the use of the Server,
> possibly dynamically in response to Client behaviour.
Except as required otherwise by the Registry and other RFCs, including
those governing the conduct of Registries, or as the welfare of the
Internet may dictate.
> 2.3 Registry
>
> The Entity or Entities in charge of a given Database which is
> accessible via a given 'WHOIS' Database. Normally, the Server
> Operator(s) and the Registry are the same Entities, however a
> distinction must be made between the two to reflect operational
> practice.
>
> Where the Registry is the custodian of Data covered by Privacy
> Restrictions, the Registry MUST enforce these restrictions.
Is there some reason why this needs to be in the RFC? Normally, such
"Privacy Restrictions" are imposed by laws (either privacy laws or
contract laws). If a country (or association of countries, such as the
EU) wishes to have and enforce such laws, they have their own means of
doing so...
> The Registry MAY also add extra restrictions to the use of it's
> Data/Database.
Again, so long as these do not conflict with rules by a parent
Registry, ICANN/IANA, or the welfare of the Internet community as a
whole.
> 2.3.2 Updating the Database
>
[...]
> The Registry may require certain information required for the
> Registry's Operation to be registered within it's Database.
>From the RFCs I have cited above, and the needs of the Internet for
contact and other information to deal with problems, this information
MUST be required by the Registry to be placed in the database and made
public.
> 2.3.3 Normal Usage of Data
>
> The exact usage of the Data within a Database is left for the
> Registry to define, however Data obtained via WHOIS has historically
> been for Internet Operational Purposes. Users should refer to the
> usage conditions imposed by a given Registry.
The data in such a database MUST be available to be used for purposes
needed by the Internet community.
[...]
> 3.2.1 Language and Character Set
>
> The 'WHOIS' Server operator MAY nominate a Language and Character Set
> to be used for any part of the 'Question'. If a Language or
> Character Set other than 'English' and 'US-ASCII' is expected from
> the Client, the Server MAY provide an initial banner message before
> the Question is asked, specifying the Language and Character set in
> use. [BCP18]
I suggest "SHOULD", at least for Character Sets other than
'US-ASCII', given possible problems with clients not expecting other
Character Sets.
[...]
> 3.3.3 Banner
>
> The Server MAY supply a Banner Message at three points during the
> connection:
>
> Immediately after initial connection,
>
> Immediately after the termination of the Question by the Client
> and before the output of the Answer.
>
> Immediately after the output of the Answer.
>
> To assist readability, the Banner Message SHOULD NOT exceed a polite
> 4 lines.
>
> The Client MUST display any Banner Message to the User without
> alteration.
Umm... including without, say, translation into a different language,
alteration of character set for display purposes, etcetera?
[...]
> 3.3.5 Warning Messages
>
> The Server MAY supply Warning Messages where part or all of the
> Question is inappropriate as defined by the Server Operator.
> Warning Messages should supply accurate and up to date information
> about the perceived problem with the Question, Connection or Client.
Is there some reason why this is not "SHOULD supply"?
[...]
> 3.3.6 Error Messages
>
> The Server MAY supply Error Messages where part or all of the Question
> is inappropriate as defined by the Server Operator. Error Messages
> should supply accurate and up to date information about the perceived
> problem with the Question, Connection or Client.
Ditto.
> 3.3.7 Rejection Messages
>
> These are a special form of Error Message for 'problem' Clients.
> They should clearly state why a given Question, Connection or Client
> has been rejected.
Ditto.
> 7. Full Copyright Statement
>
> Copyright (C) The Internet Society (2001). All Rights
> Reserved.
>
> This document and translations of it may be copied and
> furnished to others, and derivative works that comment on
> or otherwise explain it or assist in its implementation
> may be prepared, copied, published and distributed, in
> whole or in part, without restriction of any kind,
> provided that the above copyright notice and this
> paragraph are included on all such copies and derivative
> works. However, this document itself may not be modified
> in any way, such as by removing the copyright notice or
> references to the Internet Society or other Internet
> organizations, except as needed for the purpose of
> developing Internet standards in which case the
> procedures for copyrights defined in the Internet
> Standards process must be followed, or as required to
> translate it into languages other than English.
>
> The limited permissions granted above are perpetual and
> will not be revoked by the Internet Society or its
> successors or assigns. This document and the information
> contained herein is provided on an "AS IS" basis and THE
> INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
> DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
> INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
> IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
> PARTICULAR PURPOSE.
--
--
Allen Smith easmith <at> beatrice.rutgers.edu
September 11, 2001 A Day That Shall Live In Infamy II
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin
RSS Feed