Avygdor - can you tell me more about the implementations on which the document is based?
- Ralph On Oct 27, 2010, at 2:50 AM 10/27/10, 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" <mstjo...@comcast.net> > To: "Ralph Droms" <rdroms.i...@gmail.com>; "Avygdor Moise" <a...@fdos.ca> > Cc: "Ralph Droms" <rdroms.i...@gmail.com>; "Jonathan Brodkin" > <jonathan.brod...@fdos.ca>; "IETF Discussion" <ietf@ietf.org>; "IESG IESG" > <i...@ietf.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@ietf.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-boun...@ietf.org [ mailto:ietf-boun...@ietf.org] On Behalf Of >>>>>> ext Nikos Mavrogiannopoulos >>>>>> Sent: Tuesday, October 26, 2010 11:49 AM >>>>>> To: Michael StJohns >>>>>> Cc: i...@ietf.org; ietf@ietf.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 <mstjo...@comcast.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@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >>>> > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
