[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 5665

NFSv4                                                          M. Eisler
Internet-Draft                                                    NetApp
Updates: 1833 (if approved)                              August 19, 2008
Intended status: Standards Track
Expires: February 20, 2009


   IANA Considerations for RPC Net Identifiers and Universal Address
                                Formats
                   draft-ietf-nfsv4-rpc-netid-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 20, 2009.

Abstract

   This Internet-Draft lists IANA Considerations for RPC Network
   Identifiers (netids) and RPC Universal Network Addresses (uaddrs).
   This Internet-Draft updates, but does not replace, RFC1833.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].




Eisler                  Expires February 20, 2009               [Page 1]

Internet-Draft                 RPC Netids                    August 2008


Table of Contents

   1.  Introduction and Motivation  . . . . . . . . . . . . . . . . .  3
   2.  Security Considerations  . . . . . . . . . . . . . . . . . . .  3
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  IANA Considerations for Netids . . . . . . . . . . . . . .  3
       3.1.1.  Initial Registry . . . . . . . . . . . . . . . . . . .  5
       3.1.2.  Updating Registrations . . . . . . . . . . . . . . . .  7
     3.2.  IANA Considerations for Uaddr Formats  . . . . . . . . . .  7
       3.2.1.  Initial Registry . . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Updating Registrations . . . . . . . . . . . . . . . .  8
       3.2.3.  Uaddr Formats  . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Cross Referencing Between the Netid and Format Registry  . 10
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     4.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  RFC Editor Notes  . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13
































Eisler                  Expires February 20, 2009               [Page 2]

Internet-Draft                 RPC Netids                    August 2008


1.  Introduction and Motivation

   The concepts of an RPC [4] Network Identifier (netid) and an RPC
   Universal Address (uaddr) were introduced in [2] for distinguishing
   network addresses of multiple protocols and representing those
   addresses in a canonical form. [2] states that a netid ``is defined
   by a system administrator based on local conventions, and cannot be
   depended on to have the same value on every system.''  (The netid is
   contained in the field r_netid of the data type rpcb_entry, and the
   uaddr is contained in the field r_addr of the same data type, where
   rpcb_entry is defined in [2].)  Since the publication of [2], it has
   been found to be necessary that protocols like [5] and [6] depend on
   consistent values of netids and representations of uaddrs.  Current
   practices tend to ensure this consistency.  Thus, this document
   identifies the considerations for IANA to establish registries of
   netids and uaddr formats for RPC and specifies the initial content of
   the two registries.


2.  Security Considerations

   See section 9 of [7].


3.  IANA Considerations

   This section uses terms that are defined in [7].

3.1.  IANA Considerations for Netids

   IANA will create a registry called "ONC RPC Netids".  The remainder
   of this section describes the registry.

   All assignments to the ONC RPC Netids registry are made on one of two
   bases:

   o  First Come First Served basis per section 4.1 of [7].

   o  Standards Action per section 4.1 of [7].

   Netids can be up to 2^32 - 1 octets in length.  However, to ensure
   that practical values for Standards Track protocols are not
   exhausted, the values of netids one to eight octets long should be
   used for netids assigned on the Standards Action basis.  Assignments
   made on a First Come First Served basis should be assigned netids of
   length 9 to 128 octets long.  All netids, regardless of length, that
   start with the prefixes "STDS" or "FCFS" are Reserved, in order to
   extend the name space of either basis.  In addition, to give IESG the



Eisler                  Expires February 20, 2009               [Page 3]

Internet-Draft                 RPC Netids                    August 2008


   flexibility in the future to permit Private and Experimental Uses,
   all netids with the prefixes "PRIV" or "EXPE" are Reserved.  The zero
   length netid is Reserved.  Some exceptions are listed in Table 2.  A
   recommended convention for netids corresponding to transports that
   work over the IPv6 protocol is to have "6" as the last character in
   the netid's name.

   Since netids are not constructed in an explicit hierarchical manner,
   this document does not provide for Hierarchical Allocation of netids.
   Nonetheless, the octet "." in a netid string is Reserved for future
   possible provision of Hierarchical Allocation.

   The registry of netids is a list of assignments, each containing five
   fields for each assignment.

   1.  A US-ASCII string name that is the actual netid.  This name MUST
       NOT conflict with any other netid.  This string name can be zero
       to 128 octets long.

   2.  A constant name that can be used for software programs that wish
       to use the transport protocol associated with protocol.  The name
       of the constant typically has the prefix: 'NC_', and a suffix
       equal to the upper case version of the netid.  This constant name
       should be a constant that is valid in the 'C' programming
       language.  This constant name MUST NOT conflict with any other
       netid constant name.  Constant names with the prefix "NC_STDS",
       "NC_FCFS", "NC_PRIV", or "NC_EXPE" are reserved.  Constant names
       with a prefix of "NC_" and a total length of 11 characters or
       less should be for assignments made on the Standards Action
       basis.  The constant name can be 1 to 131 octets long.

   3.  A description and/or a reference to a description of the how the
       netid will be used.  For assignments made on a First Come First
       Served basis the description should include, if applicable, a
       reference to the transport and network protocols corresponding to
       the netid.  For assignments made on a Standards Action basis, the
       description field must include the RFC numbers of the protocol
       associated with the netid, including if applicable, RFC numbers
       of the transport and network protocols.  This field can be up to
       1024 octets.  If more space is required, an RFC should be
       published.

   4.  A point of contact of the registrant.  The point of contact can
       consume up to 256 octets (or more if IANA permits).  For
       assignments made on a First Come First Served basis,

       *  the point of contact should include an email address.




Eisler                  Expires February 20, 2009               [Page 4]

Internet-Draft                 RPC Netids                    August 2008


       *  subject to authorization by a Designated Expert, the point of
          contact may be omitted for extraordinary situations, such as
          the registration of a commonly used netid where the owner is
          unknown.

       For assignments made on a Standards Action basis the point of
       contact is always IESG.

   5.  A numerical value, used to cross reference the netid assignment
       with an assignment in the uaddr format registry (see
       Section 3.2).  If the registrant is registering a netid that
       cross references an existing assignment in the uaddr format
       registry, then the registrant provides the actual value of the
       cross reference along with the date the registrant retrieved the
       cross reference value from the uaddr format registry.  If the
       registrant is registering both a new netid and new uaddr format,
       then the registrant provides a value of TBD1 in the netid
       request, and uses TBD1 in the the uaddr format request.  IANA
       will then substitute TBD1 for cross reference number IANA
       allocates.

3.1.1.  Initial Registry

   The initial list of netids is broken into those assigned on a First
   Come First Serve basis in Table 1 and those assigned on a Standards
   Action basis in Table 2.  These lists will change when IANA registers
   additional netids as needed, and the authoritative list of registered
   netids will always live with IANA.

   +-------------+--------------+---------------------------+-----+----+
   | Netid       | Constant     | Description and/or        | PoC | CR |
   |             | Name         | Reference                 |     |    |
   +-------------+--------------+---------------------------+-----+----+
   | "-"         | NC_NOPROTO   | RFC1833 [2],              |     | 1  |
   |             |              | Section 3.2.3.2 of        |     |    |
   |             |              | RFCTBD2                   |     |    |
   | "ticlts"    | NC_TICLTS    | The loop back             |     | 0  |
   |             |              | connectionless transport  |     |    |
   |             |              | used in System V Release  |     |    |
   |             |              | 4 and other operating     |     |    |
   |             |              | systems.  Although this   |     |    |
   |             |              | assignment is made on a   |     |    |
   |             |              | First Come First Served   |     |    |
   |             |              | basis and is fewer than 9 |     |    |
   |             |              | characters long, the      |     |    |
   |             |              | exception is authorized.  |     |    |
   |             |              | See [8].                  |     |    |




Eisler                  Expires February 20, 2009               [Page 5]

Internet-Draft                 RPC Netids                    August 2008


   | "ticots"    | NC_TICOTS    | The loop back             |     | 0  |
   |             |              | connection-oriented       |     |    |
   |             |              | transport used in System  |     |    |
   |             |              | V Release 4 and other     |     |    |
   |             |              | operating systems.  See   |     |    |
   |             |              | [8].  Although this       |     |    |
   |             |              | assignment is made on a   |     |    |
   |             |              | First Come First Served   |     |    |
   |             |              | basis and is fewer than 9 |     |    |
   |             |              | characters long, the      |     |    |
   |             |              | exception is authorized.  |     |    |
   | "ticotsord" | NC_TICOTSORD | The loop back             |     | 0  |
   |             |              | connection-oriented with  |     |    |
   |             |              | orderly-release transport |     |    |
   |             |              | used in System V Release  |     |    |
   |             |              | 4 and other operating     |     |    |
   |             |              | systems.  See [8].        |     |    |
   +-------------+--------------+---------------------------+-----+----+

         Table 1: Initial First Come First Serve Netid Assignments

   PoC: Point of Contact.  CR: Cross Reference to the Uaddr Format
   Registry.

   +---------+--------------+------------------------------+------+----+
   | Netid   | Constant     | RFC(s) and Description (if   | PoC  | CR |
   |         | Name         | needed)                      |      |    |
   +---------+--------------+------------------------------+------+----+
   | "dccp"  | NC_DCCP      | RFC4340 [9] RFC0760 [10]     | IESG | 2  |
   | "dccp6" | NC_DCCP6     | RFC4340 [9] RFC2460 [11]     | IESG | 3  |
   | "icmp"  | NC_ICMP      | RFC0777 [12] RFC0760 [10]    | IESG | 4  |
   | "icmp6" | NC_ICMP6     | RFC0777 [12] RFC2460 [11]    | IESG | 4  |
   | "rdma"  | NC_RDMA      | RFCTBD1 [6] RFC0760 [10]     | IESG | 2  |
   | "rdma6" | NC_RDMA6     | RFCTBD1 [6] RFC2460 [11]     | IESG | 3  |
   | "sctp"  | NC_SCTP      | RFC2960 [13] RFC0760 [10]    | IESG | 2  |
   | "sctp6" | NC_SCTP6     | RFC2960 [13] RFC2460 [11]    | IESG | 3  |
   | "tcp"   | NC_TCP       | RFC0675 [14] RFC0760 [10]    | IESG | 2  |
   | "tcp6"  | NC_TCP6      | RFC0675 [14] RFC2460 [11]    | IESG | 3  |
   | "udp"   | NC_UDP       | RFC0768 [15] RFC0760 [10]    | IESG | 2  |
   | "udp6"  | NC_UDP6      | RFC0768 [15] RFC2460 [11]    | IESG | 3  |
   +---------+--------------+------------------------------+------+----+

            Table 2: Initial Standards Action Netid Assignments








Eisler                  Expires February 20, 2009               [Page 6]

Internet-Draft                 RPC Netids                    August 2008


3.1.2.  Updating Registrations

   Per section 5.2 of [7] the registrant always permitted to update a
   registration made on a First Come First Served basis "subject to the
   same constraints and review as with new registrations."  IESG or a
   Designated Expert is permitted to update any registration made on a
   First Come First Served basis, which normally is done when the PoC
   cannot be reached in order to make necessary updates.  Examples where
   an update would be needed include, but are not limited to: the email
   address or other contact information becomes invalid; the reference
   to the corresponding protocol becomes obsolete or unavailable; and
   RFC1833 [2] is updated or replaced in such a way that the scope of
   netids changes, requiring additional fields in the assignment.

   Only IESG, on the advice of a Designated Expert, can update a
   registration made on a Standards Action basis.

3.2.  IANA Considerations for Uaddr Formats

   IANA will create a registry called "ONC RPC Uaddr Format Registry"
   (called the "format registry" for the remainder of this document).
   The remainder of this section describes the registry.

   All assignments to the format registry are made on one of two bases:

   o  First Come First Served basis per section 4.1 of [7].

   o  Standards Action per section 4.1 of [7].

   The registry of formats is a list of assignments, each containing
   four fields for each assignment.

   1.  The basis for the assignment, which can be either FCFS for First
       Come First Served assignments, or STDS for Standards Action
       assignments.

   2.  A description and/or reference to a description of the actual
       uaddr format.  Assignments made on a Standards Action basis
       always have a reference to an RFC.  This field can be up to 1024
       octets.  If more space is required, an RFC should be published.

   3.  For assignments made on a First Come First Served basis, a point
       of contact, including an email address.  The point of contact can
       consume up to 256 octets (or more if IANA permits).  Subject to
       authorization by a Designated Expert, the point of contact may be
       omitted for extraordinary situations, such as the registration of
       a commonly used format where the owner is unknown.  For
       assignments made on a Standards Action basis the point of contact



Eisler                  Expires February 20, 2009               [Page 7]

Internet-Draft                 RPC Netids                    August 2008


       is always IESG.

   4.  A numerical value, used to cross reference the format assignment
       with an assignment in the netid registry.  The registrant
       provides a value of TBD1 for the cross reference filed when
       requesting an assignment.  IANA will assign TBD1 to a real value.

   All requests for assignments to the format registry must undergo
   Expert Review.  All requests for assignments made on a Standards
   Action basis must be approved by IESG.

3.2.1.  Initial Registry

   The initial list of formats is in Table 3.  This lists will change
   when IANA registers additional formats as needed, and the
   authoritative list of registered formats will always live with IANA.

   +-------+-----------------------------------------------+------+----+
   | Basis | Description and/or Reference                  | PoC  | CR |
   +-------+-----------------------------------------------+------+----+
   | FCFS  | System V Release 4 loopback transport uaddr   |      | 0  |
   |       | format.  Section 3.2.3.1 of RFCTBD2           |      |    |
   | FCFS  | Uaddr format for NC_NOPROTO.  Section 3.2.3.2 |      | 1  |
   |       | of RFCTBD2                                    |      |    |
   | STDS  | Uaddr format for IPv4 transports.             | IESG | 2  |
   |       | Section 3.2.3.3 of RFCTBD2                    |      |    |
   | STDS  | Uaddr format for IPv6 transports.             | IESG | 3  |
   |       | Section 3.2.3.4 of RFCTBD2                    |      |    |
   | STDS  | Uaddr formation for ICMP.  Section 3.2.3.5 of | IESG | 4  |
   |       | RFCTBD2                                       |      |    |
   +-------+-----------------------------------------------+------+----+

                    Table 3: Initial Format Assignments

3.2.2.  Updating Registrations

   The registrant always permitted to update a registration made on a
   First Come First Served basis "subject to the same constraints and
   review as with new registrations.", but as with new registrations,
   any requested changes to any field other the point of contact
   requires Expert Review.  IESG or a Designated Expert is permitted to
   update any registration made on a First Come First Served basis,
   which normally is done when the PoC cannot be reached in order to
   make necessary updates.  Examples where an update would be needed
   include, but are not limited to: the email address or other contact
   information becomes invalid; the reference to the format description
   becomes obsolete or unavailable; and RFC1833 [2] is updated or
   replaced in such a way that the scope of uaddr formats changes,



Eisler                  Expires February 20, 2009               [Page 8]

Internet-Draft                 RPC Netids                    August 2008


   requiring additional fields in the assignment.

   Only IESG, on the advice of a Designated Expert, can update a
   registration made on a Standards Action basis.

3.2.3.  Uaddr Formats

3.2.3.1.  Uaddr Format for System V Release 4 Loopback Transports

   Although [2] identifies the uaddr as data type string (hence, limited
   to US-ASCII), implementations of the System V Release 4 loopback
   transports will use an opaque string of octets.  Thus format of a
   loopback transport address is any non-zero length array of octets.

3.2.3.2.  Uaddr Format for Netid "-"

   There is no address format for netid "-".  This netid is apparently
   for internal use for supporting some implementations of [2].

3.2.3.3.  Uaddr Format for Most IPv4 Transports

   Most transport protocols that operate over IPv4 use 16 bit port
   numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
   [15].  The format of the uaddr for the above 16 bit port transports
   (when used over IPv4) is the US-ASCII string:

      h1.h2.h3.h4.p1.p2

   The prefix, "h1.h2.h3.h4", is the standard textual form for
   representing an IPv4 address, which is always four octets long.
   Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
   the first through fourth octets each converted to ASCII-decimal.  The
   suffix, "p1.p2", is a textual form for representing a TCP and UDP
   service port.  Assuming big-endian ordering, p1 and p2 are,
   respectively, the first and second octets each converted to ASCII-
   decimal.  For example, if a host, in big-endian order, has an address
   of 0x0A010307 and there is a service listening on, in big endian
   order, port 0x020F (decimal 527), then the complete uaddr is
   "10.1.3.7.2.15".

3.2.3.4.  Uaddr Format for Most IPv6 Transports

   Most transport protocols that operate over IPv6 use 16 bit port
   numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
   [15].  The format of the uaddr for the above 16 bit port transports
   (when used over IPv6) is the US-ASCII string:





Eisler                  Expires February 20, 2009               [Page 9]

Internet-Draft                 RPC Netids                    August 2008


      x1:x2:x3:x4:x5:x6:x7:x8.p1.p2

   The suffix "p1.p2" is the service port, and is computed the same way
   as with uaddrs for transports over IPv4 (see Section 3.2.3.3).  The
   prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for
   representing an IPv6 address as defined in Section 2.2 of [3].
   Additionally, the two alternative forms specified in Section 2.2 of
   [3] are also acceptable.

3.2.3.5.  Uaddr Format for ICMP over IPv4 and IPv6

   As ICMP is not a true transport, there is no uaddr format for ICMP.
   The netid assignments "icmp" and "icmp6" and their shared uaddr
   "format" are listed to prevent any registrant from allocating the
   netids "icmp" and "icmp6" for a purpose that would likely cause
   confusion.

3.3.  Cross Referencing Between the Netid and Format Registry

   The last field of the netids registry is used to cross reference with
   the last field of the format registry.  IANA is under no obligation
   to maintain same numeric value in cross references when updating each
   registry; i.e.  IANA is free to "re-number" these corresponding
   fields.  However, if IANA does so, both the netid and format
   registries must be updated atomically.


4.  References

4.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

   [2]   Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
         RFC 1833, August 1995.

   [3]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

4.2.  Informative References

   [4]   Srinivasan, R., "RPC: Remote Procedure Call Protocol
         Specification Version 2", RFC 1831, August 1995.

   [5]   Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
         C., Eisler, M., and D. Noveck, "Network File System (NFS)
         version 4 Protocol", RFC 3530, April 2003.



Eisler                  Expires February 20, 2009              [Page 10]

Internet-Draft                 RPC Netids                    August 2008


   [6]   Talpey, T. and B. Callaghan, "Remote Direct Memory Access
         Transport for Remote Procedure Call",
         draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008.

   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

   [8]   American Telephone and Telegraph Company, "UNIX System V,
         Release 4 Programmer's Guide: Networking Interfaces, ISBN
         0139470786", 1990.

   [9]   Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
         Control Protocol (DCCP)", RFC 4340, March 2006.

   [10]  Postel, J., "DoD standard Internet Protocol", RFC 760,
         January 1980.

   [11]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [12]  Postel, J., "Internet Control Message Protocol", RFC 777,
         April 1981.

   [13]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
         Paxson, "Stream Control Transmission Protocol", RFC 2960,
         October 2000.

   [14]  Cerf, V., Dalal, Y., and C. Sunshine, "Specification of
         Internet Transmission Control Program", RFC 675, December 1974.

   [15]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
         August 1980.


Appendix A.  RFC Editor Notes

   [RFC Editor: please remove this section prior to publication.]

   [RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx
   where xxxx is the RFC number assigned to the document referenced in
   [6].]

   [RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy
   where yyyy is the RFC number assigned to this document.]






Eisler                  Expires February 20, 2009              [Page 11]

Internet-Draft                 RPC Netids                    August 2008


Author's Address

   Mike Eisler
   NetApp
   5765 Chase Point Circle
   Colorado Springs, CO  80919
   US

   Phone: +1-719-599-9026
   Email: mike@eisler.com









































Eisler                  Expires February 20, 2009              [Page 12]

Internet-Draft                 RPC Netids                    August 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Eisler                  Expires February 20, 2009              [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/