Subject: Re: [Modern] Problem statement draft problems

From: "McGarry, Tom" <[email-masked]>
Date: Mon, 4 Jan 2016 15:16:15 +0000

Pierce, thanks for reviewing the document and the feedback.  See my
comments in line below.

On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>Steve,
>
>In section 1 I would strike the sentence, "   Telephone numbering,
>however, has long been transitioning away from a provider-centric model
>towards a user-centric model."  I think the statement is arguable and
>isn't needed.

Tom: OK.  
>
>The statement, " TN administration processes rooted in PSTN technology
>and policies dictate that this be an exception process fraught with
>problems and delays" may stand on it's own for someone familiar with the
>technology, policies, problems, and delays, but I think that is probably
>a small minority.
>
>Can you elaborate?  If not, I suggest removing this statement as well.

Tom: How about following that sentence with:
"Processes were built to associate a specific TN to a specific service
provider and never change it.  With number portability the industry had to
build new infrastructure, new administration functions and processes to
change the association of the TN from one service provider to another."

>
>Also, I would suggest that users already have full control of their TN.
>Certainly nobody will take it from them (although the area code portion
>of telephone numbers using the NANP dial plan can and does occassionally
>change).  And the porting process is solely driven by the users.
>(Although it might be worth pointing out porting in order to improve
>inbound call routing to IMS-based numbers has been a consideration for
>some North American carriers deploying VoLTE.)
>
>The statement, " Ideally the user would have full control of their TN and
>would drive the porting process on their own rather than rely on complex
>and time
>consuming back office processes among multiple service providers" needs
>work.  What is the definition of "full control" and what makes full
>control "ideal"?

Tom: A few years ago my sister moved from E. 62nd St to E. 85th St in NYC.
 Her service provider would not let her keep her number.  You and I know
that is because she moved from one CO serving area to another and the
company didn't want to go through the process of porting her number
between their switches.  While I would think this is not common, it's not
rare either.  Service providers build rules into their systems and
processes that account for things like rate centers, wire center
boundaries, LATAs, consumer addresses, etc. that seem logical to them, but
may not to a consumer.  I do think it would be beneficial for consumers to
have the opportunity for more control over their numbers.  As we move to
IP, the timing is right to look at improving this.
>
>How about, "Some members of the MODERN working group think users ought to
>be able to use an Internet-available database to directly make changes to
>the services associated with and the provisioning of their telephone
>number without assistance from service providera."?

Tom: I believe this is better handled in the use cases, where this example
is covered.  
>
>As mentioned before, claiming that the back office process among multiple
>service providers is complex does not imply harm or even a problem to be
>fixed.  Telephony is complex, but it is also very useful so the fact that
>it is complex doesn't mean that it is bad, harmful, or a problem to be
>addressed.
>
>I recommend striking the phrase, "rather than rely on complex and time
>consuming back office processes among multiple service providers".
>
>Part of the problem here is you cannot really assert a priori that a
>MODERN system will be less time consuming or even less complex.  The fact
>that the user will necessarily require assistance from one or more
>service providers in completing the provisioning of their service (in the
>case of mobile telephony at least) makes this a certainty.  In fact, it
>would be easy to argue that MODERN will be more complex.
>
>I'm also confused by the reference to back office processes as though
>they are inherently harmful.  Other terms for the same activity are
>Operational Support Systems (OSS) and Business Support Systems (BSS).
>These terms don't have a negative or positive connotation though, so
>perhaps they also don't belong in a problem statement?
>
>With respect to geographic number assignment, the rejoinder, "But the
>overwhelming success of mobile telephones has increasing eroded the
>connection between numbers and regions" has problems at least in the
>context of the North American numbering plan.

Tom: You're over thinking this.  Mobile has always eroded the connection
between numbers and regions - that's what it does.  This is pointing out
that it is now a dominant portion of the market.
>
>I think what you mean is that after a mobile telephone number is assigned
>(likely for the majority of a user's life once non-geographic portability
>is supported), a fair quantity of users (but far less than even 50%?)
>will move outside of the geography of the original assignment rendering
>the geographic information associated with that mobile number
>anachronistic and inaccurate.  I would agree with this, and I would agree
>it causes problems for service providers.  I wouldn't necessarily agree
>it's a problem a new MODERN system could help with.
>
>What is lost in this view is that there is an underlying routing number
>which still retains a very certain geographic component.  Even if we
>eliminated routing numbers and their reference to the LERG (again North
>America-centric view), there are very real operational reasons for
>wanting to recognize geography when "homing" the terminating service
>processing (at least).
>
>One of the problems with Internet telephony is the lack of recognition
>for geography both in telephone call routing and in number assignment.
>Understanding geography and it's interaction with call processing and
>numbering is going to be one of the key challenges for MODERN.  I don't
>mean this as a reason not to work on MODERN. I mean it as helpful hint.
>There is a real cost both to service providers and users for unoptimized
>call routing and media transport.
>
>I recommend changing the statement to, " But the overwhelming success of
>mobile telephones has increasing obfuscated the connection between
>numbers and regions".
>
>This way you point out that there is and should be an intentional
>relationship between mobile telephone numbering and operations at least,
>but that portability and Internet-telephony present special signaling and
>media path optimization problems.
>
>The issue will be for MODERN WG how to develop a new system of telephone
>number databasing that doesn't just recognize those problems, but somehow
>helps with them beyond what is available with conventional mechanisms.
>
>That's more than enough for this session.  I'll try to pick up tomorrow.
>
>Regards,
>
>Pierce
>
>
>________________________________
>Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T
>or T-Mobile rates. See
>sprint.com/50off<https://urldefense.proofpoint.com/v2/url?u=http-3A__sprin
>t.com_50off&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1oo
>Ncfp01IYIaVqsORjI&m=CbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=4e2GdaZQ
>gxzYOrBnyWBi4uVzX8ABHMm4DZyRE0TMgCE&e= > for details.
>
>________________________________
>
>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.
>
>_______________________________________________
>Modern mailing list
>[email-masked]
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=CbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=97kr
>pL5WZ4HCVAJuQEFeidiyONXQzq6MgU_YyxDjq1Y&e=

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 4 Jan 2016 16:25:38 +0100

Please see embedded comment below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
> Sent: Monday, January 4, 2016 16:16
> To: [email-masked]
> Subject: Re: [Modern] Problem statement draft problems
> 

SNIP

> Tom: You're over thinking this.  Mobile has always eroded the
> connection between numbers and regions - that's what it does.  This is
> pointing out that it is now a dominant portion of the market.

In other jurisdictions, fixed-number portability has eroded the connection
between numbers and regions for fixed telephony. For example, my Geneva
fixed number starts with 022, but if I move to Zurich, I can take that
prefix with me. So in fact there is no longer any way to determine with
certainty a geographical region from a telephone number.

SNIP

> >I recommend changing the statement to, " But the overwhelming success
> >of mobile telephones has increasing obfuscated the connection between
> >numbers and regions".

Building on my comment above, I think that the following could be added to
the end of the above statement: "Further, fixed number portability has
obfuscated the connection between numbers and geographical regions, in the
jurisdictions where fixed number portability has been implemented."

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 Jan 2016 16:21:19 +0000

Thanks Tom.  Inline.

I also have more edits but didn't want to send them out until I've completed the review (this week?).

Best regards,

Pierce Gorman
Office: 913-439-4368
[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: January 04, 2016 9:16 AM
To: [email-masked]
Subject: Re: [Modern] Problem statement draft problems

Pierce, thanks for reviewing the document and the feedback.  See my comments in line below.

Tom: OK.
>problems and delays" may stand on it's own for someone familiar with
>the technology, policies, problems, and delays, but I think that is
>probably a small minority.
>

Tom: How about following that sentence with:
"Processes were built to associate a specific TN to a specific service provider and never change it.  With number portability the industry had to build new infrastructure, new administration functions and processes to change the association of the TN from one service provider to another."

PG->  I'm OK with it.

>of telephone numbers using the NANP dial plan can and does
>occassionally change).  And the porting process is solely driven by the users.
>The statement, " Ideally the user would have full control of their TN
>and would drive the porting process on their own rather than rely on
>complex and time consuming back office processes among multiple service
>providers" needs work.  What is the definition of "full control" and
>what makes full control "ideal"?

Tom: A few years ago my sister moved from E. 62nd St to E. 85th St in NYC.
 Her service provider would not let her keep her number.  You and I know that is because she moved from one CO serving area to another and the company didn't want to go through the process of porting her number between their switches.  While I would think this is not common, it's not rare either.  Service providers build rules into their systems and processes that account for things like rate centers, wire center boundaries, LATAs, consumer addresses, etc. that seem logical to them, but may not to a consumer.  I do think it would be beneficial for consumers to have the opportunity for more control over their numbers.  As we move to IP, the timing is right to look at improving this.

PG->  My understanding is rate centers and LATA boundaries were defined by attorneys as part of Judge Green's "Modified Final Judgement" in the United States vs. AT&T antitrust case of 1982.  It's unfortunate that it impacted your sister (and others), and I agree that Non-Geographic Portability (NGP) should (eventually) address the issue.  I disagree that the move to VoIP has very much to do with NGP.  I think you need to prove that a new MODERN system of numbering would eliminate time from the back office processes required by CSPs, or drop the point.

PG->  I think you still need to define full control better.  The example you provided will be a benefit of NGP, not MODERN (unless MODERN were an unavoidable prerequisite or undeniable benefit which I don't think anyone will argue).

>
>How about, "Some members of the MODERN working group think users ought
>to be able to use an Internet-available database to directly make
>changes to the services associated with and the provisioning of their
>telephone number without assistance from service providera."?

Tom: I believe this is better handled in the use cases, where this example is covered.
>
>As mentioned before, claiming that the back office process among
>multiple service providers is complex does not imply harm or even a
>problem to be fixed.  Telephony is complex, but it is also very useful
>so the fact that it is complex doesn't mean that it is bad, harmful, or
>a problem to be addressed.
>
>MODERN system will be less time consuming or even less complex.  The
>fact that the user will necessarily require assistance from one or more
>service providers in completing the provisioning of their service (in
>the case of mobile telephony at least) makes this a certainty.  In
>fact, it would be easy to argue that MODERN will be more complex.
>

Tom: You're over thinking this.  Mobile has always eroded the connection between numbers and regions - that's what it does.  This is pointing out that it is now a dominant portion of the market.

PG->  I think you're underthinking this.  :-)  The majority of phone calls are "local" and charged accordingly per regulatory requirements.  This isn't changing.  Also, mobile carriers cannot page an entire network for every call termination attempt so localizing the call termination processing is important.  A benefit of NGP will be optimized call termination localization (at the cost of additional porting information management).  i.e., call processing can be optimized by porting numbers which spend a high percentage of time hosted from a "visited"  platform (within a CSP's network).  Mobile call processing necessarily resides in a platform with a geographic location and regional responsibility.  Numbering and geography for mobile call processing continue to have an important relationship that needs to be recognized, not dismissed.  i.e., to optimize call routing and number management, new number assignments should still be done with a sensitivity to geography.  And when numbers are released back to the CSP, new assignments with a number should be within the context of the region from which the number was originally assigned.  This isn't a policy suggestion, it's a network design and operation optimization.  Geography matters.

>
>I think what you mean is that after a mobile telephone number is
>assigned (likely for the majority of a user's life once non-geographic
>portability is supported), a fair quantity of users (but far less than
>even 50%?) will move outside of the geography of the original
>assignment rendering the geographic information associated with that
>mobile number anachronistic and inaccurate.  I would agree with this,
>and I would agree it causes problems for service providers.  I wouldn't
>necessarily agree it's a problem a new MODERN system could help with.
>
>There is a real cost both to service providers and users for
>unoptimized call routing and media transport.
>
>relationship between mobile telephone numbering and operations at
>least, but that portability and Internet-telephony present special
>signaling and media path optimization problems.
>
>The issue will be for MODERN WG how to develop a new system of
>telephone number databasing that doesn't just recognize those problems,
>but somehow helps with them beyond what is available with conventional mechanisms.
>
>Learn more on how to switch to Sprint and save 50% on most Verizon,
>AT&T or T-Mobile rates. See
>Ncfp01IYIaVqsORjI&m=CbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=4e2Gd
>aZQ gxzYOrBnyWBi4uVzX8ABHMm4DZyRE0TMgCE&e= > for details.
>
>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.
>
>Z1ooNcfp01IYIaVqsORjI&m=CbmNloy0epn1-OdwfTLxCoeBjyYW2zKratnTd29R6co&s=9
>7kr pL5WZ4HCVAJuQEFeidiyONXQzq6MgU_YyxDjq1Y&e=

_______________________________________________
Modern mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/modern

________________________________
Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off<http://sprint.com/50off> for details.

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 Hill" <[email-masked]>
Date: Mon, 4 Jan 2016 17:25:59 +0100

Best,
Richard

> From: Modern [mailto:[email-masked]] On Behalf Of Gorman,
> Pierce A [CTO]
> Sent: Monday, January 4, 2016 17:21
> To: McGarry, Tom; [email-masked]

SNIP

> PG->  I think you're underthinking this.  :-)  The majority of phone
> PG-> calls are "local" and charged accordingly per regulatory
> PG-> requirements.  This isn't changing.

Introduction of fixed number portability in Switzerland resulted in the end
of geographical charging.  Indeed, how can you charge by geography if the
caller cannot know in what geography the called number is?

SNIP

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 Jan 2016 16:35:56 +0000

Good to know.  Thank you.

Just because the users don't know where a call originated and terminated doesn't mean the network does not or cannot know.  I'll speculate that the Swiss portability uses a similar mechanism as used in North America and the ported number is associated with a "Local Routing Number" which indexes back to a central office switch with a specific geographic location.  The originating CSP presumably knows where the call originated, and can look at the geographic location of the terminating switch (not the LRN, but the actual switch which "owns" the LRN) and charge accordingly.

The most current NANP regulatory guidelines with respect to the Order to Reform InterCarrier Compensation Rates still includes access charges even after there is bill-and-keep (on balance of traffic?).

Pierce

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Hill
Sent: January 04, 2016 10:26 AM
To: Gorman, Pierce A [CTO] <[email-masked]>; 'McGarry, Tom' <[email-masked]>; [email-masked]
Subject: Re: [Modern] Problem statement draft problems

Best,
Richard

SNIP

> PG-> requirements.  This isn't changing.

Introduction of fixed number portability in Switzerland resulted in the end of geographical charging.  Indeed, how can you charge by geography if the caller cannot know in what geography the called number is?

SNIP

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 4 Jan 2016 18:03:12 +0100

I think that the Swiss solution is a bit more complex that what you outline
below, but yes, of course the network does know where the call originated
and terminated.  The description of Swiss number portability is at (but only
in French, German, and Italian):

  http://www.bakom.admin.ch/themen/telekom/00479/00625/index.html?lang=en 

Best,
Richard

> From: Gorman, Pierce A [CTO] [mailto:[email-masked]]
> Sent: Monday, January 4, 2016 17:36
> To: Richard Hill; 'McGarry, Tom'; [email-masked]
> Subject: RE: [Modern] Problem statement draft problems
> 
> Good to know.  Thank you.
> 
> Just because the users don't know where a call originated and
> terminated doesn't mean the network does not or cannot know.  I'll
> speculate that the Swiss portability uses a similar mechanism as used
> in North America and the ported number is associated with a "Local
> Routing Number" which indexes back to a central office switch with a
> specific geographic location.  The originating CSP presumably knows
> where the call originated, and can look at the geographic location of
> the terminating switch (not the LRN, but the actual switch which "owns"
> the LRN) and charge accordingly.
> 
> The most current NANP regulatory guidelines with respect to the Order
> to Reform InterCarrier Compensation Rates still includes access charges
> even after there is bill-and-keep (on balance of traffic?).
> 
> Pierce
> 
> To: Gorman, Pierce A [CTO] <[email-masked]>; 'McGarry, Tom'
> <[email-masked]>; [email-masked]
> Introduction of fixed number portability in Switzerland resulted in the
> end of geographical charging.  Indeed, how can you charge by geography
> if the caller cannot know in what geography the called number is?
> 
> SNIP
> 
> AT&T or T-Mobile rates. See sprint.com/50off<http://sprint.com/50off>
> for details.
>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 04 Jan 2016 14:47:05 -0500

>The most current NANP regulatory guidelines with respect to the Order to Reform InterCarrier Compensation Rates still includes access charges even after there is bill-and-keep (on balance of traffic…

Its a function of terminating call access rates.  Those have gone to .0005 or something like before it goes to zero. The issue is on origination access charges. The theory in the R&O was the rural carriers were not going to be able to modify their business models fast enough to accommodate both so on origination the regime is still in place for now.  It too will go away especially if there is a move to National Geographic NP in the US which would essentially force the issue once and for all.  That BTW was the principal topic of discussion at our last NANC meeting at the FCC. IMHO its coming.

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Jan 2016 14:13:02 -0600

Given the population of Switzerland is half a million fewer people than the population of New York City, the Swiss experience might be informative for Tom’s sister, who moved around in Manhattan, but may not be informative for a larger country such as Germany, France, the UK, Russia, or the U.S.

> On Jan 4, 2016, at 10:35 AM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 

> On Jan 4, 2016, at 9:16 AM, McGarry, Tom <[email-masked]> wrote:
> 
> may not to a consumer.

---

From: "McGarry, Tom" <[email-masked]>
Date: Mon, 4 Jan 2016 21:09:26 +0000

Thanks Pierce and Richard, please see comments in line below.

On 1/4/16 11:21 AM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>provider and never change it.  With number portability the industry had
>to build new infrastructure, new administration functions and processes
>to change the association of the TN from one service provider to another."
>
>PG->  I'm OK with it.
>
>>
>boundaries, LATAs, consumer addresses, etc. that seem logical to them,
>but may not to a consumer.  I do think it would be beneficial for
>consumers to have the opportunity for more control over their numbers.
>As we move to IP, the timing is right to look at improving this.
>
>PG->  My understanding is rate centers and LATA boundaries were defined
>by attorneys as part of Judge Green's "Modified Final Judgement" in the
>United States vs. AT&T antitrust case of 1982.  It's unfortunate that it
>impacted your sister (and others), and I agree that Non-Geographic
>Portability (NGP) should (eventually) address the issue.  I disagree that
>the move to VoIP has very much to do with NGP.  I think you need to prove
>that a new MODERN system of numbering would eliminate time from the back
>office processes required by CSPs, or drop the point.
>
>PG->  I think you still need to define full control better.  The example
>you provided will be a benefit of NGP, not MODERN (unless MODERN were an
>unavoidable prerequisite or undeniable benefit which I don't think anyone
>will argue).

Tom: The use cases propose that the consumer receives a credential that
proves they have been allocated the TN.  The example given is for number
portability.  They present the credential to the new service provider and
the service provider uses this proof to port the number w/o a back and
forth with the old service provider.  They activate service for the
customer and in essence send a "loss notification" to the old service
provider.  I could ultimately see this credential being used for other
purposes such as associating a TN with a new app.

Would "more" control work better for you?
>calls are "local" and charged accordingly per regulatory requirements.
>This isn't changing.  Also, mobile carriers cannot page an entire network
>for every call termination attempt so localizing the call termination
>processing is important.  A benefit of NGP will be optimized call
>termination localization (at the cost of additional porting information
>management).  i.e., call processing can be optimized by porting numbers
>which spend a high percentage of time hosted from a "visited"  platform
>(within a CSP's network).  Mobile call processing necessarily resides in
>a platform with a geographic location and regional responsibility.
>Numbering and geography for mobile call processing continue to have an
>important relationship that needs to be recognized, not dismissed.  i.e.,
>to optimize call routing and number management, new number assignments
>should still be done with a sensitivity to geography.  And when numbers
>are released back to the CSP, new assignments with a number should be
>within the context of the region from which the number was originally
>assigned.  This isn't a policy suggestion, it's a network design and
>operation optimization.  Geography matters.

So this discussion seems to be about the changing the word "erode" to
"obfuscate".  By erode I was suggesting that there was less and less
connection between the geography associated with the phone number and the
geography of the consumer (where they are).

Can you explain what you are trying to communicate by using the word
"obfuscate"? 
>listinfo_modern&d=CwIFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=sgz7ixbLC0QKplG2qlyreASixYtoRiCSnpEzKKPlpt0&s=LgXU
>YaelEAQGsIst1HeErsD9lEyaytfi-fSS-Mpb4f0&e=
>
>t.com_50off&d=CwIFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1oo
>Ncfp01IYIaVqsORjI&m=sgz7ixbLC0QKplG2qlyreASixYtoRiCSnpEzKKPlpt0&s=TZG_jHsj
>47Qat6lA8kdJjHdz2sp9bCcWZ9Q7RVmA4Ec&e= > for details.
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 Jan 2016 21:37:37 +0000

Richard,

This may not be completely appropriate to the MODERN WG discussion, but just a quick point of clarification.

My notes on the Order to Reform ICC Rates show that the "price cap" LECs (aka RBOC's) and the "rate of return" LECs (aka rural LECs) both get to .0007 (on different schedules as you mentioned), but my working assumption has been it never goes to "zero" as you wrote below.

There is a bill-and-keep component.  I've assumed that bill-and-keep is balance of traffic only and that balance of traffic overages would be paid to the terminating LEC.  i.e., there will still be transport access charges (albeit at .0007 per minute).

This exact understanding has been a bit of a problem for me to nail down.  Either I ask the question wrong, or ask the wrong people, but I'm not comfortable I know the complete story.  It could be I'm wrong, and the only access will be facilities charges and transport costs of .0007 (tariffs to be filed this year) do indeed fall to zero (in 2018 for price cap LECs).  Can you confirm?

Pierce

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: January 04, 2016 1:47 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; Richard Hill <[email-masked]>; 'McGarry, Tom' <[email-masked]>; [email-masked]
Subject: Re: [Modern] Problem statement draft problems

>> >With respect to geographic number assignment, the rejoinder, "But
>> >the overwhelming success of mobile telephones has increasing eroded
>> >the connection between numbers and regions" has problems at least in
>> >the context of the North American numbering plan.
>>
>> connection between numbers and regions - that's what it does.  This
>> is pointing out that it is now a dominant portion of the market.
>>

---

From: David Greenhaus <[email-masked]>
Date: Mon, 4 Jan 2016 21:56:53 +0000 (UTC)

All,
Regarding the issue of geographic origination, I'd like to bring your attention to a white paper prepared by the Future of Numbering Working Group of the NANC).  This document was transmitted by the NANC to the FCC, by member agreement, at a recent NANC meeting; it illustrates the critical importance of "fuzzy" geographic origination information required to route many toll free calls.  

The document can be found at:    http://www.nanc-chair.org/docs/documents.html
FoN White Paper on Geographic Routing of Toll Free Services

    On Monday, January 4, 2016 4:37 PM, "Gorman, Pierce A [CTO]" <[email-masked]> wrote:

 Richard,

Pierce

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 Jan 2016 21:57:51 +0000

>>of mobile telephones has increasingly obfuscated the connection between
>>numbers and regions".
>>

" Can you explain what you are trying to communicate by using the word "obfuscate"? "

Blurred.  Confused.  Made non-obvious.  Obstructed a clear and easy understanding.  Overcomplicates.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 Jan 2016 22:16:01 +0000

Thank you David.  Agree that Toll Free is one example of many call routing requirements with necessary consideration for geography.

Pierce

From: David Greenhaus [mailto:[email-masked]]
Sent: January 04, 2016 3:57 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; Richard Shockey <[email-masked]>; Richard Hill <[email-masked]>; 'McGarry, Tom' <[email-masked]>; [email-masked]
Subject: Re: [Modern] Problem statement draft problems

All,

FoN White Paper on Geographic Routing of Toll Free Services<http://www.nanc-chair.org/docs/fon/FoN_White_Paper_Geographic_Routing_Toll_Free_Services_20141001.docx>

<http://www.nanc-chair.org/docs/fon/FoN_White_Paper_Geographic_Routing_Toll_Free_Services_20141001.docx>

On Monday, January 4, 2016 4:37 PM, "Gorman, Pierce A [CTO]" <[email-masked]<mailto:[email-masked]>> wrote:

Richard,

Pierce

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]<mailto:[email-masked]>]
Sent: January 04, 2016 1:47 PM
To: Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>>; Richard Hill <[email-masked]<mailto:[email-masked]>>; 'McGarry, Tom' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Modern] Problem statement draft problems

>From: Modern [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Hill
>To: Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>>; 'McGarry, Tom'
><[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> From: Modern [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gorman,
>> Pierce A [CTO]
>> To: McGarry, Tom; [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>>
>>
>>
>> From: Modern [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of McGarry,
>> Tom
>> To: [email-masked]<mailto:[email-masked]>
>> On 12/28/15 5:53 PM, "Gorman, Pierce A [CTO]"
>> <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>> >Steve,
>> >
>
>SNIP
>
>[email-masked]<mailto:[email-masked]>

>[email-masked]<mailto:[email-masked]>

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.
_______________________________________________
Modern mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/modern

---

From: Richard Shockey <[email-masked]>
Date: Mon, 04 Jan 2016 17:27:12 -0500

Its appropriate… We are actually discussing the technical justification for the problem statement in the context of North America. 

To your point.  IMHO it goes to zero sooner rather than later since the cost of billing then outweighs the monies collected. The EU still doesn’t get this.  The basic theory behind IP interconnection aka rough symmetry. At that point its a bilateral agreement between service providers. Obviously the issue is with the RLEC's.  Termination rates falls to zero in 2018 but the issue of access rates has yet to be resolved. 

Its a complicated issue to be sure. The Commission has issued endless Further Reconsiderations here. I’d go into gory details but that to consultants like me ..that’s billable hours. 

However the trend is unmistakable. The reason it gets interesting is this issue of NG-NP.  I’ve seen the briefs here in the US and its very persuasive. The smaller wireless carriers have successfully argued that they are at a competitive disadvantage since they cannot port in numbers out of LATA from the national carriers.  National carriers like Sprint ATT VZ and T-MO just enable roaming and simply change the billing address. 

The smaller carriers went to Congress, Congress sent nasty grams to Chairman Wheeler, Tom agreed …and the ball started rolling. I’ve been around America’s swampland long enough to know what is coming.  The Chairman will preach “competition competition completion” at every bully pulpit he can find. I’ll bet serious money there is a NPRM on this this summer. Not to mention that 10% of the US population moves every year.  That is Census data. 

Pierce when you see a letter from the House Commerce Committee that has Greg Waldren and Anna Eshoo signature on the same page I smell “consensus”. 

The single NPA states will whine but I was invited to NARUC last month in Austin to muse on this subject and I did not sense a lot of resistance. 

So what does this mean for Modern.  Well if you assume NG-NP is coming then that means you have to implement national 10 digit dialing across the board landline as well as wireless.  Ok then that means you get to open up the D digit in the dialing plan.  The second N in NPA-NXX which can never be 0 or 1. Open up the D digit you instantly increase the size of the NANP by 20% and all of the NANP numbering exhaust issues go away until hell freezes over or we are all dead and you have to reform the entire access regime at the same time.   Oh and BTW you really don’t need single number allocation technology, at least in North America because the rationale for the problem statement, at least in North America is moot, unless there is some other private agenda the proponents of this problem statement have. :-) 

On 1/4/16, 4:37 PM, "Modern on behalf of Gorman, Pierce A [CTO]" <[email-masked] on behalf of [email-masked]> wrote:

>>> <[email-masked]>
>>> wrote:
>>>
>>> >Steve,
>>> >
>>
>>SNIP
>>

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 5 Jan 2016 11:22:13 +0100

> From: Modern [mailto:[email-masked]] On Behalf Of Eric Burger
> Sent: Monday, January 4, 2016 21:13
> To: [email-masked]
> Given the population of Switzerland is half a million fewer people than
> the population of New York City, the Swiss experience might be
> informative for Tom’s sister, who moved around in Manhattan, but may
> not be informative for a larger country such as Germany, France, the
> UK, Russia, or the U.S.

I used Switzerland as an example merely because that's where I live. Geographic number portability was actually implemented in other European countries before it was implemented in Switzerland, see for example:

  https://en.m.wikipedia.org/wiki/Local_number_portability#Europe 

The Wikipedia article cites an EU Directive. That directive is at:

  http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32002L0022 

As you will see from its article 30, that Directive only imposes provider portability for geographic numbers. And indeed, as far as I can tell, most countries seem to have implemented only provider portability, not full geographic portability.

One thing that I noticed when looking at individual country numbering plans is that they all seem to take the view that numbers are assigned to operators, not to end-users, even if end-users have specific rights, such as portability.

Regarding the US (and the NANP in general), there is of course a big difference with respect to most of the rest of the world. In most of the rest of the world, mobile is caller-pays, and separate "area codes" are used for mobile, so that the caller knows that he or she will be paying more for the call.  So there is no portability between fixed and mobile numbers.  In the NANP, mobile is receiver-pays and there is no distinction between mobile numbers and fixed numbers, so there could be portability between fixed and mobile numbers.

Best,
Richard

> > Her service provider would not let her keep her number.  You and I
> > know that is because she moved from one CO serving area to another
> and
> > the company didn't want to go through the process of porting her
> > number between their switches.  While I would think this is not
> > common, it's not rare either.  Service providers build rules into
> > their systems and processes that account for things like rate
> centers,
> > wire center boundaries, LATAs, consumer addresses, etc. that seem
> > logical to them, but may not to a consumer.
> >

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Sun, 10 Jan 2016 23:36:09 +0000

As promised, below are my remaining edits and editorial comments.

The format of my comments is as follows:

- Section reference

- Quoted content from the Problem Statement

- Recommended edits and/or editorial comments

I'll preface the work below by saying I have completely read the document word for word and my previous estimation remains that the main issue with the problem statement is that it fails to meet the burden of proof that there is a problem that needs to be solved.

A problem statement is something like, "The alligators in the swamp adjoining my back yard keep eating my pets."

A solution statement would be something like, "In order to deal with the issue(s) outlined in the problem statement, it is recommended that a strong fence be constructed (which prevents access to my pets from alligators in the swamp adjoining my back yard)."

The MODERN problem statement is in fact a TN management solution framework.  i.e., a solution looking for a problem.

If there is a problem that MODERN addresses, it is the inability of end users to directly (through a protocol) manage requisition and release of TNs and manage their associated metadata.  This is not a protocol problem.  It is a policy problem (if it is a problem at all).  And the only provisioning protocol I remember seeing referenced in the solution statement is a SIP REGISTER.  In this, MODERN is hardly any different then TRIP and equally useful.

My main recommendation is to scrap the so-called problem statement and start over.  Do not introduce any text that even resembles a solution framework.  The problems can then be easily identified and discussed.  And I encourage discussion of policy as part of the problem so that in the end you can hopefully clearly differentiate between issues that are political and issues which are technical and therefore appropriate for the MODERN WG.

Respectfully,

Pierce Gorman

_________________________________________________________

1.  Problem Statement

"In an Internet environment, establishing a network architecture for routing TNs would depend little on geography."

I recommend changing the word "would" in the previous sentence to "could".

At a minimum the routing of calls to and from TNs is impacted by the geography and the policies of the nation in which the TN is assigned regardless of the layer 2/3 network transport.  The fundamental problem with the line of reasoning in this sentence is that it misses the fact that geography is a key consideration in TN assignment, service provisioning, delivery and assurance, that must not be dismissed or overlooked but recognized and dealt with.

"Adapting TNs to the Internet requires more security, richer datasets and more complex query and response capabilities than previous efforts have provided."

Can you provide comparative examples to"previous efforts" illustrating why more security, richer datasets and more complex query and response capabilities are required?  If so, it will be helpful to the reader.  If not, then you should strike the sentence.

"With the PSTN well on its way to transitioning to an all IP network,and TNs showing no signs of sunsetting as a resource, it is time to address the issues of routing, management and administration of TNs in an IP environment."

The subject at the end of the sentence is ironically juxtaposed to the prequalifying assumptive phrases at the beginning of the sentence.

That is, if the PSTN is already "well on its way to transitioning to an all IP network", then how can it be that now is the "time to address the issues of routing, management and administration of TNs in an IP environment?"

It can be argued that the proof that those issues have already been addressed adequately is the very the fact that the PSTN is already "well on its way to transitioning to an all IP network".

I would strike the sentence as being unnecessary to the MODERN problem statement.

Section 2.1

"The following actors are defined in this document:

Numbering Authority:  A regulatory body within a country that manages that country's TNs.  The Numbering Authority decides national numbering policy, including what TNs can be allocated, and which are reserved."

Countries can and do have more than one numbering authority.  Either change the wording or change the actor name to "National Numbering Authority" and add a subcategory for "Regional or otherwise subtended Numbering Authority (to the National Numbering Authority)".

I would change "The Numbering Authority decides national numbering policy" to "The Numbering Authority decides numbering policy for the nation, region, or other domain for which it has authority".

"There are two types of Registries an authoritative Registry and a distributed Registry.

An authoritative Registry is a single entity with sole responsibility      for specific numbering resources.

Distributed Registries are multiple Registries responsible for the same numbering resources.  (There's more on distributed Registries later in this section.)

The general term Registry in this document refers to both kinds of Registries.  When referring to one versus the other this document will use the specific term."

I recommend breaking out each registry type as it's own actor.

I also am struggling with your use of the term "registry" whereas I think you're referring not so much to registries (i.e., database services) so much as database models with respect specifically to non-duplicated versus duplicated data.

The database models you described can have hybrids.

One hybrid could be multiple independent distributed (in the sense that they are non-collocated and/or in different administrative domains) databases who collectively represent an authoritative (i.e., non-duplicative) set of assignment data.  An example of this model would be the set of .com top-level domain name databases.

Another hybrid could contain top level (e.g., Numbering Plan Area) assignments maintained in a single national-level non-duplicative authoritative database and subtending assignments maintained in distributed (non-duplicative or duplicative) databases managed by regional numbering authorities.

"User:  An individual reachable through a communications service; usually a customer of a communication service provider who uses TNs to reach and identify services.  Sophisticated users may also act as their own CSPs."

The "User" actor definition is ambiguous.

To reduce ambiguity consider striking the phrase, "...who uses TNs to reach and identify services" from the first sentence of the definition (assuming the phrase refers to the CSP and not the User).  The phrase is uncessary and does not add clarity.

I recommend striking the 2nd sentence, "Sophisticated users may also act as their own CSPs."  Doing so would not presumably preclude a sophisticated user from being a CSP, but it appears to be a statement of policy or capability and isn't clear in either case.

"Government Entity:  An entity that, due to legal powers deriving from national policy, has privileged access to information about number administration under certain conditions.

Note that a given entity may act in one or more of the roles above. An entity acting as a CSP, Service Enabler, or User can also be said to have a relationship to the Registry of either an assignee or delegate:"

The "entity" stuff is confusing.

Are you indicating that an "entity" is somehow different from an "Actor"?  Or, are you saying that an entity is a special kind of "Actor"?

How about replacing the phrase, "a given entity" with the phrase, "an actor"?

How about removing the phrase, "An entity acting as" in the 2nd sentence of the 2nd paragraph?

"Assignee:  An entity that is assigned a TN by the Registry.  There is always a direct relationship between the Registry and the assignee.

Delegate:  An entity that is delegated a TN from an assignee or another delegate.  Delegates may use a TN for a communications service or delegate it in turn."

I didn't understand the need for the qualification, "There is always a direct relationship between the Registry and the assignee" in the definition of the Assignee actor.

I would avoid the use of the term, "entity", and replace the entire Assignee actor definition with the following:

"Assignee:  An actor that is assigned a TN by the Registry."

Similarly, I would replace the word "entity" with "actor" in the definition for Delegate.

The second sentence in the definition of the Delegate is confusing and ambiguous.

The phrase "Delegates may use a TN for a communications service" is written such that it could imply that a TN could be used as a form of communications service although clearly this wasn't the intent.  And the end of the sentence referring to additional delegation is too open-ended and should not be combined with the first part of the sentence.

I recommend breaking the sentence into 2 parts.

First change the phrase, "Delegates may use a TN for a communications service" to be a sentence reading, "Delegates may associate a TN with a communications service."

Second change the phrase, "or delegate it in turn" to be a sentence reading,  "Delegates may delegate one or more of their TN assignment(s)to one or more further downstream subdelegates who may also delegate their assignment(s).  There can be up to 1024 levels of sub-delegation."  (Just kidding about the 1024 levels, but you get the idea.)

Section 2.2

"Administrative Data:  assignment data related to the TN and the relevant actors; it includes TN status, contact data for the assignee or delegate, etc. and typically does not require real-time performance."

What is meant by "TN status"?

If the definition of "TN status" is clear, unambiguous, and short, use that instead.  If it is not, delete it from the definition of "Administrative Data".

"Service Data:  data necessary to enable service for the TN; it includes addressing data, feature capabilities, etc. and typically does require real-time performance."

If examples or the definition of "feature capabilities" is clear, unambiguous, and short, use that instead.  If it is not, delete it from the definition of "Service Data".

Delete "etc.".

Define what is meant by "real-time performance" in the context of it being a requirement.  i.e., what part of the problem statement indicates a need for real-time, or non-real-time performance?

If we look at existing numbering and registration systems (in North America) as an example, what about their real-time, near-real-time, or non-real-time performance is a problem to be solved?

"Public:  data that anyone can access, for example a list of which numbering resources are available for acquisition from the Registry."

Define "numbering resources".

Define "available".

"Semi-restricted:  data that a somewhat broad subset of actors can access, for example CSPs may be able to access other CSP's service data."

Delete the words "somewhat broad".

Delete the example.  Defining policy should be outside the scope of the problem statement should it not?

"Restricted:  data that is only available to a small subset of actors, for example a Government Entity may be able access contact information for a User."

Delete the example.

As you acknowledge there are really only two categories; unrestricted and restricted.  Degree of restriction is a matter of policy.

2.3 Data Management Architectures

"Beyond traditional centralized Registries, this framework also supports environments where the same data is being managed by multiple entities, and stored in many locations."

I would delete this paragraph for being inappropriate to a problem statement.  Save it for the solution to the problem(s).

"Data store:  a service that stores and enables access to administrative and/or service data.  Typically Registries and CSPs would manage data stores."

I would delete the last sentence, "Typically Registries and CSPs would manage data stores."

"Reference Address:  a URL that dereferences to the location of the data store."

This is an artifact of a presupposed solution to a problem and does not belong in a problem statement.  I would delete this and save it for a solution statement.

"Distributed Registries:  refers to multiple Registries managing the same numbering resource.  Actors could interact with one or multiple Registries.  The Registries would update each other when change occurs.  The challenge is to ensure there are no clashes, e.g., two Registries assigning the same TN to two different actors."

Define "numbering resource".

I would delete, "The Registries would update each other when change occurs.  The challenge is to ensure there are no clashes, e.g., two Registries assigning the same TN to two different actors."

These statements presuppose a solution architecture and make assumptions about the type of TN being assigned.  These statements do not belong in a problem statement.  They should be saved for a solution statement.

3. Framework

"The framework outlined in this document requires three Internet-based mechanisms for managing and resolving TNs (TNs) in an IP environment.  These mechanisms will likely reuse existing protocols for sharing structured data; it is unlikely that new protocol development work will be required, though new information models specific to the data itself will be a major focus of framework development.  Likely candidates for reuse here include work done in DRINKS and WEIRDS, as well as the TeRQ [12] framework.

These protocol mechanisms are scoped in a way that makes them likely to apply to a broad range of future policies for number administration.  It is not the purpose of this framework to dictate number policy, but instead to provide tools that will work with policies as they evolve going forward.  These mechanisms therefore do not assume that number administration is centralized, nor that number "ownership" is restricted to any privileged service providers, though these tools must and will work in environments with those properties."

The first sentence in the first paragraph has parentheses around the acronym TN without spelling out the acronym.  Either eliminate the parenthetical TN or spell out Telephone Number.  Here I will also mention that Telephone Number is an ambiguous and increasingly anachronistic term that might be better served being replaced by the term "E.164 number".

I would delete the sentence, "Likely candidates for reuse here include work done in DRINKS and WEIRDS, as well as the TeRQ [12] framework."   It is an editorial opinion and not necessarily appropriate to a problem statement.

"Acquisition:  a protocol mechanism for acquiring TNs, including an enrollment process."

Define "enrollment".  Does "enrollment" imply or mean "subscription"?

"Retrieval:  a protocol mechanism for retrieving data about TNs from either an authority or a CSP."

I would delete the end of the definition beginning with the word "from".  It presupposes a solution architecture and is not appropriate to a problem statement.

"The acquisition mechanism will enable actors to acquire TNs for use with a communications service.  The acquisition mechanism will provide a means to request numbering resources from a service operated by a Registry, CSP or similar actor.  TNs may be requested either on a number-by-number basis, or as inventory blocks.  Any actor who grants numbering resources will retain metadata about the assignment, including the responsible or individual to whom numbers have been assigned."

Define "numbering resources".

Insert  the word "parties" between the words "responsible" and "or" in the last sentence.

Should the paragraph describing acquisition mechanism be included as a subparagraph under the initial definition of "Acquisition"?

"The management mechanism will let actors provision data associated with TNs at CSPs.  For example, if a User has been assigned a TN, they may select a CSP to provide a particular service associated with the TN, or a CSP may assign a TN to a User upon service activation.  In either case, a mechanism is needed to provision data associated with the TN at that CSP."

To me, the first sentence is ambiguous with respect to where management action is taking place.  Are you indicating management of TN and TN-associated information withing the corporate database of a CSP?  Or, are you indicating the ability to manage the TN and TN-associated information within a MODERN database hosted by one or more MODERN-enabled registries?

The latter of the two possibilities seems less fraught with legal and operational problems.   I would have just assumed the latter except for your additional remarks about the "retrieval mechanism".   More on that below, but here I'll just state my opinion you should confine your scope to the public realm (as inferred in the last sentence of the charter) and will direct most of my remarks as though you agreed.

Perhaps change the first sentence to read, "The management mechanism will permit actors to provision data associated with TNs within registries."

And change the last sentence to be, "In either case, a mechanism is needed to provision data associated with the TN within registries."

Should the paragraph describing the management mechanism be moved to be a subparagraph under the initial definition of "Management"?

"The retrieval mechanism will enable actors to learn information about TNs, typically by sending a request to a CSP.  For some information, an actor may need to send a request to a Registry rather than a CSP.  Different parties may be authorized to receive different information about TNs."

The Charter implies the output of the working group is a a potentially global process and method which user and CSP actors would use to manage TN assignment and the metadata associated with the TN.

I'm stunned that you're also recommending that the framework include a requirement for user actors to be able to directly manage TN and TN metadata within a CSP actor's private corporate database.

My opinion is you should confine your scope to the public registry realm and avoid creating mechanisms and frameworks which force CSPs to expose their private corporate databases in any particular way.

CSPs often (and increasingly so) make user-defined provisioning options available as a matter of competitive advantage, but creating an IETF-designed requirement to do so as part of a TN and TN metadata management framework is not advisable.  It makes adoption hurdles more difficult and therefore increases the chances that MODERN is more narrowly accepted, if at all.

If you want your work used, you should aim for the broadest possible adoption and requiring user actor access to CSP actor information is probably going to harm your chances of achieving your goals.  I recommend you confine your framework and design to publicly-held and managed implementations.

Many IETF protocols and mechanisms have been the source of cyberplagues and MODERN is an obvious target.  If you have a specific kind of information that you think would only be available to a CSP actor and that MUST be directly retrievable or changeable by user actor having direct access to a CSP actor's database, then you should state what that information is and why that steers away from a design using an indirect method through a public registry.

4. Use Cases

4.1 Acquisition

"There are three actors from which numbers can be acquired: a Registry, a CSP and a User (presumably one who is delegating to another party). In these use cases, a User may acquire TNs either from a CSP or a Registry, or from an intermediate delegate."

The use of the term "delegate" is very loose in this document.  The definitions and use cases seem to imply delgation and subdelegation between user, CSP, and service enabler actors can cascade factorily.

I appreciate that Section 4.1.1 tries to more precisely outline and proscribe possible or probable assignee and delegation relationships.  This is necessary.  It would be good if you could also describe what are the expected reasons for having permitted/designed those relationships.

Section 4.1.1 CSP Aquires TN from Registry

"The Registry maintains a profile of the CSP and what qualifications they possess for requesting TNs."

Please explain (somewhere) what is meant by "a profile of the CSP".

Please outline why it is important for the registry to maintain a profile that contains the CSP "qualifications they possess for requesting TNs".

Is there also an expectation that a registry should also maintain profiles of users and the "qualifications they possess for requesting TNs"?

The suggestion of using the MODERN numbering management process to also perform key management for another IETF initiative (STIR) is sensible in the context of advocates of MODERN promoting other favorite sons, but hopefully won't be a detailed part of the MODERN number management solution.  It is fine to suggest it as a plausible thing to do, but there isn't anything like consensus with regard to whether STIR is a good or favored approach for authenticating calling identity and should be outside of the scope of MODERN.

I'm going to skip over making any further comments on the various MODERN use cases.  They would have been useful as part of a definition of terms from which a problem statement was constructed.  In the case of this document they are presented as functional parts of a MODERN solution framework, not a problem statement.

4.2 Management

"While some similar use cases may apply to individual Users, it is anticipated that for the most part these lower-level service information changes would be communicated via existing protocols (like the baseline [2] SIP REGISTER method) rather than through any interfaces defined by MODERN."

The above paragraph is duplicated in it's entirety across pages 10 and 11.  Delete the duplicate that ends on page 11.

4.2.2.  Management of Service Data

"Service data is data necessary to enable communications service to the delegate or User, for example a SIP URI."

This is naive.  It assumes a simple single SIP URI would be sufficient "to enable communications service to the delegate or User".

A consequence of private interconnection networks used for exchanging peering traffic between CSPs (which is the norm) means that a single SIP URI is almost certainly out of the question.  As I tried to explain in on-line discussions about numbers and geography, call routing of services to a TN often requires knowing where the call is originating (either physically and/or logically) and then using the terminating address that makes sense in the context of the originating network.

This oversimplified model of how call routing works is a weakness of the MODERN TN information management model.

CSPs often have multiple (and regional) physical and logical private and public network boundaries using a mixture of private (e.g., RFC1918) and public IP (IPv4 or IPv6) addressing.  This impacts managing SIP URIs associated with a TN and what the visibility should be to those URIs and by whom.  It eliminates any practical possibility that a single URI is sufficient.

URI information associated with a TN will be different for different interconnection relationships which steers toward a distributed database model maintained largely by and for CSPs moreso than end-users and governments.  (I think you tacitly acknowledge this in section "4.2.2.1.  CSP to other CSPs".)

4.2.2.3.  User to Registry

"As stated already the protocol should enable Users to acquire TNs directly from a Registry and in essence act as their own CSP."

This is just impractical in the case where there are tens or hundreds, or even thousands of millions of users (which is all of the important cases) because the registry cannot possibly vet with any usable reliability the trustworthiness of this many actors let alone prosecute them.  Ask anyone whose worked in the US Internal Revenue Service.  They can't possibly know if all of the "users" are alive, dead, illegal aliens or where they say they are, or whether they appropriately paid their taxes.  Tax fraud is a multi-billion dollar problem.  If we overlay that model on management of TNs, you can practically guarantee that STIR will be of no use whatsoever.

The reality is users are going to want (and should be permitted) multiple TNs, but the management of their access and use has to be delegated to organizations who have a vested interest in being able to recover the TNs, make efficient use of them, and who can prosecute the users if there is a problem.  That is, the government needs to give inventory to CSPs who then need to manage the users' use of it.

4.2.3.1.  Changing the CSP for an Existing Communications Service

"The User provides their credential to the new CSP and the CSP initiates the change in service."

No argument with the method, but will mention at least two large regulatory environments do not embrace it.  You should consider how to integrate other methods such as requesting that the old CSP move the TN assignment to the new CSP.

"The old credential is revoked and a new one is provided."

This seems to imply an integrated STIR or STIR-like function which might make sense but should be outside of the scope of MODERN.

I recommend deleting all references to credential management that fall outside of section 4.1. use case examples.

"[TBD - more on the case where multiple CSPs provide services for a given TN, and only one service is "ported" to a new CSP?]"

This is actually one of the more important use cases in my mind but not as a part of a problem that MODERN is required to solve.  Based on what I've read of problems in the so-called "problem statement" I still don't believe MODERN is required.  Regardless, the use case is valid and important.

I have a sincere frustration that my e-mail address is broken if I move my e-mail between e-mail service providers.  I would much prefer to have e-mail address portability.  I could easily have this if my e-mail address were based on my TN.  This is an example of where TNs are far superior to domain names.  They are not vulnerable to international character set exploits, et cetera.  So, I am very sympathetic to a broadened use of TNs and associating metadata (such as e-mail URI) to them for the very purpose of enabling portability between CSPs if nothing else.  It's just that MODERN isn't required in order to achieve this outcome and benefit.

4.2.3.2.  Terminating a Service

"In an alternative use case, a User who received their own TN assignment directly from the Registry terminates their service with a CSP.  At this time, the User might terminate their assignment from the Registry, and return the TN to the Registry for re-assignment. Alternatively, they could retain the TN and elect to assign it to some other service at a later time."

I'll encourage others who know more about TN inventory management, but on the surface this and delegation look promising for providing an environment ripe for problems with fraud, abuse, and number exhaust.

4.3.1.  Retrieval of Public Data

"Under most circumstances, a CSP wants its communications service tobe publicly reachable through TNs, so the retrieval interface supports public interfaces that permit clients to query for service data about a TN.  Some service data may however require that the client by authorized to receive it, per the use case in Section 4.3.3 below.

Public data can simply be posted on websites or made available through a publicly available API.  Public data hosted by a CSP may have a reference address at the Registry."

One of the robocalling problems plaguing the industry are calls that are apparently sequencing through number blocks in an apparent attempt to identify which numbers are assigned and which are not.  The intentions of the robocallers wanting this information are suspect and assumed to be bad.  Making the information publicly available on the Internet may actually put the public at risk of material harm.  Ask any mobile user if they would prefer that their TN and CSP information be available on a public database and see what they say.

Most of this paragraph is of a policy nature and does not belong in a problem statement or an RFC.  Section 4.2.3.2 has similar weaknesses.  i recommend removing any references to policy.

4.3.2.  Retrieval of Semi-restricted Administrative Data

"A CSP is having service problems completing calls to a specific TN, so it wants to contact the CSP serving that TN."

This is not representative of how trouble management is handled in the US.  Trouble management is between carriers with Inter-Connection Agreements, not between originating and terminating carriers.

I believe the sentence and example does not contribute usefully to the section.  I recommend deleting it.

4.3.3.  Retrieval of Semi-restricted Service Data

"There are multiple scenarios to for the query and response."

Delete either the word "to", or the word "for" from the sentence.  I recommend deleting "to".

5.  Distributed Registries and Data Stores

"For example, when a CSP enables service for a User they can initiative an update of the service address to multiple other data stores managed by other service providers."

The word "initiative" should be changed to "initiate".

The phrase "[More TBD]" should be removed or more should be added.

8.  Security Considerations

"TBD."

This is a bigger handwave then the usual caveat that security is important and be careful because the authors didn't know what else useful to write.

I recommend adding the usual useless boiler-plate, or actually try to introduce discussion and description about potential fraud and abuse issues from malintentioned User actors being able to directly request and manage the metadata associated with their own TN number assignments or the unrestricted public data of other TN  and associated CSP assignments.

---

From: Eric Burger <[email-masked]>
Date: Sun, 10 Jan 2016 22:47:03 -0600

Smells like we are a long way from a WG document.

> On Jan 10, 2016, at 5:36 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 11 Jan 2016 17:07:15 -0600

On 1/10/16 17:36, Gorman, Pierce A [CTO] wrote:
> *Learn more on how to switch to Sprint and save 50% on most Verizon, 
> AT&T or T-Mobile rates. See sprint.com/50off <http://sprint.com/50off> 
> for details. *

Really?

/a

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 11 Jan 2016 23:20:57 +0000

Yes, I wrote that and I place it at the bottom of every single e-mail issued by every single Sprint employee who sends e-mail outside of Sprint because I’m just that good.

Or, wait.  No, sorry.  I was thinking of something else.  I have nothing to do with the advertising that gets appended to our e-mails.  But what a great deal, eh!?

Best regards,

Pierce Gorman
[email-masked]
[Macintosh HD:Users:stephanie.laemoa:Desktop:moveforward_1.png]

From: Adam Roach [mailto:[email-masked]]
Sent: January 11, 2016 5:07 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; McGarry, Tom <[email-masked]>; [email-masked]
Subject: Re: [Modern] Problem statement draft problems

Really?

/a

---

From: "McGarry, Tom" <[email-masked]>
Date: Wed, 20 Jan 2016 19:08:05 +0000

Thanks for the feedback Pierce.  Here are responses to your comments in Sections 1 and 2.  Please see below.

From: <Gorman>, Pierce Gorman <[email-masked]<mailto:[email-masked]>>
Date: Sunday, January 10, 2016 6:36 PM
To: Tom Mcgarry <[email-masked]<mailto:[email-masked]>>, Modern List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Problem statement draft problems

- Section reference

Respectfully,

Pierce Gorman

1.  Problem Statement

Tom:  OK

Tom:  Earlier versions of the draft provided specific previous examples, but people objected to it as protocol bashing, so the examples no longer appear in the draft.

Tom:  OK

Section 2.1

Tom:  OK

Tom:  OK

Tom:  OK

Tom:  This is a statement of role, not policy.

Tom:  I agree, the term entity should be removed in the descriptive text.

Tom:  The second sentences in the definitions are to further explain the difference between the two definitions.  I'll clarify the text.

Section 2.2

Tom: assigned, unassigned, etc.  I'll add a parenthetical definition.

Tom:  I'll change it to "features"

Delete "etc.".

Tom:  Will add a parenthetical definition.

Define "available".

Tom:  OK

Delete the example.

Tom:  I believe the examples are helpful and not confusing.

Tom:  This is covered in the use cases and defining it here is helpful to the flow of the document.

Tom:  OK

Tom:  A reference address is a well understood method to access a data store.  This is one of multiple solutions described in the use cases.

Tom:  These are described in the use cases and I believe it is helpful to define it here.

---

From: "McGarry, Tom" <[email-masked]>
Date: Sat, 30 Jan 2016 16:58:23 +0000

Thank for the feedback, Pierce.  Comments below.

3. Framework

TOM:  OK.

TOM:  Part of the discussion so far is how we can borrow from many existing protocol work already done.  This is simply emphasizing that.

TOM:  The term is used as it is commonly defined as a verb.

TOM:  OK

TOM:  OK

TOM:  I prefer to define the concepts at a high level, then go through each on more detail, rather than go through each in detail.

TOM:  I'd rather be less proscriptive here and leave the detail you're referring to to the use cases.  We can make it more general by deleting the text "at CSPs" in the two places it appears.

TOM:  Actors in the environment need to access data about TNs.  This may help them route, may help them manage their networks, it may help them identify other actors.  These are true today.  All this is saying is that there is a need to retrieve this data from those that have it.

4. Use Cases

4.1 Acquisition

TOM:  Most of these relationships exist today.  Others have been added to capture those possibilities.

TOM:  The term is used as commonly defined as a noun.

TOM:  This is self explanatory to anyone knowledgable about the environment.

TOM:  Yes, but not this use case.

4.2 Management

TOM:  OK

TOM:  We will replace "necessary" with "required by an originating or intermediate CSP".

TOM:  Yes, we should capture the concept of that method.

TOM:  There is no intention to do STIR work here.  It simply mentions a possible solution.

TOM:  Agree that this is important to get right.  Regulators with the industry will determine what data fits into which category.  This is merely giving examples.

TOM:  This does not suggest that the service providers do or do not have an agreement.

TOM:  OK

TOM:  OK

TOM:  OK

"TBD."

________________________________
Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off<https://urldefense.proofpoint.com/v2/url?u=http-3A__sprint.com_50off&d=CwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=PN9H3Uh_oqrqmFqjHhCvWEsGaVryUcELdOgJyuP-xk4&s=feLBdMwmyyyJPDidSluzELpopEOmx_gUTOluH95vqJI&e=> for details.