draft-ietf-netmod-interfaces-cfg-04.txt | draft-ietf-netmod-interfaces-cfg-05.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 April 29, 2012 | Intended status: Standards Track July 14, 2012 | |||
Expires: October 31, 2012 | Expires: January 15, 2013 | |||
A YANG Data Model for Interface Configuration | A YANG Data Model for Interface Configuration | |||
draft-ietf-netmod-interfaces-cfg-04 | draft-ietf-netmod-interfaces-cfg-05 | |||
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 October 31, 2012. | This Internet-Draft will expire on January 15, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 5 | 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. The interface List . . . . . . . . . . . . . . . . . . . . 5 | 3.1. The interface List . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Interface References . . . . . . . . . . . . . . . . . . . 6 | 3.2. Interface References . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 6 | 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 | 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 | |||
5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 9 | 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 9 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 | ||||
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 18 | Appendix A. Example: Ethernet Interface Module . . . . . . . . . 18 | |||
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 20 | Appendix B. Example: Ethernet Bonding Interface Module . . . . . 20 | |||
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 21 | Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 21 | |||
Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 22 | Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 22 | |||
Appendix E. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 23 | Appendix E. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 23 | |||
E.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23 | E.1. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
E.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 | E.2. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
E.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 | E.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
E.4. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 23 | E.4. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
E.5. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
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 | |||
skipping to change at page 6, line 42 | skipping to change at page 6, line 42 | |||
An interface is identified by its name, which is unique within the | An interface is identified by its name, which is unique within the | |||
server. This property is captured in the "interface-ref" typedef, | server. This property is captured in the "interface-ref" typedef, | |||
which other YANG modules SHOULD use when they need to reference an | which other YANG modules SHOULD use when they need to reference an | |||
existing interface. | 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 nodes for interface | interface type specific models define their own data nodes for | |||
layering, by using "interface-ref" types to reference lower layers. | interface layering, by using "interface-ref" types to reference lower | |||
layers. | ||||
Below is an example of a model with such nodes. For a more complete | Below is an example of a model with such nodes. For a more 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()]" | |||
skipping to change at page 8, line 25 | skipping to change at page 8, line 25 | |||
The IF-MIB allows two different ifEntries to have the same ifName. | The IF-MIB allows two different ifEntries to have the same ifName. | |||
Devices that support this feature, and also support the configuration | Devices that support this feature, and also support the configuration | |||
of these interfaces using the "interface" list, cannot have a 1-1 | of these interfaces using the "interface" list, cannot have a 1-1 | |||
mapping between the "name" leaf and ifName. | mapping between the "name" leaf and ifName. | |||
The IF-MIB also defines the writable object ifPromiscuousMode. Since | The IF-MIB also defines the writable object ifPromiscuousMode. Since | |||
this object typically is not a configuration object, it is not mapped | this object typically is not a configuration object, it is not mapped | |||
to the "ietf-interfaces" module. | to the "ietf-interfaces" module. | |||
The following table lists the YANG nodes with corresponding objects | The following table lists the YANG data nodes with corresponding | |||
in the IF-MIB. | objects in the IF-MIB. | |||
+--------------------------+------------------------+ | +--------------------------+------------------------+ | |||
| YANG node | IF-MIB object | | | YANG data node | IF-MIB object | | |||
+--------------------------+------------------------+ | +--------------------------+------------------------+ | |||
| interface | ifEntry | | | interface | ifEntry | | |||
| name | ifName | | | name | ifName | | |||
| description | ifAlias | | | description | ifAlias | | |||
| type | ifType | | | type | ifType | | |||
| enabled | ifAdminStatus | | | enabled | ifAdminStatus | | |||
| if-index | ifIndex | | | if-index | ifIndex | | |||
| mtu | ifMtu | | | mtu | ifMtu | | |||
| link-up-down-trap-enable | ifLinkUpDownTrapEnable | | | link-up-down-trap-enable | ifLinkUpDownTrapEnable | | |||
+--------------------------+------------------------+ | +--------------------------+------------------------+ | |||
Mapping of YANG nodes to IF-MIB objects | Mapping of YANG data nodes to IF-MIB objects | |||
5. Interfaces YANG Module | 5. Interfaces YANG Module | |||
This YANG module imports a typedef from | This YANG module imports a typedef from | |||
[I-D.ietf-netmod-iana-if-type]. | [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@2012-04-29.yang" | <CODE BEGINS> file "ietf-interfaces@2012-07-14.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 ianaift; | prefix ianaift; | |||
} | } | |||
skipping to change at page 9, line 44 | skipping to change at page 9, line 44 | |||
WG Chair: Juergen Schoenwaelder | WG Chair: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
Editor: Martin Bjorklund | Editor: Martin Bjorklund | |||
<mailto:mbj@tail-f.com>"; | <mailto:mbj@tail-f.com>"; | |||
description | description | |||
"This module contains a collection of YANG definitions for | "This module contains a collection of YANG definitions for | |||
configuring network interfaces. | configuring network interfaces. | |||
Copyright (c) 2011 IETF Trust and the persons identified as | Copyright (c) 2012 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 2012-04-29 { | revision 2012-07-14 { | |||
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 11, line 15 | skipping to change at page 11, line 15 | |||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
"An arbitrary name for the interface. | "An arbitrary name for the interface. | |||
A device MAY restrict the allowed values for this leaf, | A device MAY restrict the allowed values for this leaf, | |||
possibly depending on the type and location. | possibly depending on the type and location. | |||
For example, if a device has a single array of 8 ethernet | For example, if a device has a single array of 8 ethernet | |||
ports, the name might be restricted to be on the form | ports, the name might be restricted to be on the form | |||
'ethN', where N is an integer between '1' and '8'. | 'ethN', where N is an integer between '1' and '8'. | |||
This leaf MAY be mapped to ifName by an implementation. | This leaf MAY be mapped to ifName by an implementation. | |||
Such an implementation MAY restrict the allowed values | Such an implementation MAY restrict the allowed values for | |||
for this leaf so that it matches the restrictions of | this leaf so that it matches the restrictions of ifName. | |||
ifName."; | If a NETCONF server that implements this restriction is | |||
sent a value that doesn't match the restriction, it MUST | ||||
reply with an rpc-error with the error-tag | ||||
'invalid-value'."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifName"; | "RFC 2863: The Interfaces Group MIB - ifName"; | |||
} | } | |||
leaf description { | leaf description { | |||
type string; | type string; | |||
description | description | |||
"A textual description of the interface. | "A textual description of the interface. | |||
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 allowed values | Such an implementation MAY restrict the allowed values for | |||
for this leaf so that it matches the restrictions of | this leaf so that it matches the restrictions of ifAlias. | |||
ifAlias."; | If a NETCONF server that implements this restriction is | |||
sent a value that doesn't match the restriction, it MUST | ||||
reply with an rpc-error with the error-tag | ||||
'invalid-value'."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifAlias"; | "RFC 2863: The Interfaces Group MIB - ifAlias"; | |||
} | } | |||
leaf type { | leaf type { | |||
type ianaift:iana-if-type; | type ianaift:iana-if-type; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"The type of the interface. | "The type of the interface. | |||
skipping to change at page 12, line 8 | skipping to change at page 12, line 14 | |||
interface."; | interface."; | |||
} | } | |||
leaf location { | leaf location { | |||
type string; | type string; | |||
description | description | |||
"The device-specific location of the interface of a | "The device-specific location of the interface of a | |||
particular type. The format of the location string | particular type. The format of the location string | |||
depends on the interface type and the device. | depends on the interface type and the device. | |||
Media-specific modules must specify if the location | If the interface's type represents a physical interface, | |||
is needed for the given type. | this leaf MUST be set. | |||
For example, if a device has a single array of 8 ethernet | For example, if a device has a single array of 8 ethernet | |||
ports, the location can be one of '1' to '8'. As another | ports, the location can be one of '1' to '8'. As another | |||
example, if a device has N cards of M ports, the location | example, if a device has N cards of M ports, the location | |||
can be on the form 'n/m'. | can be on the form 'n/m'. | |||
When an interface entry is created, a server MAY | When an interface entry is created, a server MAY | |||
initialize the location leaf with a valid value, e.g., if | initialize the location leaf with a valid value, e.g., if | |||
it is possible to derive the location from the name of | it is possible to derive the location from the name of | |||
the interface."; | the interface."; | |||
skipping to change at page 15, line 22 | skipping to change at page 15, line 22 | |||
There are a number of data nodes defined in the YANG module which are | There are a number of data nodes defined in the YANG module which are | |||
writable/creatable/deletable (i.e., config true, which is the | writable/creatable/deletable (i.e., config true, which is the | |||
default). These data nodes may be considered sensitive or vulnerable | default). These data nodes may be considered sensitive or vulnerable | |||
in some network environments. Write operations (e.g., <edit-config>) | in some network environments. Write operations (e.g., <edit-config>) | |||
to these data nodes without proper protection can have a negative | to these data nodes without proper protection can have a negative | |||
effect on network operations. These are the subtrees and data nodes | effect on network operations. These are the subtrees and data nodes | |||
and their sensitivity/vulnerability: | and their sensitivity/vulnerability: | |||
/interfaces/interface: This list specifies the configured interfaces | /interfaces/interface: This list specifies 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 it should receive and process. | |||
/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 it should receive and process. | |||
/interfaces/interface/mtu: Setting this leaf to a very small value | ||||
can be used to slow down interfaces. | ||||
8. Acknowledgments | 8. Acknowledgments | |||
The author wishes to thank Per Hedeland, Ladislav Lhotka, and Juergen | The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav | |||
Schoenwaelder for their helpful comments. | Lhotka, and Juergen Schoenwaelder for their helpful comments. | |||
9. Normative References | 9. References | |||
9.1. Normative References | ||||
[I-D.ietf-netmod-iana-if-type] | [I-D.ietf-netmod-iana-if-type] | |||
Bjorklund, M., "IANA Interface Type and Address Family | Bjorklund, M., "IANA Interface Type and Address Family | |||
YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in | YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in | |||
progress), April 2012. | progress), April 2012. | |||
[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. | |||
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. | ||||
Schoenwaelder, Ed., "Textual Conventions for SMIv2", | ||||
STD 58, RFC 2579, April 1999. | ||||
[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. | |||
9.2. Informative References | ||||
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. | ||||
Schoenwaelder, Ed., "Textual Conventions for SMIv2", | ||||
STD 58, RFC 2579, April 1999. | ||||
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | |||
Bierman, "Network Configuration Protocol (NETCONF)", | Bierman, "Network Configuration Protocol (NETCONF)", | |||
RFC 6241, June 2011. | RFC 6241, June 2011. | |||
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
Shell (SSH)", RFC 6242, June 2011. | 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 | |||
skipping to change at page 23, line 9 | skipping to change at page 23, line 9 | |||
xmlns="http://example.com/vlan">true</vlan-tagging> | xmlns="http://example.com/vlan">true</vlan-tagging> | |||
</interface> | </interface> | |||
</interfaces> | </interfaces> | |||
</data> | </data> | |||
</rpc-reply> | </rpc-reply> | |||
Appendix E. ChangeLog | Appendix E. ChangeLog | |||
RFC Editor: remove this section upon publication as an RFC. | RFC Editor: remove this section upon publication as an RFC. | |||
E.1. Version -04 | E.1. Version -05 | |||
o Added an Informative References section. | ||||
o Updated the Security Considerations section. | ||||
o Clarified the behavior of an NETCONF server when invalid values | ||||
are received. | ||||
E.2. Version -04 | ||||
o Clarified why ifPromiscuousMode is not part of this data model. | o Clarified why ifPromiscuousMode is not part of this data model. | |||
o Added a table that shows the mapping between this YANG data model | o Added a table that shows the mapping between this YANG data model | |||
and IF-MIB. | and IF-MIB. | |||
E.2. Version -03 | E.3. Version -03 | |||
o Added the section Relationship to the IF-MIB. | o Added the section Relationship to the IF-MIB. | |||
o Changed if-index to be a leaf instead of leaf-list. | o Changed if-index to be a leaf instead of leaf-list. | |||
o Explained the notation used in the data model tree picture. | o Explained the notation used in the data model tree picture. | |||
E.3. Version -02 | E.4. Version -02 | |||
o Editorial fixes | o Editorial fixes | |||
E.4. Version -01 | E.5. 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. 26 change blocks. | ||||
40 lines changed or deleted | 66 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/ |