Subject: [newtrk] List of Old Standards to be retired

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Dec 2004 12:46:46 +0100

Hello,

This is an update from the Old Standards experiment.  Below are a list 
of proposed standards that are candidates to be obsoleted.  The old 
standards mailing list has vetted out a good number, but still a good 
number remains.  We are looking for experts who can say affirmatively 
whether a standard is implemented and in use.  In particular, many of 
the docs class into four categories:

  - telnet options
  - MIBs (for X.25, 802.5, FDDI, and other)
  - SOCKS
  - Interaction with other protocol stacks (ISO, IPX, Appelalk, SNA, etc)

If you see a document on the list below and you know it to be in use, 
would you please reply to this message indicating the RFC number, and 
whether you believe the doc should be advanced beyond proposed?  Also, 
if you know of work to update anything on the list below, please include 
that.  A note along these lines is generally sufficient to remove a 
document from the list below.

RFC0698       Telnet extended ASCII option
RFC0726       Remote Controlled Transmission and Echoing Telnet option
RFC0727       Telnet logout option
RFC0735       Revised Telnet byte macro option
RFC0736       Telnet SUPDUP option
RFC0749       Telnet SUPDUP-Output option
RFC0779       Telnet send-location option
RFC0885       Telnet end of record option
RFC0927       TACACS user identification Telnet option
RFC0933       Output marking Telnet option
RFC0946       Telnet terminal location number option
RFC1041       Telnet 3270 regime option
RFC1043       Telnet Data Entry Terminal option: DODIIS implementation
RFC1053       Telnet X.3 PAD option
RFC1234       Tunneling IPX traffic through IP networks
RFC1239       Reassignment of experimental MIBs to standard MIBs
RFC1269       Definitions of Managed Objects for the Border Gateway
               Protocol: Version 3
RFC1276       Replication and Distributed Operations extensions to
               provide an Internet Directory using X.500
RFC1277       Encoding Network Addresses to Support Operation over
               Non-OSI Lower Layers
RFC1285       FDDI Management Information Base
RFC1314       A File Format for the Exchange of Images in the Internet
RFC1328       X.400 1988 to 1984 downgrading
RFC1370       Applicability Statement for OSPF
RFC1372       Telnet Remote Flow Control Option
RFC1378       The PPP AppleTalk Control Protocol (ATCP)
RFC1381       SNMP MIB Extension for X.25 LAPB
RFC1382       SNMP MIB Extension for the X.25 Packet Layer
RFC1397       Default Route Advertisement In BGP2 and BGP3 Version of
               The Border Gateway Protocol
RFC1414       Identification MIB
RFC1415       FTP-FTAM Gateway Specification
RFC1418       SNMP over OSI
RFC1419       SNMP over AppleTalk
RFC1420       SNMP over IPX
RFC1421       Privacy Enhancement for Internet Electronic Mail: Part I:
               Message  Encryption and Authentication Procedures
RFC1422       Privacy Enhancement for Internet Electronic Mail: Part II:
               Certificate-Based Key Management
RFC1423       Privacy Enhancement for Internet Electronic Mail: Part
               III: Algorithms, Modes, and Identifiers
RFC1424       Privacy Enhancement for Internet Electronic Mail: Part IV:
               Key Certification and Related Services
RFC1461       SNMP MIB extension for Multiprotocol Interconnect over
               X.25
RFC1469       IP Multicast over Token-Ring Local Area Networks
RFC1471       The Definitions of Managed Objects for the Link Control
               Protocol of the Point-to-Point Protocol
RFC1472       The Definitions of Managed Objects for the Security
               Protocols of the Point-to-Point Protocol
RFC1473       The Definitions of Managed Objects for the IP Network
               Control Protocol of the Point-to-Point Protocol
RFC1474       The Definitions of Managed Objects for the Bridge Network
               Control Protocol of the Point-to-Point Protocol
RFC1478       An Architecture for Inter-Domain Policy Routing
RFC1479       Inter-Domain Policy Routing Protocol Specification:
               Version 1
RFC1494       Equivalences between 1988 X.400 and RFC-822 Message Bodies
RFC1496       Rules for downgrading messages from X.400/88 to X.400/84
               when MIME content-types are present in the messages
RFC1502       X.400 Use of Extended Character Sets
RFC1512       FDDI Management Information Base
RFC1513       Token Ring Extensions to the Remote Network Monitoring MIB
RFC1518       An Architecture for IP Address Allocation with CIDR
RFC1519       Classless Inter-Domain Routing (CIDR): an Address
               Assignment and Aggregation Strategy
RFC1525       Definitions of Managed Objects for Source Routing Bridges
RFC1552       The PPP Internetworking Packet Exchange Control Protocol
               (IPXCP)
