Re: Working Group Last Call on enumservices guide 12
Peter Koch <[email protected]> Sun, 21 Sep 2008 19:45:28 +0200
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Sep 06, 2008 at 11:00:51AM -0400, Richard Shockey wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-12.tx
> t
>
> The intent of the last call is to solicit comments before submitting the ID
> to the IESG as a Proposed Standard.
I have reviewed version 12 of the Enumservice Guidelines draft.
I support the general change of the registration policy from Experimental or
Standards Track to Expert Review, as proposed in this document.
I support publication as BCP.
However, there are several editorial and terminology issues that IMHO warrant
another update before sending this to the IESG.
Regarding Terminology, the draft mixes "Registration", "Registration Template"
and "Registration Document", where I'd suggest the following distinctions to
be consistently applied:
"Registration" is what is entered into the Registry after an application has
been approved.
"Registration Template" is the multiline template given in section 11.
"Enumservice Specification" is what the applicant uses to specify the
actual data. In fact, the Registration Template should be copied into
the specification document, as it is today.
I'd suggest to completely drop the term "Registration Document".
The XML template in the appendix could be dropped without harm, in my opinion.
If it is going to stay, the maintenance obligations need to be specified.
During this review I might have stumbled across issues that have already been
dealt with and have been declared closed. In this case, I'd appreciate a hint;
there's no attempt to consciously rehash old discussions.
-Peter
> ENUM -- Telephone Number Mapping B. Hoeneisen
> Working Group Swisscom
> Internet-Draft A. Mayrhofer
> Obsoletes: 3761 (if approved) enum.at
> Intended status: Standards Track J. Livingood
> Expires: March 5, 2009 Comcast
IANA Registry Descriptions usually are BCP documents, and this draft
obsoletes only part of RFC 3761, so "Updates: 3761" is probably more appropriate.
> IANA Registration of Enumservices: Guide, Template and IANA
> Considerations
> draft-ietf-enum-enumservices-guide-12
> Abstract
>
> This document specifies a revision of the IANA Registry for
NIT: s/revision of the IANA Registry/revision of the IANA Registration
Guidelines/
> Enumservices, describes corresponding registration procedures, and
> provides a guideline for creating Enumservices and its Registration
NIT: s/its/their/
> 3.1. Functionality Requirements
>
> A registered Enumservice must be able to function as a selection
> mechanism when choosing one NAPTR resource record from another. That
> means that the Registration MUST specify what is expected when using
> that very NAPTR record, and the URI which is the outcome of the use
> of it.
Here and in the rest of the document, "NAPTR" is always used in its
singular form, where an ENUM service cannot expect to be covered by a
single RR only.
Also, a reference to DDDS and an introduction of the NAPTR RR [RFC3403]
would be helpful.
> Specifically, a registered Enumservice MUST specify the URI Scheme(s)
> that may be used for the Enumservice, and, when needed, other
The wording, active voice with "Enumservice" in the first person irritates me.
-> "An Enumservice Specification MUST specify all URI Schemes ..."
> 3.2. Naming Requirements
>
> An Enumservice MUST be unique in order to be useful as a selection
> criteria:
NIT: criterion
> o The Type MUST be unique.
>
> o The Subtype (being dependent on the Type) MUST be unique within a
> given Type.
>
> Types and Subtypes MUST conform to the ABNF specified in
> [I-D.ietf-enum-3761bis].
Since that is only clarified in the -bis draft, it should be noted (non-
normatively) here that type and subtype strings will be matched
case insensitively (2.4.4 and 3.4 in -bis).
> The ABNF specified in [I-D.ietf-enum-3761bis] allows the "-" (dash)
> character for Types and Subtypes . To avoid confusion with possible
> future prefixes, a "-" MUST NOT be used as the first nor as the
> second character of a Type nor a Subtype.
Strange enough, the current draft would allow "-" also as a last character.
This should be changed in the -bis document, not in the registration
guidelines.
> To avoid confusion with Enumservice fields using an obsolete syntax,
> any identifying tag of any Enumservice MUST NOT be set to nor start
> with "E2U".
>
> The Subtype for one Type MAY be the same as a Subtype for a different
> registered Type but it is not sufficient to simply reference another
> Type's Subtype. The functionality of each Subtype MUST be specified
> in the context of the Type being registered.
This basicly says that the subtypes aren't equal, so I'd suggest to reword:
"The Subtype for one Type MAY have the same identifier as a Subtype ..."
> Section 4 contains further naming requirements.
This is a bit hard to follow for applicants, experts and right now for me.
Can we have a summary of the requirements right here? The following
section ("cookbook") should contain recommendations only, not requirements.
> 3.3. Security Requirements
>
> An analysis of security issues is REQUIRED for all registered
> Enumservices. (This is in accordance with the basic requirements for
> all IETF protocols.)
>
> All descriptions of security issues MUST be as accurate and extensive
> as feasible. In particular, a statement that there are "no security
> issues associated with this Enumservice" must not be confused with
> "the security issues associated with this Enumservice have not been
> assessed".
>
> There is no requirement that an Enumservice must be completely free
> of security risks. Nevertheless, all known security risks MUST be
> identified in the Registration of an Enumservice.
The draft isn't completely consistent in its use of the term "Registration".
Isn't it the registration template that should contain the risk assessment?
[see introduction]
> The security considerations section of all Registrations is subject
> to continuing evaluation and modification.
How would that work and whose obligation is it?
> Some of the issues that SHOULD be looked at in a security analysis of
> an Enumservice are:
Not sure this SHOULD is justified or helpful. For the expert evaluation,
some consideration by the applicant has to be shown anyway. "SHOULD be looked
at" is rather fuzzy.
> 2. Complex Enumservices may include provisions for directives that
> institute actions which, while not directly harmful, may result
> in disclosure of information that either facilitates a subsequent
> attack or else violates the users privacy in some way.
NIT: user's or users'
> 3.4. Publication Requirements
>
> Enumservices Registrations MUST be published according to the
See previous remark about terminology. In my reading, the "Registrations" would
be published by incorporation into the IANA registry after the application has
been granted, while the _Specification_ is what is dealt with here.
> requirements for 'Specification Required' set in "Guidelines for
> Writing an IANA Considerations Section in RFCs" [RFC5226]. RFCs
> fulfill these requirements. Therefore, it is strongly RECOMMENDED
> Registration Documents be published as RFCs.
This emphasis isn't necessary IMHO, but I can live with it. My discomfort
lies with the interaction of ISR and "Designated Expert".
> 4. Enumservice Creation Cookbook
>
> 4.1. General Enumservice Considerations
>
> ENUM is an extremely flexible identifier mapping mechanism, using
> E.164 (phone) numbers as input identifiers, and returning URIs as
> output identifiers. Because of this flexibility, almost every use
> case for ENUM could be implemented in several ways.
>
> Section 2 of "Guidelines for Writing an IANA Considerations Section
> in RFCs" [RFC5226] provides motivation why management of a name space
> might be necessary. Since the name space for Enumservice
> registrations is among the largest namespaces that IANA manages (even
> when ignoring Subtypes, its 32 alphanumeric characters make it much
NIT: s/32/up to 32/; otherwise the 32 could be read as the number of
characters rather than string length.
> larger than the entire IPv6 addressing space), exhaustion is not a
> problem. However, the following motivation for management taken from
> Section 2 of [RFC5226] applies to Enumservices:
I'd rephrase the whole paragraph to avoid the confusing (to me) comparison and
duplication of reference:
Even though the namespace for Enumservice Types [NIT: Too Many Capitals]
is rather large (up to 32 alphanumerical characters), there are reasons
suggesting a guided management. These reasons are given following the
structure in section 2 of [RFC5226]:
> o Prevent hoarding / wasting of values: Enumservice Types are not an
> opaque identifier to prevent collisions in the namespace, but
> rather identify the use of a certain technology in the context of
> ENUM. Service Types might also be displayed to end users in
> implementations, so meaningful Type strings having a clear
> relation to the protocols / applications used are strongly
> preferred (and RECOMMENDED). Therefore, preventing hoarding /
> wasting / "hijacking" of Enumservice Type names is important.
NIT: translate the "/" style into plain English
NIT: s/strongly preferred (and RECOMMENDED)/RECOMMENDED/
> o Sanity check to ensure sensible / necessary requests: This applies
> to Enumservices, since especially various Enumservices for the
> same purpose would reduce the chance of successful
> interoperability, and unnecessarily increase the confusion among
> implementers.
>
> o Delegation of namespace portions: Theoretically, the Type /
> Subtype structure of Enumservices would allow for delegations of
> Type values, and self-supporting management of Subtype values by a
> delegate within the Type value. Such delegates could for example
> be other standardization bodies. However, this would require
> clear policies regarding publication and use of such Subtypes.
> Delegation of Enumservice namespace portions is therefore
> currently not supported.
I'd approach this less defensively, since 5226 only suggests delegation, but
doesn't RECOMMEND it: Since the main motivations formanagement are sanity
checks and space preservation in NAPTR responses, a unique policy has to
be applied to all registrations and therefore delegation wouldn't gain
anything.
> o Interoperability: Since the benefit of an Enumservice rises with
> the number of supporting clients, the registration of several
> services for a similar or identical purpose clearly reduces
> interoperability. Also, space within the protocol on which ENUM
> is based (DNS packets) is rather scarce compared to the huge
> identifier space that Enumservice typing provides. Registering
> nearly identical services would clutter that space.
Strictly speaking, the registration alone wouldn't do any harm, competing
use would.
Operational circumstances suggest to keep the space occupied by all
services published in the NAPTR RRSet at any owner in the e164.arpa
domain bounded. Registration of nearly identical services and subsequent
competing or parallel use could easily increase the DNS operational
complexity.
> Generally, before commencing work on a new Enumservice registration,
> the following should be considered:
>
> o Is there an existing Enumservice that could fulfill the desired
> functionality without overloading it? Check the IANA Enumservice
> Registry at <http://www.iana.org/assignments/enum-services>.
>
> o Is there work in progress, or previous work, on a similar
> Enumservice? Check the <[email protected]> mailing list archives at
> <http://www.ietf.org/mail-archive/web/enum/index.html>, and search
> the Internet-Drafts Archive at <http://tools.ietf.org/>. As some
> Internet-Drafts may have expired and no longer be available in the
> Internet-Drafts Archive, it is important to search the
> <[email protected]> mailing list archives and to perform a web search.
While the advice is fine pragmatically, I'd suggest the IETF not make a
statement in an RFC suggesting that the policy of six month lifetime
for internet drafts wasn't meant seriously.
> 4.2.1. General Type / Subtype Considerations
>
> To avoid confusion, the name of an URI Scheme MUST NOT be used as a
> Type name for an Enumservice which is not specifically about the
> respective protocol / URI Scheme - for example, the Type name 'imap'
NIT: s/ - for/. For/
> would be inadequate for use in an Enumservice about "Internet
> mapping" services, because it corresponds to an existing URI Scheme /
> protocol for something different.
>
> If Subtypes are defined, the minimum number SHOULD be two (including
> the empty subtype, if defined). The choice of just one possible
> Subtype for a given Type does not add any information when selecting
> a ENUM record, and hence can be left out completely. However,
> potential future expansion of a Type towards several Subtypes MAY
> justify the use of Subtypes, even in the case just one is currently
> defined.
"may justify" doesn't justify 2119 language.
Add a forward reference to Section 9 to explain "future expansion" of
existing Enumservice Registrations.
> It is perfectly legal under a certain Type to mix the Enumservice
> without a Subtype ("empty Subtype") with Enumservices containing a
> Subtype. In that case, however, the Enumservice with an empty
> Subtype SHOULD be used to reflect the base service, while the other
> Enumservices SHOULD be used to reflect variants.
The use of "SHOULD be used" in this paragraph confuses me. Would that
refer to the way the service has to be specified or the actual operational
use in NAPTR RRSets and queries?
> 4.2.2. Protocol-based Enumservices Class
>
> Such an Enumservice indicates that an interaction using the named
> protocol will result for use of this NAPTR. The expected behavior of
See above: NAPTR in singular only.
> a system using this Enumservice MUST be clear from the protocol.
>
> A good indication that an Enumservice belongs to this Class is the
> fact that a client does not need to understand the actual application
> to make use of an instance of this Enumservice.
>
> Examples of such Enumservices include XMPP [RFC4979] and SIP
> [RFC3764].
>
> 4.2.2.1. Protocol-based Enumservice "Type" Strings
>
> A protocol-based Enumservice SHOULD use the lowercased name of the
> protocol as its Type name.
Language: For a protocol-based Enumservice the Type SHOULD be specified as
the lowercased name of the base protocol.
Why lowercased when the field is case insensitive?
> 4.2.2.2. Protocol-based Enumservice "Subtype" Strings
>
> Where there is a single URI Scheme associated with this protocol,
> then the Enumservice SHOULD NOT use a Subtype.
>
> Where there are a number of different URI Schemes associated with
> this protocol, the Registration MAY use the empty Subtype for all URI
> Schemes that it specifies as mandatory to implement. For each URI
> Scheme that is not mandatory to implement a distinct Subtype string
> MUST be used.
Language: Enumservice/Registration "use" Subtypes
Where there is a single URI Scheme associated with this protocol,
a Subtype SHOULD NOT be specified for the Enumservice.
> 4.2.3. Application-based Enumservice Classes
[...]
> Another example is sms, where the presence of such an Enumservice
> indicates that the publishing entity is capable of engaging in
Clarification needed: what's meant by "presence of such an Enumservice"?
> 4.2.3.2. Application-based Enumservice "Subtype" Strings
>
> It is RECOMMENDED to use the URI Scheme(s) which the application
> uses, as Subtype name(s). Subtype names SHOULD be shared only
> between URI Schemes that the Registration specifies as mandatory to
> implement for a given Subtype.
NIT: "SHOULD be shared only" better expressed by "MAY be shared", therwise
it's inconsistent with the previous sharing requirement.
> 4.2.4.2. Data- / Format-based Enumservice "Subtype" Strings
>
> It is RECOMMENDED to use the URI Schemes used to access the service
> as Subtype name. Subtype names SHOULD be shared only between URI
SHOULD ... only: see above
> 5. Required Sections and Information
>
> In addition to the sections required for an RFC as outlined in
> [RFC2223] and [instructions2authors] "Instructions to RFC Authors",
> there are several sections that MUST appear in an Enumservice
> Registration Document. These sections are as follows, and SHOULD be
> in the given order.
Given that non-RFC sepcifications are allowed, as well, it should be
clarified how far the references above should be applied normatively
to those specificatins.
> 5.2. IANA Registration (MANDATORY)
>
> This section MUST be included in an Enumservice Registration. Where
> a given Enumservice Type has multiple Subtypes, there MUST be a
> separate 'IANA Registration' section for each Subtype. The following
> lists the fields and order of an 'IANA Registration' section.
>
>
>
> o Enumservice Class:
>
> This field contains the Class of the Enumservice as defined in
> Section 4.2. It's value MUST be one of (without quotes):
>
> * "Protocol-based": The Enumservice belongs to the Protocol-based
> class as described in Section 4.2.2.
>
> * "Application-based, Common": The Enumservice is a "common" case
> of the Application-based class as described in Section 4.2.3.
>
> * "Application-based, Subset": The Enumservice belongs to the
> "subset" case of the Application-based class as described in
> Section 4.2.3.
>
> * "Application-based, Ancillary": The Enumservice is an
> "ancillary" case of the Application-based class, as described
> in Section 4.2.3.
>
> * "Data- / Format-based": The Enumservice belongs to the Data- /
> Format-based class as described in Section 4.2.4.
>
> * "Other": The majority of the functionality of the Enumservice
> does not fall into one of the classes defined.
>
> e.g.
> Protocol-based
I've never understood why this information needs to be recorded, but so be it.
When the tag is yo be used verbatimly, "Data- / Format-based" should be
condensed to a single token.
The example comes as a surprise a bit. In fact, the step-by-step walk-through
might deserve a subsubsection number per field and some complete examples
at the end of section 5.2.
> o Enumservice Type:
>
> The Type of the Enumservice. All Types SHOULD be listed in lower-
> case. The choice of Type depends on the Enumservice Class.
> Please find further instructions in Section 4.
>
> e.g.
> "foo"
>
> Note: Put the Type string between double quotes.
Why? And does "Note" imply "MUST"?
> o Enumservice Subtype:
>
> The Subtype of the Enumservice. All Subtypes SHOULD be listed in
> lower-case. The choice of Subtype depends on the Enumservice
> Class. Please find further instructions in Section 4.
>
> e.g.
> "bar"
>
> e.g.
> N/A
>
> Note: Put the Subtype string between double quotes.
>
> Note: Many Enumservices do not require a Subtype; use "N/A" in
> this case.
What if the empty subtype is registered in addition to others?
Also, see questions for "Type".
> o URI Scheme(s):
>
> The URI Schemes that are used with the Enumservice. The selection
> of URI Schemes often depends on the Enumservice Class, Type,
> and/or Subtype. Please find further instructions in Section 4.
>
> 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.
Maybe add a reference to DDDS [RFC 3402] here.
> * "COMMON": Indicates that the Enumservice is intended for
> widespread use on the public Internet, and that it's scope is
NIT: its
> o Registration Document(s):
>
> A *unique* reference to the Enumservice Registration Document.
>
> e.g.
> [RFC 9999]
>
> e.g.
> [RFC 7777] (Obsoleted by RFC 8888)
> [RFC 8888] (Updated by RFC 9999)
> [RFC 9999]
Now, is the intention here to list the history of the underlying protocol
or the enumservice registration? How is who supposed to track and update
this field?
> 5.3. Examples (MANDATORY)
>
> This section MUST show at least one example of the Enumservice being
> registered, for illustrative purposes. The example(s) shall in no
> way limit the various forms that a given Enumservice may take, and
> this should be noted at the beginning of this section of the
> document. The example(s) MUST show the specific formatting of the
> intended NAPTRs (according to [RFC3403] and [I-D.ietf-enum-3761bis]),
> including one or more NAPTR example(s), AND a brief textual
> description, consisting of one or more sentences written in plain
> English, explaining the various parts or attributes of the record(s).
>
> The example(s) SHOULD contain a brief description how a client
> supporting this Enumservice could behave, if that description was not
> already given in e.g. the Introduction or the Functional
> Specification.
>
> e.g.
> $ORIGIN 9.7.8.0.9.7.8.9.0.9.4.4.e164.arpa.
> @ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" .
With reference to good practice and the pending IESG statement on examples,
some hint for reserved or "drama" numbers should be given here, at least
to the extent not to use numbers in example that could have any meaning
in real life.
> 5.5. Security Considerations (MANDATORY)
[...]
> However, this section is not intended as a general security Best
> Current Practices (BCP) document and therefore it should not include
> general and obvious security recommendations, such as securing
> servers with strong password authentication.
Remove reference to "BCP", since a section never makes a BCP.
> [RFC3552] provides guidance to write a good Security Considerations
> section, Section 10.2 of this document contains guidance specific to
> Enumservice registration.
That's perfectly sufficient!
> 5.8. Other Sections (OPTIONAL)
>
> Other sections, beyond those required by the IETF and/or IANA, which
> are cited or otherwise referenced herein, MAY be included in an
Other sections beyond those required above may be included in an
Enumservice Specification.
> 6. The Process of Registering New Enumservices
>
> This section describes the process by which a new Enumservice is
> submitted for review and comment, how such proposed Enumservices are
> reviewed, and how they are published.
Is this an illustration of the process or a normative description? What
is the difference to BCP26/RFC 5226?
> R-D: Registration Document
I'd rather use the term "Enumservice specification" here to avoid confusion.
> 6.2. Step 2: Write and Submit Registration Document
>
> An Internet-Draft (or another specification as appropriate) MUST be
> written and made publicly available (submitted). The Registration
> Document MUST follow the guidelines according to Section 4 and
> Section 5 of this document. It is RECOMMENDED to use the XML2RFC
> template contained in Appendix A of this document.
This makes implicit assumptions about the IPR of the "Enumservice specification".
> 6.3. Step 3: Request Comments from the IETF Community
>
> The authors MUST send an email to <[email protected]>, in which comments
> on the Registration Document are requested. A proper public
> reference (a URL is RECOMMENDED) to the Registration Document MUST be
> included in this email.
>
> The authors SHOULD allow a reasonable period of time to elapse, such
> as two to four weeks, in order to collect any feedback. The authors
> then consider whether or not to take any of those comments into
> account, by making changes to the Registration Document and
> submitting a revision, or otherwise proceeding. The following
> outcomes are open to the authors. The choice of path is left to the
> authors' judgement.
As an informal consultation this is fine, but at some point in time someone
else but the author needs to step in and actually steer the process and
to actually judge the outcome. That happens as soon as the registration
is requested and an Expert assigned. However, as an informal prelude
this (i.e., 6.3) might be a bit overspecified. Other than that, I don't think
it does any real harm as long as it's clear that, say, an Expert isn't
bound by a "no objections" in this phase.
> 6.5.1. Outcome 1: Experts Approve the Registation
>
> No (more) changes to the Registration Document are made. IANA will
> inform the authors, who then will proceed to Step 6 below.
Now, for transparency, shouldn't the - now official - application go to
the list under the supervision of IANA or the Expert?
> 6.6. Step 6: Publication of the Registration Document
>
> The authors are responsible that the Registration Document is
> published according to 'Specification Required' as defined in
> [RFC5226].
>
> Typically Enumservice Registrations will be published as
> Informational RFC via the Independent Submission process (see also
> [instructions2authors]).
s/Typically/Non-IETF/
> 6.7. Step 7: Adding Enumservice to IANA Registry
>
> In case the specification is published as an RFC, the RFC publication
> process ensures that IANA will add the Enumservice to the Registry.
>
> If the specification will not be published as an RFC, the authors
> MUST inform IANA, as soon as the Registration Document has been
> published according to 'Specification Required' as defined in
> [RFC5226]. The 'Registration Document(s)' field in the IANA Template
> MUST contain a unambiguous reference to the Registration Document
> (see also Section 5.2). In addition, the authors SHOULD provide IANA
> with a stable URL to the Registration Document. IANA will then add
> the Enumservice to the Registry.
Why is the last SHOULD not a MUST,, except that noone can guarantee stability?
> 7. Expert Review
>
> 7.1. Expert Selection Process
>
> According to Section 3.2 of [RFC5226], experts are appointed by the
> IESG upon recommendation by the RAI Area Directors. The RAI area
> directors are responsible for ensuring that there is always a
> sufficient pool of experts available.
>
> 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].
>
> The experts SHOULD evaluate the criteria as set out in [RFC5226], as
> well as consider the following:
Why not MUST?
> o Verify conformance with the ENUM specification
> [I-D.ietf-enum-3761bis].
>
> o Verify that the requirements set in this document (Section 5) are
> met. This includes check for completeness and whether all the
> aspects described in Section 5 are sufficiently addressed.
Add reference to this draft, Section 3.
> 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].
s/as described/as currently described/; Indeed, it might be better to only
refer to RFC 5226 here.
> 9. Extension of Existing Enumservice Registrations
>
> There are cases where it is more sensible to extend an existing
> Enumservice registration rather than proposing a new one. Such cases
> include adding a new Subtype to an existing Type. Depending on the
> nature of the extension, the original Registration Document needs to
> be extended (Updates) or replaced (Obsoletes) [RFC2223].
This is too RFC centric.
> 11. IANA Considerations
> 11.1.5. Change Control
>
> Change control of any Enumservices Registrations is done by "Expert
> Review" and "Specification Required" according to [RFC5226]. Updates
> of Enumservices Registrations MUST comply with the guidelines
> described in this document. Updates are handled the same way as
> initial Enumservice Registrations.
>
> Authorized Change Controllers are the experts and the IESG.
>
> Enumservice registrations MUST NOT be deleted. An Enumservice that
> is believed no longer appropriate for use, can be declared obsolete
> by publication of a new Enumservices Registrations document changing
> its "Intended Usage" field to "OBSOLETE"; such Enumservices will be
> clearly marked in the lists published by IANA.
Obsoletion of an Enumservice should be subject to the same procedure as
registration.
> 11.1.6. Restrictions
>
> As stated in Section 3.2, a "-" (dash) MUST NOT be used as the first
> nor as the second character of a Type nor a Subtype. Furthermore,
> 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 contains examples for Enumservice registrations.
> Therefore, IANA MUST NOT register an Enumservice with Type or Subtype
> set to "foo", "bar", or "sbar", unless the experts explicitly confirm
> an exception.
Shouldn't the ENUM WG take the opportunity to designate "example" schemes
which will be added to the Registry and thus no longer be available for
registration?
> 11.2. XML2RFC Template
>
> Before publication of this document IANA shall make the XML2RFC
> template in Appendix A publicly available so that authors of new
> Enumservice Registrations can easily download it.
Given all the implications from boilerplate text, I doubt the template
is really helpful. Also, it would introduce maintenance burden for whoever
is tasked (hint!) with keeping this template in sync with xml2rfc and
the IETF's requirements. While I'd assume taht IANA can take care of
the Registration Template, I doubt it's the right place to provide for
specification templates.
> Appendix A. XML2RFC Template for Enumservice Registration
Admittedly, I skipped this.
-Peter