Hi IESG members, folks,
I'm one of the authors of the draft, so this is rather odd. But...
as per request, I'm pushing this issue as a comment into the IETF
LC/IESG review for draft rfc3761bis. This has an error that should be
fixed and has caused confusion.
draft rfc3761bis-04 inherits a lot of text directly from rfc3761.
In particular, the DDDS application template specifications covered in
rfc3761bis-04 sections 2.1, 2.2, 2.3 and 2.4 define respectively the
Application Unique String (AUS), the First Well Known Rule, expected
output of this application, and the Rules database & the way that
record fields are used. Unsurprisingly, large chunks of this came
straight from rfc3761.
Unfortunately, these sections include a bug that has been present since
rfc3761.
ENUM (as defined in rfc3761 and in rfc3761bis) is a DDDS application,
and so has to fit within the DDDS framework.
DDDS states that the "First Well Known Rule" is used to turn the AUS
into a key that is used to query the database.
Unfortunately, rfc3761 describes this as identity -- given that the AUS
is a string holding a telephone number, this is NOT going to produce a
suitable domain name. It was wrong then and rfc3761bis-04 inherits this
error.
rfc3761 then goes on to describe how keys into the database are used;
it shows how a telephone number can be converted into a domain name
that can be queried in DNS. For most cases the two steps will cancel
out each other's errors.
However, non-terminal NAPTRs generate domain names that are then
queried to get the "next round" of NAPTRs. If the steps described in
the database section are applied to those domain names then the result
will not be what was intended -- in effect, it reverses the telephone
number as it re-constructs an "ENUM domain".
What *should* be present is a description of the first well known rule
that does create a domain name (i.e. including the steps currently in
the database section), and the database section should just refer to
rfc3403 -- this database is the DNS and is unsurprisingly used as
expected, i.e. domains are queried for NAPTRs, and those NAPTRs hold
DDDS rules.
This is a relatively simple bug fix, has no impact at all on the vast
majority of ENUM systems that do not hold or use non-terminal NAPTRs,
whilst permitting ENUM to work correctly with non-terminal NAPTRs where
it is, at best, ambiguous at present.
Proposed text for this fix can be found in:
<http://www.ietf.org/mail-archive/web/enum/current/msg06908.html>.
That text should replace the existing section 2.1 through to the end of
section 2.4. The main changes are to sections 2.2 and 2.4 (which loses
the misplaced 2.4.1 and so subsequent sub-sections are renumbered).
Finally, is it worth raising an erratum against rfc3761 as well, when
rfc3761bis is intended to replace it and can incorporate this fix RSN?
all the best,
Lawrence
On 26 May 2009, at 15:12, The IESG wrote:
The IESG has received a request from the Telephone Number Mapping WG
(enum) to consider the following document:
- 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM) '
<draft-ietf-enum-3761bis-04.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the
ietf(_at_)ietf(_dot_)org mailing lists by 2009-06-09. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf