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

Vint Cerf <vint@google.com> Sun, 27 June 2010 18:45 UTC

Return-Path: <vint@google.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 A4F653A696E for <smartpowerdir@core3.amsl.com>; Sun, 27 Jun 2010 11:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8u002DhgQeJn for <smartpowerdir@core3.amsl.com>; Sun, 27 Jun 2010 11:45:35 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id EB2893A696A for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 11:45:34 -0700 (PDT)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o5RIjhkM009257 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 11:45:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277664343; bh=LtqGMcAjkqb5hwNGhR8IMNf1Ofw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=nhjIMrplz5OLWw4aZLVItyj9pU3qUCPn2SNFhTcvqxJ2mO6Ni3AG36up0SGr9POKl RoaWFroIGA6Zd5U+W6KOA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=PoVn3Hb988CqPCigSqJBPcN0vKkrKQND0ant1IReq6fSrMXQioaGqkCyiBE8yEMAv qM8HuoAPGQcsCT5A6qTPA==
Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by wpaz1.hot.corp.google.com with ESMTP id o5RIjf0d007260 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 11:45:42 -0700
Received: by vws5 with SMTP id 5so5333074vws.30 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 11:45:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.183.198 with SMTP id ch6mr1982338qcb.243.1277664341387; Sun, 27 Jun 2010 11:45:41 -0700 (PDT)
Received: by 10.229.78.130 with HTTP; Sun, 27 Jun 2010 11:45:41 -0700 (PDT)
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49307A5E0D864@MBCLUSTER.xchange.nist.gov>
References: <AANLkTimUtzYnqjRB404z8f9Hpbtk4ObhHhLx1Wy8nybj@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C49307A5E0D864@MBCLUSTER.xchange.nist.gov>
Date: Sun, 27 Jun 2010 14:45:41 -0400
Message-ID: <AANLkTimmGZT-2AnZBqf6Xx8TsD7rfLBpfw7oSC50J5AQ@mail.gmail.com>
From: Vint Cerf <vint@google.com>
To: "Su, David H." <david.su@nist.gov>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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 18:45:36 -0000

David, et al,

perhaps it is appropriate for the Arch WG to suggest example stacks
drawm from the list??

v


On Sun, Jun 27, 2010 at 2:41 PM, Su, David H. <david.su@nist.gov> 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)
>>
>>
>