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
- Re: [smartpowerdir] Heads Up: Need info on Releas… Fred Baker
- Re: [smartpowerdir] Heads Up: Need info on Releas… Vint Cerf
- Re: [smartpowerdir] Heads Up: Need info on Releas… Fred Baker
- Re: [smartpowerdir] Heads Up: Need info on Releas… Vint Cerf
- Re: [smartpowerdir] Heads Up: Need info on Releas… Ralph Droms
- Re: [smartpowerdir] Heads Up: Need info on Releas… Russ Housley
- Re: [smartpowerdir] Heads Up: Need info on Releas… Vint Cerf
- Re: [smartpowerdir] Heads Up: Need info on Releas… Fred Baker