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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf