Subject: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement?

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 6 Nov 2006 17:54:49 -0500

Follow-up on discussion of this I-D at the WG session today.  It seems
like the chairs and AD are asking whether or not people feel strongly
about this particular service and will actually use it, as it will take
time & energy to overcome concerns raised through the I-D review process
(concerns which will surely be raised again in later reviews in the
process).

So perhaps I can propose we step back for a moment, considering the need
for void or not as an enumservice type?  Here I think the best starting
point is for everyone to re-read section 3 of the draft, called "The
Problem" and decide whether or not there is agreement on that problem.
If so, we can *then* decide if void solves that problem or not, but we
have to first at least agree on the problem.  Here is that text, FYI:

3.  The Problem

   At present, from the ENUM client's perspective, two possibilities
   exist: there is an ENUM domain that potentially holds alternative
   contacts, or there is no ENUM domain, in which case a query on ENUM
   will return a DNS response showing 'no such domain' (NXDOMAIN, code
   3)[4].

   This latter response is ambiguous.  There are two potential reasons
   for the lack of an ENUM domain holding alternative contacts; either
   the assignee has chosen not to register the domain, or the E.164
   number is not assigned for communications service at present.

   If the number is assigned, then the caller can use the E.164 number
   to place the call via a network that uses such identifiers as global
   addresses (i.e. the CSN).  If however, there is no domain because the
   associated E.164 number is not assigned for communications service,
   then any attempt to place the call via the CSN will fail.

   What would be useful is a mechanism "between" a registration holding
   NAPTRs with URIs and the lack of a domain registration.  In this way,
   an entity who is responsible for E.164 numbers in a range can
   indicate that a particular number has not been assigned to anyone for
   communications service.  For example, if a communications service
   provider has been allocated responsibility for delivering calls to
   endpoints identified with E.164 numbers in a block, then they may
   have some numbers in that block that are currently unused.  These
   E.164 numbers are not used to terminate calls to end users.

   An originating user agent cannot differentiate this state from the
   one in which there is an end user as a number assignee, but that end
   user has have chosen not to "publish" other contacts.  In effect, it
   would be more useful if the originating end user could receive a
   response that states "there is no service via this number", as
   opposed to "there may be service via this number, but there are no
   alternative contacts available".

   In short, the issue is distinguishing between E.164 numbers that do
   not have corresponding ENUM entries but are supported via the PSTN
   and those E.164 numbers that are not terminated on the PSTN.  In this
   latter case lack of a NAPTR holding a destination URI really implies
   that there is no service at all for this telephone number.  For
   example, some number ranges have been allocated for service that is
   provided only via reference to an ENUM domain, and terminate on the
   Internet (i.e. these calls will terminate only at a VoIP end point).
   The fundamental problem is that there may be inconsistencies between
   the E.164 name space as it is understood by the National Regulatory
   Authority (NRA) and how that name space is represented in ENUM, as
   service moves towards being provided in some cases only via non-PSTN
   access.  In effect, the PSTN may list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Follow-up on discussion of this I-D at the WG session today.  It seems
like the chairs and AD are asking whether or not people feel strongly
about this particular service and will actually use it, as it will take
time & energy to overcome concerns raised through the I-D review process
(concerns which will surely be raised again in later reviews in the
process).

So perhaps I can propose we step back for a moment, considering the need
for void or not as an enumservice type?  Here I think the best starting
point is for everyone to re-read section 3 of the draft, called "The
Problem" and decide whether or not there is agreement on that problem.
If so, we can *then* decide if void solves that problem or not, but we
have to first at least agree on the problem.  Here is that text, FYI:

3.  The Problem

   At present, from the ENUM client's perspective, two possibilities
   exist: there is an ENUM domain that potentially holds alternative
   contacts, or there is no ENUM domain, in which case a query on ENUM
   will return a DNS response showing 'no such domain' (NXDOMAIN, code
   3)[4].

   This latter response is ambiguous.  There are two potential reasons
   for the lack of an ENUM domain holding alternative contacts; either
   the assignee has chosen not to register the domain, or the E.164
   number is not assigned for communications service at present.

   If the number is assigned, then the caller can use the E.164 number
   to place the call via a network that uses such identifiers as global
   addresses (i.e. the CSN).  If however, there is no domain because the
   associated E.164 number is not assigned for communications service,
   then any attempt to place the call via the CSN will fail.

   What would be useful is a mechanism "between" a registration holding
   NAPTRs with URIs and the lack of a domain registration.  In this way,
   an entity who is responsible for E.164 numbers in a range can
   indicate that a particular number has not been assigned to anyone for
   communications service.  For example, if a communications service
   provider has been allocated responsibility for delivering calls to
   endpoints identified with E.164 numbers in a block, then they may
   have some numbers in that block that are currently unused.  These
   E.164 numbers are not used to terminate calls to end users.

   An originating user agent cannot differentiate this state from the
   one in which there is an end user as a number assignee, but that end
   user has have chosen not to "publish" other contacts.  In effect, it
   would be more useful if the originating end user could receive a
   response that states "there is no service via this number", as
   opposed to "there may be service via this number, but there are no
   alternative contacts available".

   In short, the issue is distinguishing between E.164 numbers that do
   not have corresponding ENUM entries but are supported via the PSTN
   and those E.164 numbers that are not terminated on the PSTN.  In this
   latter case lack of a NAPTR holding a destination URI really implies
   that there is no service at all for this telephone number.  For
   example, some number ranges have been allocated for service that is
   provided only via reference to an ENUM domain, and terminate on the
   Internet (i.e. these calls will terminate only at a VoIP end point).
   The fundamental problem is that there may be inconsistencies between
   the E.164 name space as it is understood by the National Regulatory
   Authority (NRA) and how that name space is represented in ENUM, as
   service moves towards being provided in some cases only via non-PSTN
   access.  In effect, the PSTN may not have complete information and
   ENUM may be required to deliver a call, but the data stored in ENUM
   at present may be ambiguous.

   For applications such as an ENUM-aware VoIP/PSTN gateway, this
   presents a problem.  These would use ENUM to decide how to route or
   terminate a call.  A simple default configuration rule for such a
   gateway would probably be: "if the number called is not in ENUM or
   has no NAPTR records, dump the call to the PSTN".  Such a rule is
   likely to be the norm while most telephony traffic uses the public
   telephone network.  In other words, if the response from the DNS is
   that the number does not exist in ENUM, the gateway would try to
   terminate the call on the PSTN.

   This will not always work.  The number that was attempted may be in
   some range that cannot be terminated on the PSTN: a block assigned
   for VoIP and ENUM exclusively, and for which there is no PSTN
   termination, for example.  If a number in such a range had not been
   entered into ENUM, the DNS would return the expected NXDOMAIN or
   NOHOST response, causing the gateway to take its default action which
   would have undefined results.  Where a "not in service" number is
   within such a special number block, the typical action of a PSTN
   element will be to pass this on to a VoIP/PSTN gateway, where as just
   described another ENUM query may be used to determine call treatment:
   the result could be a processing "loop".

Jason

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

 not have complete information and
   ENUM may be required to deliver a call, but the data stored in ENUM
   at present may be ambiguous.

   For applications such as an ENUM-aware VoIP/PSTN gateway, this
   presents a problem.  These would use ENUM to decide how to route or
   terminate a call.  A simple default configuration rule for such a
   gateway would probably be: "if the number called is not in ENUM or
   has no NAPTR records, dump the call to the PSTN".  Such a rule is
   likely to be the norm while most telephony traffic uses the public
   telephone network.  In other words, if the response from the DNS is
   that the number does not exist in ENUM, the gateway would try to
   terminate the call on the PSTN.

   This will not always work.  The number that was attempted may be in
   some range that cannot be terminated on the PSTN: a block assigned
   for VoIP and ENUM exclusively, and for which there is no PSTN
   termination, for example.  If a number in such a range had not been
   entered into ENUM, the DNS would return the expected NXDOMAIN or
   NOHOST response, causing the gateway to take its default action which
   would have undefined results.  Where a "not in service" number is
   within such a special number block, the typical action of a PSTN
   element will be to pass this on to a VoIP/PSTN gateway, where as just
   described another ENUM query may be used to determine call treatment:
   the result could be a processing "loop".

Jason

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum