draft-ietf-netmod-interfaces-cfg-01.txt | draft-ietf-netmod-interfaces-cfg-02.txt | |||
---|---|---|---|---|
Network Working Group M. Bjorklund | Network Working Group M. Bjorklund | |||
Internet-Draft Tail-f Systems | Internet-Draft Tail-f Systems | |||
Intended status: Standards Track May 20, 2011 | Intended status: Standards Track September 7, 2011 | |||
Expires: November 21, 2011 | Expires: March 10, 2012 | |||
A YANG Data Model for Interface Configuration | A YANG Data Model for Interface Configuration | |||
draft-ietf-netmod-interfaces-cfg-01 | draft-ietf-netmod-interfaces-cfg-02 | |||
Abstract | Abstract | |||
This document defines a YANG data model for the configuration of | This document defines a YANG data model for the configuration of | |||
network interfaces. It is expected that interface type specific | network interfaces. It is expected that interface type specific | |||
configuration data models augment the generic interfaces data model | configuration data models augment the generic interfaces data model | |||
defined in this document. | defined in this document. | |||
Status of this Memo | Status of this Memo | |||
skipping to change at page 1, line 33 | skipping to change at page 1, line 33 | |||
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 November 21, 2011. | This Internet-Draft will expire on March 10, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 21 | skipping to change at page 2, line 21 | |||
3.2. Interface References . . . . . . . . . . . . . . . . . . . 6 | 3.2. Interface References . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 6 | 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 7 | 4. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 7 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 | 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 16 | Appendix A. Example: Ethernet Interface Module . . . . . . . . . 16 | |||
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 18 | Appendix B. Example: Ethernet Bonding Interface Module . . . . . 18 | |||
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 19 | Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 19 | |||
Appendix D. Example: IP Module . . . . . . . . . . . . . . . . . 20 | Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 20 | |||
Appendix E. Example: NETCONF <get> reply . . . . . . . . . . . . 21 | Appendix E. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 21 | |||
Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 22 | E.1. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
F.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 22 | E.2. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
1. Introduction | 1. Introduction | |||
This document defines a YANG [RFC6020] data model for the | This document defines a YANG [RFC6020] data model for the | |||
configuration of network interfaces. It is expected that interface | configuration of network interfaces. It is expected that interface | |||
type specific configuration data models augment the generic | type specific configuration data models augment the generic | |||
interfaces data model defined in this document. | interfaces data model defined in this document. | |||
Network interfaces are central to the configuration of many Internet | Network interfaces are central to the configuration of many Internet | |||
protocols. Thus, it is important to establish a common data model | protocols. Thus, it is important to establish a common data model | |||
skipping to change at page 4, line 18 | skipping to change at page 4, line 18 | |||
presented in Section 4. | presented in Section 4. | |||
o It is recognized that existing implementations will have to map | o It is recognized that existing implementations will have to map | |||
the interface data model defined in this memo to their proprietary | the interface data model defined in this memo to their proprietary | |||
native data model. The new data model should be simple to | native data model. The new data model should be simple to | |||
facilitate such mappings. | facilitate such mappings. | |||
o The data model should be suitable for new implementations to use | o The data model should be suitable for new implementations to use | |||
as-is, without requiring a mapping to a different native model. | as-is, without requiring a mapping to a different native model. | |||
o The data model must be extensible for different specific interface | ||||
types, including vendor-specific types. | ||||
o References to interfaces should be as simple as possible, | o References to interfaces should be as simple as possible, | |||
preferably by using a single leafref. | preferably by using a single leafref. | |||
o The mapping to ifIndex [RFC2863] used by SNMP to identify | o The mapping to ifIndex [RFC2863] used by SNMP to identify | |||
interfaces must be clear. | interfaces must be clear. | |||
o The model must support interface layering, both simple layering | o The model must support interface layering, both simple layering | |||
where one interface is layered on top of exactly one other | where one interface is layered on top of exactly one other | |||
interface, and more complex scenarios where one interface is | interface, and more complex scenarios where one interface is | |||
aggregated over N other interfaces, or when N interfaces are | aggregated over N other interfaces, or when N interfaces are | |||
skipping to change at page 5, line 13 | skipping to change at page 5, line 13 | |||
provisioning. | provisioning. | |||
3. Interfaces Data Model | 3. Interfaces Data Model | |||
The module "ietf-interfaces" has the following structure: | The module "ietf-interfaces" has the following structure: | |||
+--rw interfaces | +--rw interfaces | |||
+--rw interface [name] | +--rw interface [name] | |||
+--rw name string | +--rw name string | |||
+--rw description? string | +--rw description? string | |||
+--rw type ift:iana-if-type | +--rw type ianaift:iana-if-type | |||
+--rw location? string | +--rw location? string | |||
+--rw enabled? boolean | +--rw enabled? boolean | |||
+--ro if-index* int32 | +--ro if-index* int32 | |||
+--rw mtu? uint32 | +--rw mtu? uint32 | |||
+--rw link-up-down-trap-enable? enumeration | +--rw link-up-down-trap-enable? enumeration | |||
This module defines one YANG feature: | This module defines one YANG feature: | |||
snmp-if-mib: Indicates that the server implements IF-MIB [RFC2863]. | snmp-if-mib: Indicates that the server implements IF-MIB [RFC2863]. | |||
skipping to change at page 6, line 27 | skipping to change at page 6, line 27 | |||
3.2. Interface References | 3.2. Interface References | |||
An interface is uniquely identified by its name. This property is | An interface is uniquely identified by its name. This property is | |||
captured in the "interface-ref" typedef, which other YANG modules | captured in the "interface-ref" typedef, which other YANG modules | |||
SHOULD use when they need to reference an existing interface. | SHOULD use when they need to reference an existing interface. | |||
3.3. Interface Layering | 3.3. Interface Layering | |||
There is no generic mechanism for how an interface is configured to | There is no generic mechanism for how an interface is configured to | |||
be layered on top of some other interface. It is expected that | be layered on top of some other interface. It is expected that | |||
interface type specific models define their own objects for interface | interface type specific models define their own nodes for interface | |||
layering, by using "interface-ref" types to reference lower layers. | layering, by using "interface-ref" types to reference lower layers. | |||
Below is an example of a model with such objects. For a more | Below is an example of a model with such nodes. For a more complete | |||
complete example, see Appendix B. | example, see Appendix B. | |||
augment "/if:interfaces/if:interface" { | augment "/if:interfaces/if:interface" { | |||
when "if:type = 'ieee8023adLag'"; | when "if:type = 'ieee8023adLag'"; | |||
leaf-list slave-if { | leaf-list slave-if { | |||
type if:interface-ref; | type if:interface-ref; | |||
must "/if:interfaces/if:interface[if:name = current()]" | must "/if:interfaces/if:interface[if:name = current()]" | |||
+ "/if:type = 'eth:ethernet'" { | + "/if:type = 'ethernetCsmacd'" { | |||
description | description | |||
"The type of a slave interface must be ethernet"; | "The type of a slave interface must be ethernet"; | |||
} | } | |||
} | } | |||
// other bonding config params, failover times etc. | // other bonding config params, failover times etc. | |||
} | } | |||
4. Interfaces YANG Module | 4. Interfaces YANG Module | |||
This YANG module imports a typedef from | ||||
[I-D.ietf-netmod-iana-if-type]. | ||||
RFC Ed.: update the date below with the date of RFC publication and | RFC Ed.: update the date below with the date of RFC publication and | |||
remove this note. | remove this note. | |||
<CODE BEGINS> file "ietf-interfaces@2011-05-20.yang" | <CODE BEGINS> file "ietf-interfaces@2011-09-07.yang" | |||
module ietf-interfaces { | module ietf-interfaces { | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; | namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; | |||
prefix if; | prefix if; | |||
import iana-if-type { | import iana-if-type { | |||
prefix ift; | prefix ianaift; | |||
} | } | |||
organization | organization | |||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | |||
contact | contact | |||
"WG Web: <http://tools.ietf.org/wg/netmod/> | "WG Web: <http://tools.ietf.org/wg/netmod/> | |||
WG List: <mailto:netmod@ietf.org> | WG List: <mailto:netmod@ietf.org> | |||
WG Chair: David Kessens | WG Chair: David Kessens | |||
skipping to change at page 7, line 50 | skipping to change at page 8, line 4 | |||
Copyright (c) 2011 IETF Trust and the persons identified as | Copyright (c) 2011 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject | without modification, is permitted pursuant to, and subject | |||
to the license terms contained in, the Simplified BSD License | to the license terms contained in, the Simplified BSD License | |||
set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC XXXX; see | This version of this YANG module is part of RFC XXXX; see | |||
the RFC itself for full legal notices."; | the RFC itself for full legal notices."; | |||
// RFC Ed.: replace XXXX with actual RFC number and remove this | // RFC Ed.: replace XXXX with actual RFC number and remove this | |||
// note. | // note. | |||
// RFC Ed.: update the date below with the date of RFC publication | // RFC Ed.: update the date below with the date of RFC publication | |||
// and remove this note. | // and remove this note. | |||
revision 2011-05-20 { | revision 2011-09-07 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: A YANG Data Model for Interface Configuration"; | "RFC XXXX: A YANG Data Model for Interface Configuration"; | |||
} | } | |||
/* Typedefs */ | /* Typedefs */ | |||
typedef interface-ref { | typedef interface-ref { | |||
type leafref { | type leafref { | |||
skipping to change at page 9, line 31 | skipping to change at page 9, line 34 | |||
This leaf MAY be mapped to ifAlias by an implementation. | This leaf MAY be mapped to ifAlias by an implementation. | |||
Such an implementation MAY restrict the length of the | Such an implementation MAY restrict the length of the | |||
value of this leaf so that it matches the restrictions | value of this leaf so that it matches the restrictions | |||
of ifAlias."; | of ifAlias."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifAlias"; | "RFC 2863: The Interfaces Group MIB - ifAlias"; | |||
} | } | |||
leaf type { | leaf type { | |||
type ift:iana-if-type; | type ianaift:iana-if-type; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"The type of the interface. | "The type of the interface. | |||
When an interface entry is created, a server MAY | When an interface entry is created, a server MAY | |||
initialize the type leaf with a valid value, e.g., if it | initialize the type leaf with a valid value, e.g., if it | |||
is possible to derive the type from the name of the | is possible to derive the type from the name of the | |||
interface."; | interface."; | |||
} | } | |||
skipping to change at page 13, line 7 | skipping to change at page 13, line 7 | |||
This document registers a YANG module in the YANG Module Names | This document registers a YANG module in the YANG Module Names | |||
registry [RFC6020]. | registry [RFC6020]. | |||
name: ietf-interfaces | name: ietf-interfaces | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces | namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces | |||
prefix: if | prefix: if | |||
reference: RFC XXXX | reference: RFC XXXX | |||
6. Security Considerations | 6. Security Considerations | |||
The YANG module and submodules defined in this memo are designed to | The YANG module defined in this memo is designed to be accessed via | |||
be accessed via the NETCONF protocol [I-D.ietf-netconf-4741bis]. The | the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the | |||
lowest NETCONF layer is the secure transport layer and the mandatory- | secure transport layer and the mandatory-to-implement secure | |||
to-implement secure transport is SSH [I-D.ietf-netconf-rfc4742bis]. | transport is SSH [RFC6242]. | |||
There are a number of data nodes defined in the YANG module and | There are a number of data nodes defined in the YANG module which are | |||
submodules which are writable/creatable/deletable (i.e., config true, | writable/creatable/deletable (i.e., config true, which is the | |||
which is the default). These data nodes may be considered sensitive | default). These data nodes may be considered sensitive or vulnerable | |||
or vulnerable in some network environments. Write operations (e.g., | in some network environments. Write operations (e.g., edit-config) | |||
edit-config) to these data nodes without proper protection can have a | to these data nodes without proper protection can have a negative | |||
negative effect on network operations. These are the subtrees and | effect on network operations. These are the subtrees and data nodes | |||
data nodes and their sensitivity/vulnerability: | and their sensitivity/vulnerability: | |||
/interfaces/interface: This list specify the configured interfaces | /interfaces/interface: This list specify the configured interfaces | |||
on a device. Unauthorized access to this list could cause the | on a device. Unauthorized access to this list could cause the | |||
device to ignore packets destined to it. | device to ignore packets destined to it. | |||
/interfaces/interface/enabled: This leaf controls if an interface is | /interfaces/interface/enabled: This leaf controls if an interface is | |||
enabled or not. Unauthorized access to this leaf could cause the | enabled or not. Unauthorized access to this leaf could cause the | |||
device to ignore packets destined to it. | device to ignore packets destined to it. | |||
7. Acknowledgments | 7. Acknowledgments | |||
The author wishes to thank Per Hedeland, Ladislav Lhotka, and Juergen | The author wishes to thank Per Hedeland, Ladislav Lhotka, and Juergen | |||
Schoenwaelder for their helpful comments. | Schoenwaelder for their helpful comments. | |||
8. Normative References | 8. Normative References | |||
[I-D.ietf-netconf-4741bis] | [I-D.ietf-netmod-iana-if-type] | |||
Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | Bjorklund, M., "IANA Interface Type YANG Module", | |||
Bierman, "Network Configuration Protocol (NETCONF)", | draft-ietf-netmod-iana-if-type-00 (work in progress), | |||
draft-ietf-netconf-4741bis-10 (work in progress), | April 2011. | |||
March 2011. | ||||
[I-D.ietf-netconf-rfc4742bis] | ||||
Wasserman, M. and T. Goddard, "Using the NETCONF | ||||
Configuration Protocol over Secure Shell (SSH)", | ||||
draft-ietf-netconf-rfc4742bis-08 (work in progress), | ||||
March 2011. | ||||
[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, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | |||
MIB", RFC 2863, June 2000. | MIB", RFC 2863, June 2000. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
January 2004. | January 2004. | |||
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the | [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the | |||
Network Configuration Protocol (NETCONF)", RFC 6020, | Network Configuration Protocol (NETCONF)", RFC 6020, | |||
October 2010. | October 2010. | |||
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | ||||
Bierman, "Network Configuration Protocol (NETCONF)", | ||||
RFC 6241, June 2011. | ||||
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | ||||
Shell (SSH)", RFC 6242, June 2011. | ||||
Appendix A. Example: Ethernet Interface Module | Appendix A. Example: Ethernet Interface Module | |||
This section gives a simple example of how an Ethernet interface | This section gives a simple example of how an Ethernet interface | |||
module could be defined. It demonstrates how media-specific | module could be defined. It demonstrates how media-specific | |||
configuration parameters can be conditionally augmented to the | configuration parameters can be conditionally augmented to the | |||
generic interface list. It is not intended as a complete module for | generic interface list. It is not intended as a complete module for | |||
ethernet configuration. | ethernet configuration. | |||
module ex-ethernet { | module ex-ethernet { | |||
namespace "http://example.com/ethernet"; | namespace "http://example.com/ethernet"; | |||
skipping to change at page 20, line 5 | skipping to change at page 20, line 5 | |||
} | } | |||
leaf vlan-id { | leaf vlan-id { | |||
type uint16 { | type uint16 { | |||
range "1..4094"; | range "1..4094"; | |||
} | } | |||
must "../base-interface"; | must "../base-interface"; | |||
} | } | |||
} | } | |||
} | } | |||
Appendix D. Example: IP Module | Appendix D. Example: NETCONF <get> reply | |||
This section gives an example how an IP module can be defined. | ||||
module ex-ip { | ||||
namespace "http://example.com/ip"; | ||||
prefix "ip"; | ||||
import ietf-interfaces { | ||||
prefix if; | ||||
} | ||||
import ietf-inet-types { | ||||
prefix inet; | ||||
} | ||||
augment "/if:interfaces/if:interface" { | ||||
container ip { | ||||
list address { | ||||
key "ip"; | ||||
leaf ip { | ||||
type inet:ip-address; | ||||
} | ||||
leaf prefix-length { | ||||
type uint16; | ||||
// range depends on type of address | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
Appendix E. Example: NETCONF <get> reply | ||||
This section gives an example of a reply to the NETCOMF <get> request | This section gives an example of a reply to the NETCOMF <get> request | |||
for a device that implements the example data models above. | for a device that implements the example data models above. | |||
<rpc-reply | <rpc-reply | |||
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
message-id="101"> | message-id="101"> | |||
<data> | <data> | |||
<interfaces | <interfaces | |||
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> | xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> | |||
<interface> | <interface> | |||
<name>eth0</name> | <name>eth0</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<location>0</location> | <location>0</location> | |||
<admin-status>up</admin-status> | <enabled>true</enabled> | |||
<if-index>2</if-index> | <if-index>2</if-index> | |||
<ip xmlns="http://example.com/ip"> | <ip xmlns="http://example.com/ip"> | |||
<address> | <address> | |||
<ip>192.0.2.1</ip> | <ip>192.0.2.1</ip> | |||
<prefix-length>24</prefix-length> | <prefix-length>24</prefix-length> | |||
</address> | </address> | |||
</ip> | </ip> | |||
</interface> | </interface> | |||
<interface> | <interface> | |||
<name>eth1</name> | <name>eth1</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<location>1</location> | <location>1</location> | |||
<admin-status>up</admin-status> | <enabled>true</enabled> | |||
<if-index>7</if-index> | <if-index>7</if-index> | |||
<ip xmlns="http://example.com/ip"> | <ip xmlns="http://example.com/ip"> | |||
<address> | <address> | |||
<ip>192.168.1.1</ip> | <ip>192.168.1.1</ip> | |||
<prefix-length>24</prefix-length> | <prefix-length>24</prefix-length> | |||
</address> | </address> | |||
</ip> | </ip> | |||
</interface> | </interface> | |||
</interfaces> | </interfaces> | |||
</data> | </data> | |||
</rpc-reply> | </rpc-reply> | |||
Appendix F. ChangeLog | Appendix E. ChangeLog | |||
RFC Editor: remove this section upon publication as an RFC. | RFC Editor: remove this section upon publication as an RFC. | |||
F.1. Version -01 | E.1. Version -02 | |||
o Editorial fixes | ||||
E.2. Version -01 | ||||
o Changed leaf "if-admin-status" to leaf "enabled". | o Changed leaf "if-admin-status" to leaf "enabled". | |||
o Added Security Considerations | o Added Security Considerations | |||
Author's Address | Author's Address | |||
Martin Bjorklund | Martin Bjorklund | |||
Tail-f Systems | Tail-f Systems | |||
End of changes. 24 change blocks. | ||||
82 lines changed or deleted | 52 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |