Skip to main content

DSL Forum Vendor-Specific RADIUS Attributes
RFC 4679

Document Type RFC - Informational (September 2006) Errata
Authors Glen Zorn , Robert Rennison , Vince Mammoliti , Peter Arberg
Last updated 2020-01-21
RFC stream Independent Submission
Formats
IESG Responsible AD Dan Romascanu
Send notices to (None)
RFC 4679
#x27;d.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      132 (0x84) for Minimum-Data-Rate-Downstream

   Vendor-Length

      6

   Value

      This field contains a 4-byte unsigned integer, indicating the
      subscriber's minimum downstream data rate (as configured by the
      operator).  The rate is coded in bits per second.

3.3.7.  Attainable-Data-Rate-Upstream

   Description

      This Attribute contains the subscriber's attainable upstream data
      rate.  It MAY be included in Accounting-Request packets.

   A summary of the Attainable-Data-Rate-Upstream Attribute format is
   shown below.  The fields are transmitted from left to right.

Mammoliti, et al.            Informational                     [Page 11]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      133 (0x85) for Attainable-Data-Rate-Upstream

   Vendor-Length

      6

   Value

      This field contains a 4-byte unsigned integer, indicating the
      subscriber's actual DSL attainable upstream data rate.  The rate
      is coded in bits per second.

3.3.8.  Attainable-Data-Rate-Downstream

   Description

      This Attribute contains the subscriber's attainable downstream
      data rate.  It MAY be included in Accounting-Request packets.

   A summary of the Attainable-Data-Rate-Downstream Attribute format is
   shown below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      134 (0x86) for Attainable-Data-Rate-Downstream

   Vendor-Length

      6

Mammoliti, et al.            Informational                     [Page 12]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

   Value

      This field contains a 4-byte unsigned integer, indicating the
      subscriber's actual DSL attainable downstream data rate.  The rate
      is coded in bits per second.

3.3.9.  Maximum-Data-Rate-Upstream

   Description

      This Attribute contains the subscriber's maximum upstream data
      rate, as configured by the operator.  It MAY be included in
      Accounting-Request packets.

   A summary of the Maximum-Data-Rate-Upstream Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      135 (0x87) for Maximum-Data-Rate-Upstream

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value of the subscriber's DSL maximum upstream data rate.  The
      rate is coded in bits per second.

3.3.10.  Maximum-Data-Rate-Downstream

   Description

      This Attribute contains the subscriber's maximum downstream data
      rate, as configured by the operator.  It MAY be included in
      Accounting-Request packets.

Mammoliti, et al.            Informational                     [Page 13]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

   A summary of the Maximum-Data-Rate-Downstream Attribute format is
   shown below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      136 (0x88) for Maximum-Data-Rate-Downstream

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value of the subscriber's DSL maximum downstream data rate.  The
      rate is coded in bits per second.

3.3.11.  Minimum-Data-Rate-Upstream-Low-Power

   Description

      This Attribute contains the subscriber's minimum upstream data
      rate in low power state, as configured by the operator.  It MAY be
      included in Accounting-Request packets.

   A summary of the Minimum-Data-Rate-Upstream-Low-Power Attribute
   format is shown below.  The fields are transmitted from left to
   right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      137 (0x89) for Minimum-Data-Rate-Upstream-Low-Power

Mammoliti, et al.            Informational                     [Page 14]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value of the subscriber's DSL minimum upstream data rate when in
      low power state (L1/L2).  The rate is coded in bits per second.

3.3.12.  Minimum-Data-Rate-Downstream-Low-Power

   Description

      This Attribute contains the subscriber's minimum downstream data
      rate in low power state, as configured by the operator.  It MAY be
      included in Accounting-Request packets.

   A summary of the Minimum-Data-Rate-Downstream-Low-Power Attribute
   format is shown below.  The fields are transmitted from left to
   right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      138 (0x8A) for Minimum-Data-Rate-Downstream-Low-Power

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value of the subscriber's DSL minimum downstream data rate.  The
      rate is coded in bits per second.

Mammoliti, et al.            Informational                     [Page 15]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

3.3.13.  Maximum-Interleaving-Delay-Upstream

   Description

      This Attribute contains the subscriber's maximum one-way upstream
      interleaving delay, as configured by the operator.  It MAY be
      included in Accounting-Request packets.

   A summary of the Maximum-Interleaving-Delay-Upstream Attribute format
   is shown below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      139 (0x8B) for Maximum-Interleaving-Delay-Upstream

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value in milliseconds of the subscriber's DSL maximum one-way
      upstream interleaving delay.

3.3.14.  Actual-Interleaving-Delay-Upstream

   Description

      This Attribute contains the subscriber's actual one-way upstream
      interleaving delay.  It MAY be included in Accounting-Request
      packets.

   A summary of the Actual-Interleaving-Delay-Upstream Attribute format
   is shown below.  The fields are transmitted from left to right.

Mammoliti, et al.            Informational                     [Page 16]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      140 (0x8C) for Actual-Interleaving-Delay-Upstream

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value in milliseconds of the subscriber's DSL actual upstream
      interleaving delay.

3.3.15.  Maximum-Interleaving-Delay-Downstream

   Description

      This Attribute contains the subscriber's maximum one-way
      downstream interleaving delay, as configured by the operator.  It
      MAY be included in Accounting-Request packets.

   A summary of the Maximum-Interleaving-Delay-Downstream Attribute
   format is shown below.  The fields are transmitted from left to
   right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      141 (0x8D) for Maximum-Interleaving-Delay-Downstream

Mammoliti, et al.            Informational                     [Page 17]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value in milliseconds of the subscriber's DSL maximum one-way
      downstream interleaving delay.

3.3.16.  Actual-Interleaving-Delay-Downstream

   Description

      This Attribute contains the subscriber's actual one-way downstream
      interleaving delay.  It MAY be included in Accounting-Request
      packets.

   A summary of the Actual-Interleaving-Delay-Downstream Attribute
   format is shown below.  The fields are transmitted from left to
   right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      142 (0x8E) for Actual-Interleaving-Delay-Downstream

   Vendor-Length

      6

   Value

      This field is a 4-byte unsigned integer, indicating the numeric
      value in milliseconds of the subscriber's DSL actual downstream
      interleaving delay.

Mammoliti, et al.            Informational                     [Page 18]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

3.3.17.  Access-Loop-Encapsulation

   Description

      This Attribute describes the encapsulation(s) used by the
      subscriber on the DSL access loop.  It MAY be present in both
      Access-Request and Accounting-Request packets.

   A summary of the Access-Loop-Encapsulation Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |                    Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Value (cont'd) |
   +-+-+-+-+-+-+-+-+

   Vendor-Type

      144 (0x90) for Access-Loop-Encapsulation

   Vendor-Length

      5

   Value

      This field is a string 3 bytes in length, logically divided into
      three 1-byte sub-fields as shown in the following diagram:

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Data Link   |    Encaps 1   |    Encaps 2   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Valid values for the sub-fields are as follows:

      Data Link

         0x01 AAL5
         0x02 Ethernet

Mammoliti, et al.            Informational                     [Page 19]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

      Encaps 1

         0x00 NA - Not Available
         0x01 Untagged Ethernet
         0x02 Single-Tagged Ethernet

      Encaps 2

         0x00 NA - Not Available
         0x01 PPPoA LLC
         0x02 PPPoA Null
         0x03 IPoA LLC
         0x04 IPoA Null
         0x05 Ethernet over AAL5 LLC with FCS
         0x06 Ethernet over AAL5 LLC without FCS
         0x07 Ethernet over AAL5 Null with FCS
         0x08 Ethernet over AAL5 Null without FCS

3.3.18.  IWF-Session

   Description

      The presence of this Attribute indicates that the IWF has been
      performed with respect to the subscriber's session; note that no
      data field is necessary.  It MAY be included in both Access-
      Request and Accounting-Request packets.

   A summary of the IWF-Session Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Type

      254 (0xFE) for IWF-Session

   Vendor-Length

      2

Mammoliti, et al.            Informational                     [Page 20]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

4.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity; note that since none
   of the DSL Forum VSAs may be present in the Access-Accept, Access-
   Reject or Access-Challenge packets, those columns have been omitted
   from the table.

   Request   Acct-Request  #   Attribute
   0-1       0-1            1  Agent-Circuit-Id
   0-1       0-1            2  Agent-Remote-Id
   0-1       0-1          129  Actual-Data-Rate-Upstream
   0-1       0-1          130  Actual-Data-Rate-Downstream
   0         0-1          131  Minimum-Data-Rate-Upstream
   0         0-1          132  Minimum-Data-Rate-Downstream
   0         0-1          133  Attainable-Data-Rate-Upstream
   0         0-1          134  Attainable-Data-Rate-Downstream
   0         0-1          135  Maximum-Data-Rate-Upstream
   0         0-1          136  Maximum-Data-Rate-Downstream
   0         0-1          137  Minimum-Data-Rate-Upstream-Low-Power
   0         0-1          138  Minimum-Data-Rate-Downstream-Low-Power
   0         0-1          139  Maximum-Interleaving-Delay-Upstream
   0         0-1          140  Actual-Interleaving-Delay-Upstream
   0         0-1          141  Maximum-Interleaving-Delay-Downstream
   0         0-1          142  Actual-Interleaving-Delay-Downstream
   0-1       0-1          144  Access-Loop-Encapsulation
   0-1       0-1          254  IWF-Session

   The following table defines the meaning of the above table entries.

   0      This Attribute MUST NOT be present in packet.

   0-1    Zero or one instances of this Attribute MAY be present in
          packet.

5.  Security Considerations

   The security of these Attributes relies on an implied trust
   relationship between the Access Node/DSLAM and the BRAS.  The
   identifiers that are inserted by the Access Node/DSLAM are
   unconditionally trusted; the BRAS does not perform any validity check
   on the information received.  These Attributes are intended to be
   used in environments in which the network infrastructure (the Access
   Node/DSLAM, the BRAS, and the entire network in which those two
   devices reside) is trusted and secure.

Mammoliti, et al.            Informational                     [Page 21]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

   As used in this document, the word "trusted" implies that
   unauthorized traffic cannot enter the network except through secured
   and trusted devices and that all devices internal to the network are
   secure and trusted.  Careful consideration should be given to the
   potential security vulnerabilities that are present in this model
   before deploying this option in actual networks.

   The Attributes described in this document neither increase nor
   decrease the security of the RADIUS protocol.  For discussions of
   various RADIUS vulnerabilities, see [RFC2607], [RFC3579], [RFC3162],
   and [RFC3580].

6.  References

6.1.  Normative References

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

6.2.  Informative References

   [IANA]     Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE
              NUMBERS", January 2006,
              <http://www.iana.org/assignments/enterprise-numbers>.

   [ITU.I363-5.1996]
              International Telecommunications Union, "B-ISDN ATM
              Adaptation Layer Specification: Type 5 AAL", ITU-T
              Recommendation I.363.5, August 1996.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC2607]  Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
              Implementation in Roaming", RFC 2607, June 1999.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3162]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
              RFC 3162, August 2001.

Mammoliti, et al.            Informational                     [Page 22]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3580]  Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
              "IEEE 802.1X Remote Authentication Dial In User Service
              (RADIUS) Usage Guidelines", RFC 3580, September 2003.

   [RFC4243]  Stapp, M., Johnson, R., and T. Palaniappan, "Vendor-
              Specific Information Suboption for the Dynamic Host
              Configuration Protocol (DHCP) Relay Agent Option",
              RFC 4243, December 2005.

Mammoliti, et al.            Informational                     [Page 23]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

Authors' Addresses

   Vince Mammoliti
   Cisco Systems
   181 Bay Street, Suite 3400
   Toronto, ON  M5J 2T3
   Canada

   EMail: vince@cisco.com

   Glen Zorn
   Cisco Systems
   2901 Third Avenue, Suite 600
   SEA1/5/
   Seattle, WA  98121
   USA

   Phone: +1 (425) 344 8113
   EMail: gwz@cisco.com

   Peter Arberg
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA  95134
   USA

   EMail: parberg@redback.com

   Robert Rennison
   ECI Telecom
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA  15205
   USA

   EMail: robert.rennison@ecitele.com

Mammoliti, et al.            Informational                     [Page 24]
RFC 4679                  DSL Forum RADIUS VSA            September 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Mammoliti, et al.            Informational                     [Page 25]