03.03.2011 17:59, RJ Atkinson wrote:
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.
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?
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.
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.
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.
Agreed - I'll make the corresponding changes.
Mykyta Yevstifeyev
Yours,
Ran
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf