On Tue, 26 May 2009, The IESG wrote:
- 'IANA Registration of Enumservices: Guide, Template and IANA
Considerations '
draft-ietf-enum-enumservices-guide-16.txt as a Proposed Standard
This is an ops-dir review. I'm only superficially familiar with ENUM,
so take the comments with a grain of salt. I did not see major issues
with the document, but the document could be improved by a clarifying
revision.
Wrt. operational considerations, given that the document deals with
IANA registrations, I do not see much that should be a cause for
concern. Registration documents must include a section on DNS
considerations, which could possibly discuss some operational aspects
as well (some of this below). Personally identifiable information has
already been highlighted in the document. Management-side of OM does
not appear to be relevant in this case. The usability and control of
enum from users' point of view is a possible issue but that goes
beyond the scope of this document.
Some specific comments below:
substantial
---
5.7. DNS Considerations (MANDATORY)
.. I note that exampe DNS considerations mostly relate to DNS protocol. I
wonder about DNS operations related considerations. For example, is the
usage expected to incur a significant (quantifiable?) load on the name
server chain? Are there recommendations/restrictions/assumptions wrt TTL of
the records (somewhat related to the previous)?
Further I assume that DNS records related to the enum services are static
in such a fashion that they can be protected if needed by DNSSEC signing.
Is this a correct assumption? There is no clear prohibition of defining
synthetic or synthethizing DNS records that would be generated on the fly.
(I'm not sure if this would even be interesting to someone...)
semi-editorial
--
This document specifies a revision of the IANA Registry for
Enumservices, which was originally described in [RFC3761]. This
document obsoletes Section 3 of RFC 3761.
.. yet in the header it says Obsoletes: 3761. What about the rest of 3761?
I'd say it's best that the whole 3761 gets obsoleted in some manner.
The IETF's ENUM Working Group has encountered an unnecessary amount
of variation in the format of Enumservice Specifications. The ENUM
Working Group's view of what particular information is required
and/or recommended has also evolved, and capturing these best current
practices is helpful in both the creation of new Enumservice
Specifications, as well as the revision or refinement of existing
Enumservice Specifications.
.. yet the revision of existing Enumservices Specification is only touched
upon in Section 8, which says doing the revision is a MAY. Is this
sufficient? (After reading the whole doc, it appears that there is an
effort in progress to revise these, but it is not clear if that process is
exhaustive.)
In Section 9, you describe extension of existing enumservices.
If an enum service is extended, does the extended version need to comply
with this document (Section 8 could be read to imply that but this is not
100% clear)?
Types and Subtypes MUST conform to the ABNF specified in
[I-D.ietf-enum-3761bis].
The ABNF specified in [I-D.ietf-enum-3761bis] allows the - (dash)
character for Types and Subtypes .
.. when I search for ABNF in I-D.ietf-enum-3761bis, I come up with one
hit, and it seems to be in an irrelevant spot. I'm not sure if ABNF is
defined clearly enough in I-D.ietf-enum-3761bis (and that document could be
improved); in addition, given this is not very clear, I'd suggest a more
specific reference in this document (e.g. pointing to specific sections of
3761bis one should conform to).
6.5.3. Outcome 3: Experts Reject the Registration Document
The expert might reject the Registration, which means the Expert
Review Process is discontinued. For appeals, see Section 7.3.
.. I'm not sure in which case the result might be a rejection instead of
changes needed, but should you also point to some other recourse other
than the appeals process? For example, Go back to step 1 and
reconsider whether a registration is needed. :-)
7.2. Review Guidelines
.. one of the things that could perhaps be explicitly listed here is
verifying that the type name does not conflict with any well-known other
name (e.g. the example given in the document where imap was proposed for
internet mapping service).
11.1.4.2. Published as generic Specification
.. in S 11.1.2 you require IANA to escrow the specification, so I guess it
should be stated in the required IANA steps in the last paragraph of this
section as well.
13.1. Normative References
[RFC2223] Postel, J. and J. Reynolds, Instructions to RFC Authors,
RFC 2223, October 1997.
.. this is a down-ref problem: BCP referring to an informational document.
Is this critical for understanding this document? If not, it could be moved
to an informative reference.
editorial
