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

From: "Shawn Pouliotte" <[email-masked]>
Date: Tue, 07 Nov 2006 10:06:10 -0800

The problem statement at least in my mind is clear and pretty much every carrier I discuss the concept with see the value. Its important to be able to distinguish between un-issued addresses and non-existant for all the reasons already mentioned. 

Just my 2 cents
  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]]
To: Livingood, Jason [mailto:[email-masked]], [email-masked]
Sent: Tue, 07 Nov 2006 08:33:40 -0800
Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement?

It's a question of pay me now or pay me later.
  
  Do SP's want to pay the cost in an ENUM response, or a failed PSTN GW
  call?
  
  I would argue that handling in ENUM would be much, much more efficient,
  since it won't involve setting up media to a PSTN GW, the added gateway
  control signaling, and possibly occupation of otherwise useful trunk
  capacity, just to find out the number is not assigned.
  
  Mike

  > -----Original Message-----
  > From: Livingood, Jason [mailto:[email-masked]] 
  > Sent: Monday, November 06, 2006 7:15 PM
  > To: [email-masked]
  > Subject: RE: [Enum] draft-ietf-enum-void-02 --> First 
  > Question - Agreement onProblem Statement?
  > 
  > >    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.
  > 
  > So from this, I would understand the problem as such -
  > 
  > A service provider has a number block of, for example, 
  > +1-215-981-XXXX, where XXXX is -0000 to -9999.  That SP has 
  > issued 50% of these numbers to individual subscribers and the 
  > other 50% have not been.  These are not neatly distributed 
  > within the block, as subscribers choose their numbers so the 
  > active numbers end up being randomly distributed in the block. 
  > 
  > If the SP registers SIP URIs for all of the active TNs then 
  > those calls will work and terminate just fine.  If a TN is 
  > not registered then, since it is inactive, then if a person 
  > dials one of the unregistered TNs then you have to wait for 
  > NXDOMAIN response.  In that case, most softswitches / proxies 
  > will then do legacy lookups (LNP, LERG, etc.).
  > The downside is two-fold: greater post-dial delay than is 
  > necessary, and having to rely on legacy call lookup tools 
  > (which may have associated costs).  There should be a way 
  > instead to stop the call routing progression immediately if 
  > you know that the TN is inactive, thus triggering back the 
  > code for a number not in service network announcement to a caller.
  > 
  > Is this a correct understanding of one of the issues the 
  > authors are trying to identify in the problem statement?
  > 
  > Jason
  > 
  > _______________________________________________
  > enum mailing list
  > [email-masked]
  > https://www1.ietf.org/mailman/listinfo/enum
  > 
  
  _______________________________________________
  enum mailing list
  [email-masked]
  https://www1.ietf.org/mailman/listinfo/enum

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

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 19:39:24 +0100

I think there is a rough consensus that it is useful to have an indication 
of unallocated number blocks and unassigned numbers in ENUM.
 
To update the draft I have some questions:
 
Q1: is it useful to distinguish between unallocated numbers and unassigned
numbers from an originating users point-of-view?
 
Q2: Some people seem to have a problem with the naming of the
ENUMservice (void). We choose the name because it was short
I am open for proposals for something else
(also dependant of Q1)
Proposals that where mentioned already:
status
sit
If there is a distinction required between unassigned and unallocated:
unas
unal
 
Q3: There where also some discussions on the URI
(note: we need an URI because of the syntax of the NAPTR)
I do not see any need for a change here, but there was also a 
proposal to use a txt URI
 
Note: there was also a proposal to simply use a sip URI pointing 
to an (sit) announcement. This is not possible because ENUM may
be used also by non-voice clients. It is the decision of the originating
client how to react to the user if it encounters (void).
 
Q4: The problem of section 7 (enclosing zone)
If one reads the text, the whole issue is optional and it is recommended
to enter (void) for each potential number.
 
Nevertheless, in countries with variable length numbers (including direct-
dial-in) THIS DOES NOT WORK.
 
So we optionally came up with this approach, because we need it. 
It is e.g not required in countries with fixed number lenght such as
the NANP.
Maybe we should state this more clearly
 
regards
Richard

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 7 Nov 2006 20:22:10 +0100

> numbers from an originating users point-of-view?

Not that much. IMHO. Does the PSTN offer different error codes to
the end-user (i.e. SIT cadence vs. ???) ?

> If there is a distinction required between unassigned and unallocated:

"status" may be the better choice as it keeps the path open to
indicate other conditions which we have not considered right now.

> proposal to use a txt URI

What about we change the service-type to a generic status and
use a URI to indicate the status? e.g.

"E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" .

or perhaps do something similar to the ECRIT service URNs:

"E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.unassigned!" .
or
"E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.unallocated!" .
"E2U+status" "u" 0 0 "!.*!urn:pstn-status:inactive.invalid!" .

this opens to

"E2U+status" "u" 0 0 "!.*!urn:pstn-status:active.ported!" .

> client how to react to the user if it encounters (void).

agreed.

> to enter (void) for each potential number.

AFAIK this is exactly the point where Peter's concerns are.

> dial-in) THIS DOES NOT WORK.

Well, it's either that or DNS wildcards.

The URI might contain some information regarding the range of
numbers which are not valid on the PSTN.

> Maybe we should state this more clearly

That may be a good idea in any case.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

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

> the end-user (i.e. SIT cadence vs. ???) ?

YEP they are standard TCAP responses but many of them are not useful here.

> "E2U+status" "u" 0 0 "!.*!data:text/plain,unassigned!" .

EXACTLY ... or as I was thinking text is itself a URI..but this would work
very well IMHO.

The data field could be more useful and its what Jason and I used for CNAM
etc.

> "E2U+status" "u" 0 0 "!.*!urn:pstn-status:active.ported!" .

Out of scope ... see RFC 3761

> Well, it's either that or DNS wildcards.

Reminder that there are lots of RFC indicating wildcards in the DNS etc are
harmful. 

> numbers which are not valid on the PSTN.

Interesting how could you express this in a data: URI?

> That may be a good idea in any case.=

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 7 Nov 2006 21:59:24 +0100

> EXACTLY ... or as I was thinking text is itself a URI..but this would work

Agreed. I really think we should keep the ENUM-service type simple
and generic stating "the URI in the regex will define the status of the
number".

> The data field could be more useful and its what Jason and I used for CNAM

The question of what URI scheme to use (and yes, urn: is just yet
another URI-scheme) is open to discussion. I think there are a
few possible solutions. data:, text: or urn:.  If we want to 
find out what is best choice, we should first fomulate a quick
requirements list. What information should be encodable in that URI?

Quick list:

 * status as a set of pre-defined values. Perhaps hierarchically
   structured.
 * Carrier identification?
 * Number block information (e.g. "this status applies to all of +43780")
 * Porting indicator?

> Reminder that there are lots of RFC indicating wildcards in the DNS etc are

I'm very much open to suggestion on how to solve the problem without
resorting to wildcards.

> Interesting how could you express this in a data: URI?

...;apliesto=+43780

/ol

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 16:12:03 -0500

> few possible solutions. data:, text: or urn:.

IMHO data or text. I don't want to go down the URN rat hole for reasons
earlier noted.

  If we want to
>  * Number block information (e.g. "this status applies to all of +43780")

PLEASE PLEASE... I think we had consensus here. The initial use case for
this ID surrounds 3 conditions as Richard noted.

unallocated (not existent)

unassigned (not existent)

inactive (inactive -= out-of-service- barred - etc)

Can we stick with this and finish up?  Please!! This is an issue that people
want to use NOW. If the URI scheme is extensible enough people can write
separate drafts on those other items.

Add the rest of that stuff into the draft and we might have to totally
respin the document. As it was 'void' was in the IESG queue I'd like to
justify a note to the AD's that this revision is in the context of the
original, answers their concerns, and as such does not necessarily need
additional WG LAST Call.

OK?

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 22:24:53 +0100

>inactive (inactive -= out-of-service- barred - etc)

I think we have at least consensus here

I see some decisions still to make:

E2U+status:unass  with mailto and http pointing to owner
E2U+status:unall
E2U+status:inact

E2U+status with text:unassigned or text::unallocated or text:inactive

or

E2U+unass:http
E2U+unass:mailto
etc

all schemes are extensible

>original, answers their concerns, and as such does not necessarily need

for a complete rewrite count me out

Richard

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Di 07.11.2006 22:12
An: 'Otmar Lendl'; 'Richard Shockey'
Cc: Stastny Richard; [email-masked]
Betreff: RE: [Enum] void-02 new version

  If we want to

OK?

---

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

OK its just me but I'm not going to the IESG with a "UNASS" parameter in an
ID.  :-) Cant you just spell it out..

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 4:25 PM
> To: [email-masked]; Otmar Lendl; Richard Shockey
> Cc: [email-masked]
> Subject: Re: [Enum] void-02 new version
> 
> > > Reminder that there are lots of RFC indicating wildcards in the DNS
> etc
> > are
> > > harmful.
> >

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 22:38:35 +0100

Ok, at least I tried ;-)

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Di 07.11.2006 22:37
An: Stastny Richard; [email-masked]; 'Otmar Lendl'; 'Richard Shockey'
Cc: [email-masked]
Betreff: RE: [Enum] void-02 new version