RFC1553       Compressing IPX Headers Over WAN Media (CIPX)
RFC1582       Extensions to RIP to Support Demand Circuits
RFC1584       Multicast Extensions to OSPF
RFC1598       PPP in X.25
RFC1618       PPP over ISDN
RFC1648       Postmaster Convention for X.400 Operations
RFC1666       Definitions of Managed Objects for SNA NAUs using SMIv2
RFC1692       Transport Multiplexing Protocol (TMux)
RFC1696       Modem Management Information Base (MIB) using SMIv2
RFC1742       AppleTalk Management Information Base II
RFC1747       Definitions of Managed Objects for SNA Data Link Control
               (SDLC) using SMIv2
RFC1749       IEEE 802.5 Station Source Routing MIB using SMIv2
RFC1755       ATM Signaling Support for IP over ATM
RFC1763       The PPP Banyan Vines Control Protocol (BVCP)
RFC1764       The PPP XNS IDP Control Protocol (XNSCP)
RFC1793       Extending OSPF to Support Demand Circuits
RFC1828       IP Authentication using Keyed MD5
RFC1829       The ESP DES-CBC Transform
RFC1835       Architecture of the WHOIS++ service
RFC1848       MIME Object Security Services
RFC1913       Architecture of the Whois++ Index Service
RFC1914       How to Interact with a Whois++ Mesh
RFC1929       Username/Password Authentication for SOCKS V5
RFC1961       GSS-API Authentication Method for SOCKS Version 5

Thanks...

Eliot
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 16 Dec 2004 06:44:01 -0600

Oh, lovely.

In our discussions about cruft, did we distinguish between crufty 
protocols and crufty specifications? I don't remember that we did 
(most of the examples during our working group meeting in San Diego 
were about plaintext passwords and such - in other words, crufty 
protocols).

Would we ever move a standard to historic just because the 
specification is so bad that it's unhelpful?

Spencer

From: "Carsten Bormann" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Carsten Bormann" <[email-masked]>; 
"IETF Discussion" <[email-masked]>
Sent: Thursday, December 16, 2004 6:27 AM
Subject: [Old-standards] Re: List of Old Standards to be retired

> On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote:
>
>> RFC1618       PPP over ISDN
>
> We had a short discussion about this in pppext.
>
> The gist was: The document is pretty bad (partly because things were 
> murky in 1994, but also because it was written by Martians that had 
> no space ship to take them to the ISDN planet), but some parts of it 
> do describe what currently shipping, actively marketed products do 
> (and should do) in this domain.
> Having done some ISDN work in the late 80s/early 90s, I all but 
> volunteered during this discussion to do a DS version of the thing 
> (probably by striking 80 % of the text and rewriting the rest).
> If this is what it takes to keep an active standards-track 
> specification about IP over ISDN, I'll do that tiny amount of work.
> Or we could leave it where it is.
>
> Gruesse, Carsten 

.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Dec 2004 06:48:41 -0600

I'm initially really surprised 1518/1519 is on this list. Wasn't there 
recent talk (like last week) of extending CIDR? And if this is true, 
shouldn't that work be completed before the existing docs are moved out to 
the pasture?

At 12:46 PM 12/16/2004 +0100, Eliot Lear wrote:
>Hello,
>
>This is an update from the Old Standards experiment.  Below are a list of 
>proposed standards that are candidates to be obsoleted.  The old standards 
>mailing list has vetted out a good number, but still a good number 
>remains.  We are looking for experts who can say affirmatively whether a 
>standard is implemented and in use.  In particular, many of the docs class 
>into four categories:
>
>  - telnet options
>whether you believe the doc should be advanced beyond proposed?  Also, if 
>you know of work to update anything on the list below, please include 
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 16 Dec 2004 08:02:44 -0500

>RFC0885       Telnet end of record option

This option was, at least at one time, used for telnet clients that 
connected to IBM mainframes...  It was used to indicate the end of a 
3270 datastream.  I don't know if it is still used in that fashion, 
but Bob Moskowitz might know.

>RFC1041       Telnet 3270 regime option

I'm not sure what this was ever used for, but again Bob Moskowitz 
would be a good person to ask if this is still in-use.

>RFC1269       Definitions of Managed Objects for the Border Gateway

Why would this be cruft?  The BGP4 MIB was just recently approved...

>               Assignment and Aggregation Strategy

CIDR is still in-use and rather frequently discussed in other 
documents.  Are there newer references  or something?

Margaret
.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 2004 14:29:16 +0100

Spencer Dawkins wrote:
> protocols and crufty specifications? I don't remember that we did (most 
> of the examples during our working group meeting in San Diego were about 
> plaintext passwords and such - in other words, crufty protocols).
> 
> Would we ever move a standard to historic just because the specification 
> is so bad that it's unhelpful?

Actually, logic would suggest moving it to Experimental, even
though that's a forbidden transition.

    Brian

> Cc: <[email-masked]>; "Carsten Bormann" <[email-masked]>; "IETF 
> Discussion" <[email-masked]>
>> murky in 1994, but also because it was written by Martians that had no 
>> space ship to take them to the ISDN planet), but some parts of it do 
>> describe what currently shipping, actively marketed products do (and 
>> should do) in this domain.
.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 2004 14:36:18 +0100

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.

    Brian
.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 2004 14:51:52 +0100

It's obvious when I look at this list and see things like
the FDDI MIB on it that we cannot confine the poll on usage
to the small world of the IETF. Most Boeing 777 aircraft still
use FDDI, for example; I have no idea whether the MIB flies with
them, but I'd hate us to obsolete it without being certain.

Gory details:
http://www.aviationtoday.com/cgi/av/show_mag.cgi?pub=av&mon=1101&file=1101productfocus.htm

I think we are really going to need a widely advertised
public comment period for the final list.

     Brian

.

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Dec 2004 09:33:07 -0500

> them, but I'd hate us to obsolete it without being certain.

not that I disagree with you - as long as people are implementing or 
using FDDI for any significant purpose I don't think we should move the 
MIB to historic.

however, in the aviation world it is not unusual to hardware to remain 
in regular use much longer than the specifications to which the 
hardware was designed.  as long as the specification can still be 
unambiguously referenced and accurate copies can be obtained, this 
doesn't seem to be a problem.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 2004 16:15:48 +0100

Keith Moore wrote:
> in regular use much longer than the specifications to which the hardware 
> was designed.  as long as the specification can still be unambiguously 
> referenced and accurate copies can be obtained, this doesn't seem to be 
> a problem.

Correct (and Phill said about the same). That's why the distinction
between simply historic and deprecated matters (and it isn't covered
by our current RFC classifications).

But my actual point was: as responsible engineers, don't we need to
ask the whole industry, not just the people who happen to be
on current IETF lists?

     Brian

     Brian
.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Dec 2004 17:42:17 +0100

The way we've been running the experiment, if there is a portion of the 
doc that is still useful then we leave it alone but recommend an update. 
  In other words no status change until someone takes further action. 
Having said that, I will remove RFC 1618 from the list, but it would be 
great if you did the update and in the process then obsoleted RFC 1618.

Eliot

Carsten Bormann wrote:
> If this is what it takes to keep an active standards-track specification 
> about IP over ISDN, I'll do that tiny amount of work.
.

---

From: [email-masked]
Date: Thu, 16 Dec 2004 17:35:39 +0100

Brian,
This suggests the need for some form of public notice section on the IETF 
web site (with press releases announcing it changes to it) that formally 
announces intention to deprecate a given list of RFCs and allow some 3 
months to receive public comments. 

Note that another class of "commenters" would be other standards bodies 
that make normative reference to these RFC.

This is a purely process issue but clearly something that shouldn't be 
forgotten (IETF decides to move RFC xxxx to "old list" > public comment 
period> resolution process> final action)

- Alistair

Brian E Carpenter <[email-masked]>
Sent by: [email-masked]
16/12/2004 16:15
Please respond to Brian E Carpenter
 
        To:     Keith Moore <[email-masked]>
        cc:     "[email-masked]'" <[email-masked]>
        Subject:        Re: [newtrk] Genuine public comment [Re: List of 
Old Standards to be retired]

     Brian

     Brian
.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2004 13:27:52 +0100

Gruesse, Carsten
.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Dec 2004 13:25:12 +0000

> RFC1277       Encoding Network Addresses to Support Operation over

This is still in use.

draft-melnikov-nsap-ipv6-00.txt references it and in theory it can be
updated to include bits of RFC 1277 which are still relevant.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2004 14:55:26 +0100

On Dec 16 2004, at 14:02 Uhr, Margaret Wasserman wrote:

> 3270 datastream.

... and 5250 (RFC2877).

Note that there was a draft-murphy-iser-telnet-02.txt attempt at
RFC2877bis as recent as May 2004, which still uses EOR.

RFC1576 (which is cited in the PS document RFC2355 as "traditional
TN3270") says:

    Currently, support for 3270 terminal emulation over Telnet is
    accomplished by the de facto standard of negotiating three separate
    Telnet Options - Terminal-Type [2], Binary Transmission [3], and End
    of Record [4].  This negotiation and the resulting data flow will be
    described below.
[...]
    [4] Postel, J., "Telnet End of Record Option", RFC 885,
        USC/Information Sciences Institute, December 1983.

It's probably necessary to do a full dependency analysis to do this
right.

OMG, what a visit to the technology attic.

Gruesse, Carsten
.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2004 14:28:03 +0100

> specification is so bad that it's unhelpful?

That's exactly why I almost volunteered to do the DS -- there is little
way to rescue the nugget out of the dirt except by respinning the
document.
If a PS is so uninteresting that nobody is interested in doing that
kind of work, maybe it *is* cruft in substance, not just in
specification.

Looking at 1618 -- we had a working group for a decade or so that
specifically was about *extensions*.
Why would anyone have touched *stable* (i.e. working) technology, which
is interoperating fine, if poorly documented?
This is probably an exercise for an academic (which I happen to be),
unless there is some pressure based on the disincentive that the
standard will be removed.
That's why other SDOs have five-year reviews.

Gruesse, Carsten
.

---

From: Scott W Brim <[email-masked]>
Date: Thu, 16 Dec 2004 09:11:32 -0500

> specification is so bad that it's unhelpful?

I think that's the right thing to do.  You need to explicitly label it
"unhelpful" (at the least) somehow.  You use what mechanisms we have.

swb
.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Dec 2004 15:16:31 +0100

> OMG, what a visit to the technology attic.

Why do we care if there are still implementations that are based on
these documents in use?

The important question is whether there are going to be new or revised
implementations based on these documents.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: George Swallow <[email-masked]>
Date: Thu, 16 Dec 2004 10:50:41 -0500

> Maybe we need a new category STABLE?

I don't think that would be a good name since it might imply that others
are INSTABLE ;-).  Perhaps FROZEN, STATIC, MATURE?

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Dec 2004 15:16:31 +0100

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2004 15:40:54 +0100

> implementations based on these documents.

A new implementation for tn5250 is about as likely as a new
implementation for NTP.

Standards have been invented for creating markets.
If the market is mature, you may not see many new entrants, but the
existing players still need the standard to keep the market intact.
(Of course, tn5250 is a strange market as it is ancillary to one
created by a specific vendor, but that's not my point.)
Maybe we need a new category STABLE?  (But even that is not the case
for tn5250, as evidenced by draft-murphy-iser-telnet-02.txt.)

So what does HISTORIC mean?
-- bad protocol (advice is to get rid of it), as in RIPv1
-- bad specification, but the protocol is alright
-- an underlying/related technology is dying out slowly
-- an underlying/related technology is used mainly in parts of the
world many IETFers don't visit that often
-- the market is stable, so there won't be new implementations
-- existing open source implementations are doing well, so there won't
be new implementations
-- there is unlikely to be new development about this standard, as in
IPv4

Gruesse, Carsten
.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 16 Dec 2004 14:00:13 -0500

I see this exercise has already reached the point of absurdity. 

How can it possibly be worth anyone's time to look at each telnet option and
determine whether it  is deployed?  What possible purpose  could be achieved
by  changing the  standards status  of some  telnet option?   Is  there some
chance that someone is going to implement one of these by mistake somehow? 

A similar comment applies to the FDDI  MIB.  Are we trying to make sure that
no one  implements that MIB by mistake?   Or that no one  implements FDDI by
mistake, just because he thinks there's an IETF standard about it? 

Let me echo Bob Braden's "if it's not broken, why break it?" query. 
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 16 Dec 2004 11:32:03 -0800

Eliot Lear wrote:

> of proposed standards that are candidates to be obsoleted.

> RFC1793       Extending OSPF to Support Demand Circuits

the NEMO Basic Support protocol
http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt
has a reference to RFC 1793.

a Mobile Router could run OSPF with its Home Agent from a remote
location through a tunnel to the Home Agent. the NEMO spec
recommends that the tunnel between the Home Agent and the Mobile
Router be treated as a demand circuit.

there is no implementation of this, however, AFAIK.

Vijay

.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Dec 2004 20:56:09 +0100

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Dec 2004 22:07:39 +0200 (EET)

> pointed out on the old-standards list already, but it must have

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 Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 16 Dec 2004 15:41:11 -0500

Carsten Bormann wrote:

> space ship to take them to the ISDN planet),

(sorry, I've given up reading IETF lists regularly, but I was pointed at
this comment.)

The document was written in 1992-1993 based on using real equipment
over Ameritech lines in Ann Arbor, Michigan.  In those days, I was so
personally dedicated to the IETF that I actually moved to Ann Arbor to
test and use it, as it was the first place in the state to offer ISDN.

I've heard that things differ in other places in the world.  But other
places in the world participated in the lively design and implementation
discussion.

Without that discussion, it would have been octet-sync only, but others
felt the need for bit-sync.  Moreover, that bit-sync be preferred over
octet-sync, as some places in the world would actually lose octet
alignment over time.  Horrors!  Now that backbones use fiber this
probably happens a lot less, but those were the realities of the day.

The specification was implemented by me in at least 2 product lines.
I've heard that it was implemented by others as well.

But, I've never seen results of any interoperability testing, and thus
it was never advanced toward standard.  Most folks seemed to just buy
the same vendor for both ends of the link.

> but some parts of it do describe what currently shipping, actively
> marketed products do (and should do) in this domain.

And that needs to be documented on the PPP list.

I found the nroff, and would be happy to document interoperability,
should there be any.

-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eric Rosen <[email-masked]>
Date: Thu, 16 Dec 2004 16:23:34 -0500

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

.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 16 Dec 2004 14:10:41 -0800

>has a reference to RFC 1793.

More than that...

mango% awk '$2 ~ /1793/' rfcref/db draftref/db
1793    1793    unknown
2843    1793    unknown
2844    1793    unknown
draft-ietf-ospf-dc      rfc1793 Normative
draft-pillay-esnault-ospf-flooding      rfc1793 Normative
draft-ietf-ospf-mib-update      rfc1793 Informative
draft-ietf-nemo-basic-support   rfc1793 Informative

In particular, draft-pillay-esnault-ospf-flooding was recently
approved and has a normative reference, so I think 1793 needs to
be removed from the list.

http://rtg.ietf.org/~fenner/ietf/deps/index.cgi will find the last 3
if you enter "1793" into the second box; I will work on getting
RFCs into the database too.

  Bill
.

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Dec 2004 18:18:43 -0500

--On Thursday, 16 December, 2004 22:07 +0200 Pekka Savola
<[email-masked]> wrote:

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

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Dec 2004 07:32:32 +0200 (EET)

Hi,

On Thu, 16 Dec 2004, John C Klensin wrote:
[...]
> 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.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Dec 2004 18:13:47 +0100

Carsten,

please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2, and 
see if it answers your question.... this has been a major discussion 
source....

                      Harald

--On 16. desember 2004 15:40 +0100 Carsten Bormann <[email-masked]> wrote:

> -- an underlying/related technology is used mainly in parts of the world
> many IETFers don't visit that often
> -- existing open source implementations are doing well, so there won't be
> new implementations
> -- there is unlikely to be new development about this standard, as in IPv4

.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Dec 2004 08:49:07 +0100

Eric Rosen wrote:
> 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.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Dec 2004 18:04:09 +0100

> ask the whole industry, not just the people who happen to be

The additional thing that I think the old-standards team needs in addition 
to your usage: Names of persons or lists that can be queried in order to 
ascertain the state.

If FDDI flies in 747, but is not a candidate for the 7E7 because Boeing 
regards it as obsolete, I think that's a statement that supports moving the 
FDDI MIB to Historic; if they say that they want FDDI in their new aircraft 
and will be coding the MIB in their new components, then that definitely 
supports keeping them on-track.

But we need to know how to ask.

For instance.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Dec 2004 10:40:20 +0100

Exactly. I think this needs to be added to the decrufting
proposal in the next revision.

    Brian

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Dec 2004 10:38:13 +0100

> A new implementation for tn5250 is about as likely as a new

Well, I wouldn't be too sure. There are thousands of heritage
mainframe systems in the world, and a common tactic is to give them
a nice Web front end by screen-scraping the 3270 or 5250 presentation
and reformatting it for HTML presentation. I can assure you there are
certainly *recent* tn3270 and tn5250 implementations as a result.

     Brian

.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Dec 2004 12:32:17 +0100

On Dec 16 2004, at 18:13 Uhr, Harald Tveit Alvestrand wrote:

> please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2,

Ah good, I did.

     o  Usage.  A standard that is widely used should probably be left
        alone (better it should be advanced, but that is beyond the scope
        of this memo).

Case closed (talking about 1618).

Now Bill (the author) and I (and whoever else is into that corner of 
the technology attic) probably should start talking about whether to 
put in work to advance it.
(This should have been done in 1999.)

Gruesse, Carsten

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 17 Dec 2004 13:16:25 +0100

Since the IETF list is obviously in rehash-of-WG-discussion mode today, I 
thought I'd contribute to the flamage, and rehash the logic behind the list 
of old standards that arrived in your inboxes a few days ago.....

Let's look back on what the IETF has decided previously.

In 1994, the IETF community resolved to make the following procedure into 
"IETF law" through RFC 1602:

      When a standards-track specification has not reached the Internet
      Standard level but has remained at the same status level for
      twenty-four (24) months, and every twelve (12) months thereafter
      until the status is changed, the IESG shall review the viability
      of the standardization effort responsible for that specification.
      Following each such review, the IESG shall approve termination or
      continuation of the development. This decision shall be
      communicated to the IETF via electronic mail to the IETF mailing
      list, to allow the Internet community an opportunity to comment.
      This provision is not intended to threaten a legitimate and active
      Working Group effort, but rather to provide an administrative
      mechanism for terminating a moribund effort.

In 1996, through RFC 2026, it reconfirmed that decision.

In 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 and 2004, various people 
cricticized the IESG for not following the process as written; the standard 
answer was "this is not the most important thing for the IESG to be doing".
And that's still true.

In March 2004, having gone through yet another of those "debates", I 
decided to see if I could write down some words on how this COULD be done 
without being an undue burden on the IESG.
I recruited Eliot Lear to lead the effort, and together we created what's 
currently draft-ietf-newtrk-cruft-00.

At the NEWTRK WG meeting in San Diego in August, I explained my motivation 
for pursuing this:

   This is the lightest-way process for doing what RFC 2026 mandates
   that I have been able to imagine. Now, we should either execute on
   that process, OR STOP TALKING ABOUT MOVING TO HISTORIC.

The argument that Bob Braden is making, and you seem to be making - that we 
should not move "crufty" things to Historic at all - is a rational argument.

But in that case, WE SHOULD UPDATE RFC 2026 TO SAY EXACTLY THAT.

<flame>
HAVING THE IETF CONTINUE TO SAY ONE THING AND DO ANOTHER IS NOT A GOOD 
THING FOR THE INTERNET.
</flame>

OK, finished shouting. Eric and Bob: the NEWTRK list is waiting for your 
contribution on the principle involved, and your internet-draft suggesting 
the change to RFC 2026 to get rules aligned with reality.

It's possible that that contribution will overturn the consensus of the WG 
to run this experiment.

But in the meantime - please get out of the way and let us who want to try 
run the experiment and evaluate the result.

                       Harald

--On torsdag, desember 16, 2004 14:00:13 -0500 Eric Rosen 
<[email-masked]> wrote:

> How can it possibly be worth anyone's time to look at each telnet option
> and determine whether it  is deployed?  What possible purpose  could be
> achieved by  changing the  standards status  of some  telnet option?   Is
> there some chance that someone is going to implement one of these by
> mistake somehow?
>
> A similar comment applies to the FDDI  MIB.  Are we trying to make sure
> that no one  implements that MIB by mistake?   Or that no one  implements
> FDDI by mistake, just because he thinks there's an IETF standard about
> it?
>

.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Dec 2004 09:56:11 -0500

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?
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Dec 2004 08:49:07 +0100

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 17 Dec 2004 13:16:25 +0100

<flame>

                       Harald

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Dec 2004 07:32:32 +0200 (EET)

Hi,

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Dec 2004 11:41:04 -0500

--On Friday, 17 December, 2004 07:32 +0200 Pekka Savola
<[email-masked]> 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.
>> 
>> 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

.

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Dec 2004 11:47:10 -0500

--On Friday, 17 December, 2004 13:16 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> Since the IETF list is obviously in rehash-of-WG-discussion
> mode today, I thought I'd contribute to the flamage, and
> rehash the logic behind the list of old standards that arrived
> in your inboxes a few days ago.....
> 
> In 1994, the IETF community resolved to make the following
> procedure into "IETF law" through RFC 1602:
>...
> OK, finished shouting. Eric and Bob: the NEWTRK list is
> waiting for your contribution on the principle involved, and
> your internet-draft suggesting the change to RFC 2026 to get
> rules aligned with reality.
> 
> It's possible that that contribution will overturn the
> consensus of the WG to run this experiment.
> 
> But in the meantime - please get out of the way and let us who
> want to try run the experiment and evaluate the result.

Harald, while I agree in principle, I would suggest that some of
the comments Eric, Bill, and others have pointed out call for
the beginnings of an evaluation of your experiment.   I further
suggest that evaluation is appropriate at almost any time, once
data start to come in.  My recent response to Pekka's analysis
of the CIDR documents is one suggestion about where such an
evaluation might lead.  And, of course, this whole firestorm of
discussion on the IETF list, while a welcome distraction from
hairsplitting debates about administrative structures, adds
strength to the position of those who argued in newtrk that this
effort might not be worth the 
amount of community energy it would take up.

   john

.

---

From: [email-masked]
Date: Fri, 17 Dec 2004 18:12:50 +0100

Brain,
Thanks for spotting my comment in amongst the thousands of "I love telnet" 
or "x25 is still important" messages!

BTW, many other organisations have successful "historical" processes. 

For example, W3C has section 7.7 in its proceedures (see 
http://www.w3c.org/Consortium/Process/) althought they call it "rescinding 
a recommendation" (Status=RSCND).  Can not see an examples of this process 
being used however.

Likewise, ETSI defines the process as:
"TWP 2.2.5      Historical documents
Any ETSI deliverable may be designated "historical" by the responsible 
Technical Body if a part or the whole of its content is for some reason 
considered obsolete and it is decided that the deliverable will not be 
maintained (updated or revised). As the contents of the deliverable may 
still be applicable or in use in some context, it may nevertheless be 
considered of value to keep the deliverable in the public domain.

When this is the case, the Technical Body shall inform the Secretariat and 
the Secretariat shall ensure that the ETSI deliverable is flagged as 
"historical" in the ETSI work programme.

An ETSI deliverable which is flagged as "historical" shall not be modified 
in any way."

(for TWP - "Technical working Proceedures" (a sort of rather long RFC 
2026), see the back 2/3 of the "Directives" at 
http://portal.etsi.org/Directives/home.asp)

To see the current list use 
http://webapp.etsi.org/workprogram/SimpleSearch/QueryForm.asp and search 
for Status=historical (total of 216 items currently). 

Looks like a simple, low cost, low controversial, process to me...

- alistair

17/12/2004 10:40
 
        To:     Alistair AU URIE/FR/ALCATEL@ALCATEL
        cc:     "[email-masked]'" <[email-masked]>
        Subject:        Re: [newtrk] Genuine public comment [Re: List of 
Old Standards to be retired]

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 17 Dec 2004 14:49:59 +0100

>the change to RFC 2026 to get rules aligned with reality.

Great. This is a good statement and the first step ahead!

While updating RFC 2026, better also to make the second step and say that
"having the IETF continue to do one thing according to the RFCs and the
rest of the world doing something else is not a good thing either for the
Internet (what ever the "Internet" may then mean since IETF says it is the
adherence to its Internet documents).

Then may be someone will consider publishing the "Internet Book" were the
consequences of the valid standards and RFC would be maintained in an
orderly maner and translated into the various working languages of the
world. This would solve the obsolesence issue: if an RFC is not quoted in
the Internet Book and no one protests for one year or more, it becomes
historic.

jfc

.

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 17 Dec 2004 11:49:04 -0500

Harald Tveit Alvestrand wrote:

> At the NEWTRK WG meeting in San Diego in August, I explained my
> motivation for pursuing this:
>
> The argument that Bob Braden is making, and you seem to be making -
> that we should not move "crufty" things to Historic at all - is a
> rational argument.
>

OK, I see that you are trying to make the IETF less moribund, and that
might be a good thing, and I applaud you for it.

Actually, the IESG riding herd on the standardization process TO SPEED
IT UP is exactly what we thought it should do circa '92-'94.  It just
didn't do it very well.  Instead, they mostly SLOWED things down,
since they all want to be "architects" -- instead of just "steering",
a pretty boring clerical job, they want to be "captain"s, mostly of
the debate team -- and there were the usual politics associated with
human beings.

For example, while you are picking on PPP in particular, I'll draw
your attention to RFC-1332 of 1992.  Still at Proposed Standard!?!?
Gosh, perhaps there weren't enough interoperable implementations?
Or, nobody uses the PPP Internet Protocol CP any more???

Actually, of course, it was reasonably well written, but it turned
out that it couldn't be implemented without asking questions on the
PPP list -- and folks did, and things got done, and products shipped.

So, that wisdom needs to be added to the document, but McGregor
wasn't around anymore (he told me he came to IETF last December
once again -- I hadn't heard from him in a decade, and haven't
heard from him since).  The kind of things that happen in a
volunteer organization.

Also, there was no sense of urgency, since it was all going to be
replaced by IPv6 soon (for the past decade).  So, the WG wasted its
time on IPv6....

So, here's my promise to you.  I'll track down McGregor, and we'll
write something up.  I will work on moving my Proposed Standards,
assuming that the IESG is actually _interested_ in doing its job.

The proof will be in the pudding.  In earlier times, I expected to
go from internet-draft to Proposed Standard in 2 IETF meetings, and
to Full Standard in under 1 year on average, 2 years for extremely
controversial items.

You see, I disagree with one of your earlier statements.  The IESG
really DOESN'T have anything more important to do....

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Dec 2004 14:17:50 +0100

On Thu, Dec 16, 2004 at 10:50:41AM -0500,
 George Swallow <[email-masked]> wrote

> are INSTABLE ;-).  Perhaps FROZEN, STATIC, MATURE?

BORING?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Dec 2004 14:17:50 +0100

BORING?
.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Dec 2004 14:17:50 +0100

BORING?

---

From: Scott W Brim <[email-masked]>
Date: Sat, 18 Dec 2004 04:23:47 -0500

On Fri, Dec 17, 2004 11:47:10AM -0500, John C Klensin allegedly wrote:
> data start to come in.  

I hope it can be a relatively sloppy process.  Let's not insist on
perfection.  An RFC is identified as possibly outdated, the suggestion
is posted, and people respond -- just as is happening now.  Sometimes
the suggestions are wrong.  The experiment is going fine as long as you
realize it's an experiment in process as much as discovering how much
cleaning is possible.  

> My recent response to Pekka's analysis

Yup.  The jury is still out on whether it's worthwhile.  Let's be
forgiving of the first attempt, and let it run for a little longer and
see if it becomes more polished.  

Scott
.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 18 Dec 2004 12:21:30 +0100

John,

> suggest that evaluation is appropriate at almost any time, once

First a reminder of what the procedure for this experiment is, before we 
talk about modifying it:

1.  Start with the list of RFCs prior to RFC 2001 and marked PS.
2.  Remove all RFCs known to still be relevant where new implmenetations
     might be necessary.  Be liberal in what we accept for removal
     purposes.
3.  Take the list to the IETF and other relevant mailing lists so that
     as wide an audience as possible can have a say.
4.  Present the list to the IETF and the NEWTRK WG in Minneapolis.
5.  Here things depend on the state of the Johns draft.  If it's
     ready and takes into account cruft, then we follow that
     procedure.

     Otherwise, extended WG last call, extended IETF last call,
     IESG consideration, and then take one of the following two
     steps:

6.  Either reclassify documents as Historic and write up BCP.
     or
     Don't and write up failed experiment.

