Re: draft-campbell-whois-00.txt

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 [email protected]
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			[email protected]
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