|
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 -----
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@xxxxxxxxxxx>
To: "Ralph Droms"
<rdroms.ietf@xxxxxxxxx>; "Avygdor Moise" <avy@xxxxxxx>
Cc:
"Ralph Droms" <rdroms.ietf@xxxxxxxxx>; "Jonathan Brodkin"
<jonathan.brodkin@xxxxxxx>; "IETF Discussion" <ietf@xxxxxxxx>;
"IESG IESG" <iesg@xxxxxxxx>
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@xxxxxxxx ; 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@xxxxxxxx [ mailto:ietf-bounces@xxxxxxxx] On Behalf
Of
ext Nikos Mavrogiannopoulos
Sent: Tuesday, October 26,
2010 11:49 AM
To: Michael StJohns
Cc: iesg@xxxxxxxx;
ietf@xxxxxxxx
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@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
|