[smartpowerdir] Fwd: CSWG IETF Request

[Fred Baker <[e-mail]>]

Passing along a result and a path

The SGAC a few moments ago approved the draft-baker-ietf-core document. It and the CSWG did have minor comments on the text, which I have included in this email. For the most part, these are editorial nits; the CSWG would also like the IETF to look through its various security-related standards and ensure that they are up to date, which is a general request on the referenced technology as opposed to comment on this document per se. I will be filling out the paperwork for Ron, who will sign it as chair (I noted a minor conflict of interest on the call. I am author of the document, a principle contributor to PAP #1, and the liaison to the SGAC; it could appear disconcerting if the author was also the one who certified the approval :-)

Having had PAP #1 and SGAC review, I will now initiate the publication process in the IETF. I would expect that this, consistent with normal IETF process, includes a "last call" review within the IETF context, discussion by the IESG, and an RFC number early CY2011. That will come out of the Smart Power Directorate breakfast next week.

Begin forwarded message:

> From: "Swanson, Marianne" <[e-mail]>
> Date: November 3, 2010 3:53:29 AM GMT+08:00
> To: "Polk, William T." <[e-mail]>
> Cc: Frances Cleveland <[e-mail]>, Sandy Bacik <[e-mail]>, "Su, David H." <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: CSWG IETF Request
> 
> Hi Tim -
>  
> In September 2010, the NIST Smart Grid Interoperability Panel (SGIP) Project Management Office (PMO) requested the NIST Cyber Security Working Group (CSWG) to review and provide input to Priority Action Plan (PAP) 01: Role of IP in the Smart Grid.  Fred Baker and Dave Meyer, members of PAP01, had drafted an Internet Engineering Task Force (IETF) draft document on "Core Protocols in the Internet Protocol Suite" ( http://tools.ietf.org/html/draft-baker-ietf-core-09 .)
>  
> During the review the CSWG recognized that some Internet Protocol Suite (IPS) core protocols were developed before recent updates to cyber security technologies. The CSWG recommends that the IPS core protocols be reviewed to determine if updates or enhancements are necessary.  For example, IPS could update their references to cryptographic technologies (e.g. possible inclusion of Elliptic Curve Cryptography (ECC) suites in TLS – see <draft-ietf-tls-ecc-12.txt>) or could develop more extended network management RFCs (e.g. possibly improving SNMP and/or using NetConf for network management control).  In addition, the CSWG recommends the normative and informative reference document list in section 8 of "Core Protocols in the Internet Protocol Suite" draft document be reviewed to determine if any cyber security requirements in those documents need to be updated or enhanced. 
>  
> Please feel free to contact me or Frances Cleveland if you or a member of the IETF requires any further information.
>  
> Marianne Swanson
> National Institute of Standards and Technology
> 301-975-3293





Begin forwarded message:

> From: "Salazar, Ruben" <[e-mail]>
> Date: October 29, 2010 9:07:47 PM GMT+08:00
> To: [e-mail]
> Subject: Re: PAP #1
> Reply-To: "Salazar, Ruben" <[e-mail]>
> 
> Fred,
> Through a quick review of the document I found a small “typo” that it is worth correcting:
> In section A.1 How to structure a network, in the middle of the second paragraph the document says: “…
> IEEE 802.15.4g(Zigbee), …” This should be corrected to state only …”802.15.4 (ZigBee)…”.
> Indeed the amendment “g”, which is still in the works, is mostly defined for the Neighborhood Area Network, not for the HAN. ZigBee is working on 802.15.4.
> Regards





Begin forwarded message:

> From: John Ruiz <[e-mail]>
> Date: November 6, 2010 1:58:57 AM GMT+08:00
> To: [e-mail]
> Subject: Re: ACTION REQUIRED BY NEXT SGAC CALL: PAP #1 output for close-out review
> Reply-To: [e-mail]
> 
> 
> As requested, attached are my review comments.  I think the document was very well written, the majority of my issues are nits.  In the future, it would be nice to have line numbers in the documents being reviewed :) 
> 
> 1.  Page 4, section 1, titled "Introduction", paragraph 1, line 2.  "for use on with..." should be "for use on with...". 
> 
> 2.    Page 9, section 2.2.1, titled "Physical Security", entire paragraph.  In my mind, physical security threats are different than the examples given.  The "effect of backhoes, deterioration of physical media, and various kinds of environmental noise", are not physical security threats.  When I think of physical security, I think of wire tapping, wire cutting, signal jamming, and network path rerouting.  I would suggest changing the examples. 
> 
> 3.  Page 9, section 2.2.1, titled "Physical Security", paragraph 1, line 10.  "light, and we have learned about backhoes..." should be "light, and we have learned about backhoes...". 
> 
> 4.  Page 9, new section.  Section 2.2 discusses Physical security (2.2.1), Session Authentication (2.2.2), and Confidentiality (2.2.3).  This seems incomplete, why not touch on Network security, Transport security, and Application security?  The security RFCs for these layers were discussed later. 
> 
> 5.  Page 10, section 2.2.3, titled "Confidentiality", paragraph 1, line 2.  "there frequently a requirement..." should read "there frequently is a requirement...". 
> 
> 6.  Page 11, section 2.2.3, titled "Confidentiality", paragraph 1, line 7.  "it can to encrypt..." should read "it can decide to encrypt...". 
> 
> 7.  Page 13, section 3.1.3, titled "Transport Layer Security", paragraph 2, line 1.  "securely, an TLS client..." should read "securely, an TLS client...". 
> 
> 8.  Page 13, section 3.1.3, titled "Transport Layer Security", paragraph 3, line 1.  "each categories..." should read "each category...". 
> 
> 9.  Page 21, section 3.2.4.5, titled "Dynamic MANET On-demand (DYMO) Routing", paragraph 1, line 4.  "but experiences issues..." should read "but experienced issues...". 
> 
> 10.   Page 21, section 3.2.4.5, titled "Dynamic MANET On-demand (DYMO) Routing", paragraph 1, line 6.  "of being updatedDynamic MANET..." should read "of being updated in the Dynamic MANET...". 
> 
> 11.   Page 22, section 3.2.5.1, titled "Protocol Independent Multicast Routing", paragraph 4, line 4.  "Distribution tress are rooted the sending..." should read "Distribution treess are rooted to the sending...". 
> 
> 11.   Page 25, section 3.4.1, titled "Domain Name System", paragraph 1, line 6/7.  "extensions, which all a registry to sign..." should read "extensions, which allows a registry to sign...". 
> 
> 12.   Page 26, section 3.4.2, titled "Dynamic Host Configuration", paragraph 1, line 1.  Sentence references "Section 3.2.2" and then talks about IPv6.  Section 3.2.2 is entitled "Internet Protocol Version 4".  I think the section should also talk to IPv4 but alternatively the sentence could be changed to remove that reference and talk to only IPv6. 
> 
> 13.   Page 29, section 3.6.2, titled "Resource Discovery", paragraph 2, line 10.   "be used to discovery HTTP resources." should read "be used to discovery HTTP resources.". 
> 
> 14.   Page 29, section 3.7.1, titled "Session Initiation Protocol", paragraph 2, line 8.   Acronym "NAT" is used here but not identified until 4 pages later (P33). 
> 
> 15.   Page 51, section A.1, titled "How to structure a network", paragraph 2, line 4.  " IEEE 802.15.4g"  should read "IEEE 802.15.4 (2006)".  I think SEP 2.0 is debating whether to support the "g" version of 802.15.4 but the latest document uses the 2006 version. 
> 
> 16.   Page 52, section A.1, titled "How to structure a network", paragraph 2, line 5.  "(Zigbee)..."  should read "(used by Zigbee SEP 2.0)...". Zigbee adopted IEEE 802.15.4, it is not exclusive to ZigBee and different versions of Zigbee (Zigbee, Zigbee Pro, SEP 1.0, SEP 2.0) use different versions of 802.15.4. 
> 
> 17.   Page 52, section A.1, titled "How to structure a network", paragraph 2, line 8.  "the IPS in Secure Energy Profile..."  should read "the IPS in Smart Energy Profile...". 
> 
> 18.   Page 53, section A.1.1, titled "HAN Routing", paragraph 2, line 1.  "The ESI is node..."  should read "The ESI is a node...". 
> 
> 19.   Page 55, section A.2, titled "Model 1: AMI with separated domains", paragraph 5, line 1.   Acronym "QoS" is used here but not identified as Quality of Service (QoS) in the document. 
> 
> 20.   Page 55, section A.2, titled "Model 1: AMI with separated domains", paragraph 5, line 6.   Acronym "OS" is used here but not identified as Operating System (OS) in the document. 
> 
> Regards, 
> JR 
> 
>  
> 
> 
> From:	Ron Ambrosio <[e-mail]>
> To:	[e-mail]
> Date:	10/28/2010 01:26 PM
> Subject:	ACTION REQUIRED BY NEXT SGAC CALL: PAP #1 output for close-out review
> 
> 
> 
> 
> 
> Fellow Committee Members: 
> 
> PAP #1 is entering its close-out stage, and we need to review the document that Fred Baker forwarded (by URL reference) in the attached email.  Please review it primarily for architectural consistency issues, but to also raise any other serious concerns (which I assume are unlikely at this advanced stage of the document). 
> 
> As you see in the email exchange below, there is one additional citation that will be added to the document, and Fred will forward that to us as soon as he receives it.  Consider it part of what we're reviewing. 
> 
> Since we have a web meeting coming up next Friday, I'd like to add this to the meeting agenda to discuss any issues, so please try to review the document by then.  We don't want to be a bottleneck in the close-out process, but it's important that we do a complete review. 
> 
> Thanks,
> Ron
> -----
> Ron Ambrosio, Senior Technical Staff Member
> IBM Global Research Executive, Energy & Utilities Industry
> T.J. Watson Research Center, Yorktown Heights, NY
> Chairman, U.S. Dept. of Energy GridWise Architecture Council
> Chairman, U.S. National Inst. of Standards and Tech. SGIP Smart Grid Architecture Committee
> Convenor, ISO/IEC JTC 1 Special Working Group on Smart Grid
> mailto:[e-mail]     Office: [phone]     (IBM t/l 862-3121) 
> ----- Forwarded by Ron Ambrosio/Watson/IBM on 10/28/10 02:17 PM -----
> From:	Fred Baker <[e-mail]>
> To:	Ron Ambrosio/Watson/IBM@IBMUS
> Cc:	[e-mail], Stuart McCafferty <[e-mail]>
> Date:	10/28/10 02:13 PM
> Subject:	Re: PAP #1
> 
> 
> 
> 
> 
> 
> On Oct 28, 2010, at 11:05 AM, Ron Ambrosio wrote: 
> 
> 
> Fred, 
> 
> Just want to confirm I'm reading your note correctly: there is one more change that will be made to the document, which is to add a citation to SG Networks' architectural picture.  Correct? 
> 
> Correct. 
> 
> I assume you feel the version of the document at the URL below is ready for the SGAC, so I'll forward it to the Committee and ask that everyone review it primarily for architectural consistency issues, but to also raise any other serious concerns (which I assume are unlikely at this advanced stage of the document). 
> 
> Please forward the SG Networks' architectural picture citation to the SGAC as soon as you receive it, so we can review that too before closing on our response. 
> 
> Will do. 
> 
> Ron
> -----
> Ron Ambrosio, Senior Technical Staff Member
> IBM Global Research Executive, Energy & Utilities Industry
> T.J. Watson Research Center, Yorktown Heights, NY
> Chairman, U.S. Dept. of Energy GridWise Architecture Council
> Chairman, U.S. National Inst. of Standards and Tech. SGIP Smart Grid Architecture Committee
> Convenor, ISO/IEC JTC 1 Special Working Group on Smart Grid
> mailto:[e-mail]     Office: [phone]     (IBM t/l 862-3121) 
> From:	Fred Baker <[e-mail]>
> To:	Ron Ambrosio/Watson/IBM@IBMUS
> Cc:	[e-mail]
> Date:	10/28/10 01:46 PM
> Subject:	PAP #1
> 
> 
> 
> 
> 
> 
> We had a meeting regarding PAP #1 this morning, primarily discussing 
> 
> http://tools.ietf.org/html/draft-baker-ietf-core
> "Internet Protocols for the Smart Grid", Fred Baker, Dave Meyer,
> 25-Oct-10
> 
> which was written at David's request. 
> 
> In the meeting this morning, one change was requested, which was the citation of SG Networks' architectural picture of the Smart Grid as an example of the use of the Internet Protocol Suite in the Smart Grid. The IETF will need to review it and make sure it agrees that it is reasonable, of course, but I agreed in principle to include the citation if he sent the bibliographic information and a URL for an openly accessible version of the document.
> 
> CSWG says it has reviewed it and finds it acceptable, and per the PAP closing process we need a similar statement from SGAC. I am also taking it into the document, when the above has been finalized, into the IETF final review and publication process. 
> 
> 
>