ENUM -- Telephone Number Mapping                            B. Hoeneisen
Working Group                                                     SWITCH
Internet-Draft                                              May 21, 2008
Expires: November 22, 2008


        IANA Registration of Experimental and Trial Enumservices
                            (X-Enumservices)
                   draft-ietf-enum-x-service-regs-01

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 November 22, 2008.

Abstract

   This document specifies a new IANA registry for experimental and
   trial Enumservices (X-Enumservices), describes corresponding
   registration procedures, and provides a guideline for creating
   X-Enumservices and its Registration Documents.










Hoeneisen               Expires November 22, 2008               [Page 1]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Registration Requirements  . . . . . . . . . . . . . . . . . .  3

   4.  X-Enumservice Creation Cookbook  . . . . . . . . . . . . . . .  4

   5.  Required Sections and Information  . . . . . . . . . . . . . .  4
     5.1.  IANA Registration  . . . . . . . . . . . . . . . . . . . .  4

   6.  The Process of Registering New X-Enumservices  . . . . . . . .  8

   7.  Expert Review  . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Expert Selection Process . . . . . . . . . . . . . . . . .  8
     7.2.  Review Guidelines  . . . . . . . . . . . . . . . . . . . .  8
     7.3.  Appeals  . . . . . . . . . . . . . . . . . . . . . . . . .  9

   8.  Revision of Pre-Existing X-Enumservice RFCs  . . . . . . . . .  9

   9.  Extension of Existing X-Enumservice Registrations  . . . . . .  9

   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     10.1. Considerations Regarding this Document . . . . . . . . . .  9
     10.2. X-Enumservice Security Considerations Guideline  . . . . .  9

   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     11.1. IANA Registration Template . . . . . . . . . . . . . . . . 10
     11.2. Location . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.3. Structure  . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.4. Registration Procedure . . . . . . . . . . . . . . . . . . 11
     11.5. Change Control . . . . . . . . . . . . . . . . . . . . . . 11
     11.6. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 12

   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12

   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     13.2. Informative References . . . . . . . . . . . . . . . . . . 13

   Appendix A.  Document Changelog  . . . . . . . . . . . . . . . . . 13

   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 14

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15



Hoeneisen               Expires November 22, 2008               [Page 2]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


1.  Introduction

   E.164 Number Mapping (ENUM) [I-D.ietf-enum-3761bis] provides an
   identifier mapping mechanism to map E.164 numbers [ITU.E164.2005] to
   Uniform Resource Identifiers (URIs) [RFC3986].  One of the primary
   concepts of ENUM is the definition of "Enumservices", which allows
   for providing different URIs for different applications of said
   mapping mechanism.  The registration procedures for "ordinary"
   Enumservices have been specified in "IANA Registration of
   Enumservices: Guide, Template and IANA Considerations"
   [I-D.ietf-enum-enumservices-guide].

   However, the IETF's ENUM Working Group has encountered a need for
   IANA registrations of experimental and trial Enumservices
   (X-Enumservices).

   The X-Enumservice registration is intended to allow people to use the
   template for ordinary Enumservices to describe what X-Enumservice
   strings exist in NAPTR Resource Records and to describe how they are
   used, but not (yet) to require a full IETF review and change control.

   This is needed as some trials use URI schemes that are not
   registered, and so cannot be used in "ordinary" Enumservice
   registrations.  Also, until trials have been completed, it may not be
   appropriate to produce an "ordinary" Enumservice registration
   document, as Enumservice syntax details, use and issues of security
   and/or privacy may not have been analyzed fully at that point.

   This document specifies a new IANA registry for X-Enumservices.


2.  Terminology

   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 [RFC2119].

   For the purpose of this document, 'Registration Document' and
   'Registration' refer to a specification that defines an X-Enumservice
   and proposes its registration following the procedures outlined
   herein.


3.  Registration Requirements

   The Requirements outlined in Section 3 "Registration Requirements" of
   [I-D.ietf-enum-enumservices-guide] also apply to X-Enumservices
   registrations, unless specified differently in this document.



Hoeneisen               Expires November 22, 2008               [Page 3]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


4.  X-Enumservice Creation Cookbook

   The guidelines in Section 4 "Enumservice Creation Cookbook" of
   [I-D.ietf-enum-enumservices-guide] also apply to X-Enumservices
   registrations, unless specified differently in this document.


5.  Required Sections and Information

   In addition to the sections required for an RFC as outlined in
   "Instructions to RFC Authors" [I-D.rfc-editor-rfc2223bis], there are
   several sections that MUST appear in an X-Enumservice Registration
   Document.  These sections are specified in Section 5 of
   [I-D.ietf-enum-enumservices-guide].

   A Registration Document for an X-Enumservice is similar to a
   "ordinary" Enumservice registration as described in
   [I-D.ietf-enum-enumservices-guide].  The only differences are for the
   "IANA Registration" section, where Section 5.1 of this document
   applies.

   The following terms SHOULD begin with a capital letter, whenever they
   refer to the IANA Registration:
   o  Class
   o  Type
   o  Subtype
   o  URI Scheme

   Appendix A of [I-D.ietf-enum-enumservices-guide] contains an XML2RFC
   template that can be used to create Internet Drafts and RFCs by means
   described on <http://xml.resource.org/>.  This XML2RFC template
   contains a prototype for most of these sections.

5.1.  IANA Registration

   The field names "Enumservice Class", and "Enumservice Type",
   "Enumservice Subtype" are different in IANA Registrations for
   X-Enumservices, namely the fields are prefixed by "X-" resulting in
   "X-Enumservice Class", "X-Enumservice Type", and "X-Enumservice
   Subtype"


   o  X-Enumservice Class:

      This field contains the Class of the X-Enumservice as defined in
      Section 4.2. of [I-D.ietf-enum-enumservices-guide] and it's value
      MUST be one of those listed in Section 5.2 of
      [I-D.ietf-enum-enumservices-guide] (without quotes).



Hoeneisen               Expires November 22, 2008               [Page 4]


Internet-Draft     IANA Registration of X-Enumservices          May 2008



         e.g.
         Protocol-based

   o  X-Enumservice Type:

      The Type of the X-Enumservice.  All Types SHOULD be listed in
      lower-case.  The choice of Type depends on the X-Enumservice
      Class.  Please find further instructions in Section 4 of
      [I-D.ietf-enum-enumservices-guide].

      The Type of an X-Enumservice MUST be prefixed with "x-".

         e.g.
         "x-foo"

      Note: Put the Type string between double quotes.

   o  X-Enumservice Subtype:

      The Subtype of the X-Enumservice.  All Subtypes SHOULD be listed
      in lower-case.  The choice of Subtype depends on the X-Enumservice
      Class.  Please find further instructions in Section 4 of
      [I-D.ietf-enum-enumservices-guide].

         e.g.
         "bar"

         e.g.
         N/A

      Note: Put the Subtype string between double quotes.

      Note: Many X-Enumservices do not require a Subtype; use "N/A" in
      this case.

      Note: As stated above, where a given X-Enumservice Type has
      multiple Subtypes, there MUST be a separate 'IANA Registration'
      section for each Subtype.

   o  URI Scheme(s):

      The Uniform Resource Identifier (URI) [RFC3986] Schemes that are
      used with the X-Enumservice.  The selection of URI Schemes often
      depends on the X-Enumservice Class, Type, and/or Subtype.  Please
      find further instructions in Section 4. of
      [I-D.ietf-enum-enumservices-guide].




Hoeneisen               Expires November 22, 2008               [Page 5]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


      The URI Schemes, which are used with an X-Enumservice do not
      necessarily need to be documented in an IETF document.  If a
      publicly referenceable document is available it MUST be referenced
      in the Registration Document.  In case there is no publicly
      referenceable document, the URI Scheme MUST be sufficiently
      described in the Registration Document.

         e.g.
         'bar', 'sbar'

      Note: Do not put a colon after a URI Scheme and put each URI
      Scheme between single quotes.  If there is more than one URI
      Scheme, use a comma as separator.

      Note: A client cannot choose a specific ENUM record in a record
      set based on the URI Scheme - the selection is only based on
      'Type' and 'Subtype'.

   o  Functional Specification:

      The Functional Specification describes how the X-Enumservice is
      used in connection with the URI to which it resolves.

      This section quite depends on how much publicly available
      documentation about the service already exists.

         e.g.
         This X-Enumservice indicates that the resource identified can
         be addressed by the associated URI in order to foo the bar.
         [...]

      Where the terms used are non-obvious, they should be defined in
      the Registration Document, or a reference to an external document
      containing their definition should be provided.

   o  Security Considerations:

      An internal reference to the 'Security Considerations' section of
      a given Registration Document.

         e.g.
         See Section 10

   o  Intended Usage:

      One of the following values (without quotes):





Hoeneisen               Expires November 22, 2008               [Page 6]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


      *  "EXPERIMENTAL": Indicates that the X-Enumservice is intended
         for experimental use, and that it's scope is not limited to a
         certain environment.

      *  "TRIAL": Indicates that the X-Enumservice is intended for trial
         use, and that it's scope MAY be limited to a participants of a
         trial.

      *  "OBSOLETE": Indicates that the X-Enumservice has been declared
         obsolete (Section 11.5) and is not to be used in new
         deployments.  Applications SHOULD however expect to encounter
         legacy instances of this X-Enumservice.

         e.g.
         EXPERIMENTAL

   o  Registration Document(s):

      A *unique* reference to the X-Enumservice Registration Document.

         e.g.
         [RFC 9999]

         e.g.
         [RFC 7777] (Obsoleted by RFC 8888)
         [RFC 8888] (Updated by RFC 9999)
         [RFC 9999]

         e.g.
         [International Telecommunications Union, "X-Enumservice
         Registration for Foobar", ITU-F Recommendation B.193, Release
         73, Mar 2008.]

   o  Author(s):

      The author(s) of the X-Enumservice Registration.

         e.g.
         John Doe, Jane Dale

      Note: If there is more than one author, use a comma as separator.

      Note: Do not put email addresses to author(s) field of an IANA
      registration.

   o  Further Information:

      Any other information the author(s) deem(s) interesting.



Hoeneisen               Expires November 22, 2008               [Page 7]


Internet-Draft     IANA Registration of X-Enumservices          May 2008



         e.g.
         See Section 3

         e.g.
         N/A

      Note: Use "N/A", if there is no content for this field.


6.  The Process of Registering New X-Enumservices

   The process of registering new X-Enumservices is the same as for
   "ordinary" Enumservices as specified in Section 6 "The Process of
   Registering New Enumservice" of [I-D.ietf-enum-enumservices-guide].


7.  Expert Review

7.1.  Expert Selection Process

   The same (pool of) experts as appointed for "ordinary" Enumservice
   registrations (see Section 7.1 of [I-D.ietf-enum-enumservices-guide])
   is also responsible for X-Enumservice registrations.

7.2.  Review Guidelines

   Generally, the Expert Review process of an Enumservice MUST follow
   the guidelines documented in Section 3.3 of "Guidelines for Writing
   an IANA Considerations Section in RFCs" [RFC5226].

   Expert review for X-Enumservices is conducted the same way as defined
   for ordinary Enumservice registrations
   [I-D.ietf-enum-enumservices-guide].  However, the barriers for
   approval are lower.

   Expert review for X-Enumservices for will include an initial
   evaluation of whether this specification will have issues in
   transferring to an ordinary Enumservice registration (for example, if
   it uses an unregistered URI scheme, or that the security and privacy
   analysis is incomplete at this stage).  It will also indicate whether
   the use of this X-Enumservice will clash with any other
   (X-)Enumservices or cause damage to other compliant ENUM components.

   Expert reviews for X-Enumservices do not normally result in
   rejection, unless its use will cause serious negative impact to ENUM,
   DNS or the Internet.  However, authors SHOULD address issues raised
   during expert review in an update of the Registration Document,



Hoeneisen               Expires November 22, 2008               [Page 8]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


   before a new X-Enumservice is added to the IANA registry.

   The results of such an expert review MUST be appended to the
   Registration Document and will be recorded along with the
   specification itself.

   The Expert Review process of X-Enumservices SHOULD also regard
   Section 7.2 "Review Guidelines" of
   [I-D.ietf-enum-enumservices-guide].

7.3.  Appeals

   Appeals against Expert Review decisions follow the normal IETF appeal
   process as described in section 7 of [RFC5226] and section 6.5 of
   [RFC2026].


8.  Revision of Pre-Existing X-Enumservice RFCs

   At this point in time there are no pre-existing X-Enumservice
   Registrations.


9.  Extension of Existing X-Enumservice Registrations

   Extensions of existing X-Enumservice Registrations follow the same
   specifications as for "ordinary" Enumservice registrations, which are
   outlined in Section 9 "Extension of Existing Enumservice
   Registrations" of [I-D.ietf-enum-enumservices-guide].


10.  Security Considerations

10.1.  Considerations Regarding this Document

   Since this document does not introduce any technology or protocol,
   there are no security issues to be considered for this document
   itself.

10.2.  X-Enumservice Security Considerations Guideline

   [I-D.ietf-enum-3761bis] already outlines security considerations
   affecting ENUM as a whole.  X-Enumservice Registration Documents do
   not need and SHOULD NOT repeat considerations already listed there,
   but they SHOULD include a reference to that section.

   ENUM refers to resources using pre-existing URI Schemes and
   protocols.  X-Enumservice Registration Documents do not need and



Hoeneisen               Expires November 22, 2008               [Page 9]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


   SHOULD NOT repeat security considerations affecting those protocols
   and URI Schemes itself.

   However, in case that the inclusion of those protocols and URI
   Schemes into ENUM specifically introduces new security issues, those
   issues MUST be covered in the 'Security Considerations' section of
   the Registration Document.


11.  IANA Considerations

   IANA will insert a new registry "X-Enumservice Registrations"
   according to (this) Section 11, which will complement the registry
   for "ordinary" Enumservice registrations as specified in Section 11
   "IANA Considerations" of [I-D.ietf-enum-enumservices-guide].

   It is noted that the process described herein applies only to
   X-Enumservice registrations (i.e. the registration process of
   "ordinary" Enumservices is beyond the scope of this document).

11.1.  IANA Registration Template

   The IANA registration template consists of the following fields that
   are specified in Section 5.1:


   o  X-Enumservice Class:

   o  X-Enumservice Type:

   o  X-Enumservice Subtype:

   o  URI Scheme(s):

   o  Functional Specification:

   o  Security Considerations:

   o  Intended Usage:

   o  Registration Document(s):

   o  Author(s):

   o  Further Information:

   Note: In the case where a particular field has no value, 'N/A' (Not
   Applicable) MUST be used.  This case especially may occur where a



Hoeneisen               Expires November 22, 2008              [Page 10]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


   given Type has no Subtypes, or if there is no "Further Information".

11.2.  Location

   Approved X-Enumservice registrations are published in the IANA
   repository "X-Enumservice Registrations", which is proposed to be
   located at the following URI:
   < http://www.iana.org/assignments/x-enum-services >.

   At this repository only the filled IANA Registration Template as
   listed in Section 11.1 and specified in Section 5.1 is published.

   Where the Registration Document is NOT an RFC, IANA MUST hold an
   escrow copy of that Registration Document.  Said escrow copy will act
   as the master reference for that X-Enumservice Registration.

   In order to help the users, IANA should place HTML links between the
   repositories "Enumservice Registrations" and "X-Enumservice
   Registrations" at appropriate places.

11.3.  Structure

   IANA maintains the X-Enumservice repository sorted in alphabetical
   order.  The first sort field is Type, the second is Subtype.

   Each X-Enumservice starts with a caption, which is composed of Type
   and Subtype, separated by a colon; e.g. if the Type is "foo" and the
   Subtype "bar", the resulting caption is "foo:bar".

11.4.  Registration Procedure

   Whenever a proposal for a new X-Enumservice is submitted, IANA will
   take care of the 'Expert Review' process according to "Guidelines for
   Writing an IANA Considerations Section in RFCs" [RFC5226].

   Provided that the X-Enumservice has obtained the necessary approval
   of the expert(s), and the Registration Document is published, IANA
   will register the X-Enumservice, i.e. add the X-Enumservice to the
   IANA "X-Enumservice Registrations" registry (see also Section 11.2).

11.5.  Change Control

   For X-Enumservices Registrations published as an RFC, change control
   stays with the IETF via the RFC publication process.

   Change control of X-Enumservices Registrations not published as an
   RFC (i.e. according the process described herein) is done by "Expert
   Review" and "Specification Required" according to [RFC5226].



Hoeneisen               Expires November 22, 2008              [Page 11]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


   X-Enumservice registrations MUST NOT be deleted.  An X-Enumservice
   that is believed no longer appropriate for use, can be declared
   obsolete by publication of a new X-Enumservices Registrations
   document changing its "Intended Usage" field to "OBSOLETE"; such
   X-Enumservices will be clearly marked in the lists published by IANA.

   Updates of any X-Enumservice Registrations MUST follow the guidelines
   described in this document.

11.6.  Restrictions

   As stated in Section 3.2 "Naming Requirements" of
   [I-D.ietf-enum-enumservices-guide], any identifying tag of any
   Enumservice MUST NOT be set to nor start with "E2U".  Any Enumservice
   registration requests covered by these restrictions MUST be rejected
   by IANA, and the 'Expert Review' process SHOULD NOT be initiated.

   Appendix A of [I-D.ietf-enum-enumservices-guide] contains examples
   for Enumservice registrations.  Therefore, IANA MUST NOT register an
   Enumservice with Type or Subtype set to "foo", "bar", or "sbar",
   unless the Expert(s) explicitly confirm an exception.


12.  Acknowledgements

   The author would like to thank the following people who have provided
   feedback or significant contributions to the development of this
   document: Lawrence Conroy, and Alexander Mayrhofer


13.  References

13.1.  Normative References

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

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [I-D.ietf-enum-3761bis]
              Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery  System (DDDS) Application (ENUM)",
              draft-ietf-enum-3761bis-03 (work in progress), March 2008.

   [I-D.ietf-enum-enumservices-guide]
              Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA



Hoeneisen               Expires November 22, 2008              [Page 12]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


              Registration of Enumservices: Guide, Template and IANA
              Considerations", draft-ietf-enum-enumservices-guide-10
              (work in progress), May 2008.

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

   [I-D.rfc-editor-rfc2223bis]
              Reynolds, J. and R. Braden, "Instructions to Request for
              Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
              (work in progress), July 2004.

13.2.  Informative References

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [ITU.E164.2005]
              International Telecommunications Union, "The International
              Public Telecommunication Numbering Plan", ITU-
              T Recommendation E.164, Feb 2005.


Appendix A.  Document Changelog

   [RFC Editor: This section is to be removed before publication]

   draft-ietf-enum-x-service-regs-01:
   o  Removed 'Private' (as per ENUM WG decision during IETF-70)
   o  Complete rewrite in line with draft-ietf-enum-enumservice-guide-10

   draft-ietf-enum-x-service-regs-00:
   o  Spelled out the Expert Review Process
   o  Added ASCII-arts and descriptions
   o  Now Working Group Item

   draft-hoeneisen-enum-x-service-regs-02:
   o  Name must have 'X-' prefix (Feedback L. Conroy)
   o  Type should be equal to Name (Feedback L. Conroy)

   draft-hoeneisen-enum-x-service-regs-01:
   o  added dash issue
   o  introduced abbreviation X-Enumservice and used it throughout the
      document





Hoeneisen               Expires November 22, 2008              [Page 13]


Internet-Draft     IANA Registration of X-Enumservices          May 2008


   o  clarified section URI Schemes
   o  added to section Expert Review

   draft-hoeneisen-enum-x-service-regs-00:
   o  Initial version


Appendix B.  Open Issues

   [RFC Editor: This section should be empty before publication]
   o  Is there a need for "duration" of X-Enumservice registrations?
   o  Will there be an additional (IANA) Registry or just use the same
      IANA Registry as for ordinary Enumservice registrations or a Sub-
      Registry?
   o  Require a first Security analysis for trial registrations?


Author's Address

   Bernie Hoeneisen
   SWITCH
   Werdstrasse 2
   CH-8004 Zuerich
   Switzerland

   Phone: +41 44 268 1515
   Email: bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch
   URI:   http://www.switch.ch/























Hoeneisen               Expires November 22, 2008              [Page 14]


Internet-Draft     IANA Registration of X-Enumservices          May 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.











Hoeneisen               Expires November 22, 2008              [Page 15]