Request to Move RFC 954 to Historic Status

[Eric Brunner-Williams in Portland Maine]

[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: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt
Date: Thu, 05 Sep 2002 07:18:36 -0400
Sender: nsyracus at cnri.reston.va.us

- --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:
	mailserv at ietf.org.
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="mailserv at ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-4143115.I-D at ietf.org>

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:	<2002-9-4143115.I-D at ietf.org>

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message