Subject: Re: [Modern] Zombie numbering issues

From: Richard Shockey <[email-masked]>
Date: Wed, 15 Oct 2014 17:33:54 -0400

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

>My sense is that any numbering OSS development will need code
>development, since the process will presumably differ from the current
>model, particularly if we allow consumers (and other end users) to "rent"
>numbers. 

Well numbering is a National Policy Issue as you well know. :-) ICANN is
different. Who gets access to numbering resources and how those resources
are allocated is a national policy problem first. That said any protocol
development has to try ..try and accommodate those issues consistent with
national policy which is often inconsistent from Nation State to Nation
State.

>Anything-over-HTTP is just invoking a library, so I'm not sure I
>understand the trade-off. Or are you suggesting that the new mechanism
>needs to be fully backwards-compatible with the current Neustar LNPA and
>other APIs?

OMG NO  its just but the issues of dealing with the legacy systems of
BIIRDS the SOA and LSMS in the NPAC is complicated by the issues of
Transitioning or at the least revising existing systems.  Neustar has been
looking at NGN LSMS SOA issues for some time. Again the zombie resistance
has been ³challenging²

>
>________________________________________
>From: Richard Shockey [[email-masked]]
>Sent: Wednesday, October 15, 2014 4:34 PM
>To: Henning Schulzrinne; [email-masked]
>Subject: Re: [Modern] Almost Halloween - time to wake the numbering
>zombies
>
>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.
>_______________________________________________
>Modern mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/modern

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 16 Oct 2014 19:06:23 +0000

As much as it's fun to discuss what protocols we  have in the closet that might be useful or not, am I wrong for thinking we need to start with some assumptions about the architecture and what it has to do?

I agree that that number administration regime is a national matter but perhaps we can still devise a generic framework that will be attractive to right-thinking regulators everywhere :-)
So,
Based on the Workshop back in March can we assume that there will be a numbering registry that combines resource allocation and porting (delegation) for all types of E.164 numbers? This is not saying whether the registry is centralized or distributed a la Whitespaces. So we'll need some kind of registrar-registry protocol. What are the necessary characteristics? Can we assume anything about the actors?

Can we also assume that the registry is the apex for distribution of routing formation? I say apex because one decision is whether the registry contains such information (and potentially service logic to derive it) itself or delegates that and potentially other, e.g., identity related information to other parties. Depending on the answer, different protocols may be appropriate.
If there is delegation there might be different protocols involved at different stages of the resolution to the desired information.

Penn Pfautz

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Oct 2014 19:16:52 +0000

My hope is that similar protocols would work, maybe as subsets or with additions, for both the hierarchical and "flat" case. It is at least possible that we'll see combinations, e.g., flat at the top and trees below, or a tree with some flat parts in a branch (e.g., between replicas or between parts of an organization).

I'm implicitly assuming that the actors are cooperative, i.e., they authenticate themselves, and they don't intentionally try to inflict damage.

For routing, I wonder whether we'll see both: some entries will contain an initial routing contact (a SIP URL, some ENUM root, etc.), others may not. Would it be sufficient to provide this as optional data, recognizing that it may not be always present?

Is it sufficient to have one query protocol for everyone, where the information that is returned depends on who is asking? (For example, the assignee of a number gets lots of information, an anonymous querier may only get the rough equivalent of DNS whois, i.e., contact information for the assignee.)

Since policies and business arrangements are still evolving, I'm trying to explore flexible options, so that we don't end up in embedding too many assumptions, as, to some extent, ENUM did, where the assumption seems to have been that of a single kind of querier.

________________________________________
From: Modern [[email-masked]] on behalf of PFAUTZ, PENN L [[email-masked]]
Sent: Thursday, October 16, 2014 3:06 PM
To: [email-masked]
Subject: Re: [Modern] Zombie numbering issues

Penn Pfautz

---

From: Brian Rosen <[email-masked]>
Date: Thu, 16 Oct 2014 15:29:16 -0400

I definitely think it’s an open architectural question of whether there is one database that has “ownership” information, and another that has routing.  In some cases, of course, knowledge of ownership is enough information to complete routing, so that argues there is one database.  But we should seriously consider if that is what we want.

I do think that we want to take into consideration that we’re clearly headed towards two complications we don’t consider today:
1. More direct user control of their numbers
2. Multiple services attached to a single number where the service providers for each of the services may be different.

I also suspect that we’re going to change the current mechanisms for inventory control of numbers, heading towards either “centralized” inventory, with service providers or users requesting one number at a time from common inventory, or at least much smaller units of inventory allocation from the numbering authorities.

Brian

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 16 Oct 2014 19:36:08 +0000

See in-line

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, October 16, 2014 3:17 PM
To: PFAUTZ, PENN L; [email-masked]
Subject: RE: [Modern] Zombie numbering issues

>>perhaps the right approach would be to allow either a simple direct answer OR a reference (for example, like DNS does).
>> I do want to keep policy and service logic at least out of any *common* infrastructure. I already find in bi-lateral 
>> interconnection negotiations (albeit for "aggregate" routing methods) that the variations in routing policy desired by different
>>SPs is such that anticipating them all in a shared infrastructure will be problematic. Keeping such logic in the hands of the
>> number delegate will maximize flexibility and minimize what we have to agree on to get started. 

Penn Pfautz

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Oct 2014 19:41:15 +0000

My only quick comment is that I think it's generally a good idea to allow simple cases to be handled with minimal complexity. If, for example, the protocol allows, but does not mandate, disclosing a contact point, this will make it much easier for small entities that then only have to run a SIP server, without setting up lots of additional machinery. (Somewhat similar to the current DNS model, where the NS records can be found easily.)

Large carriers can rely on people making an effort to find them, even if it's complicated.

________________________________________
From: PFAUTZ, PENN L [[email-masked]]
Sent: Thursday, October 16, 2014 3:36 PM
To: Henning Schulzrinne; [email-masked]
Subject: RE: [Modern] Zombie numbering issues

See in-line

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 16 Oct 2014 19:42:56 +0000

Brian:
I for one do believe there should be one (potentially distributed) registry and not a separate routing database. As I indicated that registry might or might not supply routing information directly depending on number delegate (whether end user or SP) choice and complexity.

Re number 2 below I understand the desire but remind you that then we have to get into service definition - maybe there is a way to fudge that?

I agree w/r/t to inventory; a well-designed system should allow SPs to dispense with inventory.

Penn

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, October 16, 2014 3:29 PM
To: Henning Schulzrinne
Cc: PFAUTZ, PENN L; [email-masked]
Subject: Re: [Modern] Zombie numbering issues

I definitely think it's an open architectural question of whether there is one database that has "ownership" information, and another that has routing.  In some cases, of course, knowledge of ownership is enough information to complete routing, so that argues there is one database.  But we should seriously consider if that is what we want.

I do think that we want to take into consideration that we're clearly headed towards two complications we don't consider today:
1. More direct user control of their numbers
2. Multiple services attached to a single number where the service providers for each of the services may be different.

I also suspect that we're going to change the current mechanisms for inventory control of numbers, heading towards either "centralized" inventory, with service providers or users requesting one number at a time from common inventory, or at least much smaller units of inventory allocation from the numbering authorities.

Brian