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" <[email protected]> >To: "Ralph Droms" <[email protected]>; "Avygdor Moise" <[email protected]> >Cc: "Ralph Droms" <[email protected]>; "Jonathan Brodkin" ><[email protected]>; "IETF Discussion" <[email protected]>; "IESG IESG" ><[email protected]> >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: [email protected] ; 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: [email protected] [ mailto:[email protected]] On Behalf Of >>>>>>ext Nikos Mavrogiannopoulos >>>>>>Sent: Tuesday, October 26, 2010 11:49 AM >>>>>>To: Michael StJohns >>>>>>Cc: [email protected]; [email protected] >>>>>>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 <[email protected]> >>>>>>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 >>>>>>[email protected] >>>>>>https://www.ietf.org/mailman/listinfo/ietf >>>>
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
