IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information
RFC 4769

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...

[Ballot comment]
From Gen-ART review by David Black:

-- IANA-related nits

a) The registrations in Section 4 need to be self-contained, as
they will be extracted into an IANA registry:

http://www.iana.org/assignments/enum-services

So, the "(for author contact detail see Authors' Addresses section)"
text will not work in the registry.  A reference to the to-be-
published RFC with instructions to the RFC-Editor to put in the
actual number and supply that number to IANA for registration
purposes should work.

b) Why does the IANA Considerations section include a reference
to Section 3?  The registrations that IANA needs to process
appear to be entirely contained within Section 4.

From id-nits:

  - Unused Reference: '9' is defined on line 449, but not referenced
  - Unused Reference: '12' is defined on line 460, but not referenced
  - Unused Reference: '16' is defined on line 472, but not referenced

[Ballot discuss]
All the examples use an npdi to prevent subsequent lookups
in legacy-style PSTN databases.  If an npdi is something that
should or SHOULD be used with this enumservice in general, that
ought to be stated, possibly in the "Any other information the
author deems interesting:" fields of the registrations (Section 4).

If it isn't a SHOULD, then it is anomalous that *all* the examples
use it.

(from Gen-ART review by David Black)

[Ballot comment]
From Gen-ART review by David Black:

-- IANA-related nits

a) The registrations in Section 4 need to be self-contained, as
they will be extracted into an IANA registry:

http://www.iana.org/assignments/enum-services

So, the "(for author contact detail see Authors' Addresses section)"
text will not work in the registry.  A reference to the to-be-
published RFC with instructions to the RFC-Editor to put in the
actual number and supply that number to IANA for registration
purposes should work.

b) Why does the IANA Considerations section include a reference
to Section 3?  The registrations that IANA needs to process
appear to be entirely contained within Section 4.

[Ballot comment]
RFC 3761 which includes the IANA registration process upon which the content of this work is based is mentioned several times in the text without the appropriate reference number [1].

[Ballot comment]
Section 11.1, paragraph 0:

11.1 Normative References

        Nit: idnits says:
        Unused Reference: [9] is defined on line 449, but not referenced
        Unused Reference: [12] is defined on line 460, but not referenced
        Unused Reference: [16] is defined on line 472, but not referenced

[Ballot comment]
I think the examples numbers used in this draft need a pass to check that none of them could ever be numbers assigned to a real phone.

[Ballot discuss]
> The purpose of this Enumservice is to describe information
>  about telephone numbers which cannot be used on the public Internet
>  or a private/peered Internet Protocol (IP) network.  Thus, these are
>  numbers which are only reachable via the traditional PSTN.


How can you reach a number using SIP without either being on the
public internet or a private IP network?  How does this enum service
differ from existing enum services for call routing?


This document does not follow appropriate guidelines for example e.164
numbers; I noticed at least one instance of 555-1212 in country code
1; that is clearly not an appropriate example e.164 number.  Please
update and confirm all numbers have been checked as valid e.164
examples.

PROTO Write-up

1. Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready to
forward to the IESG for publication?

Yes .. in fact one of the chairs is a co-author.

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

Yes. The document is part of a ongoing series of Enumservice
registrations and as such is generally non controversial

3. Do you have any concerns about the depth or breadth of the reviews
that have been performed?

No. The item has been discussed twice in face to face WG meetings and
extensively on the list.

4. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

5. Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or have concerns
whether there really is a need for it. In any event, if your issues have
been discussed in the WG and the WG has indicated it that it still
wishes to advance the document, detail those concerns in the write-up.

Yes and No. The issues that may concern the IESG are those that data
elements that may or may not and in some cases cannot be exposed to the
general Internet by contract or regulatory mandate. It is useful then
for the IESG to understand the overall context that this draft was
developed under.

This draft relates to some unique conditions in the North America but
clearly has applicability going forward to those countries looking at
database oriented Local Number Portability models.

In addition it touches on a rather unique twist in how some carriers now
view the use of DNS technology in general in the context of RFC 3761

The technical as well as business case for this standard is to eliminate
SS7 queries a much as possible from the VoIP network The driver for
this particular draft was the desire by some US and Canadian Carriers,
principally the to have internal access to Number Portability
Administration Center [NPAC] LNP data in an all IP format and structure.
SS7 TCAP queries are becoming a unacceptable variable cost to a service
providers with the kind of fixed price model that some operators are now
using.

The technique described in this draft can eliminates LNP TCAP queries
at the edge of the VoIP network by deploying either a private DNS
servers, protected by VPN or subnets and/or fully cached copies of the
LNP database in DNS servers directly attached to their SIP Soft
Switches. This is form 'private ENUM' if you want to call it that. If
the LNP query is done inside the VoIP network at call origination the
proxy can signal the Media GW at the network edge what the true Local
Routing Number [LRN] is and route accordingly without any additional
number translations or TCAP queries. The elimination of these TCAP
queries provides operators remarkable cost savings.

In classic PSTN terms the thrust of this draft and others to follow
provide a model for any and all information about an E.164 named
endpoint, PSTN or IP URI based at call origination.

The fully cached DNS database in the operators infrastructure
essentially creates the equilivant of a IP-Service Control Point or
IP-SCP in the carrier network that actually performs the same number
translation functions as an Intelligent Network SCP but does not use
TCAP. There is such a need for a signaling database within the IMS
architecture, but that role and function has not been formalized yet in
3gPP.

In addition, the network operator gains probably 10-40 MS on the
transaction latency as well if the database is fully cached inside the
SP network vs queried externally.

6. 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?

It represents a strong concurrence of a few individuals that understand
the draft and the underlying need for it. Though other members of the WG
understand its unique context they are general silent and do not oppose
its moving forward.

7. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email to the Responsible Area Director.

No

8. Have the chairs verified that the document adheres to all of the ID
Checklist items ?

NIT and ID Checklist review preformed by WG Secretary and reviewed my
myself.

9. Is the document split into normative and informative references? Are
there normative references to IDs, where the IDs are not also ready for
advancement or are otherwise in an unclear state? (note here that the
RFC editor will not publish an RFC with normative references to IDs, it
will delay publication until all such IDs are also ready for publication
as RFCs.)

Yes . The document is split into normative and informative references
there are normative references to ID currently under IESG review.

10. What is the intended status of the document? (e.g., Proposed
Standard, Informational?)

Proposed Standard

11. For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following sections:
o Technical Summary
o Working Group Summary
o Protocol Quality
Please provide such a write-up. Recent examples can be found in the
"protocol action" announcements for approved documents.


Technical Summary

This Enumservice is used to facilitate the routing of telephone calls
within in VoIP networks in those countries where Number Portability
exists.This data could be place into externally available or highly
locally cached ENUM databases. This, in turn, could enable such parties
to consolidate all telephone number lookups in their networks into a
single ENUM lookup, thereby simplifying call routing and network
operations, which would then result in either an on-net, or IP-based
response, or off-net, PSTN-based response.

Working Group Summary

The working group reviewed this document extensively in 2005 and was
document NIT review preformed by Alexander Mayrhofer
Protocol Quality

A significant number of North American service providers have indicated
a strong interest in implementing this protocol and a number of vendors
are already in implementation trials.