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

[Frank Ellermann]

Harald Tveit Alvestrand wrote:

> 

Nice.  I used another tool for this task, but that's
limited to RfCs up to 3195 (on a now old c'T CD ROM).

> 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.

Not clear - there must be a reason why whois.iana.org exists,
it's not "just for fun".

{...]
> 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)

That says that 1032 is in fact a BCP, but that series didn't
exist at this time.

> 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

Two STDs are more than good enough that it would hit the fan
if somebody tries to kill 1032 in a private vendetta with RFCI.

> - unless someone comes up with a real example of a NORMATIVE
> dependency on RFC 1032, of course. I could be wrong.

Your three points quoted above will do.  With "3912 = 954 - X"
and "X' = 1032" there might be some more indirect dependencies
on the X in 954.  Okay, that's esoteric, 1034 and 1123 will do.

Nobody's really interested to create a proper 1032bis BCP at
this time.  If the whole purpose of the erroneous draft is to
get some ammo against the dubious de.whois.RFCI entry, then a
3912bis using whois.denic.de as example (instead of TLD .mil)
explaining how it supports I18N and the query "?" would be more
constructive.  3912 is bad.  If that 3912bis somehow obsoletes
also 1032 it could be fine, but that's not really necessary.

Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Harald Tveit Alvestrand]

--On 31. august 2005 03:08 -0700 "william(at)elan.net" <[EMAIL PROTECTED]> 
wrote:



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.


Just because I was curious, I used some time on this
Bill Fenner's tool  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








pgpRj8EBBZ3OE.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Pekka Savola]

On Wed, 31 Aug 2005, Stephane Bortzmeyer wrote:

Every TLD has its own X. X should not be provided by the IETF. It is
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 Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[william(at)elan.net]

On Wed, 31 Aug 2005, Frank Ellermann wrote:


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 [EMAIL PROTECTED]  This cannot work.  I don't care
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 PROTECTED]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Frank Ellermann]

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 [EMAIL PROTECTED]  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 '.

  Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Stephane Bortzmeyer]

On Wed, Aug 31, 2005 at 10:00:41AM +0200,
 Frank Ellermann <[EMAIL PROTECTED]> 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.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Frank Ellermann]

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



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Harald Tveit Alvestrand]

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



The rest, as mentioned by Harald Alverstrand, is just policy
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.


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



pgpylQYSEeWbq.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Frank Ellermann]

Stephane Bortzmeyer wrote:
 
> 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:
 
> Reporting-MTA: dns; mx2.nic.fr
> Arrival-Date: Mon, 29 Aug 2005 11:42:56 +0200 (CEST)
> 
> Final-Recipient: rfc822; [EMAIL PROTECTED]
> Action: failed
> Status: 5.0.0

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.

> The rest, as mentioned by Harald Alverstrand, is just policy
> 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

 "updated  whois.nic.tf"



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[SM]

At 02:47 29-08-2005, Stephane Bortzmeyer wrote:

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

Final-Recipient: rfc822; [EMAIL PROTECTED]


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


The rest, as mentioned by Harald Alverstrand, is just policy
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



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[SM]

At 19:31 28-08-2005, Harald Tveit Alvestrand wrote:
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.


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 



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Stephane Bortzmeyer]

On Sun, Aug 28, 2005 at 01:22:07AM -0700,
 SM <[EMAIL PROTECTED]> 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.
 
> The reasons for moving RFC 1032 from status UNKNOWN to status 
> 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 PROTECTED]
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.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Frank Ellermann]

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  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



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Harald Tveit Alvestrand]

--On 28. august 2005 01:22 -0700 SM <[EMAIL PROTECTED]> 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


pgpSlDxQ5Cn3T.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[SM]

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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf