Subject: [Enum] [Fwd: I-D submission: draft-lind-infrastructure-enum-reqs-01]

From: Richard Shockey <[email-masked]>
Date: Tue, 18 Oct 2005 13:45:49 -0400

ENUM                                                             S. Lind
Internet-Draft                                                 AT&T Labs
Expires: April 22, 2006                                        P. Pfautz
                                                                     AT&T
                                                         October 18, 2005

                 Carrier/Infrastructure ENUM Requirements
                  draft-lind-infrastructure-enum-reqs-01

Status of this Memo

    This document is an Internet-Draft and is subject to all provisions
    of Section 3 of RFC 3667.  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 April 22, 2006.

Copyright Notice

    Copyright (C) The Internet Society (2005).

Abstract

    This document provides requirements for "infrastructure" or "carrier"
    ENUM, defined as the use of RFC 3761 technology to facilitate
    interconnection of networks for E.164 number addressed services, in
    particular but not restricted to VoIP.

Lind & Pfautz            Expires April 22, 2006                 [Page 1]

Internet-Draft          Carrier ENUM Requirements           October 2005

Conventions used in this document

    RFC2119 [1] provides the interpretations for the key words "MUST",
    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.

1.  Infrastructure ENUM

1.1.  Definition

    Infrastructure ENUM is defined as the use of the technology in
    RFC3761 [2] by the carrier-of-record for a specific E.164 number [3]
    to map a telephone number into a URI that identifies a specific point
    of interconnection to that service provider's network that could
    enable the originating party to establish communication with the
    associated terminating party.  It is separate from any URIs that the
    end-user, who registers their E.164 number, may wish to associate
    with that E.164 number.

    For purposes of this document, "Carrier of Record" refers to the
    entity that provides PSTN service for an E.164 number with the
    understanding that this definition is ultimately a matter for
    national authorities to determine.

1.2.  Background

    Carriers use E.164 numbers currently as their main naming and routing
    vehicle.  Carrier ENUM in e164.arpa or another publicly available
    tree allows Carriers to link Internet based resources such as URIs to
    E.164 numbers (Note: this is the other way round then User ENUM).
    This allows Carrier in addition to interconnecting via the PSTN (or
    exclusively) to peer via IP-based protocols.  Carriers may announce
    all E.164 numbers or number ranges they host, regardless if the final
    end-user device is on the Internet, on IP-based closed NGNs or on the
    PSTN, provided an access (e.g.  SBC or gateway) to the destination
    carriers network is available on the Internet.  There is also no
    guarantee that the originating carrier querying Carrier ENUM is able
    to access the ingress network element of the destination carriers
    network.  Additional peering and accounting agreements requiring
    authentication may be necessary.  The access provided may also be to
    a shared network of a group of carriers, resolving the final
    destination network within the shared network.

2.  Requirements for Infrastructure ENUM

Lind & Pfautz            Expires April 22, 2006                 [Page 2]

Internet-Draft          Carrier ENUM Requirements           October 2005

2.1.

    Infrastructure ENUM SHALL provide a means for a carrier to populate
    DNS RRs in a common publicly accessible namespace for the E.164
    numbering resources for which it is the carrier-of-record.

2.2.

    Queries of infrastructure ENUM FQDNs MUST return a result, even if
    the result is NXDOMAIN.  Queries must not be rejected, e.g. based on
    ACLs.

2.3.

    Infrastructure ENUM SHALL support RRs providing a URI that can
    identify a point of interconnection for delivery of communications
    addressed to the E.164 number.

2.4.

    Infrastructure ENUM SHALL support an IRIS capability that allows
    qualified parties to obtain information regarding the E.164 numbering
    resources and the corresponding carrier-of-record.

2.5.

    Implementation of Infrastructure ENUM MUST NOT restrict the ability
    of an end-user, in a competitive environment, to choose a Registrar
    and/or Tier 2 name server provider for end-user ENUM registrations.

2.6.

    Infrastructure ENUM SHALL be implemented under a TLD that can support
    reliability and performance suitable for PSTN applications.

2.7.

    Infrastructure ENUM MUST meet all reasonable privacy concerns about
    visibility of information an end user has no control over, for
    example discovery of unlisted numbers, or inadvertent disclosure of
    user identity.

2.8.

    Proposed implementations of Infrastructure ENUM SHOULD

    a.  Minimize changes required to existing requirements that are part
    of RFC 3761

Lind & Pfautz            Expires April 22, 2006                 [Page 3]

Internet-Draft          Carrier ENUM Requirements           October 2005

    b.  Work with open numbering plans

    c.  Restrict additional functionality to carrier resolvers.

    d.  Minimize the number of lookups required to obtain as many NAPTR
    records (end-user and carrier) as possible.

    e.  Minimize the client knowledge of the numbering plan required.

    f.  Maximize synergies with end-user ENUM

    g.  Support interworking with private ENUM trees.

3.  Security Considerations

    Existing security considerations for ENUM detailed in [2] still
    apply.  Note that some registration validation issues concerning end
    user ENUM may not apply to carrier ENUM.  Where the Tier 1 registry
    is able to identify the carrier serving a number e.g., based on
    industry data for number block assignments and number portability,
    registration might be more easily automated and a separate registrar
    not required.

    Some parties have expressed concern that a carrier ENUM could
    compromise end user privacy by making it possible for others to
    identify unlisted or unpublished numbers based on their registration
    in ENUM.  This can be avoided if carriers register all of the their
    allocated (as opposed to assigned) numbers.  Unassigned numbers
    should be provisioned to route to the carrier's network in the same
    fashion as assigned numbers and only then provide an indication that
    they are unassigned.  In that way, carrier registration of a number
    in ENUM provides no more information about status of a number than
    could be obtained by dialing it.

4.  IANA Considerations

    IANA considerations will depend on the architecture ultimately chosen
    to meet the requirements.

5.  Normative References

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

    [2]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
         Identifiers (URI) Dynamic Delegation Discovery System (DDDS)

Lind & Pfautz            Expires April 22, 2006                 [Page 4]

Internet-Draft          Carrier ENUM Requirements           October 2005

         Application (ENUM)", RFC 3761, April 2004.

    [3]  International Telecommunications Union-T, "The International
         Public Telecommunication Number Plan", Recommendation E.164",
         May 1997.

Lind & Pfautz            Expires April 22, 2006                 [Page 5]

Internet-Draft          Carrier ENUM Requirements           October 2005

Authors' Addresses

    Steven Lind
    AT&T Labs
    180 Park Ave
    Florham Park, NJ  07932-0971
    USA

    Email: [email-masked]

    Penn Pfautz
    AT&T
    200 S. Laurel Ave
    Middletown, NJ  07748
    USA

    Email: [email-masked]

Lind & Pfautz            Expires April 22, 2006                 [Page 6]

Internet-Draft          Carrier ENUM Requirements           October 2005

Intellectual Property Statement

    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
    [email-masked].

Disclaimer of Validity

    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.

Copyright Statement

    Copyright (C) The Internet Society (2005).  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.

Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Lind & Pfautz            Expires April 22, 2006                 [Page 7]

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

ENUM                                                             S. Lind
Internet-Draft                                                 AT&T Labs
Expires: April 22, 2006                                        P. Pfautz
                                                                    AT&T
                                                        October 18, 2005

                Carrier/Infrastrucure ENUM Requirements
                 draft-lind-infrastructure-enum-reqs-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 April 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides requirements for "infrastructure" or "carrier"
   ENUM, defined as the use of RFC 3761 technology to facilitate
   interconnection of networks for E.164 number addressed services, in
   particular but not restricted to VoIP.

Lind & Pfautz            Expires April 22, 2006                 [Page 1]

Internet-Draft          Carrier ENUM Requirements           October 2005

Conventions used in this document

   RFC2119 [1] provides the interpretations for the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.

1.  Infrastructure ENUM

1.1.  Definition

   Infrastructure ENUM is defined as the use of the technology in
   RFC3761 [2] by the carrier-of-record for a specific E.164 number [3]
   to map a telephone number into a URI that identifies a specific point
   of interconnection to that service provider's network that could
   enable the originating party to establish communication with the
   associated terminating party.  It is separate from any URIs that the
   end-user, who registers their E.164 number, may wish to associate
   with that E.164 number.

   For purposes of this document, "Carrier of Record" refers to the
   entity that provides PSTN service for an E.164 number with the
   understanding that this definition is ultimately a matter for
   national authorities to determine.

1.2.  Background

   Carriers use E.164 numbers currently as their main naming and routing
   vehicle.  Carrier ENUM in e164.arpa or another publicly available
   tree allows Carriers to link Internet based resources such as URIs to
   E.164 numbers (Note: this is the other way round then User ENUM).
   This allows Carrier in addition to interconnecting via the PSTN (or
   exclusively) to peer via IP-based protocols.  Carriers may announce
   all E.164 numbers or number ranges they host, regardless if the final
   end-user device is on the Internet, on IP-based closed NGNs or on the
   PSTN, provided an access (e.g.  SBC or gateway) to the destination
   carriers network is available on the Internet.  There is also no
   guarantee that the originating carrier querying Carrier ENUM is able
   to access the ingress network element of the destination carriers
   network.  Additional peering and accounting agreements requiring
   authentication may be necessary.  The access provided may also be to
   a shared network of a group of carriers, resolving the final
   destination network within the shared network.

2.  Requirements for Infrastructure ENUM

Lind & Pfautz            Expires April 22, 2006                 [Page 2]

Internet-Draft          Carrier ENUM Requirements           October 2005

2.1.

   Infrastructure ENUM SHALL provide a means for a carrier to populate
   DNS RRs in a common publicly accessible namespace for the E.164
   numbering resources for which it is the carrier-of-record.

2.2.

   Queries of infrastructure ENUM FQDNs MUST return a result, even if
   the result is NXDOMAIN.  Queries must not be rejected, e.g. based on
   ACLs.

2.3.

   Infrastructure ENUM SHALL support RRs providing a URI that can
   identify a point of interconnection for delivery of communications
   addressed to the E.164 number.

2.4.

   Infrastructure ENUM SHALL support an IRIS capability that allows
   qualified parties to obtain information regarding the E.164 numbering
   resources and the corresponding carrier-of-record.

2.5.

   Implementation of Infrastructure ENUM MUST NOT restrict the ability
   of an end-user, in a competitive environment, to choose a Registrar
   and/or Tier 2 name server provider for end-user ENUM registrations.

2.6.

   Infrastructure ENUM SHALL be implemented under a TLD that can support
   reliability and performance suitable for PSTN applications.

2.7.

   Infrastructure ENUM MUST meet all reasonable privacy concerns about
   visibility of information an end user has no control over, for
   example discovery of unlisted numbers, or inadvertent disclosure of
   user identity.

2.8.

   Proposed implementations of Infrastructure ENUM SHOULD

   a.  Minimize changes required to existing requirements that are part
   of RFC 3761

Lind & Pfautz            Expires April 22, 2006                 [Page 3]

Internet-Draft          Carrier ENUM Requirements           October 2005

   b.  Work with open numbering plans

   c.  Restrict additional functionality to carrier resolvers.

   d.  Minimize the number of lookups required to obtain as many NAPTR
   records (end-user and carrier) as possible.

   e.  Minimize the client knowledge of the numbering plan required.

   f.  Maximize synergies with end-user ENUM

   g.  Support interworking with private ENUM trees.

3.  Security Considerations

   Existing security considerations for ENUM detailed in [2] still
   apply.  Note that some registration validation issues concerning end
   user ENUM may not apply to carrier ENUM.  Where the Tier 1 registry
   is able to identify the carrier serving a number e.g., based on
   industry data for number block assignments and number portability,
   registration might be more easily automated and a separate registrar
   not required.

   Some parties have expressed concern that a carrier ENUM could
   compromise end user privacy by making it possible for others to
   identify unlisted or unpublished numbers based on their registration
   in ENUM.  This can be avoided if carriers register all of the their
   allocated (as opposed to assigned) numbers.  Unassigned numbers
   should be provisioned to route to the carrier's network in the same
   fashion as assigned numbers and only then provide an indication that
   they are unassigned.  In that way, carrier registration of a number
   in ENUM provides no more information about status of a number than
   could be obtained by dialing it.

4.  IANA Considerations

   IANA considerations will depend on the architecture ultimately chosen
   to meet the requirements.

5.  Normative References

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

   [2]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
        Identifiers (URI) Dynamic Delegation Discovery System (DDDS)

Lind & Pfautz            Expires April 22, 2006                 [Page 4]

Internet-Draft          Carrier ENUM Requirements           October 2005

        Application (ENUM)", RFC 3761, April 2004.

   [3]  International Telecommunications Union-T, "The International
        Public Telecommunication Number Plan", Recommendation E.164",
        May 1997.

Lind & Pfautz            Expires April 22, 2006                 [Page 5]

Internet-Draft          Carrier ENUM Requirements           October 2005

Authors' Addresses

   Steven Lind
   AT&T Labs
   180 Park Ave
   Florham Park, NJ  07932-0971
   USA

   Email: [email-masked]

   Penn Pfautz
   AT&T
   200 S. Laurel Ave
   Middletown, NJ  07748
   USA

   Email: [email-masked]

Lind & Pfautz            Expires April 22, 2006                 [Page 6]

Internet-Draft          Carrier ENUM Requirements           October 2005

Intellectual Property Statement

   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
   [email-masked].

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Lind & Pfautz            Expires April 22, 2006                 [Page 7]


_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Douglas Ranalli" <[email-masked]>
Date: Wed, 19 Oct 2005 08:31:25 -0400

Penn and Steve,

Nice work on this first draft of Carrier-ENUM requirements.  One comment
regarding scope of the solution.  Section 1.1 "Definition" defines
Infrastructure-ENUM as a service that returns a single URI identifying a
point of interconnection.  Consider broadening the scope of the first
sentence of section 1.1 as follows: 

"...to map a telephone number into one or more URIs that identify
protocol or service specific points of interconnection..." 

Doug

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Tuesday, October 18, 2005 12:46 PM
To: [email-masked]'
Subject: [Enum] [Fwd: I-D submission:
draft-lind-infrastructure-enum-reqs-01]

ENUM                                                             S. Lind
Internet-Draft                                                 AT&T Labs
 
AT&T
                                                         October 18,
2005

Status of this Memo

    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."

Copyright Notice

Abstract

    This document provides requirements for "infrastructure" or
"carrier"
    ENUM, defined as the use of RFC 3761 technology to facilitate
    interconnection of networks for E.164 number addressed services, in
    particular but not restricted to VoIP.

    RFC2119 [1] provides the interpretations for the key words "MUST",
    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.

1.  Infrastructure ENUM

1.1.  Definition

    to map a telephone number into a URI that identifies a specific
point

1.2.  Background

    Carriers use E.164 numbers currently as their main naming and
routing
    vehicle.  Carrier ENUM in e164.arpa or another publicly available
    tree allows Carriers to link Internet based resources such as URIs
to
    E.164 numbers (Note: this is the other way round then User ENUM).
    This allows Carrier in addition to interconnecting via the PSTN (or
    exclusively) to peer via IP-based protocols.  Carriers may announce
    all E.164 numbers or number ranges they host, regardless if the
final
    end-user device is on the Internet, on IP-based closed NGNs or on
the
    PSTN, provided an access (e.g.  SBC or gateway) to the destination
    carriers network is available on the Internet.  There is also no
    guarantee that the originating carrier querying Carrier ENUM is able
    to access the ingress network element of the destination carriers
    network.  Additional peering and accounting agreements requiring
    authentication may be necessary.  The access provided may also be to
    a shared network of a group of carriers, resolving the final
    destination network within the shared network.

2.1.

2.2.

2.3.

2.4.

    Infrastructure ENUM SHALL support an IRIS capability that allows
    qualified parties to obtain information regarding the E.164
numbering
    resources and the corresponding carrier-of-record.

2.5.

2.6.

    Infrastructure ENUM SHALL be implemented under a TLD that can
support
    reliability and performance suitable for PSTN applications.

2.7.

2.8.

4.  IANA Considerations

    IANA considerations will depend on the architecture ultimately
chosen
    to meet the requirements.

5.  Normative References

Authors' Addresses

    Steven Lind
    AT&T Labs
    180 Park Ave

    Email: [email-masked]

    Penn Pfautz
    AT&T
    200 S. Laurel Ave
    Middletown, NJ  07748
    USA

    Email: [email-masked]

    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.

Disclaimer of Validity

    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.

Copyright Statement

Acknowledgment

--