Re: [smartpower-interest] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt

[Yoshihiro Ohba <[e-mail]>]

I have a comment on the following paragraph in section 3.1.3:

"
   When used in conjunction with IEEE 802.1X [IEEE802.1X], both EAP-TLS
   [RFC5216] and the Protocol for Carrying Authentication for Network
   Access (PANA) [RFC5193] are widely considered to offer excellent
   access security to a wired or wireless IEEE 802 LAN (IEEE 802.1X in
   conjunction with EAP-TLS is the baseline for Zigbee SEP 2.0).
"

I guess what the above paragraph actually wanted to convey is,
when used with EAP-TLS both 802.1X and PANA are widely considered to
offer excellent access security to a wired or wireless IEEE 802 LAN.
This is because both 802.1X and PANA are EAP transports.   Also,
AFAIK, PANA in conjuction with EAP-TLS is the baseline for ZigBee
SEP2.0 (I am working with ZigBee people on defining PANA relay
draft needed for ZigBee SEP2.0).  Finally, RFC5191 (PANA protocol
specification) is more appropriate reference for PANA than
RFC5193 (PANA framework).

Having said that, here is my suggested change:

"
   When used in conjunction with EAP-TLS [RFC5216], both IEEE 802.1X
   [IEEE802.1X] and the Protocol for Carrying Authentication for
   Network Access (PANA) [RFC5191] are widely considered
   to offer excellent access security to a wired or wireless IEEE 802
   LAN (PANA in conjunction with EAP-TLS is the baseline for Zigbee
   SEP 2.0).
"

Best Regards,
Yoshihiro Ohba

(2010/10/26 3:53), Fred Baker wrote:
> 
> On Oct 25, 2010, at 11:29 AM, IETF I-D Submission Tool wrote:
> 
>>
>> A new version of I-D, draft-baker-ietf-core-09.txt has been successfully submitted by Fred Baker and posted to the IETF repository.
>>
>> Filename:	 draft-baker-ietf-core
>> Revision:	 09
>> Title:		 Internet Protocols for the Smart Grid
>> Creation_date:	 2010-10-25
>> WG ID:		 Independent Submission
>> Number_of_pages: 57
>>
>> Abstract:
>> This note identifies the key protocols of the Internet Protocol Suite
>> for use in the Smart Grid.  The target audience is those people
>> seeking guidance on how to construct an appropriate Internet Protocol
>> Suite profile for the Smart Grid.  In practice, such a profile would
>> consist of selecting what is needed for Smart Grid deployment from
>> the picture presented here.
> 
> <  draft-baker-ietf-core-07.txt 		 sg-ietf-compendium.txt 	
>   		
> Network Working Group                                           F. Baker	 	Network Working Group                                           F. Baker	
> Internet-Draft                                                  D. Meyer	 	Internet-Draft                                                  D. Meyer	
> Intended status: Informational                             Cisco Systems	 	Intended status: Informational                             Cisco Systems	
> Expires: February 18, 2011                               August 17, 2010	 	Expires: April 28, 2011                                 October 25, 2010	
>   		
>                   Internet Protocols for the Smart Grid	 	                 Internet Protocols for the Smart Grid	
>                          draft-baker-ietf-core-07	 	                        draft-baker-ietf-core-09	
>   		
> Abstract	 	Abstract	
>   		
>     This note identifies the key protocols of the Internet Protocol Suite	 	   This note identifies the key protocols of the Internet Protocol Suite	
>     for use in the Smart Grid.  The target audience is those people	 	   for use in the Smart Grid.  The target audience is those people	
>     seeking guidance on how to construct an appropriate Internet Protocol	 	   seeking guidance on how to construct an appropriate Internet Protocol	
>     Suite profile for the Smart Grid.  In practice, such a profile would	 	   Suite profile for the Smart Grid.  In practice, such a profile would	
>     consist of selecting what is needed for Smart Grid deployment from	 	   consist of selecting what is needed for Smart Grid deployment from	
>     the picture presented here.	 	   the picture presented here.	
>   		
>   		
> skipping to change at page 1, line 35		skipping to change at page 1, line 35	
>     Internet-Drafts are working documents of the Internet Engineering	 	   Internet-Drafts are working documents of the Internet Engineering	
>     Task Force (IETF).  Note that other groups may also distribute	 	   Task Force (IETF).  Note that other groups may also distribute	
>     working documents as Internet-Drafts.  The list of current Internet-	 	   working documents as Internet-Drafts.  The list of current Internet-	
>     Drafts is at http://datatracker.ietf.org/drafts/current/.	 	   Drafts is at http://datatracker.ietf.org/drafts/current/.	
>   		
>     Internet-Drafts are draft documents valid for a maximum of six months	 	   Internet-Drafts are draft documents valid for a maximum of six months	
>     and may be updated, replaced, or obsoleted by other documents at any	 	   and may be updated, replaced, or obsoleted by other documents at any	
>     time.  It is inappropriate to use Internet-Drafts as reference	 	   time.  It is inappropriate to use Internet-Drafts as reference	
>     material or to cite them other than as "work in progress."	 	   material or to cite them other than as "work in progress."	
>   		
>     This Internet-Draft will expire on February 18, 2011.	 	   This Internet-Draft will expire on April 28, 2011.	
>   		
> Copyright Notice	 	Copyright Notice	
>   		
>     Copyright (c) 2010 IETF Trust and the persons identified as the	 	   Copyright (c) 2010 IETF Trust and the persons identified as the	
>     document authors.  All rights reserved.	 	   document authors.  All rights reserved.	
>   		
>     This document is subject to BCP 78 and the IETF Trust's Legal	 	   This document is subject to BCP 78 and the IETF Trust's Legal	
>     Provisions Relating to IETF Documents	 	   Provisions Relating to IETF Documents	
>     (http://trustee.ietf.org/license-info) in effect on the date of	 	   (http://trustee.ietf.org/license-info) in effect on the date of	
>     publication of this document.  Please review these documents	 	   publication of this document.  Please review these documents	
>   		
> skipping to change at page 2, line 19		skipping to change at page 2, line 19	
>     2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  5	 	   2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  5	
>       2.1.  Internet Protocol Layers . . . . . . . . . . . . . . . . .  5	 	     2.1.  Internet Protocol Layers . . . . . . . . . . . . . . . . .  5	
>         2.1.1.  Application  . . . . . . . . . . . . . . . . . . . . .  6	 	       2.1.1.  Application  . . . . . . . . . . . . . . . . . . . . .  6	
>         2.1.2.  Transport  . . . . . . . . . . . . . . . . . . . . . .  7	 	       2.1.2.  Transport  . . . . . . . . . . . . . . . . . . . . . .  7	
>         2.1.3.  Network  . . . . . . . . . . . . . . . . . . . . . . .  7	 	       2.1.3.  Network  . . . . . . . . . . . . . . . . . . . . . . .  7	
>           2.1.3.1.  Internet Protocol  . . . . . . . . . . . . . . . .  8	 	         2.1.3.1.  Internet Protocol  . . . . . . . . . . . . . . . .  8	
>           2.1.3.2.  Lower layer networks . . . . . . . . . . . . . . .  8	 	         2.1.3.2.  Lower layer networks . . . . . . . . . . . . . . .  8	
>         2.1.4.  Media layers: Physical and Link  . . . . . . . . . . .  8	 	       2.1.4.  Media layers: Physical and Link  . . . . . . . . . . .  8	
>       2.2.  Security issues  . . . . . . . . . . . . . . . . . . . . .  8	 	     2.2.  Security issues  . . . . . . . . . . . . . . . . . . . . .  8	
>         2.2.1.  Physical security  . . . . . . . . . . . . . . . . . .  9	 	       2.2.1.  Physical security  . . . . . . . . . . . . . . . . . .  9	
>         2.2.2.  Session identification . . . . . . . . . . . . . . . .  9	 	       2.2.2.  Session Authentication . . . . . . . . . . . . . . . .  9	
>         2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10	 	       2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10	
>       2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 11	 	     2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 11	
>         2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 11	 	       2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 11	
>         2.3.2.  Network Management . . . . . . . . . . . . . . . . . . 11	 	       2.3.2.  Network Management . . . . . . . . . . . . . . . . . . 11	
>     3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11	 	   3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11	
>       3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 12	 	     3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 12	
>         3.1.1.  Session identification, authentication,	 	       3.1.1.  Session identification, authentication,	
>                 authorization, and accounting  . . . . . . . . . . . . 12	 	               authorization, and accounting  . . . . . . . . . . . . 12	
>         3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 12	 	       3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 12	
>         3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 12	 	       3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 13	
>         3.1.4.  Secure/Multipurpose Internet Mail Extensions	 	       3.1.4.  Secure/Multipurpose Internet Mail Extensions	
>                 (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 13	 	               (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 14	
>       3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 13	 	     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 14	
>         3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 13	 	       3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 14	
>           3.2.1.1.  Dual Stack Coexistence . . . . . . . . . . . . . . 14	 	         3.2.1.1.  Dual Stack Coexistence . . . . . . . . . . . . . . 14	
>           3.2.1.2.  Tunneling Mechanism  . . . . . . . . . . . . . . . 14	 	         3.2.1.2.  Tunneling Mechanism  . . . . . . . . . . . . . . . 15	
>           3.2.1.3.  Translation between IPv4 and IPv6 Networks . . . . 14	 	         3.2.1.3.  Translation between IPv4 and IPv6 Networks . . . . 15	
>         3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 15	 	       3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 16	
>           3.2.2.1.  IPv4 Address Allocation and Assignment . . . . . . 16	 	         3.2.2.1.  IPv4 Address Allocation and Assignment . . . . . . 17	
>           3.2.2.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 16	 	         3.2.2.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 17	
>           3.2.2.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 16	 	         3.2.2.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 17	
>         3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 17	 	       3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 18	
>           3.2.3.1.  IPv6 Address Allocation and Assignment . . . . . . 17	 	         3.2.3.1.  IPv6 Address Allocation and Assignment . . . . . . 18	
>           3.2.3.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 18	 	         3.2.3.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 19	
>         3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 18	 	       3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 19	
>           3.2.4.1.  Routing Information Protocol . . . . . . . . . . . 18	 	         3.2.4.1.  Routing Information Protocol . . . . . . . . . . . 19	
>           3.2.4.2.  Open Shortest Path First . . . . . . . . . . . . . 19	 	         3.2.4.2.  Open Shortest Path First . . . . . . . . . . . . . 19	
>           3.2.4.3.  ISO Intermediate System to Intermediate System . . 19	 	         3.2.4.3.  ISO Intermediate System to Intermediate System . . 20	
>           3.2.4.4.  Border Gateway Protocol  . . . . . . . . . . . . . 19	 	         3.2.4.4.  Border Gateway Protocol  . . . . . . . . . . . . . 20	
>           3.2.4.5.  Dynamic MANET On-demand (DYMO) Routing . . . . . . 20	 	         3.2.4.5.  Dynamic MANET On-demand (DYMO) Routing . . . . . . 20	
>           3.2.4.6.  Optimized Link State Routing Protocol  . . . . . . 20	 	         3.2.4.6.  Optimized Link State Routing Protocol  . . . . . . 21	
>           3.2.4.7.  Routing for Low power and Lossy Networks . . . . . 20	 	         3.2.4.7.  Routing for Low power and Lossy Networks . . . . . 21	
>         3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 20	 	       3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 22	
>           3.2.5.1.  Protocol-Independent Multicast Routing . . . . . . 21	 	         3.2.5.1.  Protocol-Independent Multicast Routing . . . . . . 22	
>         3.2.6.  Adaptation to lower layer networks and link layer	 	       3.2.6.  Adaptation to lower layer networks and link layer	
>                 protocols  . . . . . . . . . . . . . . . . . . . . . . 21	 	               protocols  . . . . . . . . . . . . . . . . . . . . . . 23	
>       3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 22	 	     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 23	
>         3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 22	 	       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 23	
>         3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 22	 	       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 24	
>         3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 23	 	       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 24	
>         3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 23	 	       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 25	
>       3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 24	 	     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 25	
>         3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 24	 	       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 25	
>         3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 24	 	       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 26	
>       3.5.  Service and Resource Discovery . . . . . . . . . . . . . . 24	 	       3.4.3.  Network Time . . . . . . . . . . . . . . . . . . . . . 26	
>         3.5.1.  Service Discovery  . . . . . . . . . . . . . . . . . . 24	 	     3.5.  Network Management . . . . . . . . . . . . . . . . . . . . 26	
>         3.5.2.  Resource     Discovery . . . . . . . . . . . . . . . . 25	 	       3.5.1.  Simple Network Management Protocol (SNMP)  . . . . . . 26	
>       3.6.  Other Applications . . . . . . . . . . . . . . . . . . . . 26	 	       3.5.2.  Network Configuration (NETCONF) Protocol . . . . . . . 27	
>         3.6.1.  Network Time . . . . . . . . . . . . . . . . . . . . . 26	 	     3.6.  Service and Resource Discovery . . . . . . . . . . . . . . 28	
>         3.6.2.  Session Initiation Protocol  . . . . . . . . . . . . . 26	 	       3.6.1.  Service Discovery  . . . . . . . . . . . . . . . . . . 28	
>         3.6.3.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 27	 	       3.6.2.  Resource Discovery . . . . . . . . . . . . . . . . . . 28	
>     4.  A simplified view of the business architecture . . . . . . . . 27	 	     3.7.  Other Applications . . . . . . . . . . . . . . . . . . . . 29	
>     5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31	 	       3.7.1.  Session Initiation Protocol  . . . . . . . . . . . . . 29	
>     6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32	 	       3.7.2.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 30	
>     7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32	 	   4.  A simplified view of the business architecture . . . . . . . . 30	
>     8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32	 	   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34	
>       8.1.  Normative References . . . . . . . . . . . . . . . . . . . 32	 	   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35	
>       8.2.  Informative References . . . . . . . . . . . . . . . . . . 32	 	   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35	
>     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44	 	   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 35	
>   	     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 35	
>   	     8.2.  Informative References . . . . . . . . . . . . . . . . . . 35	
>   	   Appendix A.  Example: Advanced Metering Infrastructure . . . . . . 49	
>   	     A.1.  How to structure a network . . . . . . . . . . . . . . . . 51	
>   	       A.1.1.  HAN Routing  . . . . . . . . . . . . . . . . . . . . . 53	
>   	       A.1.2.  HAN Security . . . . . . . . . . . . . . . . . . . . . 53	
>   	     A.2.  Model 1: AMI with separated domains  . . . . . . . . . . . 54	
>   	     A.3.  Model 2: AMI with neighborhood access to the home  . . . . 55	
>   	     A.4.  Model 3: Collector is an IP router . . . . . . . . . . . . 56	
>   	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57	
>   		
> 1.  Introduction	 	1.  Introduction	
>   		
>     This document provides Smart Grid designers with advice on how to	 	   This document provides Smart Grid designers with advice on how to	
>     best "profile" the Internet Protocol Suite (IPS) for use on with	 	   best "profile" the Internet Protocol Suite (IPS) for use on with	
>     Smart Grids.  It provides an overview of the IPS and the key	 	   Smart Grids.  It provides an overview of the IPS and the key	
>     protocols that are critical in integrating Smart Grid devices into an	 	   protocols that are critical in integrating Smart Grid devices into an	
>     IP-based infrastructure.	 	   IP-based infrastructure.	
>   		
>     The IPS provides options for several key architectural components.	 	   The IPS provides options for several key architectural components.	
>   		
> skipping to change at page 4, line 45		skipping to change at page 4, line 45	
>   		
>     o  IPv6 Node Requirements [RFC4294],	 	   o  IPv6 Node Requirements [RFC4294],	
>   		
>     At this writing, RFC 4294 is in the process of being updated, in	 	   At this writing, RFC 4294 is in the process of being updated, in	
>     [I-D.ietf-6man-node-req-bis].	 	   [I-D.ietf-6man-node-req-bis].	
>   		
>     This document is intended to provide Smart Grid architects and	 	   This document is intended to provide Smart Grid architects and	
>     designers with a compendium of relevant RFCs (and to some extent	 	   designers with a compendium of relevant RFCs (and to some extent	
>     Internet Drafts), and is organized as an annotated list of RFCs.  To	 	   Internet Drafts), and is organized as an annotated list of RFCs.  To	
>     that end, the remainder of this document is organized as follows:	 	   that end, the remainder of this document is organized as follows:	
>     Section 2 describes the Internet Architecture and its protocol suite.	 	                                                                         	
>     Section 3 outlines the set of protocols that will be useful in Smart	 	   o  Section 2 describes the Internet Architecture and its protocol	
>     Grid deployment.  Finally, Section 4 provides an overview of the	 	      suite.	
>     business architecture embodied in the design and deployment of the	 	                                                                         	
>     IPS.	 	   o  Section 3 outlines the set of protocols that will be useful in	
>   	      Smart Grid deployment.	
>   	                                                                         	
>   	   o  Finally, Section 4 provides an overview of the business	
>   	      architecture embodied in the design and deployment of the IPS.	
>   		
> 2.  The Internet Protocol Suite	 	2.  The Internet Protocol Suite	
>   		
>     Before enumerating the list of Internet protocols relevant to Smart	 	   Before enumerating the list of Internet protocols relevant to Smart	
>     Grid, we discuss the layered architecture of the IPS, the functions	 	   Grid, we discuss the layered architecture of the IPS, the functions	
>     of the various layers, and their associated protocols.	 	   of the various layers, and their associated protocols.	
>   		
> 2.1.  Internet Protocol Layers	 	2.1.  Internet Protocol Layers	
>   		
>     While Internet architecture uses the definitions and language similar	 	   While Internet architecture uses the definitions and language similar	
>   		
> skipping to change at page 8, line 49		skipping to change at page 8, line 49	
>     At the lowest layer of the IP architecture, data is encoded in	 	   At the lowest layer of the IP architecture, data is encoded in	
>     messages and transmitted over the physical media.  While the IETF	 	   messages and transmitted over the physical media.  While the IETF	
>     specifies algorithms for carrying IPv4 and IPv6 various media types,	 	   specifies algorithms for carrying IPv4 and IPv6 various media types,	
>     it rarely actually defines the media - it happily uses specifications	 	   it rarely actually defines the media - it happily uses specifications	
>     from IEEE, ITU, and other sources.	 	   from IEEE, ITU, and other sources.	
>   		
> 2.2.  Security issues	 	2.2.  Security issues	
>   		
>     While it is popular to complain about the security of the Internet,	 	   While it is popular to complain about the security of the Internet,	
>     solutions to many Internet security problems already exist but have	 	   solutions to many Internet security problems already exist but have	
>     not been widely deployed.  Internet security solutions attempt to	 	   either not been widely deployed, may impact critical performance	
>     mitigate a set of known threats at a specified cost; addressing	 	   criteria, or require security measures outside the IPS.  Internet	
>     security issues requires first a threat analysis and assessment and a	 	   security solutions attempt to mitigate a set of known threats within	
>     set of mitigations appropriate to the threats.  Since we have threats	 	   the IPS domain at a specified cost; addressing security issues	
>     at every layer, we should expect to find mitigations at every layer.	 	   requires first a threat analysis and assessment and a set of	
>   	   mitigations appropriate to the threats.  Since we have threats at	
>   	   every layer, we should expect to find mitigations at every layer.	
>   		
> 2.2.1.  Physical security	 	2.2.1.  Physical security	
>   		
>     At the physical and data link layers, threats generally center on	 	   At the physical and data link layers, threats generally center on	
>     physical attacks on the network - the effects of backhoes,	 	   physical attacks on the network - the effects of backhoes,	
>     deterioration of physical media, and various kinds of environmental	 	   deterioration of physical media, and various kinds of environmental	
>     noise.  Radio-based networks are subject to signal fade due to	 	   noise.  Radio-based networks are subject to signal fade due to	
>     distance, interference, and environmental factors; it is widely noted	 	   distance, interference, and environmental factors; it is widely noted	
>     that IEEE 802.15.4 networks frequently place a metal ground plate	 	   that IEEE 802.15.4 networks frequently place a metal ground plate	
>     between the meter and the device that manages it.  Fiber was at one	 	   between the meter and the device that manages it.  Fiber was at one	
>   		
> skipping to change at page 9, line 26		skipping to change at page 9, line 28	
>     learned to tap it by bending the fiber and collecting incidental	 	   learned to tap it by bending the fiber and collecting incidental	
>     light, and we have learned about backhoes.  As a result, some	 	   light, and we have learned about backhoes.  As a result, some	
>     installations encase fiber optic cable in a pressurized sheath, both	 	   installations encase fiber optic cable in a pressurized sheath, both	
>     to quickly identify the location of a cut and to make it more	 	   to quickly identify the location of a cut and to make it more	
>     difficult to tap.	 	   difficult to tap.	
>   		
>     While there are protocol behaviors that can detect certain classes of	 	   While there are protocol behaviors that can detect certain classes of	
>     physical faults, such as keep-alive exchanges, physical security is	 	   physical faults, such as keep-alive exchanges, physical security is	
>     generally not considered to be a protocol problem.	 	   generally not considered to be a protocol problem.	
>   		
> 2.2.2.  Session identification	 	2.2.2.  Session Authentication	
>   		
>     At the transport and application layers and in lower layer networks	 	   At the transport and application layers and in lower layer networks	
>     where dynamic connectivity such as ATM Switched Virtual Circuits	 	   where dynamic connectivity such as ATM Switched Virtual Circuits	
>     (SVCs) or "dial" connectivity are in use, there tend to be several	 	   (SVCs) or "dial" connectivity are in use, there tend to be several	
>     different classes of authentication/authorization requirements.  The	 	   different classes of authentication/authorization requirements.  The	
>     basic requirements that must be satisfied are:	 	   basic requirements that must be satisfied are:	
>   		
>     1.  Verify that peers are appropriate partners; this generally means	 	   1.  Verify that peers are appropriate partners; this generally means	
>         knowing "who" they are and that they have a "need to know" or are	 	       knowing "who" they are and that they have a "need to know" or are	
>         trusted sources.	 	       trusted sources.	
>   		
> skipping to change at page 10, line 9		skipping to change at page 10, line 11	
>         against modification attacks.	 	       against modification attacks.	
>   		
>     In other words, both the communications channel itself and message	 	   In other words, both the communications channel itself and message	
>     exchanges (both by knowing the source of the information and to have	 	   exchanges (both by knowing the source of the information and to have	
>     proof of its validity) must be secured.  Three examples suffice to	 	   proof of its validity) must be secured.  Three examples suffice to	
>     illustrate the challenges.	 	   illustrate the challenges.	
>   		
>     One common attack against a TCP session is to bombard the session	 	   One common attack against a TCP session is to bombard the session	
>     with reset messages.  Other attacks against TCP include the "SYN	 	   with reset messages.  Other attacks against TCP include the "SYN	
>     flooding" attack, in which an attacker attempts to exhaust the memory	 	   flooding" attack, in which an attacker attempts to exhaust the memory	
>     of the target by creating TCP state.  Experience has shown that by	 	   of the target by creating TCP state.  In particular, the attacker	
>     including information in the transport header or a related protocol	 	   attempts to exhaust the target's memory by opening a large number of	
>     like the IPsec (Section 3.1.2) or TLS (Section 3.1.3), a host can	 	   unique TCP connections, each of which is represented by a	
>     identify legitimate messages and discard mitigate any damage that may	 	   Transmission Control Block (TCB).  The attack is successful if the	
>     have been caused by the attack.	 	   attacker can cause the target to fill its memory with TCBs.	
>   	   Experience has shown that by including information in the transport	
>   	   header or a related protocol like the IPsec (Section 3.1.2) or TLS	
>   	   (Section 3.1.3), a host can identify legitimate messages and discard	
>   	   the others, thus mitigating any damage that may have been caused by	
>   	   the attack.	
>   		
>     Another common attack involves unauthorized communication with a	 	   Another common attack involves unauthorized communication with a	
>     router or a service.  For example, an unauthorized party might try to	 	   router or a service.  For example, an unauthorized party might try to	
>     join the routing system.  To protect against such attacks, an	 	   join the routing system.  To protect against such attacks, an	
>     Internet Service Provider (ISP) should not accept information from	 	   Internet Service Provider (ISP) should not accept information from	
>     new peers without verifying that the peer is who it claims to be and	 	   new peers without verifying that the peer is who it claims to be and	
>     that the peer is authorized to carry on the exchange of information.	 	   that the peer is authorized to carry on the exchange of information.	
>   		
>     More generally, in order to secure a communications channel, it must	 	   More generally, in order to secure a communications channel, it must	
>     be possible to verify that messages putatively received from a peer	 	   be possible to verify that messages putatively received from a peer	
>   		
> skipping to change at page 11, line 7		skipping to change at page 11, line 11	
>     there frequently a requirement for confidentiality.  Confidentiality	 	   there frequently a requirement for confidentiality.  Confidentiality	
>     arises at several layers, sometimes simultaneously.  For example,	 	   arises at several layers, sometimes simultaneously.  For example,	
>     providers of credit card transaction services want application layer	 	   providers of credit card transaction services want application layer	
>     privacy, which can be supplied by encrypting application data or by	 	   privacy, which can be supplied by encrypting application data or by	
>     an encrypted transport layer.  If an ISP (or other entity) wants to	 	   an encrypted transport layer.  If an ISP (or other entity) wants to	
>     hide its network structure, it can to encrypt the network layer	 	   hide its network structure, it can to encrypt the network layer	
>     header.	 	   header.	
>   		
> 2.3.  Network Infrastructure	 	2.3.  Network Infrastructure	
>   		
>     While these are not critical to the design of a specific system, they	 	   While the following protocols are not critical to the design of a	
>     are important to running a network, and as such are surveyed here.	 	   specific system, they are important to running a network, and as such	
>   	   are surveyed here.	
>   		
> 2.3.1.  Domain Name System (DNS)	 	2.3.1.  Domain Name System (DNS)	
>   		
>     The DNS' main function is translating names to numeric IP addresses.	 	   The DNS' main function is translating names to numeric IP addresses.	
>     While this is not critical to running a network, certain functions	 	   While this is not critical to running a network, certain functions	
>     are made a lot easier if numeric addresses can be replaced with	 	   are made a lot easier if numeric addresses can be replaced with	
>     mnemonic names.  This facilitates renumbering of networks and	 	   mnemonic names.  This facilitates renumbering of networks and	
>     generally improves the manageability and serviceability of the	 	   generally improves the manageability and serviceability of the	
>     network.  DNS has a set of security extensions called DNSSEC, which	 	   network.  DNS has a set of security extensions called DNSSEC, which	
>     can be used to provide strong cryptographic authentication to that	 	   can be used to provide strong cryptographic authentication to the	
>     protocol.  DNS and DNSSEC are discussed further in Section 3.4.1.	 	   DNS.  DNS and DNSSEC are discussed further in Section 3.4.1.	
>   		
> 2.3.2.  Network Management	 	2.3.2.  Network Management	
>   		
>     Network management has proven to be a difficult problem.  As such,	 	   Network management has proven to be a difficult problem.  As such,	
>     various solutions have been proposed, implemented, and deployed.	 	   various solutions have been proposed, implemented, and deployed.	
>     Each solution has its proponents, all of whom have solid arguments	 	   Each solution has its proponents, all of whom have solid arguments	
>     for their viewpoints.  The IETF has two major network management	 	   for their viewpoints.  The IETF has two major network management	
>     solutions for device operation: SNMP, which is ASN.1-encoded and is	 	   solutions for device operation: SNMP, which is ASN.1-encoded and is	
>     primarily used for monitoring of system variables and is a polled	 	   primarily used for monitoring of system variables and is a polled	
>     architecture, and NetConf [RFC4741], which is XML-encoded and	 	   architecture, and NetConf [RFC4741], which is XML-encoded and	
>   		
> skipping to change at page 11, line 47		skipping to change at page 12, line 5	
>     While the IP Protocol Suite does not have specific solutions for	 	   While the IP Protocol Suite does not have specific solutions for	
>     secure provisioning and configuration, these problems have been	 	   secure provisioning and configuration, these problems have been	
>     solved using IP protocols in specifications such as DOCSIS 3.0	 	   solved using IP protocols in specifications such as DOCSIS 3.0	
>     [SP-MULPIv3.0].	 	   [SP-MULPIv3.0].	
>   		
> 3.  Specific protocols	 	3.  Specific protocols	
>   		
>     In this section, having briefly laid out the IP architecture and some	 	   In this section, having briefly laid out the IP architecture and some	
>     of the problems that the architecture tries to address, we introduce	 	   of the problems that the architecture tries to address, we introduce	
>     specific protocols that might be appropriate to various Smart Grid	 	   specific protocols that might be appropriate to various Smart Grid	
>     use cases.  Use cases should be analyzed along privacy, AAA,	 	   use cases.  Use cases should be analyzed along privacy,	
>     transport and network solution dimensions.  The following sections	 	   Authentication, Authorization, and Accounting (AAA), transport and	
>     provide guidance for such analyzes.	 	   network solution dimensions.  The following sections provide guidance	
>   	   for such analyzes.	
>   		
> 3.1.  Security solutions	 	3.1.  Security solutions	
>   		
>     As noted, a key consideration in security solutions is a good threat	 	   As noted, a key consideration in security solutions is a good threat	
>     analysis coupled with appropriate mitigation strategies at each	 	   analysis coupled with appropriate mitigation strategies at each	
>     layer.  The following sections outline the security features of the	 	   layer.  The following sections outline the security features of the	
>     IPS.	 	   IPS.	
>   		
> 3.1.1.  Session identification, authentication, authorization, and	 	3.1.1.  Session identification, authentication, authorization, and	
>          accounting	 	        accounting	
>   		
> skipping to change at page 12, line 34		skipping to change at page 12, line 39	
>   		
>     The Security Architecture for the Internet Protocol (IPsec) [RFC4301]	 	   The Security Architecture for the Internet Protocol (IPsec) [RFC4301]	
>     is a set of control and data protocols that are implemented between	 	   is a set of control and data protocols that are implemented between	
>     IPv4 and the chosen transport layer, or in IPv6's security extension	 	   IPv4 and the chosen transport layer, or in IPv6's security extension	
>     header.  It allows transport layer sessions to communicate in a way	 	   header.  It allows transport layer sessions to communicate in a way	
>     that is designed to prevent eavesdropping, tampering, or message	 	   that is designed to prevent eavesdropping, tampering, or message	
>     forgery.  As is typical with IETF specifications, the architecture is	 	   forgery.  As is typical with IETF specifications, the architecture is	
>     spelled out in a number of documents which specify the specific	 	   spelled out in a number of documents which specify the specific	
>     components: the IP Authentication Header (AH) [RFC4302] Encapsulating	 	   components: the IP Authentication Header (AH) [RFC4302] Encapsulating	
>     Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2)	 	   Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2)	
>     [RFC4306], Cryptographic Algorithms [RFC4307], Cryptographic	 	   [RFC5996], Cryptographic Algorithms [RFC4307], Cryptographic	
>     Algorithm Implementation Requirements for ESP and AH [RFC4835], and	 	   Algorithm Implementation Requirements for ESP and AH [RFC4835], and	
>     the use of Advanced Encryption Standard (AES) [RFC4309].	 	   the use of Advanced Encryption Standard (AES) [RFC4309].	
>   		
>     IPsec provides two modes: Transport mode and tunnel mode.  In	 	   IPsec provides two modes: Transport mode and tunnel mode.  In	
>     transport mode, IPsec ESP encrypts the transport layer and the	 	   transport mode, IPsec ESP encrypts the transport layer and the	
>     application data.  In tunnel mode, the source IP datagram is	 	   application data.  In tunnel mode, the source IP datagram is	
>     encrypted and encapsulated in a second IP header addressed to the	 	   encrypted and encapsulated in a second IP header addressed to the	
>     intended decryptor.  As might be expected, tunnel mode is frequently	 	   intended decryptor.  As might be expected, tunnel mode is frequently	
>     used for virtual private networks which need to securely transmit	 	   used for virtual private networks which need to securely transmit	
>     data across networks with unknown (or no) other security properties.	 	   data across networks with unknown (or no) other security properties.	
>     In both cases, authentication, authorization, and confidentiality	 	   In both cases, authentication, authorization, and confidentiality	
>     extend from system to system, and apply to all applications that the	 	   extend from system to system, and apply to all applications that the	
>     two systems use.	 	   two systems use.	
>   		
>   	   Note that IPsec can provide non-repudiation when an asymmetric	
>   	   authentication algorithm is used with the AH header and both sender	
>   	   and receiver keys are used in the authentication calculation.	
>   	   However, the default authentication algorithm is keyed MD5, which	
>   	   like all symmetric algorithms cannot provide non-repudiation by	
>   	   itself (since the sender's key is not used in the computation).  So	
>   	   while IPsec provides a means of authenticating network level objects	
>   	   (packets), these objects are are ephemeral and not directly	
>   	   correlated with a particular application.  As a result non-	
>   	   repudiation is not generally applicable to network level objects such	
>   	   as packets.	
>   	                                                                         	
> 3.1.3.  Transport Layer Security (TLS)	 	3.1.3.  Transport Layer Security (TLS)	
>   		
>     Transport Layer Security [RFC5246] and Datagram Transport Layer	 	   Transport Layer Security [RFC5246] and Datagram Transport Layer	
>     Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that	 	   Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that	
>     travel within the transport layer protocol data unit, meaning that	 	   travel within the transport layer protocol data unit, meaning that	
>     they readily traverse network address translators and secure the	 	   they readily traverse network address translators and secure the	
>     information exchanges without securing the datagrams exchanged or the	 	   information exchanges without securing the datagrams exchanged or the	
>     transport layer itself.  Each allows client/server applications to	 	   transport layer itself.  Each allows client/server applications to	
>     communicate in a way that is designed to prevent eavesdropping,	 	   communicate in a way that is designed to prevent eavesdropping,	
>     tampering, or message forgery.  Authentication, authorization, and	 	   tampering, or message forgery.  Authentication, authorization, and	
>     confidentiality exist for a session between specific applications.	 	   confidentiality exist for a session between specific applications.	
>   		
>     When used in conjunction with IEEE 802.1X [IEEE802.1X], EAP-TLS	 	   In order to communicate securely, an TLS client and TLS server must	
>     [RFC5216] is widely considered to offer excellent access security to	 	   agree on the cryptographic algorithms and keys that they will use on	
>     a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with	 	   the secured connection.  In particular, they must agree on these	
>     EAP-TLS is the baseline for Zigbee SEP 2.0).  Note that one potential	 	   items:	
>     drawback of 802.1X technology is that it requires deployment of	 		
>     client-side certificates, which is frequently seen as a deployment	 	   o  Key Establishment Algorithm	
>     barrier.	 		
>   	   o  Peer Authentication Algorithm	
>   		
>   	   o  Bulk Data Encryption Algorithm and key size	
>   		
>   	   o  Digest Algorithm	
>   		
>   	   Since each categories has multiple options, the number of possible	
>   	   combinations is large.  As a result, TLS does not allow all possible	
>   	   combinations of choices; rather it only allows certain well-defined	
>   	   combinations known as Cipher Suites.  [IEC62351-3] outlines the use	
>   	   of different TLS Cipher Suites for use in the Smart Grid.	
>   	                                                                         	
>   	   When used in conjunction with IEEE 802.1X [IEEE802.1X], both EAP-TLS	
>   	   [RFC5216] and the Protocol for Carrying Authentication for Network	
>   	   Access (PANA) [RFC5193] are widely considered to offer excellent	
>   	   access security to a wired or wireless IEEE 802 LAN (IEEE 802.1X in	
>   	   conjunction with EAP-TLS is the baseline for Zigbee SEP 2.0).	
>   		
> 3.1.4.  Secure/Multipurpose Internet Mail Extensions (S/MIME)	 	3.1.4.  Secure/Multipurpose Internet Mail Extensions (S/MIME)	
>   		
>     The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]	 	   The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]	
>     [RFC5750] [RFC5751] [RFC4262] specification was originally designed	 	   [RFC5750] [RFC5751] [RFC4262] specification was originally designed	
>     as an extension to SMTP Mail to provide evidence that the putative	 	   as an extension to SMTP Mail to provide evidence that the putative	
>     sender of an email message in fact sent it, and that the content	 	   sender of an email message in fact sent it, and that the content	
>     received was in fact the content that was sent.  As its name	 	   received was in fact the content that was sent.  As its name	
>     suggests, by extension this is a way of securing any object that can	 	   suggests, by extension this is a way of securing any object that can	
>     be exchanged, by any means, and has become one of the most common	 	   be exchanged, by any means, and has become one of the most common	
>   		
> skipping to change at page 15, line 19		skipping to change at page 16, line 6	
>        [I-D.ietf-behave-address-format]	 	      [I-D.ietf-behave-address-format]	
>   		
>     o  DNS extensions [I-D.ietf-behave-dns64]	 	   o  DNS extensions [I-D.ietf-behave-dns64]	
>   		
>     o  IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]	 	   o  IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]	
>   		
>     o  Translation from IPv6 Clients to IPv4 Servers	 	   o  Translation from IPv6 Clients to IPv4 Servers	
>        [I-D.ietf-behave-v6v4-xlate-stateful]	 	      [I-D.ietf-behave-v6v4-xlate-stateful]	
>   		
>     As with IPv4/IPv4 Network Address Translation, translation between	 	   As with IPv4/IPv4 Network Address Translation, translation between	
>     IPv4 and IPv6 has limited real world applicability: any application	 	   IPv4 and IPv6 has limited real world applicability for an application	
>     protocol that carries IP addresses and expects them to be meaningful	 	   protocol which carry IP addresses in its payload and expects those	
>     to both client and server or to both peers will have trouble when the	 	   addresses to be meaningful to both client and server.  However, for	
>     addresses are transparently translated.  However, for those protocols	 	   those protocols that do not, protocol translation can provide a	
>     that do not, protocol translation can provide a useful network	 	   useful network extension.	
>     extension.	 		
>   		
>     Network-based translation provides for two types of services:	 	   Network-based translation provides for two types of services:	
>     stateless (and therefore scalable and load-sharable) translation	 	   stateless (and therefore scalable and load-sharable) translation	
>     between IPv4 and IPv6 addresses that embed an IPv4 address in them,	 	   between IPv4 and IPv6 addresses that embed an IPv4 address in them,	
>     and stateful translation similar to IPv4/IPv4 translation between	 	   and stateful translation similar to IPv4/IPv4 translation between	
>     IPv4 addresses.  The stateless mode is straightforward to implement,	 	   IPv4 addresses.  The stateless mode is straightforward to implement,	
>     but due to the embedding, requires IPv4 addresses to be allocated to	 	   but due to the embedding, requires IPv4 addresses to be allocated to	
>     an otherwise IPv6-only network, and is primarily useful for IPv4-	 	   an otherwise IPv6-only network, and is primarily useful for IPv4-	
>     accessible servers implemented in the IPv6 network.  The stateful	 	   accessible servers implemented in the IPv6 network.  The stateful	
>     mode allows clients in the IPv6 network to access servers in the IPv4	 	   mode allows clients in the IPv6 network to access servers in the IPv4	
>     network, but does not provide such service for IPv4 clients accessing	 	   network, but does not provide such service for IPv4 clients accessing	
>     IPv6 peers or servers with general addresses; it does however have	 	   IPv6 peers or servers with general addresses; it does however have	
>     the advantage that it does not require that a unique IPv4 address be	 	   the advantage that it does not require that a unique IPv4 address be	
>     embedded in the IPv6 address of hosts using this mechanism.	 	   embedded in the IPv6 address of hosts using this mechanism.	
>   		
>   	   Finally, note that some networks site networks are IPv6 only while	
>   	   some transits networks are IPv4 only.  In these cases it may be	
>   	   necessary to tunnel IPv6 over IPv4 or translate between IPv6 and	
>   	   IPv4.	
>   	                                                                         	
> 3.2.2.  Internet Protocol Version 4	 	3.2.2.  Internet Protocol Version 4	
>   		
>     IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792]	 	   IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792]	
>     comprise the IPv4 network layer.  IPv4 provides unreliable delivery	 	   comprise the IPv4 network layer.  IPv4 provides unreliable delivery	
>     of datagrams.	 	   of datagrams.	
>   		
>     IPv4 also provides for fragmentation and reassembly of long datagrams	 	   IPv4 also provides for fragmentation and reassembly of long datagrams	
>     for transmission through networks with small Maximum Transmission	 	   for transmission through networks with small Maximum Transmission	
>     Units (MTU).  The MTU is the largest packet size that can be	 	   Units (MTU).  The MTU is the largest packet size that can be	
>     delivered across the network.  In addition, the IPS provides the	 	   delivered across the network.  In addition, the IPS provides the	
>   		
> skipping to change at page 16, line 15		skipping to change at page 17, line 6	
>     IPv4 originally supported an experimental type of service field that	 	   IPv4 originally supported an experimental type of service field that	
>     identified eight levels of operational precedence styled after the	 	   identified eight levels of operational precedence styled after the	
>     requirements of military telephony, plus three and later four bit	 	   requirements of military telephony, plus three and later four bit	
>     flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2	 	   flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2	
>     [RFC2328] interpreted as control traffic; this control traffic is	 	   [RFC2328] interpreted as control traffic; this control traffic is	
>     assured of not being dropped when queued or upon receipt even if	 	   assured of not being dropped when queued or upon receipt even if	
>     other traffic is being dropped..  These control bits turned out to be	 	   other traffic is being dropped..  These control bits turned out to be	
>     less useful than the designers had hoped.  They were replaced by the	 	   less useful than the designers had hoped.  They were replaced by the	
>     Differentiated Services Architecture [RFC2474][RFC2475], which	 	   Differentiated Services Architecture [RFC2474][RFC2475], which	
>     contains a six bit code point used to select an algorithm (a "per-hop	 	   contains a six bit code point used to select an algorithm (a "per-hop	
>     behavior") to be applied to the datagram.	 	   behavior") to be applied to the datagram.  The IETF has also produced	
>   	   a set of Configuration Guidelines for DiffServ Service Classes	
>   	   [RFC4594], which describes a set of service classes that may be	
>   	   useful to a network operator.	
>   		
> 3.2.2.1.  IPv4 Address Allocation and Assignment	 	3.2.2.1.  IPv4 Address Allocation and Assignment	
>   		
>     IPv4 addresses are administratively assigned, usually using automated	 	   IPv4 addresses are administratively assigned, usually using automated	
>     methods, and assigned using the Dynamic Host Configuration Protocol	 	   methods, and assigned using the Dynamic Host Configuration Protocol	
>     (DHCP) [RFC2131].  On most interface types, neighboring equipment	 	   (DHCP) [RFC2131].  On most interface types, neighboring equipment	
>     identify each other's addresses using Address Resolution Protocol	 	   identify each other's addresses using Address Resolution Protocol	
>     (ARP) [RFC0826].	 	   (ARP) [RFC0826].	
>   		
> 3.2.2.2.  IPv4 Unicast Routing	 	3.2.2.2.  IPv4 Unicast Routing	
>   		
> skipping to change at page 20, line 41		skipping to change at page 21, line 32	
>     can be used in other forms of ad hoc networks.  It provides arbitrary	 	   can be used in other forms of ad hoc networks.  It provides arbitrary	
>     connectivity between device within a distributed subnet.  As with	 	   connectivity between device within a distributed subnet.  As with	
>     protocols designed for wired networks, routing is calculated and	 	   protocols designed for wired networks, routing is calculated and	
>     maintained whenever changes are detected, and maintained in each	 	   maintained whenever changes are detected, and maintained in each	
>     router's tables.  The set of nodes that operate as routers within the	 	   router's tables.  The set of nodes that operate as routers within the	
>     subnet, however, are fairly fluid, and dependent on this	 	   subnet, however, are fairly fluid, and dependent on this	
>     instantaneous topology of the subnet.	 	   instantaneous topology of the subnet.	
>   		
> 3.2.4.7.  Routing for Low power and Lossy Networks	 	3.2.4.7.  Routing for Low power and Lossy Networks	
>   		
>     The RPL: IPv6 Routing Protocol for Low power and Lossy Networks	 	   The IPv6 Routing Protocol for Low power and Lossy Networks (RPL)	
>     [I-D.ietf-roll-rpl] xxx	 	   [I-D.ietf-roll-rpl] is a reactive routing protocol designed for use	
>   	   in resource constrained networks.  Requirements for resource	
>   	   constrained networks are defined in [RFC5548], [RFC5673], [RFC5826],	
>   	   and [RFC5867].	
>   		
>   	   Briefly, a constrained network is comprised of nodes that:	
>   		
>   	   o  Are built with limited processing power and memory, and sometimes	
>   	      energy when operating on batteries.	
>   		
>   	   o  Are interconnected through a low-data-rate network interface and	
>   	      potentially vulnerable to communication instability and low packet	
>   	      delivery rates.	
>   		
>   	   o  Potentially have a mix of roles such as being able to act as a	
>   	      host (i.e., generating traffic) and/or a router (i.e., both	
>   	      forwarding and generating RPL traffic).	
>   		
> 3.2.5.  IPv6 Multicast Forwarding and Routing	 	3.2.5.  IPv6 Multicast Forwarding and Routing	
>   		
>     IPv6 specifies both unicast and multicast datagram exchange.  This	 	   IPv6 specifies both unicast and multicast datagram exchange.  This	
>     uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]	 	   uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]	
>     [RFC3590] [RFC3810] [RFC4604] to enable applications to join	 	   [RFC3590] [RFC3810] [RFC4604] to enable applications to join	
>     multicast groups, and for most applications uses Source-Specific	 	   multicast groups, and for most applications uses Source-Specific	
>     Multicast [RFC4607] for routing and delivery of multicast messages.	 	   Multicast [RFC4607] for routing and delivery of multicast messages.	
>   		
>     The mechanisms experimentally developed for reliable multicast in	 	   The mechanisms experimentally developed for reliable multicast in	
>     IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.	 	   IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.	
>   		
> 3.2.5.1.  Protocol-Independent Multicast Routing	 	3.2.5.1.  Protocol-Independent Multicast Routing	
>   		
>     xxx Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol	 	   A multicast routing protocol has two basic functions: Building the	
>     Specification (Revised) [RFC3973] xxx Protocol Independent Multicast	 	   multicast distribution tree and forwarding multicast traffic.	
>   	   Multicast routing protocols generally contain a control plane for	
>   	   building distribution trees, and a forwarding plane that uses the	
>   	   distribution tree when forwarding multicast traffic.	
>   		
>   	   A the highest level, the multicast model works as follows: hosts	
>   	   express their interest in receiving multicast traffic from a source	
>   	   by sending a Join message to their first hop router.  That router in	
>   	   turn sends a Join message upstream towards the root of the tree,	
>   	   grafting the router (leaf node) onto the distribution tree for the	
>   	   group.  Data is delivered down the tree toward the leaf nodes, which	
>   	   forward it onto the local network for delivery.	
>   		
>   	   The initial multicast model deployed in the Internet was known as	
>   	   Any-Source Multicast (ASM).  In the ASM model any host could send to	
>   	   the group, and inter-domain multicast was difficult.  Protocols such	
>   	   as Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol	
>   	   Specification (Revised) [RFC3973] and Protocol Independent Multicast	
>     - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601]	 	   - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601]	
>     xxx Source-Specific Multicast (SSM) [RFC3569] xxx Source-Specific	 	   were designed for the ASM model.	
>     Protocol Independent Multicast [RFC4608] xxx Authentication and	 		
>     Confidentiality in Protocol Independent Multicast Sparse Mode	 	   Many modern multicast deployments use Source-Specific Multicast (PIM-	
>     (PIM-SM) Link-Local Messages [RFC5796] xxx	 	   SSM) [RFC3569][RFC4608].  In the SSM model, a host expresses interest	
>   	   in a "channel", which is comprised of a source (S) and a group (G).	
>   	   Distribution tress are rooted the sending host (called an "(S,G)	
>   	   tree").  Since only the source S can send on to the group, SSM has	
>   	   inherent anti-jamming capability.  In addition, inter-domain	
>   	   multicast is simplified since it is the responsibility of the	
>   	   receivers (rather than the network) to find the (S,G) channel they	
>   	   are interested in receiving.  This implies that SSM requires some	
>   	   form of directory service so that receivers can find the (S,G)	
>   	   channels.	
>   		
> 3.2.6.  Adaptation to lower layer networks and link layer protocols	 	3.2.6.  Adaptation to lower layer networks and link layer protocols	
>   		
>     In general, the layered architecture of the Internet enables the IPS	 	   In general, the layered architecture of the Internet enables the IPS	
>     to run over any appropriate layer two architecture.  The ability to	 	   to run over any appropriate layer two architecture.  The ability to	
>     change the link or physical layer without having to rethink the	 	   change the link or physical layer without having to rethink the	
>     network layer, transports, or applications has been a great benefit	 	   network layer, transports, or applications has been a great benefit	
>     in the Internet.	 	   in the Internet.	
>   		
>     Examples of link layer adaptation technology include:	 	   Examples of link layer adaptation technology include:	
>   		
> skipping to change at page 24, line 40		skipping to change at page 26, line 25	
>     [RFC2131] or DHCPv6 [RFC3315].  The best argument for the use of	 	   [RFC2131] or DHCPv6 [RFC3315].  The best argument for the use of	
>     autoconfiguration is a large number of systems that require little	 	   autoconfiguration is a large number of systems that require little	
>     more than a random number as an address; the argument for DHCP is	 	   more than a random number as an address; the argument for DHCP is	
>     administrative control.	 	   administrative control.	
>   		
>     There are other parameters that may need to be allocated to hosts	 	   There are other parameters that may need to be allocated to hosts	
>     which require administrative configuration; examples include the	 	   which require administrative configuration; examples include the	
>     addresses of DNS servers, keys for Secure DNS and Network Time	 	   addresses of DNS servers, keys for Secure DNS and Network Time	
>     servers.	 	   servers.	
>   		
> 3.5.  Service and Resource Discovery	 	3.4.3.  Network Time	
>   		
>   	   The Network Time Protocol was originally designed by Dave Mills of	
>   	   the University of Delaware and CSNET, for the purpose of implementing	
>   	   a temporal metric in the Fuzzball Routing Protocol and generally	
>   	   coordinating time experiments.  The current versions of the time	
>   	   protocol are the Network Time Protocol [RFC5905].	
>   	                                                                         	
>   	3.5.  Network Management	
>   		
>   	   The IETF has developed two protocols for network management: SNMP and	
>   	   NETCONF.  SNMP is discussed in Section 3.5.1, and NETCONF is	
>   	   discussed in Section 3.5.2.	
>   		
>   	3.5.1.  Simple Network Management Protocol (SNMP)	
>   		
>   	   The Simple Network Management Protocol, originally specified in the	
>   	   late 1980's and having passed through several revisions, is specified	
>   	   in several documents:	
>   		
>   	   o  An Architecture for Describing Simple Network Management Protocol	
>   	      (SNMP) Management Frameworks [RFC3411]	
>   		
>   	   o  Message Processing and Dispatching [RFC3412]	
>   		
>   	   o  SNMP Applications [RFC3413]	
>   	   o  User-based Security Model (USM) for SNMP version 3 [RFC3414]	
>   		
>   	   o  View-based Access Control Model (VACM) [RFC3415]	
>   		
>   	   o  Version 2 of the SNMP Protocol Operations [RFC3416]	
>   		
>   	   o  Transport Mappings [RFC3417]	
>   		
>   	   o  Management Information Base (MIB) [RFC3418]	
>   		
>   	   It provides capabilities for polled and event-driven activities, and	
>   	   for both monitoring and configuration of systems in the field.	
>   	   Historically, it has been used primarily for monitoring nodes in a	
>   	   network.  Messages and their constituent data are encoded using a	
>   	   profile of ASN.1.	
>   		
>   	3.5.2.  Network Configuration (NETCONF) Protocol	
>   		
>   	   The NETCONF Configuration Protocol is specified in one basic	
>   	   document, with supporting documents for carrying it over the IPS.	
>   	   These documents include:	
>   		
>   	   o  NETCONF Configuration Protocol [RFC4741]	
>   		
>   	   o  Using the NETCONF Configuration Protocol over Secure SHell (SSH)	
>   	      [RFC4742]	
>   		
>   	   o  Using NETCONF over the Simple Object Access Protocol (SOAP)	
>   	      [RFC4743]	
>   		
>   	   o  Using the NETCONF Protocol over the Blocks Extensible Exchange	
>   	      Protocol (BEEP) [RFC4744]	
>   		
>   	   o  NETCONF Event Notifications [RFC5277]	
>   		
>   	   o  NETCONF over Transport Layer Security (TLS) [RFC5539]	
>   		
>   	   o  Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]	
>   		
>   	   NETCONF was developed in response to operator requests for a common	
>   	   configuration protocol based on ASCII text as opposed to ASN.1.  In	
>   	   essence, it carries XML-encoded remote procedure call (RPC) data.  In	
>   	   response to Smart Grid requirements, there is consideration of a	
>   	   variant of the protocol that could be used for polled and event-	
>   	   driven management activities, and for both monitoring and	
>   	   configuration of systems in the field.	
>   		
>   	3.6.  Service and Resource Discovery	
>   		
>     Service and resource discovery are among the most important protocols	 	   Service and resource discovery are among the most important protocols	
>     for constrained resource self-organizing networks.  These include	 	   for constrained resource self-organizing networks.  These include	
>     various sensor networks as well as the Home Area Networks (HANs),	 	   various sensor networks as well as the Home Area Networks (HANs),	
>     Building Area Networks (BANs) and Field Area Networks (FANs)	 	   Building Area Networks (BANs) and Field Area Networks (FANs)	
>     envisioned by Smart Grid architects.	 	   envisioned by Smart Grid architects.	
>   		
> 3.5.1.  Service Discovery	 	3.6.1.  Service Discovery	
>   		
>     Service discovery protocols are designed for the automatic	 	   Service discovery protocols are designed for the automatic	
>     configuration and detection of devices, and the services offered by	 	   configuration and detection of devices, and the services offered by	
>     the discovered devices.  In many cases service discovery is performed	 	   the discovered devices.  In many cases service discovery is performed	
>     by so-called "constrained resource" devices (i.e., those with limited	 	   by so-called "constrained resource" devices (i.e., those with limited	
>     processing power, memory, and power resources).	 	   processing power, memory, and power resources).	
>   		
>     In general, service discovery is concerned with the assignment of	 	   In general, service discovery is concerned with the resolution and	
>     network addresses (perhaps via Stateless Address Autoconfiguration	 	   distribution of hostnames via multicast DNS	
>     [RFC4862]), resolution and distribution of hostnames via multicast	 	   [I-D.cheshire-dnsext-multicastdns] and the automatic location of	
>     DNS [I-D.cheshire-dnsext-multicastdns] and the automatic location of	 		
>     network services via DHCP (Section 3.4.2), the DNS Service Discovery	 	   network services via DHCP (Section 3.4.2), the DNS Service Discovery	
>     (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour	 	   (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour	
>     technology), and the Service Location Protocol (SLP) [RFC2608].	 	   technology) and the Service Location Protocol (SLP) [RFC2608].	
>   		
> 3.5.2.  Resource     Discovery	 	3.6.2.  Resource Discovery	
>   		
>     Resource Discovery is concerned with the discovery resources offered	 	   Resource Discovery is concerned with the discovery of resources	
>     by end-points and is extremely important in machine-to-machine	 	   offered by end-points and is extremely important in machine-to-	
>     closed-loop applications (i.e., those with no humans in the loop).	 	   machine closed-loop applications (i.e., those with no humans in the	
>     The goals of resource discover protocols include:	 	   loop).  The goals of resource discover protocols include:	
>   		
>        Simplicity of creation and maintenance of resources	 	      Simplicity of creation and maintenance of resources	
>   		
>        Commonly understood semantics	 	      Commonly understood semantics	
>   		
>        Conformance to existing and emerging standards	 	      Conformance to existing and emerging standards	
>   		
>        International scope and applicability	 	      International scope and applicability	
>   		
>        Extensibility	 	      Extensibility	
>   		
>        Interoperability among collections and indexing systems	 	      Interoperability among collections and indexing systems	
>   		
>     The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is	 	   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is	
>     being developed in IETF with these goals in mind.  In particular,	 	   being developed in IETF with these goals in mind.  In particular,	
>     CoAP is designed for use in constrained resource networks and for	 	   CoAP is designed for use in constrained resource networks and for	
>     machine-to-machine applications such as smart energy and building	 	   machine-to-machine applications such as smart energy and building	
>     automation.  It provides a RESTful transfer protocol, a built-in	 	   automation.  It provides a RESTful transfer protocol [RESTFUL], a	
>     resource discovery protocol, and includes web concepts such as URIs	 	   built-in resource discovery protocol, and includes web concepts such	
>     and content-types.  CoAP provides both unicast and multicast resource	 	   as URIs and content-types.  CoAP provides both unicast and multicast	
>     discovery and includes the ability to filter on attributes of	 	   resource discovery and includes the ability to filter on attributes	
>     resource descriptions.  Finally, CoAP resource discovery can also be	 	   of resource descriptions.  Finally, CoAP resource discovery can also	
>     used to discovery HTTP resources.	 	   be used to discovery HTTP resources.	
>   		
>     For simplicity, CoAP makes the assumption that all CoAP servers	 	   For simplicity, CoAP makes the assumption that all CoAP servers	
>     listen on the default CoAP port or otherwise have been configured or	 	   listen on the default CoAP port or otherwise have been configured or	
>     discovered using some general service discovery mechanism such as DNS	 	   discovered using some general service discovery mechanism such as DNS	
>     Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd].	 	   Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd].	
>   		
>     Resource discovery in CoAP is accomplished through the use of well-	 	   Resource discovery in CoAP is accomplished through the use of well-	
>     known resources which describe the links offered by a CoAP server.	 	   known resources which describe the links offered by a CoAP server.	
>     CoAP defines a well-known URI for discovery: "/.well-known/r"	 	   CoAP defines a well-known URI for discovery: "/.well-known/r"	
>     [RFC5785].  For example, the query [GET /.well-known/r] returns a	 	   [RFC5785].  For example, the query [GET /.well-known/r] returns a	
>     list of links (representing resources) available from the queried	 	   list of links (representing resources) available from the queried	
>     CoAP server.  A query such as [GET /.well-known/r?n=Voltage] returns	 	   CoAP server.  A query such as [GET /.well-known/r?n=Voltage] returns	
>     the resources with the name Voltage.	 	   the resources with the name Voltage.	
>   		
> 3.6.  Other Applications	 	3.7.  Other Applications	
>   		
>     There are several applications that are widely used but are not	 	   There are several applications that are widely used but are not	
>     properly thought of as infrastructure.	 	   properly thought of as infrastructure.	
>   		
> 3.6.1.  Network Time	 	3.7.1.  Session Initiation Protocol	
>   		
>     The Network Time Protocol was originally designed by Dave Mills of	 		
>     the University of Delaware and CSNET, for the purpose of implementing	 		
>     a temporal metric in the Fuzzball Routing Protocol and generally	 		
>     coordinating time experiments.  The current versions of the time	 		
>     protocol are the Network Time Protocol [RFC5905].	 		
>   		
>     NTP is currently being updated in [RFC5905].	 		
>   		
> 3.6.2.  Session Initiation Protocol	 		
>   		
>     The Session Initiation Protocol	 	   The Session Initiation Protocol	
>     [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an	 	   [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an	
>     application layer control (signaling) protocol for creating,	 	   application layer control (signaling) protocol for creating,	
>     modifying and terminating multimedia sessions on the Internet, meant	 	   modifying and terminating multimedia sessions on the Internet, meant	
>     to be more scalable than H.323.  Multimedia sessions can be voice,	 	   to be more scalable than H.323.  Multimedia sessions can be voice,	
>     video, instant messaging, shared data, and/or subscriptions of	 	   video, instant messaging, shared data, and/or subscriptions of	
>     events.  SIP can run on top of TCP, UDP, SCTP, or TLS over TCP.  SIP	 	   events.  SIP can run on top of TCP, UDP, SCTP, or TLS over TCP.  SIP	
>     is independent of the transport layer, and independent of the	 	   is independent of the transport layer, and independent of the	
>     underlying IPv4/v6 version.  In fact, the transport protocol used can	 	   underlying IPv4/v6 version.  In fact, the transport protocol used can	
>   		
> skipping to change at page 27, line 10		skipping to change at page 30, line 11	
>     designed to be SDP aware (i.e., looking into each packet far enough	 	   designed to be SDP aware (i.e., looking into each packet far enough	
>     to discover what the IP address and port number is for this	 	   to discover what the IP address and port number is for this	
>     particular session - and resetting it based on the Session Traversal	 	   particular session - and resetting it based on the Session Traversal	
>     Utilities for NAT [RFC5389], the session established by SIP will not	 	   Utilities for NAT [RFC5389], the session established by SIP will not	
>     result in RTP packets being sent to the proper endpoint (in SIP	 	   result in RTP packets being sent to the proper endpoint (in SIP	
>     called a user agent, or UA).  It should be noted that SIP messaging	 	   called a user agent, or UA).  It should be noted that SIP messaging	
>     has no issues with NATs, it is just the UA's inability to generally	 	   has no issues with NATs, it is just the UA's inability to generally	
>     learn about the presence of the NATs that prevent the RTP packets	 	   learn about the presence of the NATs that prevent the RTP packets	
>     from being received by the UA establishing the session.	 	   from being received by the UA establishing the session.	
>   		
> 3.6.3.  Calendaring	 	3.7.2.  Calendaring	
>   		
>     Internet calendaring, as implemented in Apple iCal, Microsoft Outlook	 	   Internet calendaring, as implemented in Apple iCal, Microsoft Outlook	
>     and Entourage, and Google Calendar, is specified in Internet	 	   and Entourage, and Google Calendar, is specified in Internet	
>     Calendaring and Scheduling Core Object Specification (iCalendar)	 	   Calendaring and Scheduling Core Object Specification (iCalendar)	
>     [RFC5545] and is in the process of being updated to an XML schema in	 	   [RFC5545] and is in the process of being updated to an XML schema in	
>     iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml]	 	   iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml]	
>     Several protocols exist to carry calendar events, including iCalendar	 	   Several protocols exist to carry calendar events, including iCalendar	
>     Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the	 	   Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the	
>     Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open	 	   Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open	
>     source work on the Atom Publishing Protocol [RFC5023].	 	   source work on the Atom Publishing Protocol [RFC5023].	
>   		
> skipping to change at page 32, line 17		skipping to change at page 35, line 17	
>     therefore be removed upon publication as an RFC at the RFC Editor's	 	   therefore be removed upon publication as an RFC at the RFC Editor's	
>     discretion.	 	   discretion.	
>   		
> 6.  Security Considerations	 	6.  Security Considerations	
>   		
>     Security is addressed in some detail in Section 2.2 and Section 3.1.	 	   Security is addressed in some detail in Section 2.2 and Section 3.1.	
>   		
> 7.  Acknowledgements	 	7.  Acknowledgements	
>   		
>     Review comments were made by Andrew Yourtchenko, Ashok Narayanan,	 	   Review comments were made by Andrew Yourtchenko, Ashok Narayanan,	
>     Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant	 	   Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Don	
>     Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry	 	   Sturek, Francis Cleveland, Hemant Singh, James Polk, John Meylor,	
>     Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman,	 	   Joseph Salowey, Julien Abeille, Kerry Lynn, Magnus Westerlund,	
>     Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert.  Dave	 	   Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph Droms, Russ White,	
>     McGrew, Vint Cerf, and Ralph Droms suggested text.	 	   Sheila Frankel, Tom Herbst, and Toerless Eckert.  Dave McGrew, Vint	
>   	   Cerf, and Ralph Droms suggested text.	
>   		
> 8.  References	 	8.  References	
>   		
> 8.1.  Normative References	 	8.1.  Normative References	
>   		
>     [RFC1122]  Braden, R., "Requirements for Internet Hosts -	 	   [RFC1122]  Braden, R., "Requirements for Internet Hosts -	
>                Communication Layers", STD 3, RFC 1122, October 1989.	 	              Communication Layers", STD 3, RFC 1122, October 1989.	
>   		
>     [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application	 	   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application	
>                and Support", STD 3, RFC 1123, October 1989.	 	              and Support", STD 3, RFC 1123, October 1989.	
>   		
>     [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",	 	   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",	
>                RFC 1812, June 1995.	 	              RFC 1812, June 1995.	
>   		
>     [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,	 	   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,	
>                April 2006.	 	              April 2006.	
>   		
> 8.2.  Informative References	 	8.2.  Informative References	
>   		
>   	   [1822]     Bolt Beranek and Newman Inc., "Interface Message Processor	
>   	              -- Specifications for the interconnection of a host and a	
>   	              IMP, Report No. 1822", January 1976.	
>   	                                                                         	
>     [I-D.arkko-ipv6-transition-guidelines]	 	   [I-D.arkko-ipv6-transition-guidelines]	
>                Arkko, J. and F. Baker, "Guidelines for Using IPv6	 	              Arkko, J. and F. Baker, "Guidelines for Using IPv6	
>                Transition Mechanisms",	 	              Transition Mechanisms during IPv6 Deployment",	
>                draft-arkko-ipv6-transition-guidelines-03 (work in	 	              draft-arkko-ipv6-transition-guidelines-06 (work in	
>                progress), July 2010.	 	              progress), August 2010.	
>   		
>     [I-D.cheshire-dnsext-dns-sd]	 	   [I-D.cheshire-dnsext-dns-sd]	
>                Cheshire, S. and M. Krochmal, "DNS-Based Service	 	              Cheshire, S. and M. Krochmal, "DNS-Based Service	
>                Discovery", draft-cheshire-dnsext-dns-sd-06 (work in	 	              Discovery", draft-cheshire-dnsext-dns-sd-06 (work in	
>                progress), March 2010.	 	              progress), March 2010.	
>   		
>     [I-D.cheshire-dnsext-multicastdns]	 	   [I-D.cheshire-dnsext-multicastdns]	
>                Cheshire, S. and M. Krochmal, "Multicast DNS",	 	              Cheshire, S. and M. Krochmal, "Multicast DNS",	
>                draft-cheshire-dnsext-multicastdns-11 (work in progress),	 	              draft-cheshire-dnsext-multicastdns-11 (work in progress),	
>                March 2010.	 	              March 2010.	
>   		
>     [I-D.daboo-et-al-icalendar-in-xml]	 	   [I-D.daboo-et-al-icalendar-in-xml]	
>                Daboo, C., Douglass, M., and S. Lees, "xCal: The XML	 	              Daboo, C., Douglass, M., and S. Lees, "xCal: The XML	
>                format for iCalendar",	 	              format for iCalendar",	
>                draft-daboo-et-al-icalendar-in-xml-05 (work in progress),	 	              draft-daboo-et-al-icalendar-in-xml-06 (work in progress),	
>                July 2010.	 	              September 2010.	
>   		
>     [I-D.ietf-6lowpan-hc]	 	   [I-D.ietf-6lowpan-hc]	
>                Hui, J. and P. Thubert, "Compression Format for IPv6	 	              Hui, J. and P. Thubert, "Compression Format for IPv6	
>                Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-08	 	              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-12	
>                (work in progress), July 2010.	 	              (work in progress), September 2010.	
>   		
>     [I-D.ietf-6man-node-req-bis]	 	   [I-D.ietf-6man-node-req-bis]	
>                Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node	 	              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node	
>                Requirements RFC 4294-bis",	 	              Requirements RFC 4294-bis",	
>                draft-ietf-6man-node-req-bis-05 (work in progress),	 	              draft-ietf-6man-node-req-bis-05 (work in progress),	
>                July 2010.	 	              July 2010.	
>   		
>     [I-D.ietf-behave-address-format]	 	   [I-D.ietf-behave-address-format]	
>                Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.	 	              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.	
>                Li, "IPv6 Addressing of IPv4/IPv6 Translators",	 	              Li, "IPv6 Addressing of IPv4/IPv6 Translators",	
>                draft-ietf-behave-address-format-10 (work in progress),	 	              draft-ietf-behave-address-format-10 (work in progress),	
>                August 2010.	 	              August 2010.	
>   		
>     [I-D.ietf-behave-dns64]	 	   [I-D.ietf-behave-dns64]	
>                Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,	 	              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,	
>                "DNS64: DNS extensions for Network Address Translation	 	              "DNS64: DNS extensions for Network Address Translation	
>                from IPv6 Clients to IPv4 Servers",	 	              from IPv6 Clients to IPv4 Servers",	
>                draft-ietf-behave-dns64-10 (work in progress), July 2010.	 	              draft-ietf-behave-dns64-11 (work in progress),	
>   	              October 2010.	
>   		
>     [I-D.ietf-behave-v6v4-framework]	 	   [I-D.ietf-behave-v6v4-framework]	
>                Baker, F., Li, X., Bao, C., and K. Yin, "Framework for	 	              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for	
>                IPv4/IPv6 Translation",	 	              IPv4/IPv6 Translation",	
>                draft-ietf-behave-v6v4-framework-10 (work in progress),	 	              draft-ietf-behave-v6v4-framework-10 (work in progress),	
>                August 2010.	 	              August 2010.	
>   		
>     [I-D.ietf-behave-v6v4-xlate]	 	   [I-D.ietf-behave-v6v4-xlate]	
>                Li, X., Bao, C., and F. Baker, "IP/ICMP Translation	 	              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation	
>                Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in	 	              Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in	
>                progress), August 2010.	 	              progress), September 2010.	
>   		
>     [I-D.ietf-behave-v6v4-xlate-stateful]	 	   [I-D.ietf-behave-v6v4-xlate-stateful]	
>                Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful	 	              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful	
>                NAT64: Network Address and Protocol Translation from IPv6	 	              NAT64: Network Address and Protocol Translation from IPv6	
>                Clients to IPv4 Servers",	 	              Clients to IPv4 Servers",	
>                draft-ietf-behave-v6v4-xlate-stateful-12 (work in	 	              draft-ietf-behave-v6v4-xlate-stateful-12 (work in	
>                progress), July 2010.	 	              progress), July 2010.	
>   		
>     [I-D.ietf-core-coap]	 	   [I-D.ietf-core-coap]	
>                Shelby, Z., Frank, B., and D. Sturek, "Constrained	 	              Shelby, Z., Frank, B., and D. Sturek, "Constrained	
>                Application Protocol (CoAP)", draft-ietf-core-coap-01	 	              Application Protocol (CoAP)", draft-ietf-core-coap-02	
>                (work in progress), July 2010.	 	              (work in progress), September 2010.	
>   		
>     [I-D.ietf-manet-dymo]	 	   [I-D.ietf-manet-dymo]	
>                Chakeres, I. and C. Perkins, "Dynamic MANET On-demand	 	              Chakeres, I. and C. Perkins, "Dynamic MANET On-demand	
>                (DYMO) Routing", draft-ietf-manet-dymo-21 (work in	 	              (DYMO) Routing", draft-ietf-manet-dymo-21 (work in	
>                progress), July 2010.	 	              progress), July 2010.	
>   		
>     [I-D.ietf-roll-rpl]	 	   [I-D.ietf-roll-rpl]	
>                Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing	 	              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing	
>                Protocol for Low power and Lossy Networks",	 	              Protocol for Low power and Lossy Networks",	
>                draft-ietf-roll-rpl-11 (work in progress), July 2010.	 	              draft-ietf-roll-rpl-11 (work in progress), July 2010.	
>   		
>     [I-D.ietf-tls-rfc4347-bis]	 	   [I-D.ietf-tls-rfc4347-bis]	
>                Rescorla, E. and N. Modadugu, "Datagram Transport Layer	 	              Rescorla, E. and N. Modadugu, "Datagram Transport Layer	
>                Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work	 	              Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work	
>                in progress), July 2010.	 	              in progress), July 2010.	
>   		
>   	   [IEC62351-3]	
>   	              International Electrotechnical Commission Technical	
>   	              Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED	
>   	              INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY --	
>   	              Part 3: Communication network and system security Profiles	
>   	              including TCP/IP", May 2007.	
>   	                                                                         	
>     [IEEE802.1X]	 	   [IEEE802.1X]	
>                Institute of Electrical and Electronics Engineers, "IEEE	 	              Institute of Electrical and Electronics Engineers, "IEEE	
>                Standard for Local and Metropolitan Area Networks - Port	 	              Standard for Local and Metropolitan Area Networks - Port	
>                based Network Access Control", IEEE Standard 802.1X-2010,	 	              based Network Access Control", IEEE Standard 802.1X-2010,	
>                February 2010.	 	              February 2010.	
>   		
>   	   [RESTFUL]  Fielding, "Architectural Styles and the Design of Network-	
>   	              based Software Architectures", 2000.	
>   	                                                                         	
>     [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,	 	   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,	
>                August 1980.	 	              August 1980.	
>   		
>     [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,	 	   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,	
>                September 1981.	 	              September 1981.	
>   		
>     [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,	 	   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,	
>                RFC 792, September 1981.	 	              RFC 792, September 1981.	
>   		
>     [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,	 	   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,	
>   		
> skipping to change at page 38, line 37		skipping to change at page 42, line 5	
>                March 2002.	 	              March 2002.	
>   		
>     [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,	 	   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,	
>                and M. Carney, "Dynamic Host Configuration Protocol for	 	              and M. Carney, "Dynamic Host Configuration Protocol for	
>                IPv6 (DHCPv6)", RFC 3315, July 2003.	 	              IPv6 (DHCPv6)", RFC 3315, July 2003.	
>   		
>     [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.	 	   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.	
>                Thyagarajan, "Internet Group Management Protocol, Version	 	              Thyagarajan, "Internet Group Management Protocol, Version	
>                3", RFC 3376, October 2002.	 	              3", RFC 3376, October 2002.	
>   		
>   	   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An	
>   	              Architecture for Describing Simple Network Management	
>   	              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,	
>   	              December 2002.	
>   		
>   	   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,	
>   	              "Message Processing and Dispatching for the Simple Network	
>   	              Management Protocol (SNMP)", STD 62, RFC 3412,	
>   	              December 2002.	
>   		
>   	   [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network	
>   	              Management Protocol (SNMP) Applications", STD 62,	
>   	              RFC 3413, December 2002.	
>   		
>   	   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model	
>   	              (USM) for version 3 of the Simple Network Management	
>   	              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.	
>   		
>   	   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based	
>   	              Access Control Model (VACM) for the Simple Network	
>   	              Management Protocol (SNMP)", STD 62, RFC 3415,	
>   	              December 2002.	
>   		
>   	   [RFC3416]  Presuhn, R., "Version 2 of the Protocol Operations for the	
>   	              Simple Network Management Protocol (SNMP)", STD 62,	
>   	              RFC 3416, December 2002.	
>   		
>   	   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network	
>   	              Management Protocol (SNMP)", STD 62, RFC 3417,	
>   	              December 2002.	
>   		
>   	   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the	
>   	              Simple Network Management Protocol (SNMP)", STD 62,	
>   	              RFC 3418, December 2002.	
>   	                                                                         	
>     [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral	 	   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral	
>                Self-Address Fixing (UNSAF) Across Network Address	 	              Self-Address Fixing (UNSAF) Across Network Address	
>                Translation", RFC 3424, November 2002.	 	              Translation", RFC 3424, November 2002.	
>   		
>     [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport	 	   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport	
>                Layer Security over Stream Control Transmission Protocol",	 	              Layer Security over Stream Control Transmission Protocol",	
>                RFC 3436, December 2002.	 	              RFC 3436, December 2002.	
>   		
>     [RFC3453]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,	 	   [RFC3453]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,	
>                M., and J. Crowcroft, "The Use of Forward Error Correction	 	              M., and J. Crowcroft, "The Use of Forward Error Correction	
>   		
> skipping to change at page 40, line 34		skipping to change at page 44, line 36	
>   		
>     [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the	 	   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the	
>                Internet Protocol", RFC 4301, December 2005.	 	              Internet Protocol", RFC 4301, December 2005.	
>   		
>     [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,	 	   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,	
>                December 2005.	 	              December 2005.	
>   		
>     [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",	 	   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",	
>                RFC 4303, December 2005.	 	              RFC 4303, December 2005.	
>   		
>     [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",	 		
>                RFC 4306, December 2005.	 		
>                                                                           	 		
>     [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the	 	   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the	
>                Internet Key Exchange Version 2 (IKEv2)", RFC 4307,	 	              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,	
>                December 2005.	 	              December 2005.	
>   		
>     [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM	 	   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM	
>                Mode with IPsec Encapsulating Security Payload (ESP)",	 	              Mode with IPsec Encapsulating Security Payload (ESP)",	
>                RFC 4309, December 2005.	 	              RFC 4309, December 2005.	
>   		
>     [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the	 	   [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the	
>                Session Initiation Protocol's (SIP) Non-INVITE	 	              Session Initiation Protocol's (SIP) Non-INVITE	
>   		
> skipping to change at page 41, line 23		skipping to change at page 45, line 23	
>                Message Protocol (ICMPv6) for the Internet Protocol	 	              Message Protocol (ICMPv6) for the Internet Protocol	
>                Version 6 (IPv6) Specification", RFC 4443, March 2006.	 	              Version 6 (IPv6) Specification", RFC 4443, March 2006.	
>   		
>     [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile	 	   [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile	
>                IPv6 and Firewalls: Problem Statement", RFC 4487,	 	              IPv6 and Firewalls: Problem Statement", RFC 4487,	
>                May 2006.	 	              May 2006.	
>   		
>     [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session	 	   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session	
>                Description Protocol", RFC 4566, July 2006.	 	              Description Protocol", RFC 4566, July 2006.	
>   		
>   	   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration	
>   	              Guidelines for DiffServ Service Classes", RFC 4594,	
>   	              August 2006.	
>   	                                                                         	
>     [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,	 	   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,	
>                "Protocol Independent Multicast - Sparse Mode (PIM-SM):	 	              "Protocol Independent Multicast - Sparse Mode (PIM-SM):	
>                Protocol Specification (Revised)", RFC 4601, August 2006.	 	              Protocol Specification (Revised)", RFC 4601, August 2006.	
>   		
>     [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet	 	   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet	
>                Group Management Protocol Version 3 (IGMPv3) and Multicast	 	              Group Management Protocol Version 3 (IGMPv3) and Multicast	
>                Listener Discovery Protocol Version 2 (MLDv2) for Source-	 	              Listener Discovery Protocol Version 2 (MLDv2) for Source-	
>                Specific Multicast", RFC 4604, August 2006.	 	              Specific Multicast", RFC 4604, August 2006.	
>   		
>     [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for	 	   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for	
>   		
> skipping to change at page 41, line 46		skipping to change at page 45, line 50	
>                Protocol Independent Multicast in 232/8", BCP 120,	 	              Protocol Independent Multicast in 232/8", BCP 120,	
>                RFC 4608, August 2006.	 	              RFC 4608, August 2006.	
>   		
>     [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap	 	   [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap	
>                for Transmission Control Protocol (TCP) Specification	 	              for Transmission Control Protocol (TCP) Specification	
>                Documents", RFC 4614, September 2006.	 	              Documents", RFC 4614, September 2006.	
>   		
>     [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,	 	   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,	
>                December 2006.	 	              December 2006.	
>   		
>   	   [RFC4742]  Wasserman, M. and T. Goddard, "Using the NETCONF	
>   	              Configuration Protocol over Secure SHell (SSH)", RFC 4742,	
>   	              December 2006.	
>   		
>   	   [RFC4743]  Goddard, T., "Using NETCONF over the Simple Object Access	
>   	              Protocol (SOAP)", RFC 4743, December 2006.	
>   		
>   	   [RFC4744]  Lear, E. and K. Crozier, "Using the NETCONF Protocol over	
>   	              the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,	
>   	              December 2006.	
>   	                                                                         	
>     [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,	 	   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,	
>                "Multiprotocol Extensions for BGP-4", RFC 4760,	 	              "Multiprotocol Extensions for BGP-4", RFC 4760,	
>                January 2007.	 	              January 2007.	
>   		
>     [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation	 	   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation	
>                (NAT) Behavioral Requirements for Unicast UDP", BCP 127,	 	              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,	
>                RFC 4787, January 2007.	 	              RFC 4787, January 2007.	
>   		
>     [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation	 	   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation	
>                Requirements for Encapsulating Security Payload (ESP) and	 	              Requirements for Encapsulating Security Payload (ESP) and	
>   		
> skipping to change at page 43, line 10		skipping to change at page 47, line 25	
>                PPP", RFC 5072, September 2007.	 	              PPP", RFC 5072, September 2007.	
>   		
>     [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-	 	   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-	
>                Peer (P2P) Communication across Network Address	 	              Peer (P2P) Communication across Network Address	
>                Translators (NATs)", RFC 5128, March 2008.	 	              Translators (NATs)", RFC 5128, March 2008.	
>   		
>     [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a	 	   [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a	
>                Network Address Translator (NAT) and a Network Address	 	              Network Address Translator (NAT) and a Network Address	
>                Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.	 	              Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.	
>   		
>   	   [RFC5193]  Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and	
>   	              A. Yegin, "Protocol for Carrying Authentication for	
>   	              Network Access (PANA) Framework", RFC 5193, May 2008.	
>   	                                                                         	
>     [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and	 	   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and	
>                Firewall Traversal Issues of Host Identity Protocol (HIP)	 	              Firewall Traversal Issues of Host Identity Protocol (HIP)	
>                Communication", RFC 5207, April 2008.	 	              Communication", RFC 5207, April 2008.	
>   		
>     [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS	 	   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS	
>                Authentication Protocol", RFC 5216, March 2008.	 	              Authentication Protocol", RFC 5216, March 2008.	
>   		
>     [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over	 	   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over	
>                the Datagram Congestion Control Protocol (DCCP)",	 	              the Datagram Congestion Control Protocol (DCCP)",	
>                RFC 5238, May 2008.	 	              RFC 5238, May 2008.	
>   		
>     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security	 	   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security	
>                (TLS) Protocol Version 1.2", RFC 5246, August 2008.	 	              (TLS) Protocol Version 1.2", RFC 5246, August 2008.	
>   		
>   	   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event	
>   	              Notifications", RFC 5277, July 2008.	
>   	                                                                         	
>     [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,	 	   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,	
>                October 2008.	 	              October 2008.	
>   		
>     [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF	 	   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF	
>                for IPv6", RFC 5340, July 2008.	 	              for IPv6", RFC 5340, July 2008.	
>   		
>     [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,	 	   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,	
>                "Session Traversal Utilities for NAT (STUN)", RFC 5389,	 	              "Session Traversal Utilities for NAT (STUN)", RFC 5389,	
>                October 2008.	 	              October 2008.	
>   		
>     [RFC5393]  Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,	 	   [RFC5393]  Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,	
>                "Addressing an Amplification Vulnerability in Session	 	              "Addressing an Amplification Vulnerability in Session	
>                Initiation Protocol (SIP) Forking Proxies", RFC 5393,	 	              Initiation Protocol (SIP) Forking Proxies", RFC 5393,	
>                December 2008.	 	              December 2008.	
>   		
>     [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines	 	   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines	
>                for Application Designers", BCP 145, RFC 5405,	 	              for Application Designers", BCP 145, RFC 5405,	
>                November 2008.	 	              November 2008.	
>   		
>   	   [RFC5539]  Badra, M., "NETCONF over Transport Layer Security (TLS)",	
>   	              RFC 5539, May 2009.	
>   	                                                                         	
>     [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling	 	   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling	
>                Core Object Specification (iCalendar)", RFC 5545,	 	              Core Object Specification (iCalendar)", RFC 5545,	
>                September 2009.	 	              September 2009.	
>   		
>     [RFC5546]  Daboo, C., "iCalendar Transport-Independent	 	   [RFC5546]  Daboo, C., "iCalendar Transport-Independent	
>                Interoperability Protocol (iTIP)", RFC 5546,	 	              Interoperability Protocol (iTIP)", RFC 5546,	
>                December 2009.	 	              December 2009.	
>   		
>   	   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,	
>   	              "Routing Requirements for Urban Low-Power and Lossy	
>   	              Networks", RFC 5548, May 2009.	
>   	                                                                         	
>     [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4	 	   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4	
>                Infrastructures (6rd)", RFC 5569, January 2010.	 	              Infrastructures (6rd)", RFC 5569, January 2010.	
>   		
>     [RFC5621]  Camarillo, G., "Message Body Handling in the Session	 	   [RFC5621]  Camarillo, G., "Message Body Handling in the Session	
>                Initiation Protocol (SIP)", RFC 5621, September 2009.	 	              Initiation Protocol (SIP)", RFC 5621, September 2009.	
>   		
>   	   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,	
>   	              "Industrial Routing Requirements in Low-Power and Lossy	
>   	              Networks", RFC 5673, October 2009.	
>   	                                                                         	
>     [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion	 	   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion	
>                Control", RFC 5681, September 2009.	 	              Control", RFC 5681, September 2009.	
>   		
>   	   [RFC5717]  Lengyel, B. and M. Bjorklund, "Partial Lock Remote	
>   	              Procedure Call (RPC) for NETCONF", RFC 5717,	
>   	              December 2009.	
>   	                                                                         	
>     [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,	 	   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,	
>                "NACK-Oriented Reliable Multicast (NORM) Transport	 	              "NACK-Oriented Reliable Multicast (NORM) Transport	
>                Protocol", RFC 5740, November 2009.	 	              Protocol", RFC 5740, November 2009.	
>   		
>     [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	 	   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	
>                Mail Extensions (S/MIME) Version 3.2 Certificate	 	              Mail Extensions (S/MIME) Version 3.2 Certificate	
>                Handling", RFC 5750, January 2010.	 	              Handling", RFC 5750, January 2010.	
>   		
>     [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	 	   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	
>                Mail Extensions (S/MIME) Version 3.2 Message	 	              Mail Extensions (S/MIME) Version 3.2 Message	
>                Specification", RFC 5751, January 2010.	 	              Specification", RFC 5751, January 2010.	
>   		
>     [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known	 	   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known	
>                Uniform Resource Identifiers (URIs)", RFC 5785,	 	              Uniform Resource Identifiers (URIs)", RFC 5785,	
>                April 2010.	 	              April 2010.	
>   		
>     [RFC5796]  Atwood, W., Islam, S., and M. Siami, "Authentication and	 	   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation	
>                Confidentiality in Protocol Independent Multicast Sparse	 	              Routing Requirements in Low-Power and Lossy Networks",	
>                Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.	 	              RFC 5826, April 2010.	
>   		
>     [RFC5838]  Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.	 	   [RFC5838]  Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.	
>                Aggarwal, "Support of Address Families in OSPFv3",	 	              Aggarwal, "Support of Address Families in OSPFv3",	
>                RFC 5838, April 2010.	 	              RFC 5838, April 2010.	
>   		
>   	   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,	
>   	              "Building Automation Routing Requirements in Low-Power and	
>   	              Lossy Networks", RFC 5867, June 2010.	
>   	                                                                         	
>     [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network	 	   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network	
>                Time Protocol Version 4: Protocol and Algorithms	 	              Time Protocol Version 4: Protocol and Algorithms	
>                Specification", RFC 5905, June 2010.	 	              Specification", RFC 5905, June 2010.	
>   		
>   	   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,	
>   	              "Internet Key Exchange Protocol Version 2 (IKEv2)",	
>   	              RFC 5996, September 2010.	
>   	                                                                         	
>     [SP-MULPIv3.0]	 	   [SP-MULPIv3.0]	
>                CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols	 	              CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols	
>                Interface Specification, CM-SP-MULPIv3.0-I10-090529",	 	              Interface Specification, CM-SP-MULPIv3.0-I10-090529",	
>                May 2009.	 	              May 2009.	
>   		
>   	Appendix A.  Example: Advanced Metering Infrastructure	
>   		
>   	   This appendix provides a worked example of the use of the Internet	
>   	   Protocol Suite in a network such as the Smart Grid's Advanced	
>   	   Metering Infrastructure (AMI).  There are several possible models.	
>   		
>   	   Figure 6 shows the structure of the AMI as it reaches out towards a	
>   	   set of residences.  In this structure, we have the home itself and	
>   	   its Home Area Network (HAN), the Neighborhood Area Network (NAN) that	
>   	   the utility uses to access the meter at the home, and the utility	
>   	   access network that connects a set of NANs to the utility itself.	
>   	   For the purposes of this discussion, assume that the NAN contains a	
>   	   distributed application in a set collectors, which is of course only	
>   	   one way the application could be implemented.	
>   		
>   	    ---	
>   	    A        thermostats, appliances, etc	
>   	    |  ------+-----------------------------------	
>   	    |        |	
>   	    |"HAN"   |<--- Energy Services Interface (ESI)	
>   	    |    +---+---+	
>   	    |    | Meter | Meter is generally an ALG between the AMI and the HAN	
>   	    |    +---+---+	
>   	    V         \	
>   	    ---        \	
>   	    A           \   |   /	
>   	    |            \  |  /	
>   	    | "NAN"    +--+-+-+---+  Likely a router but could	
>   	    |          |Collector |  be an front-end application	
>   	    V          +----+-----+  gateway for utility	
>   	    ---              \	
>   	    A                 \   |   /	
>   	    |                  \  |  /	
>   	    |"AMI"           +--+-+-+--+	
>   	    |                |   AMI   |	
>   	    |                | Headend |	
>   	    V                +---------+	
>   	    ---	
>   		
>   	       Figure 6: The HAN, NAN, and Utility in the Advanced Metering	
>   	                              Infrastructure	
>   		
>   	   There are several questions that have to be answered in describing	
>   	   this picture, which given possible answers yield different possible	
>   	   models.  They include at least:	
>   		
>   	   o  How does Demand Response work?  Either:	
>   		
>   	      *  The utility presents pricing signals to the home,	
>   		
>   	      *  The utility presents pricing signals individual devices (e.g.,	
>   	         a Pluggable Electric Vehicle),	
>   		
>   	      *  The utility adjusts settings on individual appliances within	
>   	         the home.	
>   		
>   	   o  How does the utility access meters at the home?	
>   		
>   	      *  The AMI Headend manages the interfaces with the meters,	
>   	         collecting metering data and passing it on to the appropriate	
>   	         applications over the Enterprise Bus, or	
>   		
>   	      *  Distributed application support (collectors") might access and	
>   	         summarize the information; this device might be managed by the	
>   	         utility or by a service between the utility and its customers.	
>   		
>   	   In implementation, these models are idealized; reality may include	
>   	   some aspects of each model in specified cases.	
>   		
>   	   The examples include:	
>   		
>   	   1.  Appendix A.2 presumes that the HAN, the NAN, and the utility's	
>   	       network are separate administrative domains and speak application	
>   	       to application across those domains.	
>   		
>   	   2.  Appendix A.3 repeats the first example, but presuming that the	
>   	       utility directly accesses appliances within the HAN from the	
>   	       collector".	
>   		
>   	   3.  Appendix A.4 repeats the first example, but presuming that the	
>   	       collector directly forwards traffic as a router in addition to	
>   	       distributed application chores.  Note that this case implies	
>   	       numerous privacy and security concerns and as such is considered	
>   	       a less likely deployment model.	
>   		
>   	A.1.  How to structure a network	
>   		
>   	   A key consideration in the Internet has been the development of new	
>   	   link layer technologies over time.  The ARPANET originally used a BBN	
>   	   proprietary link layer called BBN 1822 [1822].  In the late 1970's,	
>   	   the ARPANET switched to X.25 as an interface to the 1822 network.	
>   	   With the deployment of the IEEE 802 series technologies in the early	
>   	   1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE	
>   	   802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of	
>   	   various kinds, Frame Relay, and ATM.  A key issue in this evolution	
>   	   was that the applications developed to run on the Internet use APIs	
>   	   related to the IPS, and as a result require little or no change to	
>   	   continue to operate in a new link layer architecture or a mixture of	
>   	   them.	
>   		
>   	   The Smart Grid is likely to see a similar evolution over time.	
>   	   Consider the Home Area Network (HAN) as a readily understandable	
>   	   small network.  At this juncture, technologies proposed for	
>   	   residential networks include IEEE P1901 (Homeplug), IEEE 802.15.4g	
>   	   (Zigbee), and IEEE 802.11 (WiFi, commonly deployed today and used by	
>   	   some high end appliances).  It is reasonable to expect other	
>   	   technologies to be developed in the future.  As the Zigbee Alliance	
>   	   has learned (and as a resulted incorporated the IPS in Secure Energy	
>   	   Profile 2.0), there is significant value in providing a virtual	
>   	   address that is mapped to interfaces or nodes attached to each of	
>   	   those technologies.	
>   		
>   	   There are two possible communication models within the HAN, both of	
>   	   which are likely to be useful.  Devices may communicate directly with	
>   	   each other, or they may be managed by some central controller.  An	
>   	   example of direct communications might be a light switch that	
>   	   directly commands a lamp to turn on or off.  An example of indirect	
>   	   communications might be a control application in a Customer or	
>   	   Building that accepts telemetry from a thermostat, applies some form	
>   	   of policy, and controls the heating and air conditioning systems.  In	
>   	   addition, there are high end appliances in the market today that use	
>   	   residential broadband to communicate with their manufacturers, and	
>   	   obviously the meter needs to communicate with the utility.	
>   		
>   	                    Utility NAN	
>   	                       /	
>   	                      /	
>   	                +----+-----+ +--+ +--+ +--+	
>   	                |  Meter   | |D1| |D2| |D3|	
>   	                +-----+----+ ++-+ ++-+ ++-+	
>   	                      |       |    |    |	
>   	                ----+-+-------+----+----+---- IEEE 802.15.4	
>   	                    |	
>   	                 +--+---+	
>   	                 |Router+------/------ Residential Broadband	
>   	                 +--+---+	
>   	                    |	
>   	                ----+---------+----+----+---- IEEE P1901	
>   	                              |    |    |	
>   	                             ++-+ ++-+ ++-+	
>   	                             |D4| |D5| |D6|	
>   	                             +--+ +--+ +--+	
>   		
>   	                        Figure 7: Home Area Network	
>   		
>   	   Figure 7 shows a simple network containing IEEE 802.15.4 and IEEE	
>   	   1901 domains.  It shows the connectivity between them as a router	
>   	   separate from the EMS.  This is for clarity; the two could of course	
>   	   be incorporated into a single system, and one could imagine	
>   	   appliances that want to communicate with their manufacturers	
>   	   supporting both a HAN interface and a WiFi interface rather than	
>   	   depending on the router.  These are all manufacturer design	
>   	   decisions.	
>   		
>   	A.1.1.  HAN Routing	
>   		
>   	   The HAN can be seen as communicating with two kinds of non-HAN	
>   	   networks.  One is the home LAN, which may in turn be attached to the	
>   	   Internet, and will generally either derive its prefix from the	
>   	   upstream ISP or use a self-generated ULA.  Another is the utility's	
>   	   NAN, which through an ESI provides utility connectivity to the HAN;	
>   	   in this case the HAN will be addressed by a self-generated ULA (note,	
>   	   however, that in some cases ESI may also provide a prefix via DHCP	
>   	   [RFC3315]).  In addition, the HAN will have link-local addresses that	
>   	   can be used between neighboring nodes.  In general, an HAN will be	
>   	   comprised of both 802.15.4, 802.11 (and possibly other) networks.	
>   		
>   	   The ESI is node on the user's residential network, and will not	
>   	   typically provide stateful packet forwarding or firewall services	
>   	   between the HAN and the utility network(s).  In general, the meter/	
>   	   ESI is just a node on the home network.  However, the ESI must be	
>   	   capable of understanding that most home networks are not 802.15.4	
>   	   enabled (rather, they are typically 802.11 networks), and that it	
>   	   must be capable of setting up ad-hoc networks between various sensors	
>   	   in the home (e.g., betweeen the meter and say, a thermostat) in the	
>   	   event there aren't other networks available.	
>   		
>   	A.1.2.  HAN Security	
>   		
>   	   In any network, we have a variety of threats and a variety of	
>   	   possible mitigations.  These include, at minimum:	
>   		
>   	   Link Layer:  Why is your machine able to talk in my network?  The	
>   	      WiFi SSIDs often use some form of authenticated access control,	
>   	      which may be a simple encrypted password mechanism or may use a	
>   	      combination of encryption and IEEE 802.1X+EAP-TLS Authentication/	
>   	      Authorization to ensure that only authorized communicants can use	
>   	      it.  If a LAN has a router attached, the router may also implement	
>   	      a firewall to filter remote accesses.	
>   		
>   	   Network Layer:  Given that your machine is authorized access to my	
>   	      network, why is your machine talking with my machine?  IPsec is a	
>   	      way of ensuring that computers that can use a network are allowed	
>   	      to talk with each other, may also enforce confidentiality, and may	
>   	      provide VPN services to make a device or network appear to be part	
>   	      of a remote network.	
>   		
>   	   Application:  Given that your machine is authorized access to my	
>   	      network and my machine, why is your application talking with my	
>   	      application?  The fact that your machine and mine are allowed to	
>   	      talk for some applications doesn't mean they are allowed to for	
>   	      all applications.  (D)TLS, https, and other such mechanisms enable	
>   	      an application to impose application-to-application controls	
>   	      similar to the network layer controls provided by IPsec.	
>   		
>   	   Remote Application:  How do I know that the data I received is the	
>   	      data you sent?  Especially in applications like electronic mail,	
>   	      where data passes through a number of intermediaries that one may	
>   	      or may not really want munging it (how many times have you seen a	
>   	      URL broken by a mail server?), we have tools (DKIM, S/MIME, and	
>   	      W3C XML Signatures to name a few) to provide non-repudiability and	
>   	      integrity verification.  This may also have legal ramifications:	
>   	      if a record of a meter reading is to be used in billing, and the	
>   	      bill is disputed in court, one could imagine the court wanting	
>   	      proof that the record in fact came from that meter at that time	
>   	      and contained that data.	
>   		
>   	   Application-specific security:  In addition, applications often	
>   	      provide security services of their own.  The fact that I can	
>   	      access a file system, for example, doesn't mean that I am	
>   	      authorized to access everything in it; the file system may well	
>   	      prevent my access to some of its contents.  Routing protocols like	
>   	      BGP obsess with the question "what statements that my peer made am	
>   	      I willing to believe".  And monitoring protocols like SNMP may not	
>   	      be willing to answer every question they are asked, depending on	
>   	      access configuration.	
>   		
>   	   Devices in the HAN want controlled access to the LAN in question for	
>   	   obvious reasons.  In addition, there should be some form of mutual	
>   	   authentication between devices - the lamp controller will want to	
>   	   know that the light switch telling it to change state is the right	
>   	   light switch, for example.  The EMS may well want strong	
>   	   authentication of accesses - the parents may not want the children	
>   	   changing the settings, and while the utility and the customer are	
>   	   routinely granted access, other parties (especially parties with	
>   	   criminal intent) need to be excluded.	
>   		
>   	A.2.  Model 1: AMI with separated domains	
>   		
>   	   With the background given in Appendix A.1, we can now discuss the use	
>   	   of IP (IPv4 or IPv6) in the AMI.	
>   		
>   	   In this first model, consider the three domains in Figure 6 to	
>   	   literally be separate administrative domains, potentially operated by	
>   	   different entities.  For example, the NAN could be a WiMAX network	
>   	   operated by a traditional telecom operator, the utility's network	
>   	   (including the collector) is its own, and the residential network is	
>   	   operated by the resident.  In this model, while communications	
>   	   between the collector and the Meter are normal, the utility has no	
>   	   other access to appliances in the home, and the collector doesn't	
>   	   directly forward messages from the NAN upstream.	
>   		
>   	   In this case, as shown in Figure 7, it would make the most sense to	
>   	   design the collector, the Meter, and the EMS as hosts on the NAN -	
>   	   design them as systems whose applications can originate and terminate	
>   	   exchanges or sessions in the NAN, but not forward traffic from or to	
>   	   other devices.	
>   		
>   	   In such a configuration, Demand Response has to be performed by	
>   	   having the EMS accept messages such as price signals from the "pole	
>   	   top", apply some form of policy, and then orchestrate actions within	
>   	   the home.  Another possibility is to have the EMS communicate with	
>   	   the ESI located in the meter.  If the thermostat has high demand and	
>   	   low demand (day/night or morning/day/evening/night) settings, Demand	
>   	   Response might result in it moving to a lower demand setting, and the	
>   	   EMS might also turn off specified circuits in the home to diminish	
>   	   lighting.	
>   		
>   	   In this scenario, QoS issues reportedly arise when high precedence	
>   	   messages must be sent through the collector to the home; if the	
>   	   collector is occupied polling the meters or doing some other task,	
>   	   the application may not yield control of the processor to the	
>   	   application that services the message.  Clearly, this is either an	
>   	   application or an OS problem; applications need to be designed in a	
>   	   manner that doesn't block high precedence messages.  The collector	
>   	   also needs to use appropriate NAN services, if they exist, to provide	
>   	   the NAN QoS it needs.  For example, if WiMax is in use, it might use	
>   	   a routine-level service for normal exchanges but a higher precedence	
>   	   service for these messages.	
>   		
>   	A.3.  Model 2: AMI with neighborhood access to the home	
>   		
>   	   In this second model, let's imagine that the utility directly	
>   	   accesses appliances within the HAN.  Rather than expect an EMS to	
>   	   respond to price signals in Demand Response, it directly commands	
>   	   devices like air conditioners to change state, or throws relays on	
>   	   circuits to or within the home.	
>   		
>   	                +----------+ +--+ +--+ +--+	
>   	                |  Meter   | |D1| |D2| |D3|	
>   	                +-----+----+ ++-+ ++-+ ++-+	
>   	                      |       |    |    |	
>   	                ----+-+-------+----+----+---- IEEE 802.15.4	
>   	                    |	
>   	                 +--+---+	
>   	                 |      +------/------ NAN	
>   	                 |Router|	
>   	                 |      +------/------ Residential Broadband	
>   	                 +--+---+	
>   	                    |	
>   	                ----+---------+----+----+---- IEEE P1901	
>   	                              |    |    |	
>   	                             ++-+ ++-+ ++-+	
>   	                             |D4| |D5| |D6|	
>   	                             +--+ +--+ +--+	
>   		
>   	                        Figure 8: Home Area Network	
>   		
>   	   In this case, as shown in Figure 8, the Meter, and EMS as hosts on	
>   	   the HAN, and there is a router between the HAN and the NAN.	
>   		
>   	   As one might imagine, there are serious security considerations in	
>   	   this model.  Traffic between the NAN and the residential broadband	
>   	   network should be filtered, and the issues raised in Appendix A.1.2	
>   	   take on a new level of meaning.  One of the biggest threats may be a	
>   	   legal or at least a public relations issue; if the utility	
>   	   intentionally disables a circuit in a manner or at a time that	
>   	   threatens life (the resident's kidney dialysis machine is on it, or a	
>   	   respirator, for example) the matter might make the papers.	
>   	   Unauthorized access could be part of juvenile pranks or other things	
>   	   as well.  So one really wants the appliances to only obey commands	
>   	   under strict authentication/authorization controls.	
>   		
>   	   In addition to the QoS issues raised in Appendix A.2, there is the	
>   	   possibility of queuing issues in the router.  In such a case, the IP	
>   	   datagrams should probably use the Low-Latency Data Service Class	
>   	   described in [RFC4594], and let other traffic use the Standard	
>   	   Service Class or other service classes.	
>   		
>   	A.4.  Model 3: Collector is an IP router	
>   		
>   	   In this third model, the relationship between the NAN and the HAN is	
>   	   either as in Appendix A.2 or Appendix A.3; what is different is that	
>   	   the collector may be an IP router.  In addition to whatever	
>   	   autonomous activities it is doing, it forwards traffic as an IP	
>   	   router in some cases.	
>   		
>   	   As and analogous to Appendix A.3, there are serious security	
>   	   considerations in this model.  Traffic being forwarded should be	
>   	   filtered, and the issues raised in Appendix A.1.2 take on a new level	
>   	   of meaning - but this time at the utility mainframe.  Unauthorized	
>   	   access is likely similar to other financially-motivated attacks that	
>   	   happen in the Internet, but presumably would be coming from devices	
>   	   in the HAN that have been co-opted in some way.  One really wants the	
>   	   appliances to only obey commands under strict authentication/	
>   	   authorization controls.	
>   		
>   	   In addition to the QoS issues raised in Appendix A.2, there is the	
>   	   possibility of queuing issues in the collector.  In such a case, the	
>   	   IP datagrams should probably use the Low-Latency Data Service Class	
>   	   described in [RFC4594], and let other traffic use the Standard	
>   	   Service Class or other service classes.	
>   	                                                                         	
> Authors' Addresses	 	Authors' Addresses	
>   		
>     Fred Baker	 	   Fred Baker	
>     Cisco Systems	 	   Cisco Systems	
>     Santa Barbara, California  93117	 	   Santa Barbara, California  93117	
>     USA	 	   USA	
>   		
>     Email: [e-mail]	 	   Email: [e-mail]	
>   		
>     David Meyer	 	   David Meyer	
>   		
>   End of changes. 60 change blocks.
> 149 lines changed or deleted		758 lines changed or added	
> 
> This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
> 
> 
> 
> 
> 
> _______________________________________________
> smartpower-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/smartpower-interest