Re: [smartpowerdir] Heads Up: Need info on Release 1 standards / expected standards coming out of PAPs

Fred Baker <fred@cisco.com> Sun, 27 June 2010 22:24 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 C8ED93A687F for <smartpowerdir@core3.amsl.com>; Sun, 27 Jun 2010 15:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.771
X-Spam-Level:
X-Spam-Status: No, score=-109.771 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, 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 EgpbZ6nxJvb8 for <smartpowerdir@core3.amsl.com>; Sun, 27 Jun 2010 15:24:25 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5154D3A6803 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 15:24:25 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAF9sJ0yrR7Ht/2dsb2JhbACfK3Gkc5kmgneCLQSDZg
X-IronPort-AV: E=Sophos;i="4.53,492,1272844800"; d="scan'208";a="218292356"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2010 22:24:35 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5RMOQPY010255; Sun, 27 Jun 2010 22:24:28 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 27 Jun 2010 15:24:35 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 27 Jun 2010 15:24:35 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49307A5E0D864@MBCLUSTER.xchange.nist.gov>
Date: Sun, 27 Jun 2010 15:24:20 -0700
Message-Id: <AED37834-7FFA-45E1-B6A4-6698DA4877B2@cisco.com>
References: <D7A0423E5E193F40BE6E94126930C49307A5E0D864@MBCLUSTER.xchange.nist.gov>
To: "Su, David H." <david.su@nist.gov>
X-Mailer: Apple Mail (2.1081)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: 'IETF SmartPower Directorate' <smartpowerdir@ietf.org>
Subject: Re: [smartpowerdir] Heads Up: Need info on Release 1 standards / expected standards coming out of PAPs
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: Sun, 27 Jun 2010 22:24:26 -0000

The problem with submitting the core protocol document itself is that it is an internet draft, without an RFC number. I'm happy enough with Oct 1, but I think the real question here is what FERC wants.

The set I gave you is IPv4, IPv6, TCP, UDP, SCTP, NORM (a "reliable" multicast protocol, which is a protocol that improves the probability of delivery of multicast traffic), IPsec, and TLS/DTLS. To my mind, that is the set that should be normative; others may disagree with me.

From the IETF's perspective, I don't think we object to the Smart Grid using IPv4, as it does now in places, but we question the wisdom of that as a long term strategy. 

Others on the list may have other opinions...

On Jun 27, 2010, at 11:41 AM, Su, David H. wrote:

> To all,
> The long list make me think that to satisfy next week's reporting requirement for George, leaving the existing two entries, first one with a general statement "Internet Protocol Suite, including IPv6 and IPv4", and second one for Fred's core protocol document is sufficient for now.  What we need to add is the projected completion date of Fred's document.  I assume it will be an Information RFC, to be be completed by October 1, 2010. Is it reasonable?
> 
> However, the long list of RFCs points to a problem I have.  FERC expects NIST to submit candidate standards for its rule making; it also expect justification on each standard and specify relevancy to smart grid by pointing to specific sections of the standard.  I don't know how to do this, and is looking for guidance from all of you. 1. Shall we submit anything at all? Does it mean anything to have a regulatory mandate for IP protocols? Or let the market place to determine the outcome is a better way?  2. If the answer is affirmative for submission, which one do we submit? Whatever we pick, I am afraid we'll miss something. May be Fred's core protocol document?
> David
> 
> 
> 
> Dr. David H. Su
> Chief, Advanced Network Technologies Division
> Information Technology Laboratory
> National Institute of Standards and Technology
> 100 Bureau Drive, MS 8920
> Gaithersburg, MD 20899
> +1 301 975 6194
> 
> 
> -----Original Message-----
> From: Vint Cerf [mailto:vint@google.com] 
> Sent: Sunday, June 27, 2010 5:49 AM
> To: Fred Baker
> Cc: Su, David H.; IETF SmartPower Directorate
> Subject: Re: [smartpowerdir] Heads Up: Need info on Release 1 standards / expected standards coming out of PAPs
> 
> should some form of broadcast or multicast be included (thinking about wide propagation of pricing or demand status information)?
> 
> I know we haven't done much with either of these protocols but in the context of either the SCADA environment or possibly the HAN, one might imagine some convenience in not having to maintain a pt-pt connection between the EMI and every device in the house?
> 
> v
> 
> 
> On Sun, Jun 27, 2010 at 12:53 AM, Fred Baker <fred@cisco.com> wrote:
>> Folks:
>> 
>> David is asking for a set of RFCs to include in the next iteration of NIST standards for the Smart Grid. Does anyone have a problem with or proposed changes to the following list?
>> 
>> http://www.ietf.org/rfc/rfc0768.txt
>> 0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT=5896
>>     bytes) (Also STD0006) (Status: STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc0791.txt
>> 0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
>>     bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
>>     (Status: STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc0792.txt
>> 0792 Internet Control Message Protocol. J. Postel. September 1981.
>>     (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950,
>>     RFC4884) (Also STD0005) (Status: STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc0793.txt
>> 0793 Transmission Control Protocol. J. Postel. September 1981.
>>     (Format: TXT=172710 bytes) (Updated by RFC1122, RFC3168) (Also
>>     STD0007) (Status: STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc2460.txt
>> 2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R.
>>     Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes 
>> RFC1883)
>>     (Updated by RFC5095, RFC5722, RFC5871) (Status: DRAFT STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc4279.txt
>> 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).
>>     P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: 
>> TXT=32160
>>     bytes) (Status: PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc4301.txt
>> 4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo.
>>     December 2005. (Format: TXT=262123 bytes) (Obsoletes RFC2401)
>>     (Status: PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc4347.txt
>> 4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu.
>>     April 2006. (Format: TXT=56014 bytes) (Updated by RFC5746) (Status:
>>     PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc4443.txt
>> 4443 Internet Control Message Protocol (ICMPv6) for the Internet
>>     Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M.
>>     Gupta, Ed.. March 2006. (Format: TXT=48969 bytes) (Obsoletes 
>> RFC2463)
>>     (Updates RFC2780) (Updated by RFC4884) (Status: DRAFT STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc4785.txt
>> 4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
>>     Transport Layer Security (TLS). U. Blumenthal, P. Goel. January 2007.
>>     (Format: TXT=9550 bytes) (Status: PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc5246.txt
>> 5246 The Transport Layer Security (TLS) Protocol Version 1.2. T.
>>     Dierks, E. Rescorla. August 2008. (Format: TXT=222395 bytes)
>>     (Obsoletes RFC3268, RFC4346, RFC4366) (Updates RFC4492) (Updated 
>> by
>>     RFC5746, RFC5878) (Status: PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc5281.txt
>> 5281 Extensible Authentication Protocol Tunneled Transport Layer
>>     Security Authenticated Protocol Version 0 (EAP-TTLSv0). P. Funk, S.
>>     Blake-Wilson. August 2008. (Format: TXT=117059 bytes) (Status:
>>     INFORMATIONAL)
>> 
>> http://www.ietf.org/rfc/rfc5430.txt
>> 5430 Suite B Profile for Transport Layer Security (TLS). M. Salter, E.
>>     Rescorla, R. Housley. March 2009. (Format: TXT=27586 bytes) (Status:
>>     INFORMATIONAL)
>> 
>> http://www.ietf.org/rfc/rfc5539.txt
>> 5539 NETCONF over Transport Layer Security (TLS). M. Badra. May 2009.
>>     (Format: TXT=16073 bytes) (Status: PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc5763.txt
>> 5763 Framework for Establishing a Secure Real-time Transport Protocol
>>     (SRTP) Security Context Using Datagram Transport Layer Security
>>     (DTLS). J. Fischl, H. Tschofenig, E. Rescorla. May 2010. (Format:
>>     TXT=81546 bytes) (Status: PROPOSED STANDARD)
>> 
>> http://www.ietf.org/rfc/rfc5878.txt
>> 5878 Transport Layer Security (TLS) Authorization Extensions. M.
>>     Brown, R. Housley. May 2010. (Format: TXT=44594 bytes) (Updates
>>     RFC5246) (Status: EXPERIMENTAL)
>> 
>> 

http://www.ipinc.net/IPv4.GIF