The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
RFC 6116

This draft is ready to be approved. However, changes on draft-ietf-enum-enumservices-guide during its IESG evaluation might trigger small changes on this draft (3761bis). I will wait and approve the three drafts in the cluster at the same time.

[Ballot discuss]
[Added another item (# 5), other points are unchanged and I am happy so far with the resolution proposed by authors.]

I have a small set of blocking issues which should be straightforward to fix:

1) 3.3.  Expected Output

  The output of the last DDDS loop is a Uniform Resource Identifier in
  its absolute form according to the  production in the
  Collected ABNF found in [RFC3986].

The  production was obsolete in RFC 3986,
it should be replaced with .

2) 3.4.  Valid Databases

  The charset used for the substitution expression is UTF-8.

This is lacking a normative reference to RFC 3629 (UTF-8).

3) 3.4.3.  Services Parameters

  Service Parameters for this Application take the following form and
  are found in the Services field of the NAPTR record that holds a
  terminal rule.  Where the NAPTR holds a non-terminal Rule, the
  Services field SHOULD be empty, and clients SHOULD ignore its
  content.

This requires a Normative reference to RFC 5234 (ABNF).

4) 3.6.  Case Sensitivity in ENUM

  The only place where NAPTR field content is case sensitive is in any
  static text in the Repl sub-field of the Regexp field (see Section
  3.2 of [RFC3402] for Regexp field definitions).  Everywhere else,
  case-insensitive processing SHOULD be used.

Why is the last requirement a SHOULD and not a MUST? Do you know of any reason why an implementation might violate it?

(After discussing this with authors we agreed that the SHOULD can stay, but additional explanation on deployments withing enterprises should be added to explain when the SHOULD is violated in real world.)

5) In Section 5.1:

  If ENUM zone provisioning systems require non-ASCII characters,
  these systems SHOULD encode the non-ASCII data to emit only
  US-ASCII characters by applying the appropriate mechanism
  ([RFC3492], [RFC3987]).

s/SHOULD/MUST, in order to guaranty that the valid output is always in US-ASCII. If the valid output is not US-ASCII, then some extra text
about handling of IRIs and (possibly) about IDNA2003/IDNA2008 domains
would be needed.

[Ballot discuss]
[Added another item (# 5), other points are unchanged and I am happy so far with the resolution proposed by authors.]

I have a small set of blocking issues which should be straightforward to fix:

1) 3.3.  Expected Output

  The output of the last DDDS loop is a Uniform Resource Identifier in
  its absolute form according to the  production in the
  Collected ABNF found in [RFC3986].

The  production was obsolete in RFC 3986,
it should be replaced with .

2) 3.4.  Valid Databases

  The charset used for the substitution expression is UTF-8.

This is lacking a normative reference to RFC 3629 (UTF-8).

3) 3.4.3.  Services Parameters

  Service Parameters for this Application take the following form and
  are found in the Services field of the NAPTR record that holds a
  terminal rule.  Where the NAPTR holds a non-terminal Rule, the
  Services field SHOULD be empty, and clients SHOULD ignore its
  content.

This requires a Normative reference to RFC 5234 (ABNF).

4) 3.6.  Case Sensitivity in ENUM

  The only place where NAPTR field content is case sensitive is in any
  static text in the Repl sub-field of the Regexp field (see Section
  3.2 of [RFC3402] for Regexp field definitions).  Everywhere else,
  case-insensitive processing SHOULD be used.

Why is the last requirement a SHOULD and not a MUST? Do you know of any reason why an implementation might violate it?

5) In Section 5.1:

  If ENUM zone provisioning systems require non-ASCII characters,
  these systems SHOULD encode the non-ASCII data to emit only
  US-ASCII characters by applying the appropriate mechanism
  ([RFC3492], [RFC3987]).

s/SHOULD/MUST, in order to guaranty that the valid output is always in US-ASCII. If the valid output is not US-ASCII, then some extra text
about handling of IRIs and (possibly) about IDNA2003/IDNA2008 domains
would be needed.

[Ballot discuss]
[Added another item (# 5), other points are unchanged and I am happy so far with the resolution proposed by authors.]

I have a small set of blocking issues which should be straightforward to fix:

1) 3.3.  Expected Output

  The output of the last DDDS loop is a Uniform Resource Identifier in
  its absolute form according to the  production in the
  Collected ABNF found in [RFC3986].

The  production was obsolete in RFC 3986,
it should be replaced with .

2) 3.4.  Valid Databases

  The charset used for the substitution expression is UTF-8.

This is lacking a normative reference to RFC 3629 (UTF-8).

3) 3.4.3.  Services Parameters

  Service Parameters for this Application take the following form and
  are found in the Services field of the NAPTR record that holds a
  terminal rule.  Where the NAPTR holds a non-terminal Rule, the
  Services field SHOULD be empty, and clients SHOULD ignore its
  content.

This requires a Normative reference to RFC 5234 (ABNF).

4) 3.6.  Case Sensitivity in ENUM

  The only place where NAPTR field content is case sensitive is in any
  static text in the Repl sub-field of the Regexp field (see Section
  3.2 of [RFC3402] for Regexp field definitions).  Everywhere else,
  case-insensitive processing SHOULD be used.

Why is the last requirement a SHOULD and not a MUST? Do you know of any reason why an implementation might violate it?

5) In Section 3.4:

  The charset used for the substitution expression is UTF-8.

It seems (and also based on a message from Patrik Falstrom) that the output of ENUM resolution can be an IRI, which means that it might contain non US-ASCII characters encoded in UTF-8. Please clarify if this is the case.

Also please clarify whether the hostname part of such IRIs comply with IDNA2003 or IDNA2008

  The
  allowed input characters are all those characters that are allowed
  anywhere in an E.164 number.  The characters allowed to be in a Key
  are those that are currently defined for DNS domain names.

[Ballot discuss]
[Added another item (# 5)]

I have a small set of blocking issues which should be straightforward to fix:

1) 3.3.  Expected Output

  The output of the last DDDS loop is a Uniform Resource Identifier in
  its absolute form according to the  production in the
  Collected ABNF found in [RFC3986].

The  production was obsolete in RFC 3986,
it should be replaced with .

2) 3.4.  Valid Databases

  The charset used for the substitution expression is UTF-8.

This is lacking a normative reference to RFC 3629 (UTF-8).

3) 3.4.3.  Services Parameters

  Service Parameters for this Application take the following form and
  are found in the Services field of the NAPTR record that holds a
  terminal rule.  Where the NAPTR holds a non-terminal Rule, the
  Services field SHOULD be empty, and clients SHOULD ignore its
  content.

This requires a Normative reference to RFC 5234 (ABNF).

4) 3.6.  Case Sensitivity in ENUM

  The only place where NAPTR field content is case sensitive is in any
  static text in the Repl sub-field of the Regexp field (see Section
  3.2 of [RFC3402] for Regexp field definitions).  Everywhere else,
  case-insensitive processing SHOULD be used.

Why is the last requirement a SHOULD and not a MUST? Do you know of any reason why an implementation might violate it?

5) In Section 3.4:

  The charset used for the substitution expression is UTF-8.

It seems (and also based on a message from Patrik Falstrom) that the output of ENUM resolution can be an IRI, which means that it might contain non US-ASCII characters encoded in UTF-8. Please clarify if this is the case.

Also please clarify whether the hostname part of such IRIs comply with IDNA2003 or IDNA2008

  The
  allowed input characters are all those characters that are allowed
  anywhere in an E.164 number.  The characters allowed to be in a Key
  are those that are currently defined for DNS domain names.

[Ballot comment]
Please consider the issues brought up by Ari Keränen in his review:

1. Introduction

Abbreviations not opened (NAPTR, NS, SOA).

3.2.

    1.  Remove all characters with the exception of the digits.  For
        example, given the E.164 number "+44-20-7946-0148", this step
        would simply remove the leading '+', producing "442079460148".

Should say "[...] simply remove the leading '+' and all '-'"?

    2.  Reverse the order of the digits.  Example: "841064970244"
    3.  Put dots ('.') between each digit.  Example:
        "4.4.2.0.7.9.4.6.0.1.4.8"

The digits in step 3 should also be in the reversed order?


3.4.3. Services Parameters

        service-field = "E2U" 1*(servicespec)
        servicespec  = "+" enumservice
        enumservice  = type 0*(subtypespec)
        subtypespec  = ":" subtype
        type          = 1*32(ALPHA / DIGIT / "-")
        subtype      = 1*32(ALPHA / DIGIT / "-")

Missing ABNF reference. Is the lack of upper limit for number of
servicespecs and substypespecs intentional?

[Ballot comment]
minor comments...

I suggest adding a few words  explaining how this doc updates RFC3761, similar to the explanation in the IESG Writeup; e.g., "This document updates RFC3762 to reflect major operational issues discovered during deployment."

(mostly a curiosity question) The IESG Writeup notes that "RFC 3761 is in wide global deployment".  Have the updates in this document been widely deployed?  Have they caused any interoperability issues with deployments that have not been updated?

In section 3.2:

  In order to convert the AUS to a unique key in this database the
  string is converted into a domain name according to this algorithm:

  1.  Remove all characters with the exception of the digits.  For
      example, given the E.164 number "+44-20-7946-0148", this step
      would simply remove the leading '+', producing "442079460148".

Aren't the "-" characters also removed in this example?  I.e., "this step
would simply remove the leading '+' and internal '-' characters" ?

[Ballot discuss]
This is a Discuss-Discuss

The telephone number +44-3069-990038 seems to be a currently unallocated, but potentially valid, number in the UK dialing plan. It is a different number than that used in RFC3761.

The question arises as to whether this is a well known example telephone number, and if not, whether its use conforms to the IETF policy on examples.

[Ballot discuss]
This is a DISCUSS-DISCUSS.  To be clear there is nothing for the authors to do at this time.

How can this document and draft-ietf-enum-enumservices-guide both obsolete RFC 3761?

[Ballot comment]
A number of acronyms are not expanded at their first occurance. For example: NS, NAPTR, SOA, FQDN (expanded in 3.1, but that is not the first occurance), ABNF, ITU-T TSB.

[Ballot discuss]
The document is complete and clear, but there are a number of issues in the Security Considerations section that need attention before I can enter an approval ballot:

1. in section 7.1 I find the following paragraph:

>  Even if DNSSEC is deployed, a service that uses ENUM for address
  translation should not blindly trust that the peer is the intended
  party as DNSSEC deployment cannot protect against every kind of
  attack on DNS.  A service should always authenticate the peers as
  part of the setup process for the service itself and never blindly
  trust any kind of addressing mechanism.

The other paragraphs in this section use capitalized 2119 keywords - why are they not used here? 'should always' sounds bad in IETF-speak - we use 'must' and probably MUST in this context.

2. Section 7.2:

>  The caching in DNS can make the propagation time for a change take
  the same amount of time as the time to live for the NAPTR records in
  the zone that is changed.  The use of this in an environment where
  IP-addresses are dynamically assigned (for example, when using DHCP
  [RFC2131]) must therefore be done very carefully.

I do not understand what 'must ... be done very carefully' means - I believe that there is a need for different text here.

[Ballot discuss]
I have a small set of blocking issues which should be straightforward to fix:

1) 3.3.  Expected Output

  The output of the last DDDS loop is a Uniform Resource Identifier in
  its absolute form according to the  production in the
  Collected ABNF found in [RFC3986].

The  production was obsolete in RFC 3986,
it should be replaced with .

2) 3.4.  Valid Databases

  The charset used for the substitution expression is UTF-8.

This is lacking a normative reference to RFC 3629 (UTF-8).

3) 3.4.3.  Services Parameters

  Service Parameters for this Application take the following form and
  are found in the Services field of the NAPTR record that holds a
  terminal rule.  Where the NAPTR holds a non-terminal Rule, the
  Services field SHOULD be empty, and clients SHOULD ignore its
  content.

This requires a Normative reference to RFC 5234 (ABNF).

4) 3.6.  Case Sensitivity in ENUM

  The only place where NAPTR field content is case sensitive is in any
  static text in the Repl sub-field of the Regexp field (see Section
  3.2 of [RFC3402] for Regexp field definitions).  Everywhere else,
  case-insensitive processing SHOULD be used.

Why is the last requirement a SHOULD and not a MUST? Do you know of any reason why an implementation might violate it?

Document Shepherd Write-Up:
1A. Who is the Document Shepherd for this document?
--Richard Shockey

1B. Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?
--Yes

2A. Has the document had adequate review both from key WG members and from key non-WG members?
--Yes

2B. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
--No

3 - Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?
--No  The document is a update of RFC 3761.

4A. Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No additional areas of concern expept as noted further.


4B. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG
discussion and conclusion on this issue.

--No, IPR disclosures have been filed.

5 - How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

--Consensus, One outstanding objection related to ambiguities in the DDDS. The objection was not considered critical to advancing the document.

See:

http://www.ietf.org/mail-archive/web/enum/current/msg06908.html

http://www.ietf.org/mail-archive/web/enum/current/msg06879.html


6 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.)
--No

7A. Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html
and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough.
--Yes

7B. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews?
--Yes

7C. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.
--Intended status is Proposed Standard

8A. Has the document split its references into normative and informative?
--Yes

8B. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
--No

8C. If such normative references exist, what is the strategy for their completion?
--N/A

8D. Are there normative references that are downward references, as described in [RFC3967]?
--No

8E. If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].
--N/A

9A. Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document?
--Yes

9B. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?
--Yes

9C. Are the IANA registries clearly identified?
--Yes

9D. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future
registrations?
--
N/A this document and related documents noted in 9E updates the existing IANA Enumservices registry.

9E. Does it suggest a reasonable name for the new registry? See [RFC2434].

--N/A see related drafts


http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-transition-01.txt


http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-16.txt


9F. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

- Yes.. Expert Review process for this draft are covered in separate documents noted in 9E. above. Sheparding AD has been alerted.

10 - Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?
--Yes

================================================================
Document Announcement Write-Up:

1 - Technical Summary

This document discusses the use of the Domain Name System (DNS) for  the storage of E.164 [E164] numbers, and for resolving them into URIs  that can be used for (for example) telephony call setup.  This  document also describes how the DNS can be used to identify the  services associated with an E.164 number. This document includes a  Dynamic Delegation Discovery System (DDDS) Application specification,  as detailed in the document series described in [RFC3401]. This  document obsoletes [RFC3761].



2 - Working Group Summary

Was there anything in the discussion in the interested community that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Was the document considered in any WG, and if so, why was it not adopted as a work item there?

In general except where noted this document represents a exxelent effort to update RFC 3761 on the basis of real operational experiences and represents the effort of the ENUM WG to close its charter and declare victory.


3 - Document Quality.

Are there existing implementations of the protocol? Have a      significant number of vendors indicated their plan to implement        the specification? Are there any reviewers that merit special        mention as having done a thorough review, e.g., one that        resulted in important changes or a conclusion that the document        had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? 
 

AS noted document reflects and updates RFC 3761 to reflect major operational issues discovered during deployment. RFC 3761 is in wide global deployment within e164.arpa as well in private instantiations within in global carrier networks.


4 ? Personnel

Document Shepherd: Richard Shockey
Responsible AD: Cullen Jennings

IANA Experts Required: Yes as noted in 9D.

IANA comments:

The IANA Considerations section says, "Delegations in the zone
e164.arpa (not delegations in delegated domains of e164.arpa)
should be done after Expert Review, and the IESG will appoint a
designated expert." However, we have been instructed to delegate
the e164.arpa zone to the RIPE NCC. As such, any management
instructions should be directed at them rather than us. We cannot
arrange for the Expert Review requirement specified required here.

We understand that this document does not require any IANA actions.

Posted related IPR disclosure: Comcast IP Holdings I, LLC's Statement about IPR related to RFC 3953, RFC 4415, RFC 4759, RFC 4769, RFC 4002, RFC 4355, RFC 4414, RFC 4725, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5346, RFC 5067, RFC 5076, RFC 5105, RFC 2168, RFC 3401, RFC 3402, RF...

Title : The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application (ENUM)
Author(s) : S. Bradner, et al.
Filename : draft-ietf-enum-3761bis-03.txt
Pages : 22
Date : 2008-03-31

This document discusses the use of the Domain Name System (DNS) for the
storage of E.164 numbers, and for resolving them into URIs that can be used
for (for example) telephony call setup. This document also describes how
the DNS can be used to identify the services associated with an E.164
number. This document obsoletes RFC 3761.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-03.txt


A three week WG last call on this document concluded on June 5 2008.

The document listed above is being considered for Proposed Standard status.

This document has been extensively discussed during 2006-2008.