Subject: Re: Request for review of draft-yevstifeyev-genarea-historic-03

From: RJ Atkinson <[email-masked]>
Date: Thu, 3 Mar 2011 10:59:58 -0500

Earlier, Joel Halpern wrote:
> The first point, to echo Andrew Sullivan, is that even if a protocol
> is in use on the public Internet, it is not always easy to detect.
> It may be used in only some portions of the net.  It may be used
> inside some other protocol that makes detection ahrder. 
> 
> The second point is that enterprise uses and other private network uses 
> are still valid uses. The fact that a protocol may be used only inside 
> a virtual private network, or only inside a corporate data center,
> or in only within a military facility, does NOT mean that it is not used. 
> Such limited use is still valid use and should not result in our 
> declaring something obsolete.

+1 to all of the above.  

As an example of the 2nd point above, earlier this decade the IESG 
erroneously reclassified RFC-1108 as Historic, apparently because they 
perceived it as "not in use", even though it probably has more deployment 
and broader implementation now than 10 or 15 years ago.  
Here are 3 examples of modern products that support it:
- Cisco IOS still supports RFC-1108, and has since the early 1990s.
  <http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_ip_security.html>
- Oracle (Sun) Solaris supports it, although they call it "RIPSO".
  <http://download.oracle.com/docs/cd/E19109-01/tsolaris8/816-1048/6m7gaddht/index.html>
- Trusted Linux/SE Linux also supports it.
  <http://www.nsa.gov/research/selinux/list-archive/0605/thread_body18.shtml>

A third issue is that one of the apparent objectives is to reclassify 
a large number of RFCs that pre-date the IETF, and/or that were NOT 
published as IETF track RFCs.  What we now call the "Individual 
Submission" track is the oldest track of all, since the IETF 
did not even exist until the middle 1980s, yet RFCs go back to 1969.

Fourth, it is not appropriate for the IETF (or IESG) to reclassify any 
RFC that was not originally published as an IETF track RFC.  The IETF
simply lacks authority to reclassify such RFCs, although if the 
original author explicitly consents in advance to the reclassification
(e.g. recently for MD2/MD4) this can be done.  This is particularly 
true for the older RFCs that appear to be the target of this I-D and 
I-D author.  For those older RFCs, it isn't even the case the the 
IETF Trust (or ISoc) hold any well defined rights.

So the document also needs to clearly say that only IETF track RFCs
are within the scope of this document, and that the document does
not apply to RFCs which pre-date the IETF existence or that were
not published as IETF-track RFCs.

Yours,

Ran

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 05 Mar 2011 08:35:18 +0200

> and broader implementation now than 10 or 15 years ago.
I'd like to ask how was it done, what procedures were used.  And then 
look at RFC 4450, that uses other procedures for the same purpose.  RFC 
6037. eg. has the third choice.  Should this continue?
> IETF Trust (or ISoc) hold any well defined rights.
I agree with you here - IETF does not have the authority on the RFCs 
from other streams.  For IAB, IRTF and IS streams it is clear, but as 
for pre-IETF ones?

I also agree that IETF has the authority to define procedures for their 
own RFCs - in this way we should permit other streams' authorities do 
this on their own discretion.
> not published as IETF-track RFCs.
Agreed - I'll make the corresponding changes.

Mykyta Yevstifeyev
> Yours,
>
> Ran
>
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 5 Mar 2011 08:26:27 -0500

On 05  Mar 2011, at 01:35 , Mykyta Yevstifeyev wrote:
> I'd like to ask how was it done, what procedures were used.  

Existing IETF procedures were used, as best I understand, 
which shows that we do NOT need any new procedures.

As I noted, that use happened to have an incorrect result,
because people on the IESG were apparently unaware of 
the widespread use of that specification (albeit within
private networks on nearly all continents, rather than 
on the global Internet).

Many protocols are used primarily or exclusively within
private networks.  As many people have already said here,
it is impossible to measure such usage, which means mistakes 
are likely.  Better to leave things alone.

> I agree with you here - IETF does not have the authority
> on the RFCs from other streams.  For IAB, IRTF and IS
> streams it is clear, but as for pre-IETF ones?

Also quite clear.  Pre-IETF RFCs should be left alone.

Again, I do not believe this document is fixable.
I think it should be dropped, as should further 
discussion of publishing this document.

Yours,

Ran

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Mar 2011 13:06:51 +0100

Ran,

On the following point:

> IETF Trust (or ISoc) hold any well defined rights.

The IAB and IESG control STD1, and have every right and in fact a
responsibility to say what status they think any document has.  You or
anyone else can disagree and have your own list.

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Mar 2011 10:50:22 -0800

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "RJ Atkinson" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, March 07, 2011 4:06 AM
> Subject: Re: Request for review of draft-yevstifeyev-genarea-historic-03
...
> anyone else can disagree and have your own list.

The "historicization" of RFC 1227 provides an interesting example of
this.  Without speculating on the motivations behind that decision,
I think it does provide a clear example of an explicitly experimental
protocol that was actually getting significant use at the time being
declared historic.

Randy

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Mar 2011 05:32:02 -0400

--On Monday, March 07, 2011 10:50 -0800 Randy Presuhn
<[email-masked]> wrote:

>> The IAB and IESG control STD1, and have every right and in
>> fact a responsibility to say what status they think any
>> document has.  You or anyone else can disagree and have your
>> own list.
> 
> The "historicization" of RFC 1227 provides an interesting
> example of this.  Without speculating on the motivations
> behind that decision, I think it does provide a clear example
> of an explicitly experimental protocol that was actually
> getting significant use at the time being declared historic.

This is pure speculation --if I ever knew, I've forgotten-- but
it is possible that questions about the reasons for that
decision and others contributed to the IESG's later
conclusion/policy that changing something to Historic requires
documentation in the RFC Series.   I've disagreed with that
conclusion from time to time on the grounds that it creates an
excessively heavyweight and resource-consuming requirement.
I've even proposed and advocated alternative ways to
appropriately document such decisions.  However, the motivation
for better documentation of reclassification decisions is clear.
Your comment shows why documenting these things in some
easily-accessible way is appropriate and desirable.

     john