Protocol Action: E.164 number and DNS to Proposed Standard

[The IESG]

The IESG has approved the Internet-Draft 'E.164 number and DNS'
<draft-ietf-enum-e164-dns-03.txt> as a Proposed Standard.  This
document is the product of the Telephone Number Mapping Working Group.
The IESG contact persons are Allison Mankin and Scott Bradner.


Technical Summary
 
 This document defines a way to use the  DNS for storage of E.164 numbers.
 More specifically, it defines how DNS can be used for identifying
 available services related to one E.164 number. Routing of any actual 
 connections using the service selected using these methods is not 
 discussed.

 Through transformation of E.164 numbers into DNS names and the use
 of existing DNS services like delegation through NS records, and use
 of NAPTR records in DNS, one can look up what services are
 available for a specific domainname in a decentralized way with
 distributed management of the different levels in the lookup
 process. The process results in one or more Uniform Resource
 Identifiers being returned to the requester to identify the
 available services.

Working Group Summary

 This proposal was supported by the enum working group and no significant
 issues were raised during IETF last call.

Protocol Quality

 The document was reviewed by Scott Bradner for the IESG.


Notes to RFC Editor:

Prior to publication, please


(1) Replace the string "URL" with "URI"
    (4 occurrances in Section 3.1.2 and 1 in Appendix A


(2) Please change the following text in the IANA Consideration Section 
    (section 4):


From:
    Delegations should be done after Expert Review, and the IESG will
    appoint a designated expert.

to:

    Delegations in the zone e614.arpa (not delegations in delegated
    domains of e164.arpa) should be done after Expert Review, and the
    IESG will appoint a designated expert.


(3) Please change second paragraph in section 5:

From:

    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 and
    SRV[10] records in the zone that is changed. The TTL should because
    of that be kept to a minimum. The use of this in an environment
    where IP-addresses are for hire (for example when using DHCP[11])
    must therefore be done very carefully.

to:

    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 record
    in the zone that is changed. The use of this in an environment
    where IP-addresses are for hire (for example when using DHCP[11])
    must therefore be done very carefully.