draft-ietf-6lo-dispatch-iana-registry-06.txt   draft-ietf-6lo-dispatch-iana-registry-07.txt 
6lo S. Chakrabarti 6lo S. Chakrabarti
Internet-Draft Internet-Draft
Updates: 4944, 6282 (if approved) G. Montenegro Updates: 4944, 6282 (if approved) G. Montenegro
Intended status: Standards Track Microsoft Intended status: Standards Track Microsoft
Expires: May 20, 2017 R. Droms Expires: June 11, 2017 R. Droms
J. Woodyatt J. Woodyatt
Nest Google
November 16, 2016 December 8, 2016
6lowpan ESC Dispatch Code Points and Guidelines 6lowpan ESC Dispatch Code Points and Guidelines
draft-ietf-6lo-dispatch-iana-registry-06 draft-ietf-6lo-dispatch-iana-registry-07
Abstract Abstract
RFC4944 defines the ESC dispatch type to allow for additional RFC4944 defines the ESC dispatch type to allow for additional
dispatch bytes in the 6lowpan header. The value of the ESC byte was dispatch octets in the 6lowpan header. The value of the ESC dispatch
updated by RFC6282, however, its usage was not defined either in type was updated by RFC6282, however, its usage was not defined
RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by either in RFC6282 or in RFC4944. This document updates RFC4944 and
defining the ESC extension byte code points including registration of RFC6282 by defining the ESC extension octet code points including
entries for known use cases at the time of writing of this document. registration of entries for known use cases at the time of writing of
this document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 20, 2017. This Internet-Draft will expire on June 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3 3. Usage of ESC dispatch octets . . . . . . . . . . . . . . . . . 3
3.1. Interaction with other RFC4944 implementations . . . . . . 4 3.1. Interaction with other RFC4944 implementations . . . . . . 4
3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5 3.2. ESC Extension Octets Typical Sequence . . . . . . . . . . . 5
3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 5 3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 6
3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 6 3.4. NALP and ESC dispatch types . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[RFC4944] section 5.1 defines the dispatch header and types. The ESC [RFC4944] section 5.1 defines the dispatch header and types. The ESC
type is defined for using additional dispatch bytes in the 6lowpan type is defined for using additional dispatch octets in the 6lowpan
header. RFC 6282 modifies the value of the ESC dispatch type and it header. RFC 6282 modifies the value of the ESC dispatch type and
is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and that value is recorded in IANA registry [6LOWPAN-IANA]. However, the
usage following the ESC byte are not defined in either [RFC4944] and octets and usage following the ESC dispatch type are not defined in
[RFC6282]. However, in recent years with 6lowpan deployments, either [RFC4944] and [RFC6282]. In recent years with 6lowpan
implementations and standards organizations have started using the deployments, implementations and standards organizations have started
ESC extension bytes and co-ordination between the respective using the ESC extension octets. This highlights the need for an
organizations and IETF/IANA is needed. updated IANA registration policy.
The following sections record the ITU-T specification for ESC The following sections record the ITU-T specification for ESC
dispatch byte code points as an existing known usage and propose the dispatch octet code points as an existing known usage and propose the
definition of ESC extension bytes for future applications. The definition of ESC extension octets for future applications. The
document also requests IANA actions for the first extension byte document also requests IANA actions for the first extension octet
following the ESC byte. following the ESC dispatch type.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Usage of ESC dispatch bytes 3. Usage of ESC dispatch octets
RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type
for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently for extension of dispatch octets. RFC 6282 [RFC6282] subsequently
modified its value to [01 000000]. modified its value to [01 000000].
This document specifies that the first octet following the ESC byte This document specifies that the first octet following the ESC
be used for extension type (extended dispatch values). Subsequent dispatch type be used for extension type (extended dispatch values).
octets are left unstructured for the specific use of the extension Subsequent octets are left unstructured for the specific use of the
type: extension type:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| ESC | ESC EXT Type | Extended Dispatch Payload | ESC | ESC EXT Type | Extended Dispatch Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Frame Format with ESC Byte Figure 1: Frame Format with ESC dispatch type
ESC: The left-most byte is the ESC dispatch type containing ESC: The left-most octet is the ESC dispatch type containing
'01000000' '01000000'
ESC Extension Type (EET): It is the first byte following the ESC ESC Extension Type (EET): It is the first octet following the ESC
byte. Extension type defines the payload for the additional dispatch dispatch type. Extension type defines the payload for the additional
bytes. The values are from 0 to 255. Values 0 and 255 are reserved dispatch octets. The values are from 0 to 255. Values 0 and 255 are
for future use. These values are assigned by IANA. The EET values reserved for future use. The remaining values from 1 to 254 are
are similar to dispatch values in the 6lowpan header except they are assigned by IANA. The EET values are similar to dispatch values in
preceded by the ESC byte. Thus, ESC extension types and dispatch the 6lowpan header except they are preceded by the ESC dispatch type.
values are using orthogonal code spaces. Though not desirable, Thus, ESC extension types and dispatch values are using orthogonal
multiple ESC bytes MAY appear in a 6lowpan header. Section 3.1 code spaces. Though not desirable, multiple ESC dispatch types MAY
describes how to handle an unknown ESC dispatch type. appear in a 6lowpan header. Section 3.1 describes how to handle an
unknown ESC dispatch type.
Extended Dispatch Payload(EDP): This part of the frame format must be Extended Dispatch Payload (EDP): This part of the frame format must
defined by the corresponding extension type. A specification is be defined by the corresponding extension type. A specification is
required to define each usage of extension type and its corresponding required to define each usage of extension type and its corresponding
Extension Payload. For the sake of interoperability, specifications Extension Payload. For the sake of interoperability, specifications
of extension bytes MUST NOT redefine the existing ESC Extension Type of extension octets MUST NOT redefine the existing ESC Extension Type
codes. codes.
Section 5.1 in RFC4944 indicates that the Extension Type field may Section 5.1 in RFC4944 indicates that the Extension Type field may
contain additional dispatch values larger than 63, as corrected by contain additional dispatch values larger than 63, as corrected by
[4944-ERRATA]. For the sake of interoperability, the new dispatch [4944-ERRATA]. For the sake of interoperability, the new dispatch
type (EET) MUST NOT modify the behavior of existing dispatch types type (EET) MUST NOT modify the behavior of existing dispatch types
[RFC4944]. [RFC4944].
3.1. Interaction with other RFC4944 implementations 3.1. Interaction with other RFC4944 implementations
It is expected that RFC4944 existing implementations are not capable It is expected that existing implementations of RFC4944 are not
of processing ESC extension data bytes as defined in this document. capable of processing ESC extension data octets as defined in this
However, implementers have to assume that existing implementation document. However, implementers have to assume that existing
that attempt to process an EET unknown to them will simply drop the implementation that attempt to process an EET unknown to them will
packet or ignore the ESC dispatch bytes. simply drop the packet or ignore the ESC dispatch octets.
If an implementation following this document, during processing of If an implementation following this document, during processing of
the received packet reaches an ESC byte for which it does not the received packet reaches an ESC dispatch type for which it does
understand the extension bytes (EET), it MUST drop that packet. not understand the extension octets (EET), it MUST drop that packet.
However, it is important to clarify that a router node SHOULD forward However, it is important to clarify that a router node SHOULD forward
a 6lowpan packet with the EET bytes as long as it does not attempt to a 6lowpan packet with the EET octets as long as it does not attempt
process any unknown ESC extension bytes. to process any unknown ESC extension octets.
Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension Multiple ESC extension octets may appear in a packet. The ESC
bytes may appear in a packet. The ESC bytes can appear as the first, dispatch types can appear as the first, last or middle dispatch
last or middle dispatch bytes. However, a packet will get dropped by octets. However, a packet will get dropped by any node that does not
any node that does not understand the EET at the beginning of the understand the EET at the beginning of the packet. Placing an EET
packet. The closer to the end of the packet are the EET's, the toward the front of the packet has a greater probability of causing
higher chance there is that a legacy node will recognize and the packet to be dropped than placing the same EET later in the
successfully process some dispatch type [RFC4944] before the EET and packet. Placement of an EET later in the packet increases the chance
then ignore the EET instead of dropping the entire packet. that a legacy device will recognize and successfully process some
dispatch type [RFC4944] before the EET. In this case, the legacy
device will ignore the EET instead of dropping the entire packet.
3.2. ESC Extension Bytes Typical Sequence 3.2. ESC Extension Octets Typical Sequence
ESC Extension bytes sequence and order with respect to 6LoWPAN Mesh ESC Extension octets sequence and order with respect to 6LoWPAN Mesh
header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC
dispatch type is present, ESC bytes MUST appear before the dispatch type is present, ESC dispatch types MUST appear before the
LOWPAN_IPHC dispatch type in order to maintain backward compatibility LOWPAN_IPHC dispatch type in order to maintain backward compatibility
with RFC6282 section 3.2. The following diagrams provide examples of with RFC6282 section 3.2. The following diagrams provide examples of
ESC extension byte usages: ESC extension octet usages:
A LoWPAN encapsulated IPv6 Header compressed packet: A LoWPAN encapsulated IPv6 Header compressed packet:
+-------+------+--------+--------+-----------------+--------+ +-------+------+--------+--------+-----------------+--------+
| ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld | | ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld |
+-------+------+--------+--------+-----------------+--------+ +-------+------+--------+--------+-----------------+--------+
A LoWPAN_IPHC Header, Mesh header and an ESC extension byte: A LoWPAN_IPHC Header, Mesh header and an ESC extension octet:
+-----+-----+-----+----+------+-------+---------------+------+ +-----+-----+-----+----+------+-------+---------------+------+
|M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| |M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld|
+-----+-----+-----+----+------+-------+---------------+------+ +-----+-----+-----+----+------+-------+---------------+------+
A Mesh header with ESC bytes A Mesh header with ESC dispatch types
+-------+-------+-----+-----+-------+ +-------+-------+-----+-----+-------+
| M Typ | M Hdr | ESC | EET |EDP | | M Typ | M Hdr | ESC | EET |EDP |
+-------+-------+-----+-----+-------+ +-------+-------+-----+-----+-------+
With Fragment header With Fragment header
+-------+-------+--------+------+-----+-----+-------+ +-------+-------+--------+------+-----+-----+-------+
| M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP | | M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP |
+-------+-------+--------+------+-----+-----+-------+ +-------+-------+--------+------+-----+-----+-------+
ESC byte as a LowPAN encapsulation ESC dispatch type as a LowPAN encapsulation
+--------+--------+--------+ +--------+--------+--------+
| ESC | EET | EDP | | ESC | EET | EDP |
+--------+--------+--------+ +--------+--------+--------+
Figure 2: A 6lowpan packet with ESC Bytes Figure 2: A 6lowpan packet with ESC dispatch types
3.3. ITU-T G.9903 ESC type usage 3.3. ITU-T G.9903 ESC type usage
The ESC dispatch type is used in [G3-PLC] to provide native mesh The ESC dispatch type is used in [G3-PLC] to provide native mesh
routing and bootstrapping functionalities. The ITU-T recommendation routing and bootstrapping functionalities. The ITU-T recommendation
defines command IDs in the [G3-PLC] section 9.4.2.3 which operates [G3-PLC] section 9.4.2.3 defines commands which are formatted like
like ESC Extension type field. The command ID values are 0x01 to ESC Extension type fields. The command ID values are 0x01 to 0x1F.
0x1F.
The frame format is defined as follows: The frame format is defined as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| ESC | Command ID | Command Payload |0 1| ESC | Command ID | Command Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: G.9903 Frame Format with ESC Byte Figure 3: G.9903 Frame Format with ESC dispatch type
3.4. NALP and ESC bytes 3.4. NALP and ESC dispatch types
According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are According to RFC4944 [RFC4944] section 5.1, NALP dispatch octets are
reserved for use as a kind of escape code for identification of non- reserved for use as a kind of escape code for identification of non-
6lowpan payloads. Since ESC bytes are part of 6lowpan dispatch types 6lowpan payloads. Since ESC dispatch types are part of 6lowpan
(extended), they are orthogonal to NALP bytes. dispatch types (extended), they are orthogonal to NALP octets.
This document clarifies that NALP dispatch codes only provide an This document clarifies that NALP dispatch codes only provide an
escape method for non-6LoWPAN payloads when they appear as the escape method for non-6LoWPAN payloads when they appear as the
initial byte of a LoWPAN encapsulation, and that the potential initial octet of a LoWPAN encapsulation, and that the potential
meaning of their appearance in any other location is reserved for meaning of their appearance in any other location is reserved for
future use. future use.
4. IANA Considerations 4. IANA Considerations
This document requests IANA to register the 'ESC Extension Type' This document requests IANA to register the 'ESC Extension Type'
values per the policy 'Specification Required' [RFC5226], following values per the policy 'Specification Required' [RFC5226], following
the same policy as in the IANA section of [RFC4944]. For each the same policy as in the IANA Considerations section of [RFC4944].
Extension Type (except the Reserved values) the specification MUST For each Extension Type (except the Reserved values) the
define corresponding Extended Dispatch Payload frame bytes for the specification MUST define corresponding Extended Dispatch Payload
receiver implementation to read the ESC bytes in an interoperable frame octets for the receiver implementation to read the ESC dispatch
fashion. types in an interoperable fashion.
[RFC5226] section 4.1 also indicates that "Specification Required" [RFC5226] section 4.1 also indicates that "Specification Required"
implies a Designated Expert review of the public specification calls for a Designated Expert review of the public specification
requesting registration of the ESC Extension Type values. requesting registration of the ESC Extension Type values.
The allocation of code points should follow the guidelines on "Usage The allocation of code points should follow the guidelines on "Usage
Of ESC Dispatch Bytes" and the typical example sections. ESC of ESC dispatch octets" and the typical example sections. ESC
Extension type code points MUST be used in conjunction with 6lo Extension type code points MUST be used in conjunction with 6lo
protocols following [RFC4944] or its derivatives. The requesting protocols following [RFC4944] or its derivatives. The requesting
document MUST specify how the ESC dispatch bytes will be used along document MUST specify how the ESC dispatch octets will be used along
with 6LOWPAN headers in their use cases. with 6LOWPAN headers in their use cases.
The initial values for the 'ESC Extension Type' fields are: The initial values for the 'ESC Extension Type' fields are:
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
| 0 | Reserved for future use | This document | | 0 | Reserved for future use | This document |
| | | | | | | |
| 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &|
skipping to change at page 7, line 28 skipping to change at page 7, line 32
| | Assignment-- Spec Required) | | | | Assignment-- Spec Required) | |
| | | | | | | |
| 255 | Reserved for future use | This document | | 255 | Reserved for future use | This document |
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
Figure 4: Initial Values for IANA Registry Figure 4: Initial Values for IANA Registry
5. Security Considerations 5. Security Considerations
There are no additional security threats due to the assignments of There are no additional security threats due to the assignments of
ESC byte usage described in this document. Furthermore, this ESC dispatch type usage described in this document. Furthermore,
document forbids defining any extended dispatch values or extension this document forbids defining any extended dispatch values or
types that modify the behavior of existing Dispatch types. extension types that modify the behavior of existing Dispatch types.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank the members of the 6lo WG for their The authors would like to thank the members of the 6lo WG for their
comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys,
Cedric Lavenu, Pascal Thubert for discussions regarding the bits Cedric Lavenu, Pascal Thubert for discussions regarding the bits
allocation issues, which led to this document. Jonathan Hui and allocation issues, which led to this document. Jonathan Hui and
Robert Cragie provided extensive reviews and guidance for Robert Cragie provided extensive reviews and guidance for
interoperability. The authors acknowledge the comments from the interoperability. The authors acknowledge the comments from the
following people that helped shape this document: Paul Duffy, Don following people that helped shape this document: Paul Duffy, Don
Sturek, Michael Richardson, Xavier Vilajosana and Scott Mansfield. Sturek, Michael Richardson, Xavier Vilajosana, Scott Mansfield, Dale
Thanks to Brian Haberman, our document shepherd, for guidance in the Worley and Russ Housley. Thanks to Brian Haberman, our document
IANA section. shepherd, for guidance in the IANA Considerations section.
This document was produced using the xml2rfc tool.
7. References 7. References
7.1. Normative References 7.1. Normative References
[4944-ERRATA] [4944-ERRATA]
"https://www.rfc-editor.org/errata_search.php?rfc=4944". "https://www.rfc-editor.org/errata_search.php?rfc=4944".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 9, line 4 skipping to change at page 9, line 12
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
Authors' Addresses Authors' Addresses
Samita Chakrabarti Samita Chakrabarti
San Jose, CA San Jose, CA
USA USA
Email: samitac.ietf@gmail.com Email: samitac.ietf@gmail.com
Gabriel Montenegro Gabriel Montenegro
Microsoft Microsoft
USA USA
Email: gabriel.montenegro@microsoft.com Email: gabriel.montenegro@microsoft.com
Ralph Droms Ralph Droms
USA USA
Email: rdroms@gmail.com Email: rdroms.ietf@gmail.com
James Woodyatt James Woodyatt
Nest Google
Mountain View, CA Mountain View, CA
USA USA
Email: jhw@netstlabs.com Email: jhw@google.com
 End of changes. 47 change blocks. 
97 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/