Subject: RE: [Enum] void-02 new version

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 8 Nov 2006 00:02:21 -0500

> > Quick list:
> > 
> >  * status as a set of pre-defined values. Perhaps hierarchically
> >    structured.

Sounds complicated.  Maybe we should keep it more simple, easier to
implement and understand.

> >  * Carrier identification?
> >  * Number block information (e.g. "this status applies to all of 
> > +43780")
> >  * Porting indicator?

On those 3, IMHO, no, let's not lose focus.  If we want carrier ID or
some of the other stuff, then do it in a different enumservice...

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

Well, hold on just a second.  I thought we had consensus on the first
two use cases.  Where did the 3rd one above come from?  Can someone
please describe the specific use case and how that is noticeably
different from the first two?  In the first the NRA has not put a TN in
service, and in the second the SP has not done so.  So in the third,
what party are we talking about?

Jason

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

 05:02:21.0839 (UTC)
	FILETIME=[12C271F0:01C702F3]
Cc: [email-masked], Stastny Richard <[email-masked]>

> > Quick list:
> > 
> >  * status as a set of pre-defined values. Perhaps hierarchically
> >    structured.

Sounds complicated.  Maybe we should keep it more simple, easier to
implement and understand.

> >  * Carrier identification?
> >  * Number block information (e.g. "this status applies to all of 
> > +43780")
> >  * Porting indicator?

On those 3, IMHO, no, let's not lose focus.  If we want carrier ID or
some of the other stuff, then do it in a different enumservice...

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

Well, hold on just a second.  I thought we had consensus on the first
two use cases.  Where did the 3rd one above come from?  Can someone
please describe the specific use case and how that is noticeably
different from the first two?  In the first the NRA has not put a TN in
service, and in the second the SP has not done so.  So in the third,
what party are we talking about?

Jason

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 10 Nov 2006 13:00:21 -0500

Ed Wrote:
What happens when a number is changed?  On the PSTN, 
the Caller would be given an intercept message like
"The number have have dialled <X> has been changed.  
The new number is <y>".  
personally, I'd like to have this scenario result in an origination
feature that updates my address book.
Should this be in scope for the status indication?

Jason:  IMHO that is out of scope for this draft.  What you describe is
when a subscriber changes TNs within a given service provider.  As such,
that SP must provide such a user experience and this should not be
within the purview of ENUM.

JL

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 10 Nov 2006 13:02:18 -0500

Yes, but this should not be PSTN specific.  We are talking about URIs
here, which means we are talking over IP networks.

A variation --> NOSVC (No Service)?

Jason 

> -----Original Message-----
> From: Antoin Verschuren [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 9:56 PM
> To: [email-masked]
> Subject: RE: [Enum] void-02 new version
> 
> lconroy wrote:
> > 
> > Maybe "PSTN-unused" might avoid confusion - this doesn't 
> say that the 
> > number has NO potential communication contacts, but that it doesn't 
> > have a "via PSTN" communications path.
> 
> How about "NPT" (No PSTN Termination)
> 
> Antoin Verschuren
> 
> Technical Advisor
> Policy & Business Development
> SIDN
> Utrechtseweg 310
> PO Box 5022
> 6802 EA Arnhem
> The Netherlands
> 
> T +31 26 3525510
> F +31 26 3525505
> M +31 6 23368970
> E [email-masked]
> W http://www.sidn.nl/
>