[smartpowerdir] Fwd: ACTION REQUIRED BY NEXT SGAC CALL: PAP #1 output for close-out review

Fred Baker <fred@cisco.com> Fri, 05 November 2010 18:14 UTC

Return-Path: <fred@cisco.com>
X-Original-To: smartpowerdir@core3.amsl.com
Delivered-To: smartpowerdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF043A6918 for <smartpowerdir@core3.amsl.com>; Fri, 5 Nov 2010 11:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.854
X-Spam-Level:
X-Spam-Status: No, score=-109.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBInC8ASE3N0 for <smartpowerdir@core3.amsl.com>; Fri, 5 Nov 2010 11:14:34 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 17AD13A67EE for <smartpowerdir@ietf.org>; Fri, 5 Nov 2010 11:14:34 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: Mail Attachment.jpeg : 12569
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvUFAEbm00yrRN+K/2dsb2JhbACBY5d4AYgPcaBmmz4CgwmCPQSEVoYAgwo
X-IronPort-AV: E=Sophos; i="4.58,304,1286150400"; d="jpeg'145?scan'145,208,145,217"; a="289334638"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2010 18:14:47 +0000
Received: from Freds-Computer.local (tky-vpn-client-230-165.cisco.com [10.70.230.165]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oA5IEhXn009659 for <smartpowerdir@ietf.org>; Fri, 5 Nov 2010 18:14:45 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 06 Nov 2010 02:14:46 +0900
X-PGP-Universal: processed; by Freds-Computer.local on Sat, 06 Nov 2010 02:14:46 +0900
From: Fred Baker <fred@cisco.com>
Date: Sat, 06 Nov 2010 02:14:36 +0800
References: <OF20431AEF.399D766D-ON862577D2.005BD87D-862577D2.0062C8A5@jci.com>
To: IETF SmartPower Directorate <smartpowerdir@ietf.org>
Message-Id: <30F57BBF-0B9A-4D20-8F51-333127C83FD7@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-182--711452738"
Subject: [smartpowerdir] Fwd: ACTION REQUIRED BY NEXT SGAC CALL: PAP #1 output for close-out review
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Nov 2010 18:14:38 -0000


Begin forwarded message:

> From: John Ruiz <John.Ruiz@JCI.COM>
> Date: November 6, 2010 1:58:57 AM GMT+08:00
> To: SGIP-SGAC@SMARTGRIDLISTSERV.ORG
> Subject: Re: ACTION REQUIRED BY NEXT SGAC CALL: PAP #1 output for close-out review
> Reply-To: John.Ruiz@JCI.COM
> 
> 
> 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 <rfa@US.IBM.COM>
> To:	SGIP-SGAC@SMARTGRIDLISTSERV.ORG
> 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:rfa@us.ibm.com     Office: +1 914-945-3121     (IBM t/l 862-3121) 
> ----- Forwarded by Ron Ambrosio/Watson/IBM on 10/28/10 02:17 PM -----
> From:	Fred Baker <fred@cisco.com>
> To:	Ron Ambrosio/Watson/IBM@IBMUS
> Cc:	SGIP-PAP01WG@SMARTGRIDLISTSERV.ORG, Stuart McCafferty <stuart@enernex.com>
> 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:rfa@us.ibm.com     Office: +1 914-945-3121     (IBM t/l 862-3121) 
> From:	Fred Baker <fred@cisco.com>
> To:	Ron Ambrosio/Watson/IBM@IBMUS
> Cc:	SGIP-PAP01WG@SMARTGRIDLISTSERV.ORG
> 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. 
> 
> 
>