< draft-lonvick-private-tax-11.txt   draft-lonvick-private-tax-12.txt >
Network Working Group C. Lonvick Network Working Group C. Lonvick
Internet-Draft October 8, 2016 Internet-Draft June 17, 2017
Intended status: Informational Intended status: Informational
Expires: April 11, 2017 Expires: December 19, 2017
A Taxonomy on Private Use Fields in Protocols A Taxonomy on Private Use Fields in Protocols
draft-lonvick-private-tax-11.txt draft-lonvick-private-tax-12.txt
Abstract Abstract
This document attempts to provide some clarification for the way that This document attempts to provide some clarification for the way that
private use fields have been used in protocols developed in the IETF. private use fields have been used in protocols developed in the IETF.
It is strictly a taxonomy of what has been published and offers a It is strictly a taxonomy of what has been published and offers no
minimal amount of advice about how to design or use private use advice about how to design or use private use options.
options.
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 April 11, 2017. This Internet-Draft will expire on December 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Note on References . . . . . . . . . . . . . . . . . . . . 4
2. Origins of the Private Use Namespace . . . . . . . . . . . . . 4 2. Origins of the Private Use Namespace . . . . . . . . . . . . . 4
3. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Observed Characteristics of Private Use Options . . . . . . . 5
4. Characteristics of Useful Private Use Options . . . . . . . . 7 3.1. Start of Authority . . . . . . . . . . . . . . . . . . . . 5
4.1. Source of Authority . . . . . . . . . . . . . . . . . . . 7 3.2. Focus of the Namespace . . . . . . . . . . . . . . . . . . 7
4.2. Focus of the Namespace . . . . . . . . . . . . . . . . . . 8 4. Examples of Private Use Options . . . . . . . . . . . . . . . 7
5. Examples of Successful Private Use Options . . . . . . . . . . 8 4.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Private Enterprise Number . . . . . . . . . . . . . . . . 9 4.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Secure Shell . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.5. Syslog . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. YANG and NETCONF . . . . . . . . . . . . . . . . . . . . . 12
5.2. Domain Name Strings . . . . . . . . . . . . . . . . . . . 14 4.8. Extensible Provisioning Protocol . . . . . . . . . . . . . 13
5.2.1. Secure Shell . . . . . . . . . . . . . . . . . . . . . 14 5. Observations . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. URN-based Namespaces . . . . . . . . . . . . . . . . . . . 14 6. Authoritative Guidance . . . . . . . . . . . . . . . . . . . . 15
5.3.1. YANG and NETCONF . . . . . . . . . . . . . . . . . . . 15 7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Value of the Option . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.2. Guidance on Incomplete Understanding . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. Authors Notes . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Simply put, communications protocols are standardized ways for Simply put, communications protocols are standardized ways for
computing entities to convey information. Within each communications computing entities to convey information. Within each communications
protocol, there must be standardized pieces of information that will protocol, there must be quantified pieces of information that will be
be communicated, and there may be non-standardized pieces that can be communicated, and there may be non-standardized pieces that can be
communicated. Since one of the goals of standards is to provide communicated. Since one of the goals of standards is to provide
interoperability, all parties participating in any communications interoperability, all parties participating in any communications
protocol must be aware of how to deal with all fields in the protocol must be aware of how to deal with all fields in the
protocol. Fields reserved for private use cannot provide protocol.
interoperability unless their use is fully documented in openly
available documents. This section uses examples of some well known
protocols to demonstrate the differences between protocols that use
private use options, and those that don't.
Existing standards permit private use options in different ways. The
Time Protocol [RFC0868] is an example of a protocol that only conveys
standardized information. There is no way to add anything other than
what is specified in the document. On the other hand, DOD STANDARD
TRANSMISSION CONTROL PROTOCOL [RFC0761] does have "options" but they
must be registered through the IANA [IANAtcp] before use, which does
not leave any room for optional information supplied by equipment
vendors, network operators, or experimenters. Finally, Vendor-
Identifying Vendor Options for Dynamic Host Configuration Protocol
version 4 (DHCPv4) [RFC3925] does allow for vendor specific options
that do not need to be registered with anyone.
If a network operator wanted to add specific information to the Time
Protocol [RFC0868], they could modify the code of all senders and
receivers and run this within their own domain without any problems.
However, if an equipment vendor wanted to include information
specific to their equipment, they would have to ensure that all
senders and receivers within all network domains would either accept
the change in the protocol, or would not have problems with it. As a
final case, if several equipment vendors desired to add equipment-
specific information to this protocol, they would have to take great
care that only their own receivers would accept information from
their own transmitters. An extension to that would be that if one
equipment vendor would like to transmit or receive the same
information that another vendor is using.
For the case of TCP [RFC0761], standard options are expected; senders
may use them and receivers may be configured to act upon that
information, or to ignore it. If an experimenter wants to add an
option, they will have to create a new IETF RFC with specific
details, or obtain approval from the IESG to have the IANA add to the
registry [IANAtcp]. Similarly, if equipment vendors Foo and Bar were
to have a need for a similar option within TCP, they would each have
to go through the process to add to the registry. On the other hand,
if a properly crafted multipurpose private use option were to be
registered, such as in the case of multiple vendor instances within
DHCPv4 [RFC3925], then vendors and experimenters would each be able
to use it for their own purposes as long as all network participants
could easily differentiate between the entities using the option.
This document explores the various ways that protocols have allowed
optional information to be included using fields designated as
"private use". It uses examples of some well known protocols. In
well developed protocols, private use options may be useful in
avoiding allocation conflicts, and in dynamically extending a
feature. As with all good things, this will come with a cost.
Adding any extra fields to a protocol will require additional
processing for both the sender and the receiver. Also, larger
packets will take up more bandwidth in transmission. In another
aspect, a receiver will have to reserve buffers for an expected field
in an inbound packet. Since one way of implementing private use
options is to only enable the field if it is needed, then the
allocation of buffers could be considered wasteful if it is actually
not used.
2. Origins of the Private Use Namespace Some protocols have reserved fields for private and experimental use.
Indeed, having options reserved for testing and experimentation has
been found to be beneficial to the community as has been outlined in
"Assigning Experimental and Testing Numbers Considered Useful"
[RFC3692].
Guidelines for Writing an IANA Considerations Section in RFCs Fields reserved for private use cannot provide interoperability
[RFC2434] describes that values of specific namespaces may either be unless their use is fully documented in openly available documents.
registered with the IANA, or not. In most cases, there are well This specification uses examples of some protocols to exemplify how
defined values for namespaces. However, as the document explains, some private use options are used.
not all namespaces require centralized administration.
In that document, it seems to be assumed that private use namespaces 1.1. Requirements Language
will be domain specific and it will be up to the administrators of
any domain to avoid conflicts. The first example given about private
use namespaces refers to Dynamic Host Configuration Protocol
[RFC2131] and presumably DHCP Options and BOOTP Vendor Extensions
[RFC2132]. In this the example states that "site-specific options in
DHCP have significance only within a single site". As noted below
this became a problem that was rectified in a later revision of DHCP.
Later works identified a need to place a scope on private use The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
namespaces. The second example of private use namespaces in the IANA "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
guidelines [RFC2434] is from STANDARD FOR THE FORMAT OF ARPA INTERNET document are to be interpreted as described in "Key words for use in
TEXT MESSAGES [RFC0822] which describes X- headers. Again, there is RFCs to Indicate Requirement Levels" [RFC2119].
no effort made to control the namespace. It appears however that the
users of X- headers have self-organized; most consistently use
features that are universally useful and many have incorporated
identifiers for useful features that may overlap.
3. Nomenclature 1.2. Nomenclature
In this document, the following words are defined to prevent In this document, the following words are defined to prevent
ambiguity. Some of these words have not been used in the referenced ambiguity. Some of these words have not been used in the referenced
works but their meanings can be easily ascertained and applied. works but their meanings can be ascertained and applied.
o Communications protocol - a formal description of digital message
formats and the rules for exchanging those messages in or between
computing systems and in telecommunications [wpProt]
Example: The File Transfer Protocol [RFC0959] is an example of
a communications protocol. It has well defined fields and
standard options. The Syslog Protocol [RFC5424] is another
example of a communications protocol. It has well defined
fields, standard options, and it also has standard and private
use options. (See Section 5.1.5.)
o Protocol frame - a defined container of fields used to convey
information in a communications protocol
Example: An Internet Protocol packet [RFC0791] is considered to
be a protocol frame. In the case of The File Transfer Protocol
[RFC0959], an FTP message from the client to the server within
the Internet Protocol [RFC0791] containing an FTP command is a
protocol frame. In the case of The Syslog Protocol [RFC5424],
a message from the client to the server within the Internet
Protocol [RFC0791] containing a syslog message is also a
protocol frame.
o Field - any defined container within a communications protocol
frame
Example: In the case of The File Transfer Protocol [RFC0959], a
command will be contained within a field. In the case of The
Syslog Protocol [RFC5424], the HOSTNAME is a field.
o Standard option - a field in a protocol frame that may only use o Standard option - a field in a protocol frame that may only use
values that are strictly defined within a specification values that are strictly defined within a specification
Example: In the case of The File Transfer Protocol [RFC0959], o Private use option - a field in a protocol frame that is reserved
an FTP command, such as CDUP or QUIT, is a standard option. for private, experimental, testing, or local use only namespaces.
The reason that a command is a standard option is that only the
values listed by the IANA in the registry [IANAftp] may be
used. The standard options are not limited to the values
defined in the original RFC, but also include any additions to
the registry. In the case of The Syslog Protocol [RFC5424], an
SD-ID may be a standard option. The example given in Section
7.1.4 of [RFC5424] of
[timeQuality tzKnown="0" isSynced="0"]
is a standard option because all of the fields are listed in o Namespace - the set of possible values a field may contain; its
the document and in the IANA registry [IANAslg]. actual content may be a name, a number, or another kind of value.
o Private use option - a field in a protocol frame that is reserved Additionally, the terms "Start of Authority" and "Focus of the
for private or local use only namespaces Namespace" are defined within their respective contexts and further
discussed below.
Example: In the case of The Syslog Protocol, an SD-ID may be a The name "Start of Authority" comes from the domain name system
private use option. Example 3 given in Section 6.5 contains a configuration file which describes a "SoA" in "DOMAIN NAMES -
private use option. CONCEPTS AND FACILITIES" [RFC1034] and "DOMAIN NAMES - IMPLEMENTATION
AND SPECIFICATION" [RFC1035]. This includes the person or entity who
has ultimate control and decision making powers over the scope of the
domain. Some liberties have been taken with using this name in this
specification, but the intent is to identify an authoritative source
for the namespace.
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com 1.3. Note on References
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
Specifically, the SD-ID starting with "[exampleSDID@32473 ..." In many cases throughout this document, RFCs are referenced even
is not a specifically defined option in the RFC, nor is it though they are not the most current version of their respective
registered in the IANA registry [IANAslg]. It is a way for an protocol. This is usually done to reference the first occurrence of
equipment vendor to insert their specific information without a private use option, or to point out a distinct feature in that
having to register anything. In this case if the receiver specification. When an RFC is referenced that is not the current
knows the format of that SD-ID then it can immediately version, the reference will be followed by the RFC number of the
interpret its meaning. However, if it does not know how to current version in curly braces.
interpret that SD-ID, it can still log the message and an
Operator or Administrator can look up its meaning at a later
time.
o Namespace - the set of possible values a field may contain; its 2. Origins of the Private Use Namespace
actual content may be a name, a number or another kind of value
Example: In the same Example 3 from Section 6.5 of The Syslog Some standards permit private use options in different ways, while
Protocol [RFC5424], "exampleSDID@32473" provides the namespace others do not. The "Time Protocol" [RFC0868] is an example of a
so the context of the rest of the SD-ID may be interpreted. protocol that only conveys standardized information; there is no way
Specifically, the Private Enterprise Number [IANApen] (PEN) is to use private options and no way to add anything other than what is
used to associate the option with a private enterprise, and the specified in the document. In a more open way, "DOD STANDARD
text before the "@" identifies the option defined within that TRANSMISSION CONTROL PROTOCOL" [RFC0761] {[RFC0793]} {[RFC7805]} does
private enterprise. have "options" but they must be registered through the IANA [IANAtcp]
before use, which does not leave any room for optional information
supplied by equipment vendors, network operators, or experimenters.
An even more open way may be seen in "Vendor-Identifying Vendor
Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"
[RFC3925], which allows for vendor specific options that do not need
to be registered with anyone.
Additionally, the terms "Source of Authority" and "Focus of the For the case of TCP [RFC0761] {[RFC0793]} {[RFC7805]}, standard
Namespace" are defined and further discussed below. options are expected; senders may use them and receivers may be
configured to act upon that information, or to ignore it. If an
experimenter wants to add an option, they will have to create a new
IETF RFC with specific details, or obtain approval from the IESG to
have the IANA add to the registry [IANAtcp]. Similarly, if equipment
vendors Foo and Bar were to have a need for a similar option within
TCP, they would each have to go through the process to add to the
registry. On the other hand, if a properly crafted multipurpose
private use option were to be registered, such as in the case of
multiple vendor instances within "DHCPv4" [RFC3925], then vendors and
experimenters would each be able to use it for their own purposes as
long as all network participants could easily differentiate between
the entities using the option.
It should also be noted that some references use the term "name "Guidelines for Writing an IANA Considerations Section in RFCs"
space" to refer to namespace. The IETF has been fairly consistent in [RFC2434] {[RFC5226]} describes that values of specific namespaces
using the term "namespace" in documents and this specification may either be registered with the IANA, or not. In most cases, there
follows that precedence. are well defined values for namespaces. However, as the document
explains, not all namespaces require centralized administration. In
that document, it seems to be assumed that private use namespaces
will be domain specific and it will be up to the administrators of
any domain to avoid conflicts. The first example given about private
use namespaces refers to "Dynamic Host Configuration Protocol"
[RFC2131] and presumably "DHCP Options and BOOTP Vendor Extensions"
[RFC2132]. In this the example states that "site-specific options in
DHCP have significance only within a single site". As noted below
this became a problem that was rectified in a later revision of DHCP.
4. Characteristics of Useful Private Use Options Later works identified a need to place a scope on private use
namespaces. The second example of private use namespaces in the IANA
guidelines [RFC2434] {[RFC5226]} is from "STANDARD FOR THE FORMAT OF
ARPA INTERNET TEXT MESSAGES" [RFC0822] {[RFC5322]} which describes X-
headers. There was no effort made to control the namespace and the
use of the namespace was removed when the specification was updated
in 2001 in "Internet Message Format" [RFC2822] {[RFC5322]}.
Private use options can be separated into discreet pieces of 3. Observed Characteristics of Private Use Options
information. The interpretation of each piece of information places
its context. The interpretation of the entirety of these pieces of
information will uniquely describe the context of the information and
the value associated with it. This must provide a single and unique
interpretation of the information to each receiver.
This section summarizes the observed characteristics of private use This section summarizes the observed characteristics of some private
options that are successful and deployed. Following sections will use options that have been developed and deployed. Subsequent
explain how these characteristics apply to specific protocols that sections will explain how these characteristics may have been applied
are commonly used in the Internet. to specific protocols that are used in the Internet.
There seem to be three characteristics of successful private use There appear to be three quantifiable characteristics of private use
options: options:
A Source of Authority o Start of Authority
A Focus of the Namespace
A Value of the Option o Focus of the Namespace
As an example, in SNMP the combination of the Source of Authority and o Value of the Option
the Focus of the Namespace (Focus) represent the OID. The
combination of the Source of Authority, the Focus, and the Value of
the Option (Value) constitute the VarBind.
4.1. Source of Authority 3.1. Start of Authority
A private use option requires a path to an origin that has the A private use option requires a path to an origin that has the
authority to create and maintain the option. As shown above, this authority to create and maintain the option. The goal for a globally
referent should be unique, and not be dependent upon local unique origin is to disambiguate each focus of a namespace to allow
interpretation. freedom of expression by the vendors and experimenters using them.
The name "Source of Authority" comes from the domain name system Therefore the referent has most often been seen to be globally
configuration file which enumerates a "SoA" as the person or entity unique, and not dependent upon local interpretation.
who has ultimate control and decision making powers over the scope of
the domain. Some liberties have been taken with using this name but
the intent is to identify an authoritative source for the namespace.
The PEN (Section 5.1) is sourced by the Internet Assigned Numbers Likely, the first private use option was defined in the "Structure
Authority (IANA). These may be viewed as being similar to domain and Identification of Management Information for TCP/IP-based
names in that they are acquired by individuals, corporations, or Internets" [RFC1155] which was first used in "A Simple Network
other organizations. A notable difference is that when domain names Management Protocol" [RFC1067] {[RFC1157]} (SNMP). The globally
fall into disuse they may be acquired and used by entirely different unique origin in SNMP is the International Standards Organization
people or organizations - as per the conditions required by the [ISO] which is accredited by the United Nations to maintain this
Internet Corporation for Assigned Names and Numbers [ICANN], the structure.
source of the domain names. The structure of the PEN registry does
not place any limits on the time that a PEN will be active or While SNMP used the entire OBJECT IDENTIFIER with the prefix, other
associated with the requester. This is no different from many other protocols only used the Private Enterprise Number [IANApen] (PEN) as
registries maintained by the IANA; they are just a snapshot at the a truncated identification of an origin. This reduced the length of
time of the reservation based on the information required by the IANA the identifier but continued to provide a unique identifier through a
and provided by the applicant. This eternal association of the PEN, globally managed namespace.
The PEN is sourced by the Internet Assigned Numbers Authority (IANA).
PENs may be viewed as being similar to domain names in that they are
acquired by individuals, corporations, or other organizations. A
notable difference is that when domain names fall into disuse they
may be acquired and used by entirely different people or
organizations - as per the conditions set forth by the Internet
Corporation for Assigned Names and Numbers [ICANN], the source of the
domain names. The structure of the PEN registry does not place any
limits on the time that a PEN will be active or associated with the
requester. This is no different from many other registries
maintained by the IANA; they are just a snapshot at the time of the
reservation based on the information required by the IANA and
provided by the applicant. This eternal association of the PEN,
versus the ephemeral association of domain names, has not been shown versus the ephemeral association of domain names, has not been shown
to present any problems. This may, in fact, be a feature as this to present any problems to private use options. This may, in fact,
methodology ensures that these namespaces stay unique for the be a feature as this methodology ensures that these namespaces stay
foreseeable future. unique for the foreseeable future.
Domain names have similar problems as they can be more ephemeral than Some additional information on the PEN may be found in "Enterprise
Number for Documentation Use" [RFC5612].
An alternative to using numerical indicators is to use textual
strings such as names.
Domain names have similar problems as they may be more ephemeral than
eternal. Unlike PENs that become unserviceable when their owning eternal. Unlike PENs that become unserviceable when their owning
organization goes out of business, domain names that fall into disuse organization goes out of business, domain names that fall into disuse
may be acquired and used by entirely different organizations. may be acquired and used by entirely different organization. Similar
Similar to the use of PENs there have not been any problems reported to the use of PENs there have not been any problems reported from
from this. this.
It is vital to note that the usage of the option within the private Uniform Resource Names (URNs) have also been used to convey options.
space is the full responsibility of the private entity. In the They seem to provide flexibility for many different needs. URNs were
example of the PEN, each entity registering a PEN must fully quantify first defined in "Uniform Resource Names (URN) Namespace Definition
the parameters of the use of the option within their purview. Mechanisms" [RFC3406] {[RFC8141]}. "An IETF URN Sub-namespace for
Registered Protocol Parameters" [RFC3553] provides guidance for ways
to use URNs as protocol parameters and how to define a start of
authority.
4.2. Focus of the Namespace 3.2. Focus of the Namespace
Once the source of authority is established, an actual option, or Once the start of authority is established as a globally unique
multiple options, must be specified. This is usually an indicator of source, an actual option, or in some cases multiple options, may be
what value is expected. Within the domain established by the source specified. This has been seen to usually be an indicator of what
of authority, the focus of each value must be unique. In a very value is expected. Within the domain established by the start of
simple example, a private use option may consist of authority, the focus of each value has been seen to be unique.
"PEN"@"focus"="value". The PEN will be unique and will specify the
source of authority. The focus will be unique as long as the source
of authority maintains that uniqueness; e.g., it would be poor form
for a private enterprise to define a focus, then to redefine it at a
later time.
In some cases, multiple focuses and values need to be transmitted. In a very simple example, a private use option may consist of
When the PEN has been used, this has most often been achieved by "SoA"+"focus"="value". The SoA will be unique and will specify the
nesting "type length value" (tlv's) within the field. Each type is start of authority. The focus will be unique as long as the start of
then a focus for the private use option. More recently URIs have authority maintains that uniqueness; e.g., it would be poor form for
been used to point to a source of authority. This allows an a private enterprise to define a focus, then to redefine it at a
organization to organize an abundance of information about their later time.
namespaces.
5. Examples of Successful Private Use Options 4. Examples of Private Use Options
This section contains a review of RFCs that allow the use of private This section contains a review of RFCs that allow the use of private
use options. There seem to be three ways to address the namespace: use options.
via a global origin, via a truncated numerical origin, and via a
namespace based upon a domain name.
5.1. Private Enterprise Number
Rather than using the entire SMI, protocol engineers started using 4.1. SNMP
just the Private Enterprise Number [IANApen]. This reduces the
length of the identifier but continues to provide an identifier
through a globally unique namespace. This section provides examples
of how the PEN has been used to provide private use options.
5.1.1. SNMP As was noted, the globally unique origin in SNMP is the International
Standards Organization [ISO] which is accredited by the United
Nations to maintain this structure. The Internet subtree of
experimental OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.3.,
and the Internet subtree of private enterprise OBJECT IDENTIFIERs
starts with the prefix: 1.3.6.1.4.1. This is followed by a Private
Enterprise Number [IANApen] (PEN) and then the objects defined by
that enterprise.
Likely, the first private use option was defined in the Structure and The structure of management information (SMI) is currently defined as
Identification of Management Information for TCP/IP-based Internets the "Structure of Management Information Version 2 (SMIv2)"
[RFC1155] which was first used in A Simple Network Management [RFC2578]. SMI is a well described tree of OBJECT IDENTIFIERs
Protocol [RFC1067] (SNMP). The structure of management information (OIDs). OIDs have an origin and a path for defined object
(SMI) has been updated and is currently defined as the Structure of identifiers which this document describes as standard options. It
Management Information Version 2 (SMIv2) [RFC2578]. also allows for experimental and vendor specific object identifiers,
which are described as private use options in this document. The
IANA maintains a registry of these Network Management Parameters
SMI is a well described tree of OBJECT IDENTIFIERs (OIDs). OIDs have
an origin and a path for defined object identifiers which this
document describes as standard options. It also allows for
experimental and vendor specific object identifiers, which are
described as private use options in this document. The IANA
maintains a registry of these Network Management Parameters
[IANAsmi]. [IANAsmi].
The Internet subtree of experimental OBJECT IDENTIFIERs starts with
the prefix: 1.3.6.1.3., and the Internet subtree of private
enterprise OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.4.1.
This is followed by a Private Enterprise Number [IANApen] (PEN) and
then the objects defined by that enterprise.
The globally unique origin in SNMP (Section 5.1.1) is the
International Standards Organization [ISO] which is accredited by the
United Nations to maintain this structure. However, the namespace
resolves to the PEN (Section 5.1).
After the vendor identifier (the PEN) in the management information After the vendor identifier (the PEN) in the management information
base (MIB), a vendor can create many different trees to identify base (MIB), a vendor may create many different trees to identify
objects. This may result in a very large number of OBJECT objects. This may result in a very large number of OBJECT
IDENTIFIERs; each of which is an identifier of the namespace IDENTIFIERs, each of which is an identifier, or focus, of a
described in this document. Each of these are uniquely identified by namespace. Each of these are uniquely identified by the vendor and
the vendor and do not require registration with any coordinating do not require registration with any coordinating authority.
authority.
The last part of each OBJECT IDENTIFIER is the value corresponding to The last part of each OBJECT IDENTIFIER is the value corresponding to
the focus, which is known as the varbind. In a GetRequest the server the focus, which is known as the varbind. In a GetRequest the server
fills this field with a "0" and the client responds by replacing the fills this field with a "0" and the client responds by replacing the
"0" with the actual value. Since this field is defined by the "0" with the actual value. Since this field is defined by the
vendor, it may actually be a concatenation of values. In a vendor, it may actually be a concatenation of values. In a
SetRequest transmitted to the receiver, this is the last field. SetRequest transmitted to the receiver, this is the last field.
In this, each OBJECT IDENTIFIER contains a globally unique origin Each OBJECT IDENTIFIER contains a globally unique origin which is
which is ISO, a focus which is the OBJECT IDENTIFIER down to the last ISO, a focus which is the OBJECT IDENTIFIER, and a value which is the
field, and a value which is the last field in the SetRequest, and the last field in the SetRequest. This is also the last field in the
last field in the response to a GetRequest. response to a GetRequest.
Specific codes, known as error-indexes, are used to indicate when a Specific codes, known as error-indexes, are used to indicate when a
request cannot be processed because a device does not understand a request cannot be processed because a device does not understand a
request. request.
While this is very practical for SNMP, fully qualified OIDs are not 4.2. RADIUS
always well suited to be used as an indicator for private use
options. In many other uses, the source of authority has been
truncated to just the PEN (Section 5.1).
5.1.2. RADIUS
The Remote Authentication Dial In User Service (RADIUS) [RFC2058] "The Remote Authentication Dial In User Service (RADIUS)" [RFC2058]
specification documented how to use just the PEN (without the rest of {[RFC2865]} specification documented how to use just the PEN (without
the SMI path to the root) to allow "vendors" to articulate their own the rest of the SMI path to the root) to allow "vendors" to
options. In that document, these are called Vendor-Specific articulate their own options. In that document, these are called
Attributes (VSA). Vendor-Specific Attributes (VSA).
The updated RADIUS document, [RFC2865], gives guidance for using the The updated RADIUS document, [RFC2865], gives guidance for using the
VSA. VSA.
o Servers not equipped to interpret the vendor-specific information o Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported). sent by a client MUST ignore it (although it may be reported).
o Clients which do not receive desired vendor-specific information o Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode. so (and report they are doing so) in a degraded mode.
o The Attribute-Specific field is dependent on the vendor's o The Attribute-Specific field is dependent on the vendor's
definition of that attribute. definition of that attribute.
o It SHOULD be encoded as a sequence of vendor type / vendor length o It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields. / value fields.
o Multiple subattributes MAY be encoded within a single Vendor- o Multiple subattributes MAY be encoded within a single Vendor-
Specific Attribute, although they do not have to be. Specific Attribute, although they do not have to be.
There are many attributes defined in RADIUS [RFC2058] which may be There are many attributes defined in RADIUS [RFC2058] {[RFC2865]}
considered to be standard options. Each of these attributes is which may be considered to be standard options. Each of these
specified within a "type length value" (tlv) container. For this attributes is specified within a "type length value" (TLC) container.
protocol, the attribute "type" is a specific numerical value which For this protocol, the attribute "type" is a specific numerical value
differentiates it from other attributes. As an example, the User- which differentiates it from other attributes.
Name (type 1) and User-Password (type 2) may be considered to be
standard options as they are well defined within the specification.
Type 26 denotes the Vendor Specified Attribute. It is "available to One example of a RADIUS standard option is Type 26, which denotes the
allow vendors to support their own extended Attributes not suitable Vendor Specified Attribute. It is "available to allow vendors to
for general usage". The PEN starts the "value" which should then support their own extended Attributes not suitable for general
include a subsequent nested tlv so the vendor may define and usage". The PEN of the "vendor" starts the "value" which should then
include a subsequent nested TLV so the vendor may define and
enumerate their own options within that field. enumerate their own options within that field.
As noted above, the globally unique origin for RADIUS [RFC2865] is As noted above, the globally unique origin for "RADIUS" [RFC2865] is
the PEN. The remainder of the Attribute field after the PEN is the PEN. The remainder of the Attribute field after the PEN is
deliberately undefined in the specification. It is however suggested deliberately undefined in the specification. It is however suggested
that the field contain embedded tlv's. This is again very practical. that the field contain embedded TLVs. This is again very practical.
Each vendor may then have conflicting "types" (e.g. "1") which would Each vendor may then have conflicting "types" (e.g. "1") which would
be disambiguated by the origin. For example {PEN="N", type="1"} is be disambiguated by the origin. For example [PEN="N", type="1"] is
different from {PEN="M", type="1"}. Since there is nothing to different from [PEN="M", type="1"].
prevent vendors from registering multiple PENs, each vendor may have
a plethora of {type="1"}. However, that is actually not needed since
the focus may be extended by enumerating multiple types. For
example, the vendor attribute may contain {PEN="M", type="1"(value),
type="2"(value), type="3"(value)}.
The values for each type are bounded by the length of the attribute. The values for each type are bounded by the length of the attribute.
Since the entire vendor attribute is defined by the vendor, the The protocols exemplified here tend to be machine-to-machine readable
values may be human readable or not. Since the protocol tends to be therefore it is likely that the values will not be human readable.
machine-to-machine, it is likely that the values will not be human In some cases, it is feasible that a value has no length. In that
readable. In some cases, it is feasible that a value has no length. case, the transmission of the type alone, has been seen to be a
In that case, the transmission of the type alone, would be a signal signal of some sort to the receiver.
of some sort to the receiver.
5.1.3. Mobile IP The original specification of [RFC2058] {[RFC2865]} provided guidance
that invalid packets were to be silently discarded. That was
augmented in [RFC2865] to say that RADIUS clients and servers may
ignore Attributes with an unknown type.
Mobile IP Vendor Specific Extensions [RFC3115] defines two extensions 4.3. Mobile IP
that can be used for making organization specific extensions by
vendors/organizations for their own specific purposes for Mobile IP
[RFC2002]. Mobile IP has been revised several times and is currently
specified in IP Mobility Support for IPv4, Revised [RFC5944].
In that specification, two tlv's have been defined to contain private "Mobile IP Vendor Specific Extensions" [RFC3115] defines two
extensions that can be used for making organization specific
extensions by vendors/organizations for their own specific purposes
for Mobile IP [RFC2002] {[RFC5944]}.
In that specification, two TLVs have been defined to contain private
use options. These are collectively called Vendor/Organization use options. These are collectively called Vendor/Organization
Specific Extensions (VSE). Specific Extensions (VSE).
o When the Critical Vendor/Organization Specific Extension (CVSE) is o When the Critical Vendor/Organization Specific Extension (CVSE) is
encountered but not recognized, the message containing the encountered but not recognized, the message containing the
extension MUST be silently discarded. extension MUST be silently discarded.
o When a Normal Vendor/Organization Specific Extension (NVSE) is o When a Normal Vendor/Organization Specific Extension (NVSE) is
encountered but not recognized, the extension SHOULD be ignored, encountered but not recognized, the extension SHOULD be ignored,
but the rest of the Extensions and message data MUST still be but the rest of the Extensions and message data MUST still be
processed. processed.
Having two VSEs of this nature for private use options is consistent Having two VSEs of this nature for private use options is consistent
with the original Mobile IP specification [RFC2002] which states: with the original Mobile IP specification [RFC2002] {[RFC5944]} which
states:
When an Extension numbered in either of these sets within the When an Extension numbered in either of these sets within the
range 0 through 127 is encountered but not recognized, the message range 0 through 127 is encountered but not recognized, the message
containing that Extension MUST be silently discarded. When an containing that Extension MUST be silently discarded. When an
Extension numbered in the range 128 through 255 is encountered Extension numbered in the range 128 through 255 is encountered
which is not recognized, that particular Extension is ignored, but which is not recognized, that particular Extension is ignored, but
the rest of the Extensions and message data MUST still be the rest of the Extensions and message data MUST still be
processed. processed.
The structure of the origin, type, and value of the CVSEs and NVSEs The structure of the origin, type, and value of the CVSEs and NVSEs
for Mobile IP [RFC3115] may be used in a manner very similar to that for "Mobile IP" [RFC3115] has been seen to be used in a manner very
of RADIUS. The PEN is the origin and types and values may be stacked similar to that of RADIUS. The PEN is the origin and types and
within the field following that. values may be stacked within the field. The values are constrained
by the length of the types or subtypes.
It should be noted that this does not have to be the case.
Specifying CVSEs and NVSEs in various packets can give a vendor
another dimension in processing these private use fields. If a
vendor placed all CVSEs in a single packet, and the receiver did not
understand any one of them, the entire packet must be discarded.
However, if the vendor places individual CVSEs in separate packets,
only CVSEs that are not understood by the receiver will be discarded.
Similarly, a vendor may choose to not stack NVSEs so that a receiver
won't discard the entire cluster of NVSEs if a single one is not
understood.
The values are constrained by the length of the types or subtypes.
5.1.4. DHCP 4.4. DHCP
The introduction to Vendor-Identifying Vendor Options for Dynamic The introduction to "Vendor-Identifying Vendor Options for Dynamic
Host Configuration Protocol version 4 (DHCPv4) [RFC3925] states: Host Configuration Protocol version 4 (DHCPv4)" [RFC3925] states:
The DHCP protocol for IPv4, [RFC2131], defines options that allow The DHCP protocol for IPv4, [RFC2131], defines options that allow
a client to indicate its vendor type (option 60), and the DHCP a client to indicate its vendor type (option 60), and the DHCP
client and server to exchange vendor-specific information (option client and server to exchange vendor-specific information (option
43) [RFC2132]. Although there is no prohibition against passing 43) [RFC2132]. Although there is no prohibition against passing
multiple copies of these options in a single packet, doing so multiple copies of these options in a single packet, doing so
would introduce ambiguity of interpretation, particularly if would introduce ambiguity of interpretation, particularly if
conveying vendor-specific information for multiple vendors. conveying vendor-specific information for multiple vendors.
This meant that Dynamic Host Configuration Protocol [RFC2131] This appears to indicate that "Dynamic Host Configuration Protocol"
specified that there was one instance of the vendor type, and the [RFC2131] specified that there was one instance of the vendor type,
receiver used that namespace to set the scope for the fields in the and the receiver used that namespace to set the scope for the fields
vendor-specific information option. This version of DHCP did not in the vendor-specific information option. This version of DHCP did
allow for multiple origins; only a single origin was permitted and not allow for multiple origins; only a single origin was permitted
the types were to be defined subsequent to that. Evidently this was and the types were to be defined subsequent to that. Evidently this
found to be unworkable when different vendors needed to expand was found to be unworkable when different vendors needed to expand
private use options in the protocol. private use options in the protocol.
This situation was resolved with the publication of Vendor- This situation was resolved with the publication of "Vendor-
Identifying Vendor Options for Dynamic Host Configuration Protocol Identifying Vendor Options for Dynamic Host Configuration Protocol
version 4 (DHCPv4) [RFC3925] which states: version 4 (DHCPv4)" [RFC3925] which cautions:
The Dynamic Host Configuration Protocol (DHCP) options for Vendor The Dynamic Host Configuration Protocol (DHCP) options for Vendor
Class and Vendor-Specific Information can be limiting or ambiguous Class and Vendor-Specific Information can be limiting or ambiguous
when a DHCP client represents multiple vendors. when a DHCP client represents multiple vendors.
That specification ([RFC3925]) then used the PEN [IANApen] to define That specification ([RFC3925]) then used the PEN [IANApen] to define
a unique namespace for private use options in this protocol. Similar a unique namespace for private use options in this protocol. Similar
to other protocols of this era, tlv containers were used. to other protocols of this era, TLV containers were used.
When this protocol was updated to conform to the requirements of When this protocol was updated to conform to the requirements of
IPv6, the PEN was again used as the way to identify the origin of the IPv6, the PEN was again used as the way to identify the origin of the
private use option. private use option.
5.1.5. Syslog [RFC3925] provides guidance on actions to take if servers and clients
do not comprehend a request or a response.
The Syslog Protocol [RFC5424] also uses the PEN to uniquely qualify Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it. Clients that do not receive
desired vendor-specific information SHOULD make an attempt to
operate without it.
4.5. Syslog
"The Syslog Protocol" [RFC5424] also uses the PEN to uniquely qualify
the namespace for a private use option. Standard options do not the namespace for a private use option. Standard options do not
contain the "@" character. Private use options must have the PEN contain the "@" character. Private use options must have the PEN
following the "@" character. This allows a vendor or experimenter to following the "@" character. This allows a vendor or experimenter to
have overlapping namespaces which the PEN will then uniquely have overlapping namespaces which the PEN will then uniquely
identify. For example the standard option of tzKnown may only have identify. For example the standard option of tzKnown may only have
associated values of "0" and "1". However tzKnown@32473 may have any associated values of "0" and "1". However tzKnown@32473 may have any
value assigned to it by the owner of enterprise number 32473. value assigned to it by the owner of enterprise number 32473.
Syslog transport receivers are supposed to accept all correctly Syslog transport receivers are supposed to accept all correctly
formatted Syslog messages. Unlike RADIUS, the receiving Syslog formatted Syslog messages. Unlike RADIUS, the receiving Syslog
application does not have to have immediate knowledge of all variable application does not have to have immediate knowledge of all variable
options to continue operations. If a private use option is not options to continue operations. If a private use option is not
immediately known to the receiving application, it may still store immediately known to the receiving application, it may still store
the message and an Operator or Administrator may look it up at a the message and an Operator or Administrator may look it up at a
later time if they are really interested. later time if they are interested.
The Syslog protocol [RFC5424] uses the PEN as the origin and allows The Syslog protocol [RFC5424] uses the PEN as the origin and allows
for the focus of the private use option to be fully defined by the for the focus of the private use option to be fully defined by the
vendor within the structured data. Specifically, a vendor may define vendor within the structured data. Specifically, a vendor may define
a "type" of private use option by concatenating it with the PEN by a "type" of private use option by concatenating it with the PEN by
using the @ character. Within the bounds of the structured data, using the @ character. Within the bounds of the structured data,
multiple elements may be used that have identifiers and values. multiple elements may be used that have identifiers and values.
5.2. Domain Name Strings 4.6. Secure Shell
An alternative to using numerical indicators is to use textual "The Secure Shell (SSH) Protocol Architecture" [RFC4251] uses
strings. Again, the goal for using these strings is to disambiguate character strings rather than PENs. Similar to Syslog, but actually
the identifiers and allow freedom of expression by the vendors and predating it, standard options must not have the "@" character in
experimenters using them. them. Private use options will have an origin identifier preceding
an "@" character followed by a namespace field. For example, in "The
Secure Shell (SSH) Connection Protocol" [RFC4254] SSH channels may be
opened by specifying a channel type when sending the
SSH_MSG_CHANNEL_OPEN message. Standard options for the channel type
include "session" and "x11". A private use option for a channel type
could be "example_session@example.com".
5.2.1. Secure Shell The rational for choosing the manner of providing a format for
private use options is given in Section 4.2 of [RFC4251].
The Secure Shell (SSH) Protocol Architecture [RFC4251] uses character We have chosen to identify algorithms, methods, formats, and
strings rather than PENs. Similar to Syslog, but actually predating extension protocols with textual names that are of a specific
it, standard options must not have the "@" character in them. format. DNS names are used to create local namespaces where
Private use options will have an origin identifier preceding an "@" experimental or classified extensions can be defined without fear
character followed by a namespace field. For example, in The Secure of conflicts with other implementations.
Shell (SSH) Connection Protocol [RFC4254] SSH channels may be opened
by specifying a channel type when sending the SSH_MSG_CHANNEL_OPEN
message. Standard options for the channel type include "session" and
"x11". A private use option for a channel type could be
"example_session@example.com".
Obviously, these character strings are domain names [RFC1034] The character strings are domain names as defined in [RFC1034] and
[RFC1035]. This is specified in The Secure Shell (SSH) Protocol [RFC1035]. This is specified in "The Secure Shell (SSH) Protocol
Architecture [RFC4251]. Generally, the guidance given is that if a Architecture" [RFC4251].
private use option of this nature is not understood it is to convey
an error code to its peer. Generally, the guidance given is that if a private use option of this
nature is not understood it is to convey an error code to its peer.
In the SSH protocol [RFC4250], the origin is a domain name and the In the SSH protocol [RFC4250], the origin is a domain name and the
focus of the option is dependent upon context. For example, focus of the option is dependent upon context. For example,
ourcipher-cbc@example.com can only be used when negotiating ciphers, ourcipher-cbc@example.com can only be used when negotiating ciphers,
while example_session@example.com can only be used when negotiating while example_session@example.com can only be used when negotiating
channel types, per the examples in [RFC4250]. channel types, per the examples in [RFC4250].
5.3. URN-based Namespaces 4.7. YANG and NETCONF
Uniform Resource Names (URNs) have also been used to convey options.
They are very flexible
(Need to add a lot here.) Uniform Resource Names (URN) Namespace
Definition Mechanisms [RFC3406] An IETF URN Sub-namespace for
Registered Protocol Parameters [RFC3555] The IETF XML Registry
[RFC3688] Extensible Provisioning Protocol (EPP) [RFC5730] Extensible
Provisioning Protocol (EPP) Host Mapping [RFC5732] Namespaces in XML
1.0 (Third Edition) [W3C.REC-xml-names-20091208]
5.3.1. YANG and NETCONF
YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF) [RFC6020] and Network Configuration Protocol
(NETCONF) [RFC6241] use URIs to indicate private use namespaces. The
following is given as an example of a YANG and NETCONF configuration.
module my-config {
namespace "http://example.com/schema/config";
prefix "co";
container system { ... }
container routing { ... }
}
That example could be encoded in NETCONF as the following. One example of a protocol utilizing URNs is "Network Configuration
Protocol (NETCONF)" [RFC6241]. NETCONF may utilize "YANG - A Data
Modeling Language for the Network Configuration Protocol (NETCONF)"
[RFC6020] as a means to describe and convey options.
<rpc message-id="101" "YANG - A Data Modeling Language for the Network Configuration
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" Protocol (NETCONF)" [RFC6020] and "Network Configuration Protocol
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> (NETCONF)" [RFC6241] use URIs to indicate private use namespaces.
<edit-config>
<target>
<running/>
</target>
<config>This eternal association
<system xmlns="http://example.com/schema/config">
<!-- system data here -->
</system>
<routing xmlns="http://example.com/schema/config">
<!-- routing data here -->
</routing>
</config>
</edit-config>
</rpc>
Section 8.3 of YANG [RFC6020] describes the parsing of the YANG Section 8.3 of YANG [RFC6020] describes the parsing of the YANG
payload. It contains a good deal of information about how to process payload. It contains a good deal of information about how to process
elements or values that are not recognized. elements or values that are not recognized.
Similarly, NETCONF [RFC6241] contains much information about Similarly, NETCONF [RFC6241] contains much information about
processing requests that cannot be completed because elements or processing requests that cannot be completed because elements or
values are not recognized. values are not recognized.
Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate
skipping to change at page 16, line 4 skipping to change at page 13, line 15
Section 8.3 of YANG [RFC6020] describes the parsing of the YANG Section 8.3 of YANG [RFC6020] describes the parsing of the YANG
payload. It contains a good deal of information about how to process payload. It contains a good deal of information about how to process
elements or values that are not recognized. elements or values that are not recognized.
Similarly, NETCONF [RFC6241] contains much information about Similarly, NETCONF [RFC6241] contains much information about
processing requests that cannot be completed because elements or processing requests that cannot be completed because elements or
values are not recognized. values are not recognized.
Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate Both YANG [RFC6020] and NETCONF [RFC6241] use URIs to enumerate
private use options of a device. The use of this comes from XPATH private use options of a device. The use of this comes from XPATH
[W3C.REC-xpath-19991116]. [W3C.REC-xpath-19991116].
In both of these, the source of authority is the domain name in the In both of these, the start of authority is the domain name in the
URI and the origin is the full URI path. Many private use options URI and the origin is the full URI path. Many private use options
may be described within YANG. From that, each private use option may may be described within YANG. From that, each private use option may
be populated in NETCONF. be populated in NETCONF.
The following is used to demonstrate this. First the YANG module is 4.8. Extensible Provisioning Protocol
shown, then a subset of the NETCONF is shown.
YANG module:
// Contents of "acme-system.yang"
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-06-09 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
list user { The "Extensible Provisioning Protocol (EPP)" [RFC5730] is another
key "name"; example of a protocol that utilizes URN namespaces. From the
leaf name { Protocol Description section 2:
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}
NETCONF exchange: EPP uses XML namespaces to provide an extensible object management
framework and to identify schemas required for XML instance
parsing and validation. These namespaces and schema definitions
are used to identify both the base protocol schema and the schemas
for managed objects.
<system> The specification provides clear guidance and an example on how to
<login> extend the base protocol and how to map new objects through the use
<message>Good morning</message> of separate documents. However, commands and responses may be
</login> extended through the use of an <extension> element. In this
</system> protocol, and the extensions, the start of authority is the domain
name in the URI and the focus is the full URI path.
In this example, YANG describes the source of authority and focus for Guidance has been provided about incomplete understanding. First, a
the login message, and the NETCONF exchange populates that specific section is provided on responses for received messages that are not
value. understandable, are beyond boundaries, or are not in compliance with
policy. Additionally, guidance is given about incomplete
understanding of a response:
As noted above, both of these specifications have good descriptions Command success or failure MUST NOT be assumed if no response is
of actions to take if a namespace is not recognized. returned or if a returned response is malformed. Protocol
idempotency ensures the safety of retrying a command in cases of
response-delivery failure.
6. Issues to Consider The associated RFCs of "Extensible Provisioning Protocol (EPP) Domain
Name Mapping" [RFC5731] and "Extensible Provisioning Protocol (EPP)
Host Mapping" [RFC5732] provide a mechanism to temporally bind
options.
This document is not an encouragement or recommendation to define 5. Observations
private use fields in IETF protocols. Rather, since private use
options are useful to the community and seem to be gaining
popularity, this document is an attempt to document the ways in which
they have been successful so others may benefit.
Private use options are a way to allow vendors, network operators, Private use options are a way to allow vendors, network operators,
and experimenters to convey dynamic information without going through and experimenters to convey dynamic information without going through
a rigorous process to register each variable. There is no "one size any process to register each variable. However, there is no one size
fits all" mechanism. The use of a very specific and fixed format fits all. The use of a very specific and fixed format works for
works very well for RADIUS which requires speed in processing. On RADIUS which requires speed in processing. On the other hand, the
the other hand, the open nature of the private use options in Syslog open nature of the private use options in Syslog are appropriate for
are appropriate for that protocol where event messages need not be that protocol where event messages need not be fully parsed at the
fully parsed at the time of reception. time of reception.
There seem to be four essential features to using a private use As with all good things, the use of private use options comes with a
option. cost. Adding any extra fields to a protocol will require additional
processing for both the sender and the receiver. Also, larger
packets will take up more bandwidth in transmission. In another
aspect, the code needed to deal with private use options may be
considered wasteful if it is not used.
o One requirement is to have a definable way for the community to There appear to be five quantifiable features that have been
documented in using a private use option.
o One feature is to have a definable way for the community to
ascertain the nature of all private use options. For example, ascertain the nature of all private use options. For example,
several vendors have published their RADIUS VSAs on web pages several vendors have published their RADIUS VSAs on web pages,
which are easy to find. From that, anyone creating a new RADIUS which are easy to find. From that, anyone creating a new RADIUS
server would have access to, and be able to incorporate the server would have access to, and be able to incorporate the
information available. information available.
o Instructions are needed on how to deal with private use options o Instructions have frequently been provided on how to deal with
that are not understood by a receiver. In some cases, a receiver incomplete understanding; where private use options are not
may not need to understand the options immediately upon receipt as understood by a receiver. Within the example protocol
in the case of Syslog. In other cases, the options are specifications given in this document, some behavior has usually
immediately used and instructions must be clear on what to do if been established about what to do if the receiver does not
the receiver cannot process them. It appears that Mobile IP has understand a namespace. Some protocols have defined that a
the best thought-through instructions on this. receiver will silently discard packets that contain private use
options they do not understand. Other protocols have defined that
o Private use options must be extensible in a clearly designed way. they will only discard the private use option rather than the
RADIUS suggests that the string containing the option be another entire packet. On the other hand some other protocols have no
tlv. This allows a vendor to define multiple private use options need for the receiver to have any understanding of any private use
within their own namespace field. These are becoming known as options when it receives any.
subattributes. This appears to be working in practice and it may
be assumed that this has become a de facto rule for RADIUS.
o In most cases, a unique option (both standard and private use) o The values of private use options have frequently followed the
will only be used once within the context of an exchange. RADIUS same guidance given for standard options in their respective
and DHCP either state or strongly imply this. However, while it specifications. In most of the examples given, the value of each
is not explicitly discussed, there is nothing to prevent this private use option has been well defined and bounded. Most have
within Syslog. Some guidance should be given about this in been defined to be extensible so as to accomodate future
describing private use options in protocols. requirements.
Clear documentation in full and open standards is needed to achieve o Private use options may be extensible in a clearly designed way.
uniformity and interoperability in these features. Obviously RADIUS suggests that the string containing the option be another
implementers will need to adhere closely to these standards for TLV. This allows a vendor to define multiple private use options
complete interoperability. within their own namespace field. These are known as
subattributes.
Finally, the usage of any private use values on the wire before any o In some cases, a unique option may only be used once within the
namespace is properly reserved with the IANA is entirely inadvisable. context of an exchange. This may define a value of an option once
and will not change that value during the remainder of the
session. RADIUS and DHCP seem to either state this or strongly
imply it. However, while it is not explicitly discussed, it
appears that nothing prevents this within Syslog, and it seems to
be acceptable behavior to resend unique options multiple times
within EPP.
6.1. Value of the Option Clear documentation has been seen to achieve uniformity and
interoperability in these features. Obviously implementers will need
to adhere closely to these standards for complete interoperability.
The value of each private use option must be well defined and 6. Authoritative Guidance
bounded. It is advisable that it be extensible to accomodate future
requirements.
Generally speaking, values of private use options should follow the This document is not an encouragement or recommendation to define
same guidance given for standard options. private use fields in IETF protocols. Rather, since private use
options are being used by the community, this document is an attempt
to document the ways in which they have been used.
6.2. Guidance on Incomplete Understanding However, "Design Considerations for Protocol Extensions" [RFC6709] is
intended to provide guidance on designing protocol extensions. It
has several examples and pointers to other material that will aid in
the development of protocol extensions.
Within the protocol, an understanding needs to be established between "Procedures for Protocol Extensions and Variations" [RFC4775] is a
the transmitter and receiver about what to do if the receiver does companion document to [RFC6709] and provides the procedures for
not understand a namespace. Some protocols have defined that a review and standardization for extensions to be added to protocols.
receiver will silently discard packets that contain private use
options they do not understand. Other protocols have defined that
they will only discard the private use option rather than the entire
packet. While other protocols have no need for the receiver to have
any understanding of any private use options when it receives them.
Each of these behaviors is represented in the examples in this
document.
Regardless of whether or not this understanding is established, the Finally, the usage of any private use values on the wire before any
receiver of any protocol must have a defined path of action to follow namespace is properly reserved with the IANA is entirely inadvisable.
when receiving anything that it may not understand.
7. Authors Notes 7. Authors Notes
This section will be removed prior to publication. This section will be removed prior to publication.
This is version -11. The day job is keeping me busy. But I'm This is version -12. I finally got some time to work on this.
getting close to addressing my procrastination issues. ..just you
wait and see. A recommendation has been made to update RFC5226 with ID
draft-leiba-cotton-iana-5225bis. If that becomes an RFC while this
document is pending, I'll do that.
8. Security Considerations 8. Security Considerations
This document reviews ways that options are being used in various This document reviews ways that options are being used in various
protocols. As such, there are no security considerations inherent in protocols. As such, there are no security considerations inherent in
this document. this document.
Readers and implementers should be aware of the context of Readers and implementers should be aware of the context of
implementing options in their own protocols. implementing options in protocols they are using or that are being
developed.
9. IANA Considerations 9. IANA Considerations
This document does not propose a standard and does not require the This document does not propose a standard and does not require the
IANA to do anything. IANA to do anything.
10. Acknowledgments 10. Acknowledgments
The idea for documenting this came from questions asked in the SIP- The idea for documenting this came from questions asked in the SIP-
CLF Working Group and the author is grateful for the discussion CLF Working Group and the author is grateful for the discussion
skipping to change at page 20, line 14 skipping to change at page 16, line 41
The following people have contributed to this document. Listing The following people have contributed to this document. Listing
their names here does not mean that they agree with or endorse the their names here does not mean that they agree with or endorse the
document, but that they have contributed to its substance. document, but that they have contributed to its substance.
David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen David Harrington, Dan Romascanu, Bert Wijnen, Ralph Droms, Juergen
Schoenwalder, Nevil Brownlee, Klaas Wierenga, and Brian Carpenter. Schoenwalder, Nevil Brownlee, Klaas Wierenga, and Brian Carpenter.
11. References 11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten,
"Procedures for Protocol Extensions and Variations",
BCP 125, RFC 4775, DOI 10.17487/RFC4775, December 2006,
<http://www.rfc-editor.org/info/rfc4775>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<http://www.rfc-editor.org/info/rfc6709>.
11.2. Informative References
[IANAtcp] Internet Assigned Numbers Authority, "IANA Transmission [IANAtcp] Internet Assigned Numbers Authority, "IANA Transmission
Control Protocol (TCP) Parameters, TCP Option Kind Control Protocol (TCP) Parameters, TCP Option Kind
Numbers", 2011, <http://www.iana.org/assignments/ Numbers", 2011, <http://www.iana.org/assignments/
tcp-parameters/tcp-parameters.txt>. tcp-parameters/tcp-parameters.txt>.
[IANAftp] Internet Assigned Numbers Authority, "IANA FTP Commands
and Extensions", 2010, <http://www.iana.org/assignments/
ftp-commands-extensions/ftp-commands-extensions.txt>.
[IANAslg] Internet Assigned Numbers Authority, "IANA syslog
Parameter", 2010,
<http://www.iana.org/assignments/syslog-parameters>.
[IANAsmi] Internet Assigned Numbers Authority, "Network Management [IANAsmi] Internet Assigned Numbers Authority, "Network Management
Parameters", 2011, Parameters", 2011,
<http://www.iana.org/assignments/smi-numbers>. <http://www.iana.org/assignments/smi-numbers>.
[IANApen] Internet Assigned Numbers Authority, "IANA PRIVATE [IANApen] Internet Assigned Numbers Authority, "IANA PRIVATE
ENTERPRISE NUMBERS", 2011, ENTERPRISE NUMBERS", 2011,
<http://www.iana.org/assignments/enterprise-numbers>. <http://www.iana.org/assignments/enterprise-numbers>.
[wpProt] Wikipedia - the Free Dictionary, "Wikipedia entry for
communication protocol", 2011,
<http://en.wikipedia.org/wiki/Communications_protocol>.
[ISO] International Standards Organization, "International [ISO] International Standards Organization, "International
Standards Organization", 2011, <http://www.iso.org>. Standards Organization", 2011, <http://www.iso.org>.
[ICANN] Internet Corporation for Assigned Names and Numbers, [ICANN] Internet Corporation for Assigned Names and Numbers,
"Internet Corporation for Assigned Names and Numbers", "Internet Corporation for Assigned Names and Numbers",
2011, <http://www.icann.org>. 2011, <http://www.icann.org>.
[RFC0761] Postel, J., "DoD standard Transmission Control Protocol", [RFC0761] Postel, J., "DoD standard Transmission Control Protocol",
RFC 761, January 1980. RFC 761, January 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
September 1981. RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, May 1983. RFC 868, May 1983.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin, [RFC1067] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", RFC 1067, "Simple Network Management Protocol", RFC 1067,
August 1988. August 1988.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets", of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990. STD 16, RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990.
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002,
October 1996. October 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens,
skipping to change at page 21, line 49 skipping to change at page 18, line 39
RFC 2058, January 1997. RFC 2058, January 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
DOI 10.17487/RFC2822, April 2001,
<http://www.rfc-editor.org/info/rfc2822>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/
Organization-Specific Extensions", RFC 3115, April 2001. Organization-Specific Extensions", RFC 3115, April 2001.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition "Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002. Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
Payload Formats", RFC 3555, July 2003. IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553,
June 2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
January 2004. Considered Useful", BCP 82, RFC 3692, DOI 10.17487/
RFC3692, January 2004,
<http://www.rfc-editor.org/info/rfc3692>.
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
Dynamic Host Configuration Protocol version 4 (DHCPv4)", Dynamic Host Configuration Protocol version 4 (DHCPv4)",
RFC 3925, October 2004. RFC 3925, October 2004.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006. Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. Protocol Architecture", RFC 4251, January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006. Connection Protocol", RFC 4254, January 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, August 2009.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009. STD 69, RFC 5730, August 2009.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/
RFC5731, August 2009,
<http://www.rfc-editor.org/info/rfc5731>.
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, August 2009. Host Mapping", STD 69, RFC 5732, August 2009.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010. RFC 5944, November 2010.
[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. [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.
[RFC7805] Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated
TCP Extensions and TCP-Related Documents to Historic or
Informational Status", RFC 7805, DOI 10.17487/RFC7805,
April 2016, <http://www.rfc-editor.org/info/rfc7805>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<http://www.rfc-editor.org/info/rfc8141>.
[W3C.REC-xpath-19991116] [W3C.REC-xpath-19991116]
Clark, J. and S. DeRose, "XML Path Language (XPath) Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3C.REC-xml-names-20091208]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
Author's Address Author's Address
Chris Lonvick Chris Lonvick
1307 Kent Oak Dr. 1307 Kent Oak Dr.
Houston, Texas 77077 Houston, Texas 77077
US US
Email: lonvick.ietf@gmail.com Email: lonvick.ietf@gmail.com
 End of changes. 124 change blocks. 
611 lines changed or deleted 487 lines changed or added

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