Hi Nikos -
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(_at_)comcast(_dot_)net> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf