The following text was added to the abstract:
"This document was created by technical experts of the ANSI C12.22/IEEE
1703/MC12.22 and ANSI C12.19/IEEE 1377/MC12.19 Standards working groups, based
on their first hand knowledge of existing C12.22 implementations for the
Internet. It is not an official and approved submission on behalf of the
ANSI/IEEE or MC working groups. The content of this document is an expression
of the aggregate experience of known implementations of ANSI C12.22/IEEE
1703/MC12.22 for the SmartGrid using the Internet."
I think it addresses the concerns you raise.
Regarding your assertion that "pretty much all Informational RFCs bear the
following notation: This document is not an Internet Standards Track
specification;"
We are not an expects on the subject of IETF RFC front matter. I am confident
that the correct front matter and copyrights material will be added by the RFC
Editor. This material is not normally proided by the Authors since it is boiler
plate machine generated text.
Otherwise, I am not very clear about what you are driving at, primarily because
I do not have a clear context for your reasoning or your background with
C12.22. I would recommend that if you are aware of proprietary implementations
of C12.22 over IP that differ substantially from the documented framework in
this RFC, then by all means bring them forward to our attention and we can
review them for compliance first with IEEE 1703 / ANSI C12.22 / MC12.22 then
this RFC and identify gaps, if any.
Thank You
Avygdor Moise
----- Original Message -----
From: Michael StJohns
To: Avygdor Moise ; Ralph Droms
Cc: Ralph Droms ; Jonathan Brodkin ; IETF Discussion ; IESG IESG
Sent: Wednesday, October 27, 2010 3:58 PM
Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22
TransportOver IP' to Informational RFC
I beg to differ.... pretty much all Informational RFCs bear the following
notation:
This document is not an Internet Standards Track specification;
This is clearly an example of an RFC stating what it is not.
For the rest:
"all known" is different than "all implementations known of by the authors
and anyone they consulted (which could be a pretty limited group)" which is
what you're trying to claim is an equivalence. :-) To use your own term "all
known" is "rather strong".
"proprietary" simply means not publicly owned/produced/developed so not sure
what you mean by "several proprietary C12.22... implementations" being "rather
strong". As far as I know, there are no non-proprietary implementations since
there are no non-proprietary standards for this. To be even more specific, the
publication of this document will not create a non-proprietary standard - its
just documenting existing proprietary specifications/implementations, and
publication in and of itself doesn't change that status.
At 02:50 AM 10/27/2010, Avygdor Moise wrote:
Dear Mr. St. Johns,
Respectfully, I think that it is not the purpose of the RFC to state what
it is not.
The term "all known" cleanly relates to the authors' knowledge of known
implementations. Certainly there may be a few implementations that do not
follow this RFC, but the same is true nearly for any known Standard.
Also the term "several proprietary C12.22 over IP implementations" is
rather strong in view of the history of the C12 Standards and the manner in
which they are implemented.
Avygdor Moise
----- Original Message ----- From: "Michael StJohns"
<mstjohns(_at_)comcast(_dot_)net>
To: "Ralph Droms" <rdroms(_dot_)ietf(_at_)gmail(_dot_)com>; "Avygdor Moise"
<avy(_at_)fdos(_dot_)ca>
Cc: "Ralph Droms" <rdroms(_dot_)ietf(_at_)gmail(_dot_)com>; "Jonathan
Brodkin" <jonathan(_dot_)brodkin(_at_)fdos(_dot_)ca>; "IETF Discussion"
<ietf(_at_)ietf(_dot_)org>; "IESG IESG" <iesg(_at_)ietf(_dot_)org>
Sent: Tuesday, October 26, 2010 4:24 PM
Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22
TransportOver IP' to Informational RFC
Hi Ralph -
Exactly what I was getting at. But a slight change in the wording you
suggested to make things clear.
Instead as the first paragraph of the abstract or as an RFC editor note I
suggest:
"This document is not an official submission on behalf of the ANSI C12.19
and C12.22 working groups. It was created by participants in those groups
building on knowledge of several proprietary C12.22 over IP implementations.
The content of this document is an expression of a consensus aggregation of
those implementations."
This, unlike your formulation, doesn't beg the question of whether or not
"existing implementations" and "all known" means "every single one including
ones not publicly announced"
Thanks, Mike
At 05:34 PM 10/26/2010, Ralph Droms wrote:
Combining an excellent suggestion from Donald and Avygdor's
clarification as to the official status of this document, I suggest an RFC
Editor note to add the following text as a new last paragraph in the
Introduction:
This document was created by technical experts of the ANSI C12.22
and ANSI C12.19 Standards, based on they first hand implementation
knowledge of existing C12.22 implementations for the Internet. It
is not an official and approved submission on behalf of the ANSI
C12.22 and ANSI C12.19 working groups. The content of this document
is an expression on the aggregate experience of all known
implementations of ANSI C12.22 for the SmartGrid using the Internet.
- Ralph
On Oct 26, 2010, at 5:25 PM 10/26/10, Avygdor Moise wrote:
Mr. St. Johns,
You ask: "Is this document an official and approved submission on
behalf of the ANSI C12.22 and ANSI C12.19 working groups?"
Answer: No it is not.
The ANSI C12.22 and ANSI C12.19 standards do not define the Transport
Layer interfaces to the network. They only define the Application Layer
Services and content.
This RFC addressed the gap as it applies to transporting C12.22 APDUs
over the Internet. However technical experts that were involved in the making,
deploying, testing and documenting the referred standards contributed to the
making of this RFC.
ANSI, NEMA, NIST, SGIP, MC, IEEE, IETF, AEIC and EEI are fully aware
of this effort and this RFC. The work was carried in plain view.
Avygdor Moise
----- Original Message -----
From: Michael StJohns
To: Avygdor Moise
Cc: ietf(_at_)ietf(_dot_)org ; IESG IESG ; Jonathan Brodkin
Sent: Tuesday, October 26, 2010 2:58 PM
Subject: RE: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22
TransportOver IP' to Informational RFC
One simple question: Is this document an official and approved
submission on behalf of the ANSI C12.22 and ANSI C12.19 working groups?
The specific language in the IESG record (in the working group
summary) is
"This document was created by technical experts of the ANSI
C12.22
and ANSI C12.19 Standards, based on they first hand
implementation
knowledge of existing C12.22 implementations for the Internet.
Its
content is an expression on the aggregate experience of all known
implementations of ANSI C12.22 for the SmartGrid using the
internet."
"Created by Technical Experts of the ..." is NOT the same as "This
document was created by (or is a product of) the ANSI C12.22 and C12.19 working
groups"
If you're not paying attention, you might assume this was an official
work product of C12.22 and C12.19.
Or is this in reality a C12.22 work product? If so, why not say so?
Better yet, why not have the ANSI liaison say so?
The issue is not the qualifications of the contributors, nor the
process for creating the document, but whether or not this is a private
contribution rather than a standards body contribution. The document is NOT
clear on this and reads like a standards body submission. Given the authors
involvement with the C12 organization, a reasonable person might assume this is
an official submission even though the Working Group Notes seem to point to an
individual or private submission. It seems reasonable to clarify which hat is
being worn in terms of submission.
Mike
At 12:16 PM 10/26/2010, Avygdor Moise wrote:
Dear Nikos,
I believe that you appropriately addressed the comment and I are in
complete agreement with your remarks.
I'd would also like to point out that Mr. St. Johns' concerns are
also addressed on the IETF data tracker for this RFC (
http://datatracker.ietf.org/doc/draft-c1222-transport-over-ip/), on the IESG
Write-ups tab. Specifically there is a Technical Summary, a Working Group
Summary and a Document Quality section. These sections fully disclose and
document the origin and the processes used to produce this RFC Draft and the
qualifications of the contributors.
Sincerely
Avygdor Moise
Chair: ASC C12 SC17, WG2 / ANSI C12.19; IEEE SCC31 / WG P1377
Editor: ASC C12 SC17, WG1/ ANSI C12.22; IEEE SCC31 / WG 1703
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org [
mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
ext Nikos Mavrogiannopoulos
Sent: Tuesday, October 26, 2010 11:49 AM
To: Michael StJohns
Cc: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22
TransportOver IP' to Informational RFC
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf