Subject: [smartpower-interest] Fwd: New Version Notification for draft-baker-ietf-core-10

From: Fred Baker <[email-masked]>
Date: Mon, 8 Nov 2010 12:23:40 +0800

http://tools.ietf.org/html/draft-baker-ietf-core

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: November 8, 2010 12:20:49 PM GMT+08:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-baker-ietf-core-10 
> 
> 
> A new version of I-D, draft-baker-ietf-core-10.txt has been successfully submitted by Fred Baker and posted to the IETF repository.
> 
> Filename:	 draft-baker-ietf-core
> Revision:	 10
> Title:		 Internet Protocols for the Smart Grid
> Creation_date:	 2010-11-08
> 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.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Nov 2010 04:52:23 +0200

Hi Fred,

   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).

This text still has issues.

Zigbee SEP 2.0 is using PANA, not IEEE 802.1X.

Also, there is some mix-up with regard to the relationship among 1X, EAP-TLS
and PANA in this text. EAP-TLS is an EAP method which is carried over EAP
over IEEE802.1X or EAP over PANA. 

Thank you.

Alper

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Monday, November 08, 2010 6:24 AM
To: [email-masked]
Subject: [smartpower-interest] Fwd: New Version Notification for
draft-baker-ietf-core-10

Begin forwarded message:

> A new version of I-D, draft-baker-ietf-core-10.txt has been successfully
submitted by Fred Baker and posted to the IETF repository.
> the picture presented here.

_______________________________________________
smartpower-interest mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/smartpower-interest

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 Nov 2010 12:21:17 +0800

I have asked for text before, and I have used the text I have been given. Send text.

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 Nov 2010 12:45:25 +0800

Paul Duffy sent the following suggested text. Would it work for you?

   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).

---

From: Paul Duffy <[email-masked]>
Date: Wed, 10 Nov 2010 00:02:18 -0500

Hi Fred,

Here is my suggested text.

"When used in conjunction with RFC 5216 EAP-TLS, IEEE 802.1X offers 
excellent access security for wired or wireless IEEE 802 LANs.   
Further, Protocol for Carrying  Authentication for Network Access (PANA) 
is gaining traction for access security for Zigbee IP networks."

On 11/9/2010 11:45 PM, Fred Baker wrote:
>>> From: IETF I-D Submission Tool<[email-masked]>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 10 Nov 2010 14:48:57 +0900

(2010/11/10 14:02), Paul Duffy wrote:
> Further, Protocol for Carrying  Authentication for Network Access 
> (PANA) is gaining traction for access security for Zigbee IP networks."

This text is also fine with me.  But please add reference to RFC 5191
(or preferably both RFC 5191 and RFC 5193), for PANA.

Yoshihiro Ohba

---

From: Paul Duffy <[email-masked]>
Date: Wed, 10 Nov 2010 00:55:11 -0500

I agree with Yoshi's suggestion. Modified text...

"When used in conjunction with EAP-TLS (RFC 5216), IEEE 802.1X offers
excellent access security for wired or wireless IEEE 802 LANs. PANA (RFCs 5191 and 5193) is also gaining traction for access security for Zigbee IP networks."

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 9 Nov 2010 22:11:49 -0800

Hi Paul,

One minor nit:

s/'RFCs 5191 and 5193'/'RFC 5191 and RFC 5193'/

Thanks,
-Samita

> excellent access security for wired or wireless IEEE 802 LANs. PANA (RFCs
> 5191 and 5193) is also gaining traction for access security for Zigbee IP
> networks."
> 
> 
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 10 Nov 2010 14:15:07 +0800

Is the modifier "excellent" really needed?

spt

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Nov 2010 09:35:39 +0200

Hi Fred,

Yoshi had already sent the text. Please see attached.

   to offer access security to a wired or wireless IEEE 802

This works (dropped the "excellent" too).

I'd not agree with Paul's "gaining traction" term, as Zigbee Alliance has
already decided to use PANA. 

Alper

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2010 6:21 AM
To: Alper Yegin
Cc: [email-masked]
Subject: Re: [smartpower-interest] Fwd: New Version Notification for
draft-baker-ietf-core-10

I have asked for text before, and I have used the text I have been given.
Send text.

>> the picture presented here.

Subject: Re: [smartpower-interest] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt
From: "Yoshihiro Ohba" <[email-masked]>
To: <[email-masked]>
Date: Thu, 28 Oct 2010 21:46:00 +0200

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

"
"

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:

"
"

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
>> Revision:	 09
>> Creation_date:	 2010-10-25
> <  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	
>     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.	
>

>   		
> 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: [email-masked]	 	   Email: [email-masked]	
>   		
>     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/

---

From: Paul Duffy <[email-masked]>
Date: Wed, 10 Nov 2010 02:47:15 -0500

Hi Alper,

I disagree with this wording, particularly the word "widely" used in 
conjunction with PANA.  It leaves the uninformed reader with the 
impression that 802.1X and PANA are on equal footings.  They are not.  
802.1X is widely deployed, PANA is just starting up its deployment curve.

Cheers

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Nov 2010 10:08:52 +0200

Paul,

You're right. We weeded out the word "excellent", but missed the "widely".

I went back and looked at the text again, and realized what we needed is
more than these micro-surgeries. That text is under 3.1.3. Transport Layer
Security (TLS), so it is misplaced. EAP/PANA|1X is about network access
authentication. I couldn't find a better fitting section, so probably a new
section is needed. OK, maybe we should work offline to come up with text.

Alper

 

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Duffy
Sent: Wednesday, November 10, 2010 9:47 AM
To: [email-masked]
Subject: Re: [smartpower-interest] Fwd: New Version Notification for
draft-baker-ietf-core-10

Hi Alper,

I disagree with this wording, particularly the word "widely" used in
conjunction with PANA.  It leaves the uninformed reader with the impression
that 802.1X and PANA are on equal footings.  They are not.  802.1X is widely
deployed, PANA is just starting up its deployment curve.

Cheers

Hi Fred,

 
 
Alper

 
-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2010 6:21 AM
To: Alper Yegin
Cc: [email-masked]
Subject: Re: [smartpower-interest] Fwd: New Version Notification for
draft-baker-ietf-core-10

Hi Fred,

 
 
Also, there is some mix-up with regard to the relationship among 1X,

EAP-TLS

Thank you.

Alper

 
 
-----Original Message-----

Begin forwarded message:

From: IETF I-D Submission Tool  <mailto:[email-masked]>
<[email-masked]>
Date: November 8, 2010 12:20:49 PM GMT+08:00
To: [email-masked]
Cc: [email-masked]
Subject: New Version Notification for draft-baker-ietf-core-10 

 
Abstract:

The IETF Secretariat.

---

From: Paul Duffy <[email-masked]>
Date: Wed, 10 Nov 2010 03:11:10 -0500

How about the following...

"Used in conjunction with EAP-TLS [RFC 5216], IEEE 802.1X [IEEE802.1X] 
is a widely deployed mechanism providing  access security for wired or 
wireless IEEE 802 LANs.  PANA [RFC 5191] is also gaining traction, as 
Zigbee IP has chosen PANA using EAP-TLS for network access security."

On 11/10/2010 3:08 AM, Alper Yegin wrote:
> I went back and looked at the text again, and realized what we needed 
> is more than these micro-surgeries. That text is under 3.1.3. 
> Transport Layer Security (TLS), so it is misplaced. EAP/PANA|1X is 
> about network access authentication. I couldn't find a better fitting 
> section, so probably a new section is needed. OK, maybe we should work 
> offline to come up with text.
>
> Alper
>
> *From:[email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Paul Duffy
> *Sent:* Wednesday, November 10, 2010 9:47 AM
> *To:* [email-masked]
> *Subject:* Re: [smartpower-interest] Fwd: New Version Notification for 
> draft-baker-ietf-core-10
>
> Hi Alper,
>
> Cc:[email-masked]  <mailto:[email-masked]>
>     From:[email-masked]  <mailto:[email-masked]>
>
>     To:[email-masked]  <mailto:[email-masked]>
>
>         From: IETF I-D Submission Tool<[email-masked]>  <mailto:[email-masked]>
>
>         To:[email-masked]  <mailto:[email-masked]>
>
>         Cc:[email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>