Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

From: Richard Shockey <[email-masked]>
Date: Wed, 15 Oct 2014 15:21:49 -0400

Well I¹m delighted you brought up the subject.  I could make up some
really bad jokes about certain numbering committees ..

During the FCC workshop I mentioned that years ago we had some consensus
that EPP was not appropriate for the provisioning portion of the protocol
problem statement.

We set up IETF DRINKS in 08 specifically to look at the provisioning
problem. EPP was set up for the sole purpose of serving the domain name
industry, dealing with the ICANN requirements and as such was way carried
a lot of baggage with it.

In addition the carriers I spoke to were adamant they did not want any new
protocol stack in their already insanely expensive OSS/BSS systems and
they were all moving to something like HTTP SOAP or some RESTFUL like
protocols XML or JSON defined schema¹s.

I¹m pretty sure that sentiment has not changed.  DRINKS as a WG was a
failure for several reasons, principally timing. I really don¹t think the
industry was ready to revisit the numbering provisioning problem with a
clean sheet of paper.

Times changeŠ attitudes change.  I can assure you that the SIP Forum ATIS
NNI workshop did in fact discuss what NGN numbering would look like in the
post Transition phase and everyone is going to see the work in progress
documents in a day or so. I¹ll be posting a URL to the usual RAI lists. So
again Henning your timing is excellent.

‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
Www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 10/15/14, 2:50 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>We set up this list after the FCC numbering workshop earlier this year to
>see if there's interest and an initial list of to-do's in modernizing
>E.164 numbering delegation, porting, and lookup. I'd like to re-awaken
>this effort and see if we can make some initial progress.
>
>I see two fundamental technical discussions:
>
>(1) Architecture for managing numbers, along the
>centralized-to-distributed spectrum
>
>(2) What protocol pieces are out there that can be re-used (WEIRDS?
>EPP?), are they relevant and which ones are still needed?
>
>Henning
>
>_______________________________________________
>Modern mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/modern

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Wed, 15 Oct 2014 19:46:59 +0000

I'm awake!  I'm awake!

Richard and Henning,

Has anyone discussed moving beyond DNS/ENUM?  I’m wondering if something based on DIAMETER and XML might be a better long-term choice for routing information management requirements.  If you're familiar with work in this area (and I suspect there is), I'd be interested in looking at it.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: October 15, 2014 2:22 PM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

Well I¹m delighted you brought up the subject.  I could make up some really bad jokes about certain numbering committees ..

During the FCC workshop I mentioned that years ago we had some consensus that EPP was not appropriate for the provisioning portion of the protocol problem statement.

We set up IETF DRINKS in 08 specifically to look at the provisioning problem. EPP was set up for the sole purpose of serving the domain name industry, dealing with the ICANN requirements and as such was way carried a lot of baggage with it.

In addition the carriers I spoke to were adamant they did not want any new protocol stack in their already insanely expensive OSS/BSS systems and they were all moving to something like HTTP SOAP or some RESTFUL like protocols XML or JSON defined schema¹s.

I¹m pretty sure that sentiment has not changed.  DRINKS as a WG was a failure for several reasons, principally timing. I really don¹t think the industry was ready to revisit the numbering provisioning problem with a clean sheet of paper.

Times changeŠ attitudes change.  I can assure you that the SIP Forum ATIS NNI workshop did in fact discuss what NGN numbering would look like in the post Transition phase and everyone is going to see the work in progress documents in a day or so. I¹ll be posting a URL to the usual RAI lists. So again Henning your timing is excellent.

‹
Richard Shockey
Shockey Consulting LLC

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Oct 2014 19:52:39 +0000

There are probably several somewhat separate operations:

* get mapping from number to SIP URL (classical ENUM territory)
* mapping from number to "whois"-like information
* managing assignment of numbers to end users and/or carriers, including porting

They may have different needs. I suspect we don't want to cram a whole "whois"-like response into a DNS answer.

I'm less sure how DIAMETER would fit here, assuming we're talking about a AAA-like application, rather than (ab)using DIAMETER as a generic query-response protocol.

________________________________________
From: Gorman, Pierce A [NTK] [[email-masked]]
Sent: Wednesday, October 15, 2014 3:46 PM
To: Richard Shockey; Henning Schulzrinne; [email-masked]
Subject: RE: [Modern] Almost Halloween - time to wake the numbering zombies

I'm awake!  I'm awake!

Richard and Henning,

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: October 15, 2014 2:22 PM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

‹
Richard Shockey
Shockey Consulting LLC

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Oct 2014 19:57:01 +0000

I have no particular emotional attachment to EPP, but in the interest of learning from history, could you be more specific about its "baggage"?

After all, EPP uses XML and seems simpler than SOAP. (We can have the usual JSON-vs-XML debate, but that seems like a second-order issue, as much fun as the binary-vs-text debates that we used to have on IETF lists.)

________________________________________
From: Modern [[email-masked]] on behalf of Henning Schulzrinne [[email-masked]]
Sent: Wednesday, October 15, 2014 3:52 PM
To: [email-masked]
Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

I'm awake!  I'm awake!

Richard and Henning,

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: October 15, 2014 2:22 PM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

‹
Richard Shockey
Shockey Consulting LLC

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Wed, 15 Oct 2014 19:58:55 +0000

Nope, I was thinking of (ab)using DIAMETER as a generic query-response protocol.  The little, tiny, submission I was responsible for in the ATIS/SIP Forum JTF report was with regard to classical ENUM being woefully inadequate in terms of routing calls other than those which have no requirements for source information.  E.g., location.  There are numerous call types which use location.  E.g., local, long-distance, toll-free, emergency services.  And that is just one piece of information about the source.  Credentials and other pieces of information such as user service capabilities might be important.  Can you accept a video call? Are you allowed to call the POTUS?

Anyway a little giddy before Halloween, but definitely dissatisfied with classical ENUM and DNS for call routing.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: October 15, 2014 2:53 PM
To: [email-masked]
Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

I'm awake!  I'm awake!

Richard and Henning,

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: October 15, 2014 2:22 PM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies

‹
Richard Shockey
Shockey Consulting LLC

On 10/15/14, 2:50 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>We set up this list after the FCC numbering workshop earlier this year
>to see if there's interest and an initial list of to-do's in
>modernizing

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 15 Oct 2014 20:18:06 +0000

Certainly DIAMETER was one of the target protocols considered for the TeRQ framework:

http://www.ietf.org/archive/id/draft-peterson-terq-03.txt

For various reasons, TeRQ took a backseat to STIR, but as the initial STIR work winds down, we may want to revisit some of these ideas. 

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Oct 15, 2014, at 1:08 PM, "Gorman, Pierce A [NTK]" <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 15 Oct 2014 16:26:03 -0400

They’re alive !  They’re alive!

Well Pierce .. I certainly want to make it perfectly clear that if the
ENUM WG knew what we knew now we would not have gone down the DNS route. I
had enough problems beating back the X.500 zombies. We selected the best
available technology we had available at the time and for all of its
endless faults (and you know I can list them) it does work and work well
so far.

That said rethinking the whole problem is certainly in order here.
Determinate response.. Service capability hints certainly security
mechanisms STIR PKI  CNAM + etc.

Peterson had a excellent draft on some of this.

On 10/15/14, 3:58 PM, "Gorman, Pierce A [NTK]" <[email-masked]>
wrote:

>Nope, I was thinking of (ab)using DIAMETER as a generic query-response
>protocol.  The little, tiny, submission I was responsible for in the
>ATIS/SIP Forum JTF report was with regard to classical ENUM being
>woefully inadequate in terms of routing calls other than those which have
>no requirements for source information.  E.g., location.  There are
>numerous call types which use location.  E.g., local, long-distance,
>toll-free, emergency services.  And that is just one piece of information
>about the source.  Credentials and other pieces of information such as
>user service capabilities might be important.  Can you accept a video
>call? Are you allowed to call the POTUS?
>
>I'm less sure how DIAMETER would fit here, assuming we're talking about a
>AAA-like application, rather than (ab)using DIAMETER as a generic
>query-response protocol.
>
>Has anyone discussed moving beyond DNS/ENUM?  I’m wondering if something
>based on DIAMETER and XML might be a better long-term choice for routing
>information management requirements.  If you're familiar with work in
>this area (and I suspect there is), I'd be interested in looking at it.
>
>Best regards,
>
>
>Pierce Gorman
>Voice Architecture
>Core Planning/Sprint
>913-439-4368 (Desk)
>
>
>In addition the carriers I spoke to were adamant they did not want any
>new protocol stack in their already insanely expensive OSS/BSS systems
>and they were all moving to something like HTTP SOAP or some RESTFUL like
>NNI workshop did in fact discuss what NGN numbering would look like in
>the post Transition phase and everyone is going to see the work in
>progress documents in a day or so. I¹ll be posting a URL to the usual RAI
>lists. So again Henning your timing is excellent.
>
>‹
>Richard Shockey
>Shockey Consulting LLC
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.
>
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.
>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 15 Oct 2014 16:34:56 -0400

The baggage is dealing with the OSS/BSS systems in carrier voice networks.
 EPP as a theory is fine but it would be next to impossible to get a
different transport stack in those systems. Ask a carrier what it takes to
get a change order in one of these products and you will hear endless
tales of woe and rent extraction.

Frankly EPP was a failure as a IETF protocol since it was not really
designed to be a generic system provisioning protocol.

Money is the answer what is the question? TM

Plus I agree JSON vs XML is a second order problem but comes up .. There
are a lot of interesting discussions in the DRINKS archives about this but
there is really no need to go too far back there.

On 10/15/14, 3:57 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>I have no particular emotional attachment to EPP, but in the interest of
>learning from history, could you be more specific about its "baggage"?
>
>After all, EPP uses XML and seems simpler than SOAP. (We can have the
>usual JSON-vs-XML debate, but that seems like a second-order issue, as
>much fun as the binary-vs-text debates that we used to have on IETF
>lists.)
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 16 Oct 2014 09:06:10 -0400

I’m awake and wondering what happened to you all :)

REST and json are where it’s at these days.  Now that’s decided, we should move on.

Also, let’s keep in mind the difference between a provisioning protocol and a query protocol.  EPP/Drinks was provisioning, ENUM is query.  Different animals.

I certainly think that the query has to have more inputs than TN.  Location might be one of the, although we have a location-to-service mapping solution already.  The most important input besides TN is who is asking, because essentially all the routing mechanisms have different answers for different queriers.

I think we can learn a fair amount from the DRINKS effort on the provisioning side, but I also think that the world has changed since that work wrapped up.

Brian

---

From: "McGarry, Tom" <[email-masked]>
Date: Thu, 16 Oct 2014 16:45:43 +0000

In addition to provisioning (getting information to an administrator) and
querying (getting small amounts of data from an administrator), we should
also consider data distribution (sending large amounts of data plus
regular updates; i.e., addressing data; from an administrator to many).
Ideally just about any entity should be able to get an updated complete
copy of an addressing DB.

On 10/16/14 9:06 AM, "Brian Rosen" <[email-masked]> wrote:

><html>
>Also, let’s keep in mind the difference between a provisioning protocol
>and a query protocol.  EPP/Drinks was provisioning, ENUM is query.
>Different animals.
>
>I certainly think that the query has to have more inputs than TN.
>Location might be one of the, although we have a location-to-service
>mapping solution already.  The most important input besides TN is who is
>asking, because essentially all the routing mechanisms have different
>answers for different queriers.
>
>I think we can learn a fair amount from the DRINKS effort on the
>provisioning side, but I also think that the world has changed since that
>work wrapped up.
>
>Brian
>>> * managing assignment of numbers to end users and/or carriers,
>>>including
>>> porting
>>> 
>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm
>>>>an_listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeI
>>>>DcLextZ1ooNcfp01IYIaVqsORjI&m=Am-auDrwk_uX4rXFe-YziK45ZpqTY58S0hLy2VOZc
>>>>hI&s=6l5KztkcpEDzXPOOxSCUNblj9lR6J6bTs7mQm1oyPI8&e=
>>> 
>>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
>>>n_listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDc
>>>LextZ1ooNcfp01IYIaVqsORjI&m=Am-auDrwk_uX4rXFe-YziK45ZpqTY58S0hLy2VOZchI&
>>>s=6l5KztkcpEDzXPOOxSCUNblj9lR6J6bTs7mQm1oyPI8&e=
>>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
>>>n_listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDc
>>>LextZ1ooNcfp01IYIaVqsORjI&m=Am-auDrwk_uX4rXFe-YziK45ZpqTY58S0hLy2VOZchI&
>>>s=6l5KztkcpEDzXPOOxSCUNblj9lR6J6bTs7mQm1oyPI8&e=
>>> 
>>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
>>>n_listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDc
>>>LextZ1ooNcfp01IYIaVqsORjI&m=Am-auDrwk_uX4rXFe-YziK45ZpqTY58S0hLy2VOZchI&
>>>s=6l5KztkcpEDzXPOOxSCUNblj9lR6J6bTs7mQm1oyPI8&e=
>> 
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=Am-auDrwk_uX4rXFe-YziK45ZpqTY58S0hLy2VOZchI&s=6
>>l5KztkcpEDzXPOOxSCUNblj9lR6J6bTs7mQm1oyPI8&e=
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=Am-auDrwk_uX4rXFe-YziK45ZpqTY58S0hLy2VOZchI&s=6l5K
>ztkcpEDzXPOOxSCUNblj9lR6J6bTs7mQm1oyPI8&e=