Subject: Re: Request to Move RFC 954 to Historic Status

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 05 Sep 2002 13:32:26 -0400

[ietf-whois and related lists]

I sat down with the European Commission's Call for Expressions of Interest
for the Selection of the .eu TLD Registry this week, and was pleased that
Directive 95/46/EC is the controlling framework for that registry's core
policy requirements (B.3, 1(b), Technical Annex, page 2). Here is the URL
to the EC's DP home: 

	http://europa.eu.int/comm/internal_market/en/dataprot/

That was my first imputus to finally submit an individual contribution to
move 954 from "DRAFT STANDARD" to "HISTORIC".

Now prior to Yokahama I asked around if anyone knew why and how (process)
954 had been moved from "UNKNOWN" (like 742 and 812) to "DRAFT STANDARD".
No one I asked knew, but I didn't bother to formally ask the IESG and/or
the RFC Editor. That change of status for 954 appears to have occured in
the past two years. Perhaps someone on the IESG can enlighten me.

Then there is the current ICANN announcement of some policy w.r.t. its
Registrar Accreditation Agreement (RAA). The RAA contains language which
appears closer to the language in 954 concerning MILNET TAC users than to
the language in 954 concerning individual with a directory on an ARPANET or
MILNET host. Both are in conflict with 95/46/EC, and the OEDC Guidelines
(the oecd.org link is broken, so here is Roger Clarke's restatement, itself
a useful read)

	http://www.anu.edu.au/people/Roger.Clarke/DV/PaperOECD.html

I can't speculate on the actual status of :43 deployments by ccTLD operators
located outside of North America.

I decided not to include a mapping from the DCA language to a P3P schema,
as for many, the policy scope question (controlling jurisdiction and legal
theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the mechanism
for description and policy-scoped access, is more interesting, and both XML
and schemas and/or DTDs are a distraction. I'll add it to -01.

Your comments are welcome.

I've cc'd the Provreg WG list due to the overlap of interest (many are also
registrars and/or registry operators), and the W3C's P3P Spec WG list, also
due to the overlap of interest.

If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), or ICDPPC-24
(Rigo?) this month, and ARIN-X (Ed?) next month, that would be a good thing.

Please be sure to cc me if replying.

I started writing this before a comment got to me. The comment was:

> I strongly disagree with the suggestion posed by this Draft.  Whois is
> a protocol in the public domain, and people can and do still use it.
> The fact that SRI no longer supports it under DCA funding is an absurd
> argument; it is just as irrelevant as the fact that ISI no longer
> supports the DNS under DARPA funding, as it once did; should we make
> the DNS protocol Historic?
> 
> There is no protocol document obsoleting Whois, and I am not aware of
> any terrible network consequence of its operation.   People with
> security issues on their databases do not have to participate.  If
> there are technical security problems with the protocol, the IESG
> should move to develop a protocol to obsolete Whois.  In the absence of
> such a replacement, and in the absence of any demonstrable harm to the
> Internet from keeping it as a Draft Standard, moving it to Historic
> would be unnecessary and (I believe) a violatiokn of common sense
> and proper standards setting.

954 specifies not only a protocol:

	C: [::printable::]\r\n
	S: .*\r\n <socket close>

It also specifies a data colleciton practice, the DCA's for MILNET TAC users,
and for individual (users) with a directory on an ARPANET or MILNET host. The
data collection practice itself is historic. The PROPOSED STANDARD status of
a national military data collection practice is historic as well. If the IETF
has any role in non-military public registry data collection practices, by
RIRs, domain registry operators, or others choosing to use the above protocol
on port 43, 954 is historic.

Strong disagreement noted.

Eric

------- Forwarded Message

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt
Date: Thu, 05 Sep 2002 07:18:36 -0400
Sender: [email-masked]

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Request to Move RFC 954 to Historic Status
	Author(s)	: E. Brunner-Williams
	Filename	: draft-brunner-rfc954-historic-00.txt
	Pages		: 3
	Date		: 2002-9-4
	
This memo requests a change of the status of RFC 954,

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-rfc954-historic-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-brunner-rfc954-historic-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-brunner-rfc954-historic-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

---

From: "Derek J. Balling" <[email-masked]>
Date: Thu, 5 Sep 2002 14:12:33 -0400

On Thursday, September 5, 2002, at 01:32  PM, Eric Brunner-Williams in 
> [ietf-whois and related lists]

I won't pretend that I'm on all of these mailing list in that CC line, 
but I am at least on a few. :-)

> Your comments are welcome.

A lot of this discussion appears to sort of happen "over my head" so 
please forgive me a bit if I seem stupid or something. ;-)

Part of my "night job" is the maintenance of the rfc-ignorant.org site, 
including the "whois.rfc-ignorant.org" zone, listing both individual 
domains with bad/missing/inaccurate WHOIS data, and [using a different 
result code], ccTLD's with similar problems.  We have a wide variety of 
users who utilize our service, including universities and commercial 
establishments. Some of them, obviously, use "the entire list" and some 
use "everything but the ccTLD wildcard entries". It is fairly difficult 
to ascertain accurately what percentage is behaving how, in that regard.

In our experience, there is - as you note - two different mindsets to 
registry operators. The USian perspective seems to be "you're part of a 
shared namespace, other folks have a right to know who you are", and 
the EU perspective seems to be, simply, "no you don't".  (!US,!EU) tend 
to be either split into thirds between US, EU, and "no whois server at 
all".

I believe that the main problem of RFC954 is that it tries to (well, it 
DOES) define both a protocol and a policy. In the absence of a document 
which defines "just the protocol", though, which could obsolete RFC954, 
the removal of 954 to HISTORIC status is a misnomer. It *is* an active 
protocol in use by registries around the world.

It is also an accurate statement to say that 954 is horribly out of 
date and doesn't necessarily reflect "the real state of the world" in 
many of the things it contains within the document, and I think such 
"dated" statements taint the value of both the protocol portions of the 
document, and the "spirit" of the document.

In my ideal world, I believe that the "vision" of complete WHOIS 
information that 954 describes is still, in fact, a BCP, despite what 
some EU members might think. (it's ok, you're entitled to disagree with 
me *grin*)  I can respect the desire for privacy that some feel is 
important. However, I think in a networking environment such as we have 
today, it is equally - if not more - important, to be able to contact 
folks via "a range of available methods", to be able to do so quickly 
without jumping through various registry-induced hoops, and to be able 
to obtain that complete info via a standardized protocol. (Too many 
ccTLD operators point people at web pages, which - unless there is a 
standard - breaks automated tools quite handily).

The short version of this is, I guess, "I think relegating 954 to 
HISTORIC status is premature, and should be postponed until - at bare 
minimum - a new/updated RFC defines the protocol, and preferably until 
there is both a protocol RFC as well as a policy RFC".

We can debate what the policy RFC would say at a later date. ;-)

Cheers,
D

--
+------------------------------+--------------------------------+
| Derek J. Balling             | "You can get more with a kind  |
| [email-masked]           |  word and a two-by-four, than  |
| www.megacity.org/blog/       |  you can with just a kind      |
|                              |  word."               - Marcus |
+---------------------------------------------------------------+

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 05 Sep 2002 22:01:09 +0200

I first didn't want to react to you proposal, but since you are
spreading this around over various maillists and have my name in there, a
short reaction.

Note that whois is not on the agenda of provreg.
    
    If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?),
    or ICDPPC-24 (Rigo?) this month, and ARIN-X (Ed?) next month,
    that would be a good thing.
    
If you want to have feed back from the RIPE about this, you should
get it on the agenda of the appropriate workgroups. You might even
do it by proxy, you have your ideas presented by some (nuetral)
person.

For CENTR oppinions,  suggest to contact the CENTR office. I'm not part
of that, only my organisation (SIDN) is member of CENTR.

	jaap

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 05 Sep 2002 16:41:46 -0400

> spreading this around over various maillists and have my name in there, a

My appologies Jaap.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Sep 2002 09:55:04 +0200

[Long list of mailing lists in the Cc:, feel free to trim. I specially
believe that it is OT for Provreg.]

On Thu, Sep 05, 2002 at 01:32:26PM -0400,
 Eric Brunner-Williams in Portland Maine <[email-masked]> wrote 
 a message of 178 lines which said:

> MILNET host. Both are in conflict with 95/46/EC, 

The RAA is certainly in conflict with 95/46/EC. That's a problem with
having the ICANN as an USAn company, not an international body: ICANN
is not supposed to take European law into consideration.

For the policy part of RFC 954 (not the protocol), I hesitate.

> located outside of North America.

According to our lawyer (IANAL), the whois of the French registry,
whois.nic.fr, is legal according to the French law (which is more
strict than 95/46/EC). Do note that we do not sale or transfer the
database in bulk. Do note also that  95/46/EC does not prevent public
directories.

> and schemas and/or DTDs are a distraction. I'll add it to -01.

For those interested, EUREG, following a suggestion of CORE, is
working with the W3C to develop a P3P expression of a registry's
policy. Comments on <[email-masked]>, please.
 
> If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), 

The issue will be discussed monday at the CENTR technical meeting just
before RIPE-43.