One document matched: draft-lonvick-private-tax-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" ipr="trust200902" docName="draft-lonvick-private-tax-02.txt">
<front>
<title abbrev='Private Use Fields'>
A Taxonomy on Private Use Fields in Protocols
</title>
<author initials="C.M." surname="Lonvick"
fullname="Chris Lonvick">
<address>
<postal>
<street>213 El Rancho Grande</street>
<city>Kerrville</city><region>Texas</region>
<code>78028</code>
<country>US</country>
</postal>
<email>lonvick.ietf@gmail.com</email>
</address>
</author>
<date month="June" year="2011" />
<keyword>PEN</keyword>
<keyword>Private name space</keyword>
<keyword>Private name space</keyword>
<keyword>Private use</keyword>
<keyword>Private Enterprise Number</keyword>
<keyword>Private Enterprise Code</keyword>
<abstract>
<t>
The fields in protocols that are reserved for private use have been purposefully unregulated.
This document attempts to provide some classifications for the way that private use fields
have been used in protocols developed in the IETF.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Simply put, communications protocols are standardized ways for computing entities to convey information.
Within each communications protocol, there must be standardized pieces of information that will be
communicated, and there may be non-standardized information that can be communicated.
</t><t>
The <xref target="RFC0868">Time Protocol</xref> 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,
<xref target="RFC0761">DoD standard Transmission Control Protocol</xref> does have "options" but they
must be registered through the IANA <xref target="IANAtcp" />, which does not leave any room for
optional information supplied by equipment vendors, network operators, or experimenters. Finally,
<xref target="RFC3925">Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</xref>
does allow for vendor specific options.
</t><t>
If a network operator wanted to add specific information to the <xref target="RFC0868">Time Protocol</xref>,
they could modify the code of the 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.
</t><t>
For the case of TCP <xref target="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 the details, or obtain approval from the IESG to have the IANA add to
the registry <xref target="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 <xref target="RFC3925">DHCPv4</xref> 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.
</t><t>
This document explores the various ways that protocols may allow optional information using fields
designated as "private use" to be included in protocols, without disrupting
the desired harmony of the network.
</t>
</section>
<section anchor="history" title="Origins of the Private Use Name Space">
<t>
<xref target="RFC2432">Guidelines for Writing an IANA Considerations Section in RFCs</xref>
describes that values of specific name spaces may either be registered with the IANA, or not.
In most cases, there are well defined values for name spaces. However, as the document
explains, not all name spaces require centralized administration.
</t><t>
In that document, it seems to be assumed that private use name spaces 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 name spaces refers to <xref target="RFC2131">Dynamic Host Configuration Protocol</xref> and
presumably <xref target="RFC2132">DHCP Options and BOOTP Vendor Extensions</xref>. 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.
</t><t>
Later works identified a need to place a scope on private use name spaces. The second example of private use
name spaces in <xref target="RFC2432" /> is from
<xref target="RFC0822">STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES</xref>
which describes X- headers. Again, there is no effort made to control the name space. 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.
</t>
</section>
<section anchor="words" title="Nomenclature">
<t>
In this document, the following words are defined to prevent ambiguity. Some of these words have not been used in the
referenced works but their meanings can be ascertained.
<list style="symbols"><t>
communications protocol - a formal description of digital message formats and the rules for exchanging those messages
in or between computing systems and in telecommunications <xref target="wpProt" />
</t><t>
protocol frame - a defined container of fields used to convey information in a communications protocol
</t><t>
field - any defined container within a communications protocol frame
</t><t>
standard option - a field in a protocol frame that may only use values that are strictly defined within a specification
</t><t>
private use option - a field in a protocol frame that is reserved for private or local use only name spaces
</t><t>
name space - the set of possible values a field may contain; its actual content may be a name, a number or another kind of value
</t></list></t>
<t>
Examples
<list style="symbols"><t>
communications protocol - <xref target="RFC0959">The File Transfer Protocol</xref> is an example of a communications protocol.
It has well defined fields and standard options. <xref target="RFC5424">The Syslog Protocol</xref> is another example of a
communications protocol. It has well defined fields, standard options, and it also has private use options.
</t><t>
protocol frame - An Internet Protocol packet <xref target="RFC0791" /> is considered to be a protocol frame.
In the case of <xref target="RFC0959">The File Transfer Protocol</xref>, an FTP message from the client to the server within the
<xref target="RFC0791">Internet Protocol</xref> containing an FTP command is a protocol frame. In the case of
<xref target="RFC5424">The Syslog Protocol</xref>, a message from the client to the server within the
<xref target="RFC0791">Internet Protocol</xref> containing a syslog message is also a protocol frame.
</t><t>
field - In the case of <xref target="RFC0959">The File Transfer Protocol</xref>, a command will be contained within a field.
In the case of <xref target="RFC5424">The Syslog Protocol</xref>, the HOSTNAME is a field.
</t><t>
standard option - In the case of <xref target="RFC0959">The File Transfer Protocol</xref>,
an FTP command, such as CDUP and QUIT, is a standard option. The reason that a command is
a standard option is that only the values listed by the IANA in the registry <xref target="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 <xref target="RFC5424">The Syslog Protocol</xref>, an SD-ID may be a standard option.
The example given in Section 7.1.4
of <xref target="RFC5424" /> of
<figure><artwork><![CDATA[
[timeQuality tzKnown="0" isSynced="0"]
]]></artwork></figure>
is a standard option because all of the
fields are listed in the document and in the IANA registry <xref target="IANAslg" />.
</t><t>
private use option - In the case of The Syslog Protocol, an SD-ID may be a private use option. Example 3 given in Section 6.5
contains a private use option.
<figure><artwork><![CDATA[
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
]]></artwork></figure>
Specifically, the SD-ID starting with "[exampleSDID@32473 ..." is not a specifically defined option in the RFC, nor
is it registered in the IANA registry <xref target="IANAslg" />. It is a way for an equipment vendor to insert their specific information
without having to register anything. In this case if the receiver knows the format of that SD-ID then it can
immediately interpret its meaning. However, if it does not know how to interpret that SD-ID, it can still log
the message and an Operator or Administrator can look up its meaning at a later time.
</t><t>
name space - In the same Example 3 from Section 6.5 of <xref target="RFC5424">The Syslog Protocol</xref>,
"exampleSDID@32473" provides the name space
so the context of the rest of the SD-ID may be interpreted. Specifically the Private Enterprise Number
<xref target="IANApen" /> (PEN) is used to associate the option with a private enterprise, and the text before
the "@" identifies the option defined within that private enterprise.
</t>
</list></t>
</section>
<section anchor="ways" title="Examples of Successful Private Use Options">
<t>
This section contains a review of RFCs that allow the use of private use options. There seem to be three ways
to address the name space: via a global origin, via a truncated numerical origin, and via a namespace based upon
the domain name.
</t>
<section anchor="smi" title="SNMP">
<t>
Likely, the first private use option was defined in the
<xref target="RFC1155">Structure and Identification of Management Information for TCP/IP-based Internets</xref>
which was first used in
<xref target="RFC1067">A Simple Network Management Protocol</xref> (SNMP).
The structure of management information (SMI) has been updated and
is currently defined as the
<xref target="RFC2578">Structure of Management Information Version 2 (SMIv2)</xref>.
</t><t>
SMI is a well described tree of OBJECT IDENTIFIERs. It has 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 <xref target="IANAsmi" />.
</t><t>
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 <xref target="IANApen">Private Enterprise Number</xref> (PEN) and then the OBJECT IDENTIFIERs
defined by that enterprise.
</t><t>
While this is very practical and practicable for SNMP, fully qualified SMIs do not lend themselves well for other uses as
a generic private use option.
</t>
</section>
<section anchor="pen" title="Private Enterprise Number">
<t>
Rather than using the entire SMI, protocol engineers started using just the Private Enterprise Number
<xref target="IANApen" />. This reduces the length of the identifier but continues to provide an
identifier through a globally unique name space. This subsection provides examples of how the PEN has
been used to provide private use options.
</t>
<section anchor="radius" title="RADIUS">
<t>
<xref target="RFC2058">The Remote Authentication Dial In User Service (RADIUS)</xref> specification
documented how to use just the PEN (without the rest of the SMI path to the root) to allow
"vendors" to articulate their own options. In that document, these are called Vendor-Specific Attributes (VSA).
</t><t>
The updated RADIUS document, <xref target="RFC2865" />, gives guidance for using the VSA.
<list style="symbols">
<t>
Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported).
</t><t>
Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.
</t><t>
The Attribute-Specific field is dependent on the vendor's definition of that attribute.
</t><t>
It SHOULD be encoded as a sequence of vendor type / vendor length / value fields.
</t><t>
Multiple subattributes MAY be encoded within a single Vendor-Specific Attribute, although they do not have to be.
</t>
</list>
</t><t>
There are many attributes defined in RADIUS <xref target="RFC2058" /> which may be considered to be standard variables.
Each of these attributes are specified within a "type length value" (tlv) container.
For this protocol, the VSA "type" is a specific numerical value which separates it from other attributes.
Type 26 (decimal) denotes a VSA, and the PEN starts the "value" which should then include a subsequent nested
tlv so the vendor may enumerate their own options within the field.
</t>
</section>
<section anchor="mobile" title="Mobile IP">
<t>
<xref target="RFC3115">Mobile IP Vendor Specific Extensions</xref>
defines two extensions that can be used for making organization
specific extensions by vendors/organizations for their own specific
purposes for Mobile IP <xref target="RFC2002" />. Mobile IP has been revised several times and is currently
specified in <xref target="RFC5944">IP Mobility Support for IPv4, Revised</xref>.
</t><t>
In that specification, two tlv's have been defined to contain private use options. These are called
Vendor/Organization Specific Extensions (VSE).
<list style="symbols">
<t>
When the Critical Vendor/Organization Specific Extension (CVSE) is encountered but not recognized,
the message containing the extension MUST be silently discarded.
</t><t>
When a Normal Vendor/Organization Specific Extension (NVSE) is
encountered but not recognized, the extension SHOULD be ignored, but
the rest of the Extensions and message data MUST still be processed.
</t>
</list>
Having two VSEs of this nature for private use options is consistent with the original Mobile IP specification
<xref target="RFC2002" /> which states:
<list><t>
When an Extension numbered in either of these sets within the range 0
through 127 is encountered but not recognized, the message containing
that Extension MUST be silently discarded. When an Extension
numbered in the range 128 through 255 is encountered which is not
recognized, that particular Extension is ignored, but the rest of the
Extensions and message data MUST still be processed.
</t></list>
</t>
</section>
<section anchor="dhcp" title="DHCP">
<t>
The introduction to <xref target="RFC3925">
Vendor-Identifying Vendor Options for
Dynamic Host Configuration Protocol version 4 (DHCPv4)</xref> states:<list><t>
The DHCP protocol for IPv4, <xref target="RFC2131" />, defines options that allow
a client to indicate its vendor type (option 60), and the DHCP client
and server to exchange vendor-specific information (option 43) <xref target="RFC2132" />.
Although there is no prohibition against passing multiple copies of
these options in a single packet, doing so would introduce ambiguity
of interpretation, particularly if conveying vendor-specific
information for multiple vendors.
</t></list></t><t>
This meant that <xref target="RFC2131">Dynamic Host Configuration Protocol</xref>
specified that there was one instance of the vendor type, and the receiver used that name space
to set the scope for the fields in the vendor-specific information option.
</t><t>
This situation was resolved with the publication of <xref target="RFC3925">
Vendor-Identifying Vendor Options for
Dynamic Host Configuration Protocol version 4 (DHCPv4)</xref> which states:<list><t>
The Dynamic Host Configuration Protocol (DHCP) options for Vendor
Class and Vendor-Specific Information can be limiting or ambiguous
when a DHCP client represents multiple vendors.</t></list></t><t>
That specification (<xref target="RFC3925" />) then used the PEN <xref target="IANApen" />
to define a unique name space for private use options in
this protocol. Similar to other protocols of this era, tlv containers were used.
</t>
</section>
<section anchor="syslog" title="Syslog">
<t>
<xref target="RFC5424">The Syslog Protocol</xref> also uses the PEN to
uniquely qualify the name space for a private use option. Standard options do not contain the "@"
character. Private use options must have the PEN following the "@" character. This allows a
vendor or experimenter to have overlapping name spaces which the PEN will then uniquely identify.
For example a standard option is tzKnown which may only have associated values of "0" and "1". However
tzKnown@32473 may have any value assigned to it by the owner of enterprise number 32473.
</t><t>
Syslog transport receivers are supposed to accept all correctly formatted Syslog messages.
Unlike RADIUS, the receiving Syslog application does not have to have immediate knowledge of all variable
options to continue operations. If a private use option is not immediately known to the receiving
application, it may still store the message and an Operator or Administrator may look it up at a
later time if they are really interested.
</t>
</section>
</section>
<section anchor="ssh" title="Character strings">
<t>
<xref target="RFC4251">The Secure Shell (SSH) Protocol Architecture</xref> uses character strings rather
than PENs. Similar to Syslog, but actually predating it, standard options must not have the "@" character
in them. Private use options will have an origin identifier preceding an "@" character followed by a name space
field. For example, in <xref target="RFC4254">The Secure Shell (SSH) Connection Protocol</xref> 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".
</t><t>
Obviously, these character strings are domain names <xref target="RFC1034" /> <xref target="RFC1035" />.
This is specified in <xref target="RFC4251">The Secure Shell (SSH) Protocol Architecture</xref>.
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.
</t>
</section>
</section>
<section anchor="means" title="Characteristics of Useful Private Use Options">
<t>
This section summarizes the observed characteristics
of private use options that are successful and deployed.
</t><t>
There seem to be three characteristics of successful private use options.
</t>
<section anchor="means1" title="Source of Authority">
<t>
A private use option requires a path to an origin that has the authority to
create and maintain the option. As shown above, this referent should be unique, and not be dependent
upon local interpretation.
</t><t>
The <xref target="pen">PEN</xref> is sourced by the Internet Assigned Numbers Authority (IANA).
While there seems to be no reports of problems using PENs, PENs do not seem to be unique.
It appears that some private enterprises have registered multiple PENs, and that there are some private
enterprises whose PENs are no longer serviceable, mostly because they have been acquired by other
companies, or they have gone out of business.
</t><t>
Domain names have similar problems as they can be more ephemeral than eternal. The top level domains
are maintained by the <xref target="ICANN">Internet Corporation for Assigned Names and Numbers</xref>
however the specific names are assigned much more locally. Unlike PENs that become unserviceable
when their owning organization goes out of business, domain names that fall into disuse may be
acquired and used by entirely different organizations. Again however, like the use of PENs there
have not been any problems reported from this.
</t>
</section>
<section anchor="means2" title="Focus of the Name Space">
<t>
Once the source of authority is established, an actual option, or multiple options, must be specified.
This is usually an indicator of what value is expected. Within the domain established by the
source of authority, the focus of each value must be unique. In a very simple example, a private use
option may consist of "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.
</t><t>
In some cases, multiple focuses and values need to be transmitted. When the PEN has been used, this
has most often been achieved by nesting tlv's within the field. Each type is then a focus for the
private use option.
</t><t>
Within the protocol, an understanding needs to be established between the transmitter and receiver
about what to do if the receiver does not understand a focus. Some protocols have defined that a
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. If this understanding is not established in the protocol then some means needs
to be enabled so that the endpoints of the protocol can discuss this and form a resolution to one
of them not understanding a private use option.
</t>
</section>
<section anchor="means3" title="Value of the Option">
<t>
The value of each private use option must be extensible but bounded.
</t><t>
Generally speaking, values of private use options should follow the same guidance given for standard
options.
</t>
</section>
</section>
<section anchor="examples" title="Examples of Characteristics of Useful Private Use Options">
<section anchor="snmp-chars" title="SNMP">
<t>
The globally unique origin in <xref target="smi">SNMP</xref> is the
<xref target="ISO">International Standards Organization</xref>
which is accredited by the United Nations to maintain this structure. However, the
namespace resolves to the <xref target="pen">PEN</xref> which does not seem to be globally unique.
</t><t>
After the vendor identifier (the PEN) in the management information
base (MIB), a vendor can create many different trees to identify objects. This may result in a very large number
of OBJECT IDENTIFIERs; each of which is an identifier of the name space described in this document. Each of these are uniquely
identified by the vendor and do not require registration with any coordinating authority.
</t><t>
The last item in each OBJECT IDENTIFIER is the value corresponding to the focus. In a GetRequest
the server fills this field with a "0" and the client responds by replacing the "0"
with the actual value. In a SetRequest transmitted to the receiver, this is the last field.
</t><t>
In this, each OBJECT IDENTIFIER contains a globally unique origin which is ISO, a focus which is the
OBJECT IDENTIFIER down to the last field, and a value which is the last field in the SetRequest, and
the last field in the response to a GetRequest.
</t>
</section>
<section anchor="radius-chars" title="RADIUS">
<t>
As noted above, the globally unique origin for <xref target="RFC2865">RADIUS</xref> is the PEN.
</t><t>
The remainder of the Attribute field after the PEN is deliberately undefined in the specification. It is however
suggested that the field contain embedded tlv's. This is again very practical and practicable. Each
vendor may then have conflicting "types" (e.g. "1") which would be disambiguated by the origin. For
example {PEN="N", type="1"} is different from {PEN="M", type="1"}. Since there is nothing to 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)}.
</t><t>
The values for each type are bounded by the length of the attribute. Since the entire vendor attribute
is defined by the vendor, the values may be human readable or binary. Since the protocol tends to be
machine-to-machine, it is likely that the values will be binary. It is feasible that the value have no
length. In that case, the transmission of the type alone, would be a signal of some sort to the receiver.
</t>
</section>
<section anchor="mobileip-chars" title="Mobile IP">
<t>
The structure of the origin, type, and value of the CVSEs and NVSEs for
<xref target="RFC3115">Mobile IP</xref> may be used in a manner very similar to that of RADIUS.
The PEN is the origin and types and values may be stacked within the field following that.
</t><t>
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.
</t><t>
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.
</t><t>
The values are constrained by the length of the types or subtypes.
</t><t>
It is not known by the author if this separation of CVSEs into multiple packets, or if the separation
of NVSEs by a single vendor is currently practiced. Any clue from the clueful would be appreciated here.
</t>
</section>
<section anchor="dhcp-chars" title="DHCP">
<t>
The first version of the <xref target="RFC2131">DHCP protocol</xref> did not allow for multiple
origins; only a single origin was permitted and the types were to be defined subsequent to that.
The author of this document does not know the history of this specification but it seems to be
that this was unworkable so the specification was changed to allow for multiple origins. After
that, it becomes very similar to CVSEs and NVSEs described in <xref target="RFC3115">Mobile IP</xref>,
however multiple uses of the PEN are not permitted.
</t>
</section>
<section anchor="syslog-chars" title="Syslog">
<t>
The <xref target="RFC5424">Syslog protocol</xref> uses the PEN as the origin and allows for the focus of the private use option to be
fully defined by the vendor within the structured data. Specifically, a vendor may define a "type" of
private use option by concatenating it with the PEN by using the @ character. Within the bounds of
the structured data, multiple elements may be used that have identifiers and values.
</t>
</section>
<section anchor="ssh-chars" title="Secure Shell">
<t>
Finally, in the <xref target="RFC4250">SSH protocol</xref>, the origin is a domain name and the
focus of the option is dependent upon context.
For example, ourcipher-cbc@example.com can only be used when negotiating ciphers, while example_session@example.com
can only be used when negotiating channel types, per the examples in <xref target="RFC4250" />.
</t>
</section>
</section>
<section anchor="thinkaboutit" title="Issues to Consider">
<t>
Private use options are useful to the community and are gaining popularity. This is a way to allow
vendors, network operators, and experimenters to convey dynamic information without going
through a rigorous process to register each variable.
</t><t>
There is no "one size fits all" mechanism. The use of a very specific and fixed format works very well
for RADIUS which requires speed in processing. On the other hand, the open nature of the private use
options in Syslog are appropriate for that protocol.
</t><t>
There seem to be four essential features to using a private use option. (The author would be grateful if the
community were to validate these and/or offer more or less.)
<list style="symbols">
<t>
One requirement is to have a definable way for the community to ascertain the nature of all private use options.
For example, several vendors have published their RADIUS VSAs on web pages which are easy to find.
From that, anyone creating a new RADIUS server would have access to and would be able to incorporate
the information available.
</t><t>
Instructions are needed on how to deal with private use options that are not understood by a receiver.
In some cases, a receiver may not need to understand the options immediately upon receipt as in the
case of Syslog. In other cases, the options are immediately used and instructions must be clear on
what to do if the receiver cannot process them.
It appears that Mobile IP has the best thought-through instructions on this.
</t><t>
Private use options must be extensible in a clearly designed way. RADIUS suggests that the string containing
the option be another tlv.
This allows a vendor to define multiple private use options within their own namespace field.
These are becoming known as subattributes.
This appears to be working in practice and it may be assumed that this has become
a de facto rule for RADIUS.
</t><t>
In most cases, a subattribute will only be named once within the context of an exchange. RADIUS and DHCP
either state or strongly imply this. However, while it is not explicitly discussed,
there is nothing to prevent this within Syslog. Some guidance should be given about this in describing
private use options in protocols.
</t>
</list>
</t>
</section>
<section anchor="notes" title="Authors Notes">
<t>
This section will be removed prior to publication.
</t><t>
This is version -02. I revised the Issues section.
</t>
</section>
<section anchor="sec" title="Security Considerations">
<t>
This document reviews ways that options are being used in various protocols.
As such, there are no security considerations inherent in this document.
</t><t>
Readers and implementers should be aware of the context of implementing options
in their own protocols.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This document does not propose a standard and does not require the
IANA to do anything.
</t>
</section>
<section anchor="Acks" title="Acknowledgments">
<t>
The idea for documenting this came from questions asked in the SIP-CLF Working Group and the
author is grateful for the discussion around this topic.
</t>
<t>
The following people have contributed to this document. Listing their names here does
not mean that they endorse the document, but that they have contributed to its
substance.
</t>
<t>
David Harrington, Dan Romascanu and Bert Wijnen.
</t>
</section>
</middle>
<back>
<references title="References">
<reference anchor="IANAtcp" target="http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt">
<front>
<title>IANA Transmission Control Protocol (TCP) Parameters, TCP Option Kind Numbers</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt" />
</reference>
<reference anchor="IANAftp" target="http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.txt">
<front>
<title>IANA FTP Commands and Extensions</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2010" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.txt" />
</reference>
<reference anchor="IANAslg" target="http://www.iana.org/assignments/syslog-parameters">
<front>
<title>IANA syslog Parameter</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2010" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/syslog-parameters" />
</reference>
<reference anchor="IANAsmi" target="http://www.iana.org/assignments/smi-numbers">
<front>
<title>Network Management Parameters</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/smi-numbers" />
</reference>
<reference anchor="IANApen" target="http://www.iana.org/assignments/enterprise-numbers">
<front>
<title>IANA PRIVATE ENTERPRISE NUMBERS</title>
<author fullname="Internet Assigned Numbers Authority">
<organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iana.org/assignments/enterprise-numbers" />
</reference>
<reference anchor="wpProt" target="http://en.wikipedia.org/wiki/Communications_protocol">
<front>
<title>Wikipedia entry for communication protocol</title>
<author fullname="Wikipedia - the Free Dictionary">
<organization abbrev="Wikipedia">Wikipedia - the Free Dictionary</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://en.wikipedia.org/wiki/Communications_protocol" />
</reference>
<reference anchor="ISO" target="http://www.iso.org">
<front>
<title>International Standards Organization</title>
<author fullname="ISO">
<organization abbrev="ISO">International Standards Organization</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.iso.org" />
</reference>
<reference anchor="ICANN" target="http://www.icann.org">
<front>
<title>Internet Corporation for Assigned Names and Numbers</title>
<author fullname="ICANN">
<organization abbrev="ICANN">Internet Corporation for Assigned Names and Numbers</organization>
</author>
<date year="2011" />
</front>
<format type="TXT" target="http://www.icann.org" />
</reference>
<?rfc include="reference.RFC.0761" ?>
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0822" ?>
<?rfc include="reference.RFC.0868" ?>
<?rfc include="reference.RFC.0959" ?>
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.1067" ?>
<?rfc include="reference.RFC.1155" ?>
<?rfc include="reference.RFC.2002" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2132" ?>
<?rfc include="reference.RFC.2058" ?>
<?rfc include="reference.RFC.2432" ?>
<?rfc include="reference.RFC.2578" ?>
<?rfc include="reference.RFC.2865" ?>
<?rfc include="reference.RFC.3115" ?>
<?rfc include="reference.RFC.3925" ?>
<?rfc include="reference.RFC.4250" ?>
<?rfc include="reference.RFC.4251" ?>
<?rfc include="reference.RFC.4254" ?>
<?rfc include="reference.RFC.5424" ?>
<?rfc include="reference.RFC.5944" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:36:59 |