Re: Working Group Last Call on enumservices guide 12

Peter ... why the change to BCP vs Proposed Standard. I think this is
exactly the kind of draft that requires PS.

In any event WGLC is now over. I'm wondering if the authors want to
incorporate any of Peter's suggestions into a 13 version before the chairs
request publication.

>  -----Original Message-----
>  From: [email protected] [mailto:[email protected]] On Behalf
>  Of Peter Koch
>  Sent: Sunday, September 21, 2008 1:45 PM
>  To: IETF ENUM WG
>  Subject: Re: [Enum] Working Group Last Call on enumservices guide 12
>  
>  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
>  _______________________________________________
>  enum mailing list
>  [email protected]
>  https://www.ietf.org/mailman/listinfo/enum