All,
I agree with Mike StJohns that the status and authorship of this
document needs to be much more clearly documented in the title
and inside the front part of the document itself prior to
publication as an RFC.
* This appears to be an end-run around one or more standards processes. *
It is not clear whether this document is an individual submission by the
authors themselves, or by the authors with their employers' approval,
OR by the authors on behalf of ANSI C12.22 or some other standards body.
The document appears not to be an IETF standards-track document,
although it lacks the usual "This is not a standard" disclaimer
normally present in Informational or Experimental RFCs.
The document status needs to be made very clear in both the title
and in the front matter of the document body.
[ ASIDE:
As Mike noted, the specification of the MD5 algorithm in RFC-1321,
which defines a mathematical equation rather than a protocol,
is quite different from the specification of a protocol being
carried over IP. Separately, RFC-1321 was published in April 1992,
well before the creation of the modern IETF Standards Process
(which happened in RFC-2026). So RFC-1321 is not a valid point
for comparison in this case.]
Some recent RFCs that are valid comparison points on how openly specified,
but non-standards-track documents are handled might include:
RFC-1613 "Cisco Systems X.25 over TCP" (Informational)
RFC-2105 "Cisco Systems Tag Swiching Architecture Overview" (Informational)
RFC-2124 "Cabletron's Light-weight Flow Admission Protocol Specification (Informational)
RFC-3619 "Extreme Networks' Ethernet Automatic Protection Switching" (Informational)
Each of those documents makes very clear that:
1) the document provides an open specification for a non-standards-track protocol
2) the document is NOT any kind of standard
Further, such documents ought to make their non-standard nature clear
in several different ways:
1) Document title clearly indicates it is a private, if open, specification
2) "Status of this Memo" clearly says that it is not any kind of standard.
3) Explicitly disclaimer of being any sort of standard in the document body
By contrast this document,
(https://datatracker.ietf.org/doc/draft-c1222-transport-over-ip),
has text in the Introduction that implies this document is some kind
of standard. It also uses the term "Standardized" (e.g. Section 2.4,
Page 10) to describe aspects of the protocol, even though this document
appears not to be an actual standard. Also, the "Status of this Memo"
section does not say that this is not a standard -- disclaiming being
a standard is a customary practice dating back at least to RFC-1613.
Depending upon which publication track this document is on, I believe
that the IESG, RFC Editor, or possibly ISE Editor should add a note
at the front clarifying that "This document is not a standard of any kind"
and also that edits should be made to to the document itself as
necessary to be VERY clear that this is not any kind of standard.
Yours,
Ran
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf