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 11:26 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 C17AF3A6782 for <smartpowerdir@core3.amsl.com>; Sun, 27 Jun 2010 04:26:06 -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 q+Us7N5dQaza for <smartpowerdir@core3.amsl.com>; Sun, 27 Jun 2010 04:26:05 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BFFD03A66B4 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 04:26:04 -0700 (PDT)
Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o5RBQCL5015089 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 04:26:12 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277637973; bh=cn3iKWiGjuDV7VidiZrFzqzsK8w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=Lid3Q5JWB4AZKeDCn4CEr/v4bfwxQ/lUSr/dXYq9pmnzGk/3J3NPtoZy9Ulu5R5b+ YcNJdkmlIddj/7TccBraA==
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: content-type:x-system-of-record; b=oVPb34Mkh48uxSr7k0Hp/tSwyppYk+PNDbVjiwXa7yQ4wSVEaV4hY1+4LCGuCDi08 mddixUnaXOIfpMNvoULUw==
Received: from qwd7 (qwd7.prod.google.com [10.241.193.199]) by wpaz29.hot.corp.google.com with ESMTP id o5RBQBNU015281 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 04:26:11 -0700
Received: by qwd7 with SMTP id 7so768777qwd.35 for <smartpowerdir@ietf.org>; Sun, 27 Jun 2010 04:26:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.218.77 with SMTP id hp13mr1820779qcb.110.1277637971109; Sun, 27 Jun 2010 04:26:11 -0700 (PDT)
Received: by 10.229.78.130 with HTTP; Sun, 27 Jun 2010 04:26:11 -0700 (PDT)
In-Reply-To: <3B9BC844-EF5D-4EA9-AAD7-6DE1A10FA925@cisco.com>
References: <D7A0423E5E193F40BE6E94126930C49307A5E0D861@MBCLUSTER.xchange.nist.gov> <A3302C1A-7C75-4497-9D66-F91128820DC4@cisco.com> <AANLkTimUtzYnqjRB404z8f9Hpbtk4ObhHhLx1Wy8nybj@mail.gmail.com> <3B9BC844-EF5D-4EA9-AAD7-6DE1A10FA925@cisco.com>
Date: Sun, 27 Jun 2010 07:26:11 -0400
Message-ID: <AANLkTinR9-Rob-ycvAjFW-yswM7NTI6A1y4wgeM8KsOb@mail.gmail.com>
From: Vint Cerf <vint@google.com>
To: Fred Baker <fred@cisco.com>, "Su, David H." <david.su@nist.gov>, IETF SmartPower Directorate <smartpowerdir@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
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 11:26:06 -0000

Fred

Yes NORM seems a useful reference.

As to routing, that's a good question. Should we assume HaNs are stub
nets? We may need an IGP if several physical nets ae combined (eg
wired LAN and wireless).

V

On 6/27/10, Fred Baker <fred@cisco.com> wrote:
> Multicast is defined in both domains; however, as a transport, one could
> imagine
>
> http://www.ietf.org/rfc/rfc5740.txt
> 5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol. B.
>      Adamson, C. Bormann, M. Handley, J. Macker. November 2009. (Format:
>      TXT=268831 bytes) (Obsoletes RFC3940) (Status: PROPOSED STANDARD)
>
> Does that address your concerns?
>
> What flies next is "what routing protocol..." I would imagine PIM, OSPF,
> IS-IS, RIPv2, AODV, or OLSR. The IETF is working on 6LowPAN and RPL but is
> done with neither. Your opinions?
>
> On Jun 27, 2010, at 2:49 AM, Vint Cerf wrote:
>
>> 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
>
>

-- 
Sent from my mobile device