This follows the WG milestones:

Dec 04	If the consensus was to create a new RFC cleanup process
	then initiate a trial of the cleanup process based on the
	description in teh Internet Draft
Mar 05	Determine if there is WG consensus tha the trial of the RFC
	cleanup process was successful enough to proceed to finalize
	the process.
Jul 05  If there was WG consensus that the trial of the RFC cleanup
	process was successful submit an ID describing the process to
	IESG for publication as a BCP RFC

Now to your points:

1.  Nobody in the IETF *has* to participate in this experiment.  The 
fewer who do, the more likely we'll end up with a substandard list, and 
the less likely the IESG will buy the list.  We don't seem to be having 
this problem at the moment.

2.  Changing the procedure should only be necessary if we can identify 
specific flaws in the procedure.  The objections I hear right this very 
moment fall into two categories:

[a]  "There's obviously a lot of trash out there so can't you just focus
      on that?"  [vjs, others]

The working group agreed to Larry Masinter's suggestion that we make 
people take the most minimum step of having to send an email to request 
a document remain PS.

[b]  "This whole effort is a waste of time, and you could do more damage
      than good." [braden, rosen, perhaps you]

Other than stopping the procedure I agreed to carry out without WG 
consensus is not something I would consider short a family or health 
emergency.

Eliot
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 18 Dec 2004 16:40:36 +0100

> to Full Standard in under 1 year on average, 2 years for extremely

Did you ever get what you expected....?

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Dec 2004 12:06:49 -0500

No disagreement on any of this.   I was just responding to what
I took to be suggestions that in-flight partial evaluation was
inappropriate.

   john

--On Saturday, 18 December, 2004 04:23 -0500 Scott W Brim
<[email-masked]> wrote:

>> Harald, while I agree in principle, I would suggest that some
>> of the comments Eric, Bill, and others have pointed out call
>> for the beginnings of an evaluation of your experiment.   I
>> further suggest that evaluation is appropriate at almost any
>> time, once data start to come in.  
> 
> I hope it can be a relatively sloppy process.  Let's not
> insist on perfection.  An RFC is identified as possibly
> outdated, the suggestion is posted, and people respond -- just
> as is happening now.  Sometimes the suggestions are wrong.
> The experiment is going fine as long as you realize it's an
> experiment in process as much as discovering how much cleaning
> is possible.  
> 
>> evaluation might lead.  And, of course, this whole firestorm
>> of discussion on the IETF list, while a welcome distraction
>> from hairsplitting debates about administrative structures,
>> adds strength to the position of those who argued in newtrk
>> that this effort might not be worth the 
> Yup.  The jury is still out on whether it's worthwhile.  Let's
> be forgiving of the first attempt, and let it run for a little
> longer and see if it becomes more polished.  
> 
> Scott

.

---

From: William Allen Simpson <[email-masked]>
Date: Sat, 18 Dec 2004 13:04:52 -0500

> Did you ever get what you expected....?
Yes, certainly.  And when I didn't, I helped lead the effort to reform
the structure of the IETF....  That worked for a couple more years. 

(Without reorganization, we couldn't even have a IPSec WG.  Steve Kent
prevented it.)

Sadly, the IETF changed from an organization where Vint Cerf, even as
he was being criticized, could wear a bathing suit under his perpetual
3-piece wear.  A sense of humor and camaraderie has been lost.

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 19 Dec 2004 11:23:18 +0100

> (Without reorganization, we couldn't even have a IPSec WG.  Steve Kent

The reason why I was asking was that I've heard statements that "we were 
much faster before" a number of times, while I've also heard lots of 
stories of things that took years to accomplish "before".

So I'd rather ask again, explicitly:

- Which standards did you push from first I-D to PS in 2 IETF meetings?
- Which standards (apart from the ones that were "born that way") reached 
Full Standard 1 year after going to PS?

At least we'd have a common understanding of the term "before"...

                        Harald

.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Dec 2004 12:30:09 +0100

FWIW, Vince Fuller has shown interest in providing an update.

Eliot

Pekka Savola wrote:
> 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.
> 
.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2004 21:25:17 +0000

>               when MIME content-types are present in the messages

Even though those two are implemented by Isode, it is Ok to move them to 
historic.

.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Dec 2004 00:30:58 -0500

> document from the list below.

I am a fairly good contact point for most things "TELNET".  Back in June
1999 the Application Area Directors, Keith Moore and Patrik Falstrom,
performed a review of TELNET RFCs to move unused ones to HISTORIC.  This
was done in consultation with the subscribers to the [email-masked]
mailing list.  All of the remaining Telnet options were determined to be
implemented in various widely deployed implementations.

> RFC1372       Telnet Remote Flow Control Option

Since the requirement for moving to historic under the cruft draft is
that it is not widely implemented, all of these options must remain.
If there is desire to move these options to historic, then the guideline
must be altered.

Jeffrey Altman