Subject: Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

From: SM <[email-masked]>
Date: Sun, 28 Aug 2005 01:22:07 -0700

Quoting the draft:

"many of these functions have been taken over by ICANN, ccTLDs and gTLDs"

RFC 1032 covers that with:

"until it becomes feasible for other appropriate organizations to assume those
  responsibilities.".

"The description of the Nicname/Whois service made there has been 
obsoleted by RFC 3912"

RFC 3912 updates the specification of the WHOIS protocol only.

The Whois service provides a contact point for administrative, policy 
and technical questions about the domain.  Although some information 
in RFC 1032 is dated, it remains useful and is still widely used as a 
guide for troubleshooting technical issues.

The reasons for moving RFC 1032 from status UNKNOWN to status 
HISTORIC are light.  Such a move would have a negative impact on 
active usage as RFC 3912 does not document the contact point for 
problems concerning a domain.

Regards,
-sm 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 29 Aug 2005 04:31:06 +0200

--On 28. august 2005 01:22 -0700 SM <[email-masked]> wrote:

> The reasons for moving RFC 1032 from status UNKNOWN to status HISTORIC
> are light.  Such a move would have a negative impact on active usage as
> RFC 3912 does not document the contact point for problems concerning a
> domain.

Three thousand RFCs ago, RFCs were used for many things.
I recommend readeing some other "status UNKNOWN" perspectives, such as RFC 
1003 ("Issues in defining an equations representation standard") or RFC 
1019 ("Report of the Workshop on Environments for Computational 
Mathematics").

This particular RFC was (I think; people around at the time will correct 
me) brought out by SRI-NIC to make it easy for the early Internet users to 
get hold of its instructions; the IETF never had an opinion on it.

The IETF *is not in the business of* "document the contact point for 
problems concerning a domain". That duty is left to registry operators, who 
have a whole apparatus (ICANN) for making it possible to figure out how to 
do that. And they can ask to have such specs published as RFCs if they want 
to - it's been done before; examples include RFC 1875 ("UNINETT PCA Policy 
Statements"). But ICANN hasn't done that, so no policy related to any 
*current* domain administrator is on the record.

The only possible reason I can see for doing anything to the status of RFC 
1032 is becaue the existence of the RFC is (wrongly) abused to try to force 
people into changing their behaviour with the argument "The IETF says so". 
Those people should stop taking the name of the IETF in vain.

Status UNKNOWN seems like a fine status to keep, in my opinion. Status 
INFORMATIONAL would have been more likely if anyone had bothered to 
reclassify the status UNKNOWN documents back in 1989 or therabouts, when 
those stop appearing. But like today, the people managing the publication 
series seem to have found better use for their time back then.

                            Harald

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2005 05:39:15 +0200

Harald Tveit Alvestrand wrote:

> The only possible reason I can see for doing anything to the
> status of RFC 1032 is becaue the existence of the RFC is
> (wrongly) abused to try to force people into changing their
> behaviour with the argument "The IETF says so".

Certainly not, just read <http://rfc-ignorant.org> and the
listing policy.  It's a private service like abuse.net etc.

> Those people should stop taking the name of the IETF in vain.

"Those people" are about as coherent as this list, and as
far as I know they never talk about the "IETF" (excl. me).

They discuss RfCs, mainly 2821 and 2142.  Replacing 954 by
1032 last year, after 3912 obsoleted 954.

> Status UNKNOWN seems like a fine status to keep

                       ACK, bye, Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 29 Aug 2005 11:47:04 +0200

On Sun, Aug 28, 2005 at 01:22:07AM -0700,
 SM <[email-masked]> wrote 
 a message of 32 lines which said:

> Although some information in RFC 1032 is dated, it remains useful
> and is still widely used as a guide for troubleshooting technical
> issues.

You must be kidding.
 
> HISTORIC are light.  

It is already historic and most information in it is plainly wrong:

Reporting-MTA: dns; mx2.nic.fr
Arrival-Date: Mon, 29 Aug 2005 11:42:56 +0200 (CEST)

Final-Recipient: rfc822; [email-masked]
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; [sri-nic.arpa]: Name or service not known

The rest, as mentioned by Harald Alverstrand, is just policy
requirments (and bad ones) which are NOT IETF business.

---

From: SM <[email-masked]>
Date: Mon, 29 Aug 2005 10:46:03 -0700

At 19:31 28-08-2005, Harald Tveit Alvestrand wrote:
>problems concerning a domain". That duty is left to registry 
>operators, who have a whole apparatus (ICANN) for making it possible 
>to figure out how to do that. And they can ask to have such specs 
>published as RFCs if they want to - it's been done before; examples 
>include RFC 1875 ("UNINETT PCA Policy Statements"). But ICANN hasn't 
>done that, so no policy related to any *current* domain 
>administrator is on the record.

Thank you for the clarification.  It is more informative than what is 
written in the draft.

>Status UNKNOWN seems like a fine status to keep, in my opinion. 
>Status INFORMATIONAL

That's my opinion too.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 29 Aug 2005 11:11:58 -0700

>Final-Recipient: rfc822; [email-masked]

I was referring to the use of Whois information to identify a point of contact.

>requirments (and bad ones) which are NOT IETF business.

The draft makes no mention of policy requirements as the reason for 
the change in status.  The reply sent by Harald Alverstrand offers a 
clearer explanation for this draft.

Regards,
-sm

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2005 20:50:23 +0200

> You must be kidding.

I doubt it, some of "us" really support the 1591 "spirit":

TLDs manage their affairs as it pleases them, but public
whois data must be correct.  It's also desirable (but not
required in all TLDs) to publish it with a whois server.

Everybody is free to draw his conclusions where that's not
the case (and for ICANN's gTLDs that's not allowed, they
offer the WDPRS for such issues).

> most information in it is plainly wrong:
 
> Final-Recipient: rfc822; [email-masked]

So what ?  Move 3912 to historic because it talks about the
known mil.whois.rfc-ignorant.org in its example, which at
best suffices as a _counter-example_ ?  

`rxwhois -h whois.nic.mil nic.mil`
sock errno 61: Connection refused

Yes, I reported this to hostmaster@ about a year ago - zero
feedack.  

And no, it wasn't me who submitted MIL to rfc-ignorant.org.

My bulk TLD submission last month was because I _disagree_
with the DE entry (after they added ? explaining the I18N
options) and because I hate double standards.

Move 3912 to historic, because it claims erroneously that
I18N for whois is impossible ?  One of the authors of the
draft in the subject _proved_ that it's possible, no matter
what the RFCI admin thinks about it.

> requirments (and bad ones) which are NOT IETF business.

3912 was submitted by the IAB Chair, claiming that this isn't
IETF business is utter dubious.  BTW, I can understand that
you'd like to remove the IETF from the picture, ICANN etc. are
probably bad enough.

OTOH there was never a whois problem with one of "your" TLDs
as far as I can tell it, and yes, I even watched TF (also a
nice example for some of the more surreal threads in LTRU ;-)

                         Bye, Frank

<http://purl.net/xyzzy/rxwhois.htm#v18> "updated  whois.nic.tf"

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 30 Aug 2005 08:11:38 +0200

--On 29. august 2005 20:50 +0200 Frank Ellermann <[email-masked]> 
wrote:

> IETF business is utter dubious.

just two comments on this.....

1) 3912 was published in order to make it clear that the IETF is not making 
policy requirements - some people had been misinterpreting the status of 
RFC 954 as saying that the IETF had made such policy statements.

2) I asked Leslie to finish the document (which, as the acknowledgement 
section says, had been started by Ran Atkinson) not because she was IAB 
chair at the time, but because she was the best technical contributor 
available to do the job at the time.

Publishing RFC 3912 is definitely IETF business. But I don't see where the 
"dubious" part comes in.

                 Harald

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 31 Aug 2005 10:00:41 +0200

Harald Tveit Alvestrand wrote:
 
> 3912 was published in order to make it clear that the IETF
> is not making policy requirements

Some people incl. me consider NICNAME as an essential asset
of "the Net" (whatever that might be), like mail.  Perfectly
okay if somebody doesn't support mail, but many do, and then
they follow "the rules" (RfCs).  Or ignore them.  That's the
idea of "rfc-ignorant.org" as I understand it.

Disclaimer:  I'm only a user / contributor, don't agree with
everything RFCI does, don't represent RFCI, etc.  (No special
disclaimer, also true for the IETF and other "communities")

> some people had been misinterpreting the status of RFC 954
> as saying that the IETF had made such policy statements.

The RFCI Web pages talk about RfCs, not the IETF.  Apparently
954 is older than the IETF (?).  It was promoted to DS in 1140,
and replaced by 3912 last year...  oops, a DS replaced a DS, I
didn't know that that's possible.

> Publishing RFC 3912 is definitely IETF business.

Sure, I forwarded the "last call" to the RFCI list last year
hoping that they'd do "something", propose a better draft or
whatever, unfortunately nothing happened.

> But I don't see where the "dubious" part comes in.

The I18N part is dubious, as demonstrated by whois.denic.de
it is possible to support UTF-8 and even more MIME compatible
charsets.

The last statement in the "security considerations" is also
dubious, there's nothing wrong with "whois", it's only simple.

But the really dubious part from my POV was the intent to get
rid of the critical X in "954 - X = 3912".  Some users want
this X, and fortunately it's also covered by 1032 (plus 1591).

                             Bye, Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Aug 2005 10:21:23 +0200

On Wed, Aug 31, 2005 at 10:00:41AM +0200,
 Frank Ellermann <[email-masked]> wrote 
 a message of 44 lines which said:

> But the really dubious part from my POV was the intent to get rid of
> the critical X in "954 - X = 3912".  Some users want this X,

Every TLD has its own X. X should not be provided by the IETF. It is
completely outside of its technical standards-setting mission.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 31 Aug 2005 11:29:59 +0200

Stephane Bortzmeyer wrote:

>> But the really dubious part from my POV was the intent to
>> get rid of the critical X in "954 - X = 3912".  Some users
>> want this X,

> Every TLD has its own X.

Not limited to TLDs, IIRC 1591 proposes to apply X recursively.
So when I type 'rxwhois fr' I get the lines (truncated):

whois -h whois.iana.org fr

IANA Whois Service
Domain: fr
ID: fr
[...]
URL for registration services: http://www.nic.fr/
Whois Server (port 43): whois.nic.fr
[...]

Tons of other useful info snipped:  There are mail addresses
if something doesn't work, even phone numbers, the names and
IPs of the nameservers, the age of the TLD, and the last
update.  Depending on what you want all important, it's THE
source to manage hard cases of net abuse.

With 'rxwhois nic.fr' I'd get a similar output:

whois -h WHOIS.NIC.FR nic.fr
%%
%% This is the AFNIC Whois server.
[...]

> X should not be provided by the IETF.

Sure, I asked whois.iana.org / whois.nic.fr, not whois.ietf.org
- there's no whois.ietf.org (that could answer questions like
'whois -h whois.ietf.org 1046-ticket' ;-)

But apparently IANA, NIC.FR, and I have similar ideas what "X"
should be for domains.  That has to be documented somewhere,
and what you get is defined (several RfCs, 1032, 1591, 2901).

Which part of it you publish, and how you do this, is a second
question, the usual "your server, your rules" (or in that case
"your domains, your rules").  The traditional way is a whois
server - and that has also to be documented.  It is wrong to
obsolete these RfCs without proper replacement.  They are used.

> It is completely outside of its technical standards-setting
> mission.

With that idea you could also claim that RfCs should not talk
about postmaster@ or abuse@.  This cannot work.  I don't care
who publishs / maintains these RfCs, maybe ICANN should do it.

Or each TLD publishs its own rules as RfC - but OTOH that would
be stupid if they are all essentially identical except from the
details reported by 'whois -h whois.iana.org <tld>'.

                              Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 31 Aug 2005 03:08:05 -0700 (PDT)

> who publishs / maintains these RfCs, maybe ICANN should do it.

I happen to agree with people who want to separate policy from
protocol specification. But I disagree that such policy-like 
recommendations as that its good to have "abuse@" mailbox have
no business with IETF. If I understand correctly IETF thinking is
that such recommendations should not go into STD track but into BCP.

As such if RFC1032 is being considered for moving to historic (which
may need to happen but I see no reason to do it right now and I think
it would be difficult because many other non-historic RFCs depend on
it), some of what is there that people think is relevant should be 
considered for new BCP RFC.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 Aug 2005 13:23:15 +0300 (EEST)

> completely outside of its technical standards-setting mission.

FWIW, the IETF mission statement (a BCP) (RFC3935) includes more than 
setting standards.  This was a very conscious wording choice when 
writing the document.

To quote:

    The mission of the IETF is to produce high quality, relevant
    technical and engineering documents that influence the way people
    design, use, and manage the Internet in such a way as to make the
    Internet work better.  These documents include protocol standards,
    best current practices, and informational documents of various
    kinds.

So, This "X" is not necessarily out of scope of the IETF mission, 
though it is a judgment call whether the criteria described above are 
met -- and whether it even makes sense to try to meet them.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 31 Aug 2005 13:21:38 +0200

> considered for new BCP RFC.

Just because I was curious, I used some time on this....
Bill Fenner's tool <http://rtg.ietf.org/~fenner/ietf/deps/index.cgi> says 
(content descriptions mine, based on RFC index):

Documents that depend on: RFC1032

Depending document				Type of dependency
rfc1031 (Unknown)		rfc1032 (Unknown)	unknown	MILNET ops
rfc1034 (Standard)	rfc1032 (Unknown)	unknown	DNS spec	
rfc1035 (Standard)	rfc1032 (Unknown)	unknown	DNS spec
rfc1183 (Experimental)	rfc1032 (Unknown)	unknown	DNS - more rectypes
rfc1348 (Experimental)	rfc1032 (Unknown)	unknown	DNS NSAP RRs
rfc2052 (???)		rfc1032 (Unknown)	unknown	DNS SRV
rfc1464 (Experimental)	rfc1032 (Unknown)	unknown	DNS arbitary strings
rfc2053 (???)		rfc1032 (Unknown)	reference	AM domain ops
rfc1480 (???)		rfc1032 (Unknown)	reference	US domain ops
rfc1401 (Informational)	rfc1032 (Unknown)	reference	Correspondence
rfc1386 (Informational)	rfc1032 (Unknown)	reference	US domain ops
rfc1123 (Standard)	rfc1032 (Unknown)	reference	Host Requirements
rfc2065 (???)		rfc1032 (Unknown)	reference	DNSSEC original

Now if we agree that the operations documents and the corrspondence 
document are not critical, using the same logic as the logic used for 
dismissing RFC 1032, we have the following possibly interesting 
dependencies:

RFC 1034 - DNS base specs
  Reference: "Current policy for the top levels is discussed in [RFC-1032]."
  Reference: "While there are no particular technical constraints dealing 
with where in the tree this can be done, there are some administrative 
groupings discussed in [RFC-1032] which deal with top level organization, 
and middle level zones are free to create their own rules."

  Hardly a normative dependency.

RFC 1035 - DNS base specs
  Appears in reference list, but is not referenced in the text.
  Hardly normative.

RFC 1183 - DNS record types
  Appears in reference list, but is not referenced in the text.
  Hardly normative.

RFC 1348 - DNS NSAP RR
  Appears in reference list, but is not referenced in the text.
  This is getting to be familiar....

RFC 2052 - DNS SRV
  Appears in....

RFC 1123 - Host Requirements

         6.1.4.1  DNS Administration

            This document is concerned with design and implementation
            issues in host software, not with administrative or
            operational issues.  However, administrative issues are of
            particular importance in the DNS, since errors in particular
            segments of this large distributed database can cause poor
            or erroneous performance for many sites.  These issues are
            discussed in [DNS:6] and [DNS:7].
   (DNS:6 is RFC 1032)

RFC 2065 - DNSSEC

   Appears in reference list, but is not referenced in text....
   .... and of course this has been obsoleted by 2535, which is itself
   obsoleted.....

(If the authors of draft-sanz want to, they are free to use the information 
above..... it's all public info anyway.)

While I still don't see any reason to bother with changing "status UNKNOWN" 
to something else, I think the argument that "so many other RFCs depend on 
it" can be safely dismissed now - unless someone comes up with a real 
example of a NORMATIVE dependency on RFC 1032, of course. I could be wrong.

                       Harald