Unfortunately, [0] isn't a great reference to try and make this point:
1) It was published 20 years ago when we all of this was still in flux.
2) It's an algorithm description for crypto that's useful in certain situations, not a protocol (e.g. we've got multiple digital signature algorithms using different crypto hashes, so this isn't a global preemption of other hash algorithms
and 3) If you read to the bottom of the 3rd paragraph in the executive summary you'll find "
The MD5 algorithm is being placed in the public domain for review and possible adoption as a standard." so [0] is actually (a) or even (e) a front door attempt to create an international standard using normal IETF procedures. Today we'd do it as an internet draft, back then an Info RFC was as plausible.Mostly Informational documents are requirements, algorithm discussions, explanatory, technical discourses or fairly minor protocol extensions (e.g. use of AES-CTR with IPSEC) or other niche uses. Occasionally, they're documentation of standards from other organizations, sometimes with IETF tweaks or clarifications.
Looking at the list of RFCs going back at least 5 years I can't find any of the form "Foo over IP" as an Informational RFC.
C12.22 is probably going to be a large component of the smart grid. Letting an Informational RFC be read like "this is the way the IETF says you will do C12.22 over IP" seems to be a bad idea and a bad precedent. Letting either 2 rfc authors or possibly 2 meter companies set/force the IP standard for a multi-billion dollar world-wide industry by default also seems like a bad idea and bad precedent.
To reply to your last comment below and avoid the whole top-posting discussion - I have no problem with most of the document as written. It's perfectly fine to submit a proprietary design for a protocol to the IETF for publication as an RFC. BUT - going back to years and years of submarine patents and back door standards - the document needs to clearly describe what it is contextually and this one doesn't.
So "This document describes a C12.22 protocol over IP designed ?? and implemented by ?? in their products. It does not represent a consensus among all C12.22 manufacturers and should not be considered a community standard. It was submitted to the IETF as an example of a one possible approach to the problem and as a possible starting point for a discussion on a creation of an IETF standard"
Context.
Mike
At 05:48 AM 10/26/2010, Nikos Mavrogiannopoulos wrote:
On Mon, Oct 25, 2010 at 7:39 PM, Michael StJohns <mstjohns@xxxxxxxxxxx> wrote:
> Hi -
> I'm confused about this approval.
> As I read the draft and the approval comments, this document is an independent submission describing how to do C12.22 over IP. Â But the document is without context for "who does this" typical to an informational RFC.
Is that really typical? Check the MD5 algorithm in [0], I don't see
such boilerplates like "we at RSA security do hashing like that". I
think it is obvious that the authors of the document do that, or
recommend that. I pretty like the current format of informational
RFCs.
[0]. http://tools.ietf.org/html/rfc1321
> Is this
> a) A document describing how the document authors would do this if they were a standards organization?
> b) A description of how their company does this in their products?
Is your question on what informational RFCs are?
> c) A description of how another standards body (which one????) does this?
I'd suppose if this was the case it would be mentioned in the document
in question.
> d) A back door attempt to form an international standard within the IETF without using the traditional IETF working group mechanisms?
How can you know that? When somebody specifies his way of doing
things, is to inform and have interoperability. It might actually
happen that industry follows this approach and ends-up in a de-facto
standard. I see nothing wrong with that.
regards,
Nikos
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf