RE: [newtrk] Re: List of Old Standards to be retired
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rosen > Eliot> Even if someone *has* implemented the telnet TACACS user > Eliot> option, would a user really want to use it? > > Eric> I don't know. Do you? > > Eliot> Yes, I do. Many of us do. And that's the point. > > I'm sure you think you know, but I don't know that you > know, which means that a lot of people have to waste a lot > of time preventing you from doing damage. > > Are you also the one who "knows" that OSPF demand circuits > are never used? . newtrk Should the fact that someone uses something mean that it should be considered a standard? If so the MARID group was a mistake, SPF should simply have been accepted as is without discussion. Lets do a thought experiment, should EBCDIC be considered a 'standard'? It is certainly used but there is no imaginable sense in which anyone would ever suggest building on top of it. The whole point of standards is that you are narrowing down the range of design choices. That means discarding standards that are of antiquarian interest only. The number of Internet users is now approaching or may have reached a billion. Please make an effort to recognize your responsibility to the 99% of those users for which the debate on legacy technology is irrelevant but have some very real and very urgent issues with the technology they are faced with using. What is meant by taking a spec off standard is that it will no longer be maintained. This means no more updates, but it also means that future specs will not be constrained by it either. This is important for two reasons, first there is simply too much junk that is too badly organized that people demand backwards compatibility for. The early ASRG discussions had folk prattling on about the need to continue to support UUCP. The second reason is the opposite of the first, there are some very important dependencise that should be maintained but are not because they get lost in the sheer volume of irrelevant cruft. As Larry King's first boss told him: This is a communications business. Like it or not the Internet is now the Web and the influence any party can have is dependent on their ability to communicate a coherent message. The IETF has been unable to communicate a coherent message about its work. Take a look at the IETF web site and compare it to the W3C and OASIS sites. Finding out what the IETF has done through the web site takes a lot of effort. W3C and OASIS tell you their list of achievements straight up on their front door. Each one of the crufty irrelevant specicfications is diluting the IETF message. If you continue to tell people that backwards compatibility with obsolete mainframe terminals based on specifications from the punch card age is important while failing to tell people that stopping the current Internet crime wave is important then it is very easy for people to dismiss you. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
--On Friday, 17 December, 2004 07:32 +0200 Pekka Savola
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, 16 Dec 2004, John C Klensin wrote:
> [...]
>> I suggest that the RFC Editor's traditional rule about
>> normative references from standards track documents to things
>> of a lower maturity level should apply here as well, even
>> going backwards. If you think there is value in RFC 1517, and
>> it makes normative reference to 1518 and 1519 (which it
>> does-- I just checked), then 1518 and 1519 are live
>> documents. If one reclassifies them to historic, one risks
>> really confusing users/readers and doing a world of harm.
>>
>> If you think it is worth keeping the content of 1517 while
>> removing 1518 and 1519 from the standards track, then I think
>> you need to arrange to replace ("obsolete") 1517 with a new
>> document that stands alone, without those normative
>> references. Such a document could, of course, obsolete all
>> three of 1517-1519, which would eliminate the need for any
>> processing in the "cruft" arrangements.
>
> Correct, though 1517 only has a single References section,
> giving the RFC-editor/IESG some leeway which ones to consider
> normative.
Not exactly. It means one needs to look at the text to
determine whether the statements and requirements of the text
are well-defined and clear without the other documents. In the
case of a document that is written as an applicability statement
on the earlier documents, that is trivially false: the documents
about which the applicability statement is written are, almost
by definition, normative for it.
> If that is what it takes, a 5 page document -- based on
> RFC1517 -- could be easily written which would convey the CIDR
> principles without having to normatively reference the other
> documents.
>
> I think I agree with you that we cannot just recycle 1517 (or
> any other CIDR document) to DS, it'll require some polishing.
But here is where we get into trouble, IMO. The purpose of the
"cruft-cleaning" exercise was described, I think, as permitting
us to identify documents that we could just move to historic or
otherwise lose because doing do didn't depend on making fine
distinctions or generating new documents to pick up the few
remaining useful pieces of old standards-track documents that
have become largely, but not completely, obsolete. We have
always had the possibility of writing new documents that say
"obsolete that", or "update that by removing the requirement for
X", or even "this is the applicability statement by which that
specification should be interpreted", with "always" dating to
long before 2026 (and, if I recall, predating the IETF). The
problem with those approaches to most of these older documents
has been that no one has had the motivation to do the work,
hence, I've assumed, the "cruft" proposal.
If a non-trivial fraction of the putative-cruft documents are
going to require this level of examination by the community, and
then lead to the conclusion that it would be pretty easy to
write a new document to clean up the specific mess, then my own
inference would be that we have demonstrated that there are no
quick fixes and that a rethinking of how we identify and
document what is standard and what is not is really required.
john
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eliot> Even if someone *has* implemented the telnet TACACS user option, Eliot> would a user really want to use it? Eric> I don't know. Do you? Eliot> Yes, I do. Many of us do. And that's the point. I'm sure you think you know, but I don't know that you know, which means that a lot of people have to waste a lot of time preventing you from doing damage. Are you also the one who "knows" that OSPF demand circuits are never used? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eric Rosen wrote: Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? I don't know. Do you? Yes, I do. Many of us do. And that's the point. How do we go about answering a question like that? We will spend less time discussing that option then we will the meta conversation, it seems. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Hi,
On Thu, 16 Dec 2004, John C Klensin wrote:
[...]
I suggest that the RFC Editor's traditional rule about normative
references from standards track documents to things of a lower
maturity level should apply here as well, even going backwards.
If you think there is value in RFC 1517, and it makes normative
reference to 1518 and 1519 (which it does-- I just checked),
then 1518 and 1519 are live documents. If one reclassifies them
to historic, one risks really confusing users/readers and doing
a world of harm.
If you think it is worth keeping the content of 1517 while
removing 1518 and 1519 from the standards track, then I think
you need to arrange to replace ("obsolete") 1517 with a new
document that stands alone, without those normative references.
Such a document could, of course, obsolete all three of
1517-1519, which would eliminate the need for any processing in
the "cruft" arrangements.
Correct, though 1517 only has a single References section, giving the
RFC-editor/IESG some leeway which ones to consider normative.
If that is what it takes, a 5 page document -- based on RFC1517 --
could be easily written which would convey the CIDR principles without
having to normatively reference the other documents.
I think I agree with you that we cannot just recycle 1517 (or any
other CIDR document) to DS, it'll require some polishing.
--
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
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
--On Thursday, 16 December, 2004 22:07 +0200 Pekka Savola
<[EMAIL PROTECTED]> wrote:
> On Thu, 16 Dec 2004, Brian E Carpenter wrote:
>> James M. Polk wrote:
>>
>>> I'm initially really surprised 1518/1519 is on this list.
>>
>> Obviously, it's a bug. Of the Proposed Standards that the
>> Internet runs on, those are among the most important. I
>> believe this was pointed out on the old-standards list
>> already, but it must have got lost.
>
> Not really a bug. Note that the to-be-historic list does not
> mention this:
>
> RFC1517 Applicability Statement for the Implementation
> of Classless Inter-Domain Routing (CIDR)
>
> This is the best document to use as a basis for respinning the
> concept of CIDR, AFAICS. 1518/1519 are full of address
> assignment etc. details which were out of date or
> inappropriate for a standards track document already 5 years
> ago. There's very small amount of useful information to
> salvage from those.
Pekka and others,
I suggest that the RFC Editor's traditional rule about normative
references from standards track documents to things of a lower
maturity level should apply here as well, even going backwards.
If you think there is value in RFC 1517, and it makes normative
reference to 1518 and 1519 (which it does-- I just checked),
then 1518 and 1519 are live documents. If one reclassifies them
to historic, one risks really confusing users/readers and doing
a world of harm.
If you think it is worth keeping the content of 1517 while
removing 1518 and 1519 from the standards track, then I think
you need to arrange to replace ("obsolete") 1517 with a new
document that stands alone, without those normative references.
Such a document could, of course, obsolete all three of
1517-1519, which would eliminate the need for any processing in
the "cruft" arrangements.
john
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
> This is a simple way to simply do what we said we were going to do. The worries about this whole anti-cruft business have always been (a) the likelihood that it would do more harm than good, and (b) the likelihood that it would waste enormous amounts of time on issues of no importance. The initial foray into this area doesn't do much to relieve these worries. > Even if someone *has* implemented the telnet TACACS user option, would a > user really want to use it? I don't know. Do you? How do we go about answering a question like that? How much time should the IETF spend determining the answer to this question? It's just better to leave well enough alone. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
On Thu, 16 Dec 2004, Brian E Carpenter wrote: James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Not really a bug. Note that the to-be-historic list does not mention this: RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This is the best document to use as a basis for respinning the concept of CIDR, AFAICS. 1518/1519 are full of address assignment etc. details which were out of date or inappropriate for a standards track document already 5 years ago. There's very small amount of useful information to salvage from those. -- 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 [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eric Rosen wrote: Let me echo Bob Braden's "if it's not broken, why break it?" query. Because maybe it is broke. Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? The process is broke. We say in 2026 that proposed standards should hang around and there is good reason why they shouldn't. The stuff that does hang around falls into three categories: 1. that which works so well that we just never got around to advancing it 2. that which was useful at some point but is no longer 3. that which was never useful, and what we really had was a failed experiment. In both [2] and [3] if someone lacking experience decides to (re)implement one of these that person is likely in for a snoot full of trouble by way of security and interoperability owing to the fact that the world has changed since many of these documents were written. And if something wasn't useful in the first place, perhaps smarter people than that someone figured out why. This is a simple way to simply do what we said we were going to do. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
