Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP' to Informational RFC

From: Michael StJohns <[email-masked]>
Date: Mon, 25 Oct 2010 13:39:24 -0400

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 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?
c) A description of how another standards body (which one????) does this?
d) A back door attempt to form an international standard within the IETF without using the traditional IETF working group mechanisms?

This feels like (d)  and is written like (d) and I believe past discussions have suggested that (d) is inappropriate for the Informational series.

If this isn't the case, then the front matter of the document should identify one of a, b or c as the source case.

As the announcement didn't point to a final RFC, and the front matter as above on the -07 (https://datatracker.ietf.org/doc/draft-c1222-transport-over-ip/) is written not as a "here's how we do it" informational, but as a "here's how all of us will do it" specification.

My recommendation:

Either add an RFC comment along the lines of a, b or c, or publish this as an Experimental RFC pre-submission to the working group process with the appropriate front matter identifying the submitters in their entirety (e.g. is this an Itron/L&G submission as seems to be implied in the Introduction).

I apologize for missing this in the Last Call back in July, but I'm kind of surprised this got past the IESG without some explanatory material being added to the front.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 26 Oct 2010 11:48:41 +0200

> 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…

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

> 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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 Oct 2010 12:05:05 -0400

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:
>> 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.
>