One document matched: draft-ietf-enum-x-service-regs-01.txt
Differences from draft-ietf-enum-x-service-regs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:05 |