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

Hi folks,
  I for one want non-terminals and experimental services.
I use both, and these should be in the guide.
[want some text ?]
As for extensibility, this is specifically not permitted in the 3761  
template. The type WAS intended to be controlling, describing the  
kind of teleservice.
That was the big change from 2916. Sub-types should avoid confusion  
by doing similar things, but with different methods.
Good idea to add text to spell out extensibility, and what the limits  
are on it.
all the best,
   Lawrence

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

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 14:37:22 -0500

I certainly got the sense from the room that there is a problem here. There
is a strong desire for ENUM systems to have the ability to distinguish
between active and non allocated numbers or number blocks.

The problem statement being that CUA or other entities do not want to
initiate a session if it is clear that the number is inactive.

There are clear reasons to distinguish between non active vs non existent
numbers.

> -----Original Message-----
> From: Livingood, Jason [mailto:[email-masked]]
> Sent: Monday, November 06, 2006 5:55 PM
> To: [email-masked]
> Subject: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement
> onProblem Statement?
> 
> 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
>

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 21:03:45 +0100

<There are clear reasons to distinguish between non active vs non existent
>numbers.

Could you please elaborate what this clear reasons are?
 
BTW: we have three values now:
 
unallocated (not existent)
unassigned (not existent)
inactive (inactive -= out-of-service- barred - etc)
 
Richard

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Di 07.11.2006 20:37
An: 'Livingood, Jason'; [email-masked]
Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonProblem Statement?