Subject: [Modern] Revised MODERN Charter

From: "McGarry, Tom" <[email-masked]>
Date: Mon, 20 Apr 2015 14:45:44 +0000

The following changes were made from the version we went over in the BoF:

  *   The fourth paragraph defines the identifiers to be worked on as "E.164 telephone numbers and telephony related identifiers"
  *   The fourth paragraph describes the motivation as "the changing telecommunications environment and interest expressed by telecommunications industry regulators"
  *   The fourth paragraph acknowledges that while the work of a proposed working group could be reusable for other identifiers, the work will focus on E.164 telephone numbers and other telephony related identifiers
  *   The word "document" has been deleted from the list of deliverables to allow flexibility for combining deliverables

CHARTER TEXT:
The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment.  Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible.  The traditional model of a TN having an association to a single service provider and a single application is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities.

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment data and security of the resource will be primary considerations.

Additionally, the working group will deliver a protocol mechanism for resolving TNs which will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time application performance, security and privacy are primary considerations.  The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS.

The work of this group will focus on E.164 telephone numbers and other telephony related identifiers due to the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today.  There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers.  Extensions to the MODERN defined architecture and protocols can occur outside of the MODERN working group, either in parallel with the MODERN working group or after the MODERN working group is complete.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies.

The work group will deliver the following:

-       An architecture overview, including high level requirements and security/privacy considerations

-       A description of the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs

-       A description of protocol mechanisms for accessing contact information associated with enrollments

-       A description of mechanisms for resolving information related to TNs

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Apr 2015 01:35:53 +0000

Quick comments:

"security of the resource" - unclear what "resource" refers to and what security threats we worry about. Disruption by third parties? Rogue number manager? We don't have to go into great detail, but I think we agree that we generally assume that the managers are vetted and trusted and that any misbehavior would be dealt with outside a protocol context. (In the US, this is known as the FCC Enforcement Bureau - I guess you could call it the protocol police in this role.)

More substantially, we might want to specify more precisely what privacy risk we're worried about. After all, all TN managers will have access to the enrollment data. It also isn't obvious whether enrollment data includes whois-like information or (say) simply the OCN. I suspect that this will depend on national regulators and industry customs. Is the "enrollment data" the same as the CNAM data? Right now, pretty much anyone can query CNAM for any number (see OpenCNAM and other API services).

There is a bit of duplication between the "Additionally" paragraph and the next one, as both seem to include resolution and mention varying design requirements lists. Might be crisper to wrap the list of desirables into one.

This also implies that the lookup to CNAM and the unspecified resolution are different, but it seems likely that there's a single query -> data operation, possibly with qualifiers and differentiated data availability.

"or after the MODERN" - I wouldn't preclude re-chartering after the completion of the initial tasks.

________________________________
From: Modern [[email-masked]] on behalf of McGarry, Tom [[email-masked]]
Sent: Monday, April 20, 2015 10:45 AM
To: Modern List
Subject: [Modern] Revised MODERN Charter

CHARTER TEXT:

---

From: Steve Donovan <[email-masked]>
Date: Fri, 24 Apr 2015 11:01:05 -0500

Henning,

Please see comments inline.

Regards,

Steve

> "security of the resource" - unclear what "resource" refers to and what security threats we worry about. Disruption by third parties? Rogue number manager? We don't have to go into great detail, bu…
SRD> I read it as the resource being the identifier.
> More substantially, we might want to specify more precisely what privacy risk we're worried about. After all, all TN managers will have access to the enrollment data. It also isn't obvious whether…
SRD> Does this need to be specified in the charter?
> There is a bit of duplication between the "Additionally" paragraph and the next one, as both seem to include resolution and mention varying design requirements lists. Might be crisper to wrap the l…
SRD> The second paragraph focuses on the managing aspect mentioned in 
the first sentence of that paragraph.  The "Additionally" paragraph 
deals with the resolving aspect.  Maybe if we make the first sentence a 
separate paragraph?
> "or after the MODERN" - I wouldn't preclude re-chartering after the completion of the initial tasks.
SRD>  How about "or after the initial MODERN working group deliverable 
are complete".
> _______________________________________________
> Modern mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/modern
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 24 Apr 2015 15:11:48 -0500

On 24 Apr 2015, at 11:01, Steve Donovan wrote:

>> "security of the resource" - unclear what "resource" refers to and 
>> what security threats we worry about. Disruption by third parties? 
>> Rogue number manager? We don't have to go into great detail, but I 
>> think we agree that we generally assume that the managers are vetted 
>> and trusted and that any misbehavior would be dealt with outside a 
>> protocol context. (In the US, this is known as the FCC Enforcement 
>> Bureau - I guess you could call it the protocol police in this role.)
>> More substantially, we might want to specify more precisely what 
>> privacy risk we're worried about. After all, all TN managers will 
>> have access to the enrollment data. It also isn't obvious whether 
>> enrollment data includes whois-like information or (say) simply the 
>> OCN. I suspect that this will depend on national regulators and 
>> industry customs. Is the "enrollment data" the same as the CNAM data? 
>> Right now, pretty much anyone can query CNAM for any number (see 
>> OpenCNAM and other API services).

While I agree that the charter needs to talk about security and privacy, 
I think we may be putting the cart before the horse trying in to define 
what needs to be private an what needs to be secure in advance of the 
work. Can we word things in a way to require the working group to decide 
what "things" have privacy and security implications? (Likely as part of 
the framework.)
>>
>> There is a bit of duplication between the "Additionally" paragraph 
>> and the next one, as both seem to include resolution and mention 
>> varying design requirements lists. Might be crisper to wrap the list 
>> of desirables into one.
> deals with the resolving aspect.  Maybe if we make the first sentence 
> a separate paragraph?

I suggest something like the following:

"The working group will define a framework for the roles and functions 
involved in managing and resolving TNs in an IP environment. It will 
also define protocol mechanisms for acquiring, [managing?], and 
resolving TNs. <Sentences about acquisition mechanism>. <Sentences about 
resolution mechanism>.

>>
>> This also implies that the lookup to CNAM and the unspecified 
>> resolution are different, but it seems likely that there's a single 
>> query -> data operation, possibly with qualifiers and differentiated 
>> data availability.
>>

I find it odd when charters talk about rechartering--charters can 
_always_ be rechartered. I think the point is that these things are out 
of scope for _this_ charter, but we don't preclude them from being done 
elsewhere or in the future.

>> *   The fourth paragraph defines the identifiers to be worked on as 
>> "E.164 telephone numbers and telephony related identifiers"
>> *   The fourth paragraph describes the motivation as "the changing 
>> telecommunications environment and interest expressed by 
>> telecommunications industry regulators"
>> *   The fourth paragraph acknowledges that while the work of a 
>> proposed working group could be reusable for other identifiers, the 
>> work will focus on E.164 telephone numbers and other telephony 
>> related identifiers
>> *   The word "document" has been deleted from the list of 
>> deliverables to allow flexibility for combining deliverables
>>
>> CHARTER TEXT:
>> The MODERN working group will define a set of Internet-based 
>> mechanisms for the purposes of managing and resolving telephone 
>> numbers (TNs) in an IP environment.  Existing mechanisms for these 
>> purposes face obsolescence as the voice communications infrastructure 
>> evolves to IP technology and new applications for TNs become 
>> possible.  The traditional model of a TN having an association to a 
>> single service provider and a single application is breaking down.  
>> Its use as a network locator is going away, but its use as an 
>> identifier for an individual or an organization will remain for some 
>> time. Devices, applications, and network tools increasingly need to 
>> manage TNs, including requesting and acquiring TN delegations from 
>> authorities.
>>
>> The working group will define a framework for the roles and functions 
>> involved in managing and resolving TNs in an IP environment. This 
>> includes a protocol mechanism for acquiring TNs, which will provide 
>> an enrollment process for the individuals and entities that use and 
>> manage TNs. TNs may either be managed in a hierarchical tree, or in a 
>> distributed peer-to-peer architecture.  Privacy of the enrollment 
>> data and security of the resource will be primary considerations.
>>
>> Additionally, the working group will deliver a protocol mechanism for 
>> resolving TNs which will allow entities such as service providers, 
>> devices, and applications to access data related to TNs, possibly 
>> including caller name data (CNAM).  Maintaining reliability, real 
>> time application performance, security and privacy are primary 
>> considerations.  The working group will take into consideration 
>> existing IETF work including ENUM, SPEERMINT, and DRINKS.
>>
>> The work of this group will focus on E.164 telephone numbers and 
>> other telephony related identifiers due to the changing telecom 
>> environment and interest expressed by telecommunications industry 
>> regulators to support more flexible regulatory models than exist 
>> today.  There is an expectation that aspects of the architecture and 
>> protocols defined by the working group will be reusable for other 
>> user-focused identifiers.  Extensions to the MODERN defined 
>> architecture and protocols can occur outside of the MODERN working 
>> group, either in parallel with the MODERN working group or after the 
>> MODERN working group is complete.  Solutions and mechanisms created 
>> by the working group will be flexible enough to accommodate different 
>> policies, e.g., by different regulatory agencies.
>>
>> -       A description of the enrollment processes for existing and 
>> new TNs including any modifications to metadata related to those TNs
>>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 24 Apr 2015 15:14:56 -0500

On 20 Apr 2015, at 9:45, McGarry, Tom wrote:

[...]

> The work of this group will focus on E.164 telephone numbers and other 
> telephony related identifiers due to the changing telecom environment 
> and interest expressed by telecommunications industry regulators to 
> support more flexible regulatory models than exist today.

Are "other telephony related identifiers" still assumed to be numbers? 
Or in other words, is my Skype ID in or out of scope?

[...]

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Apr 2015 16:43:23 -0400

Out hopefullyŠthat is a private proprietary namespace.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Apr 2015 16:46:17 -0400

>elsewhere or in the future.

Just say what what the WG will not do is the point.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 24 Apr 2015 16:09:51 -0500

On 24 Apr 2015, at 15:43, Richard Shockey wrote:

> Out hopefullythat is a private proprietary namespace.

Okay, so Skype IDs were a bad example--but my question was about whether 
the "other telephony related identifiers" were still assumed to be 
things that look like TNs.

>>> other

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Apr 2015 17:40:02 -0400

Ok like IMSI’s certainly. Regulated namespace identifiers are certainly in
scope. 

Telephony Identifiers governed by National Regulatory Authorities etc and
the meta data associated with them.

On 4/24/15, 5:09 PM, "Ben Campbell" <[email-masked]> wrote:

>> Out hopefully?that is a private proprietary namespace.
>

---

From: "Holmes, David W [CTO]" <[email-masked]>
Date: Fri, 24 Apr 2015 23:26:08 +0000

Richard, I assume you are joking?

E212 IMSI is NOT a good example, it is definitely out of scope (& is no business for) MODERN or IETF in general.   It's a non-public-domain routing address, NOT a "telephony identifier"; if it were, then logically IP addresses would be also . . .

OK, so it actually appears that the first order of business for MODERN should be to define what a "telephoney identifier" actually is, as part of the charter definition?

~David Holmes / Sprint

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Friday, April 24, 2015 2:40 PM
To: Ben Campbell
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

Ok like IMSI's certainly. Regulated namespace identifiers are certainly in scope.

Telephony Identifiers governed by National Regulatory Authorities etc and the meta data associated with them.

On 4/24/15, 5:09 PM, "Ben Campbell" <[email-masked]> wrote:

>Okay, so Skype IDs were a bad example--but my question was about
>whether the "other telephony related identifiers" were still assumed to
>be things that look like TNs.
>
>>
>>
>>
>>
>>>> today.

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: Sat, 25 Apr 2015 12:37:06 +0000

I'm not sure it matters if the identifier is numeric or not, but the unifying principle seems to be that there is a clear delegation chain, within a confined geographic (mostly in the legal sense, i.e., a well-known set of national laws apply) scope. In particular, this implies that the entities participating can generally be assumed to be cooperative, as there is an umpire to remove any uncooperative players from the field.

I don't think it's a priority, but SMS shortcodes seem similar enough to fit into the same mechanism.

To avoid needless ambiguity, simply saying E.164 numbers and leaving the door open to other identifiers that happen to fit might work.

________________________________________
From: Modern [[email-masked]] on behalf of Ben Campbell [[email-masked]]
Sent: Friday, April 24, 2015 5:09 PM
To: Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

---

From: Steve Donovan <[email-masked]>
Date: Mon, 27 Apr 2015 09:29:29 -0500

SMS shortcodes were one of the reasons we left in the "other telephony 
related identifiers" language.

I support, however, limiting the scope to E.164 numbers for the initial 
charter.

Steve

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 27 Apr 2015 14:36:59 +0000

David Holmes has made the point in the past that it is important to list out what are the issues or problems to be solved that drive the work effort.

To David's point, what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group?  i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?

My question is aimed specifically at the section in the charter which reads:

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs.

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: April 25, 2015 7:37 AM
To: Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

To: Richard Shockey

> Out hopefullyŠthat is a private proprietary namespace.

Okay, so Skype IDs were a bad example--but my question was about whether the "other telephony related identifiers" were still assumed to be things that look like TNs.

Modern mailing list

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

---

From: "McGarry, Tom" <[email-masked]>
Date: Tue, 28 Apr 2015 20:53:22 +0000

The other telephony related identifiers includes things like number blocks (in the US these are called central office codes and thousands blocks) and identifiers for service providers (I could see these taking both alpha and numeric forms). There are identifiers for switches, points of interconnect, trunk groups, etc. Not all of these are shared between networks (sometimes only bilaterally) and some of these will have an analog in an IP environment, some will not. 

I was thinking it would be the job of the working group to figure out the relevant other identifiers. Clearly E164s are the baseline. 

Sent from my iPhone

> On Apr 27, 2015, at 10:29 AM, Steve Donovan <[email-masked]> wrote:
> 
> SMS shortcodes were one of the reasons we left in the "other telephony related identifiers" language.
> 
> I support, however, limiting the scope to E.164 numbers for the initial charter.
> 
> Steve
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 28 Apr 2015 16:35:06 -0500

On 28 Apr 2015, at 15:53, McGarry, Tom wrote:

> The other telephony related identifiers includes things like number 
> blocks (in the US these are called central office codes and thousands 
> blocks) and identifiers for service providers (I could see these 
> taking both alpha and numeric forms). There are identifiers for 
> switches, points of interconnect, trunk groups, etc. Not all of these 
> are shared between networks (sometimes only bilaterally) and some of 
> these will have an analog in an IP environment, some will not.
>
> I was thinking it would be the job of the working group to figure out 
> the relevant other identifiers. Clearly E164s are the baseline.

Keep in mind "scope" has been a sensitive topic so far. It seems to me 
so far that the "other telephony related identifiers" is kind of a 
"we'll know it when we see it" category. That's going to get pushback 
during the formal review process--so it would be helpful to have a clear 
definition.

If that's not possible, we _might_ be able to get away with language 
saying that E164s are the primary scope, but the working group may 
consider other identifiers that it finds to be closely enough related.  
(That needs wordsmithing.)

Ben.

>>> I'm not sure it matters if the identifier is numeric or not, but the 
>>> unifying principle seems to be that there is a clear delegation 
>>> chain, within a confined geographic (mostly in the legal sense, 
>>> i.e., a well-known set of national laws apply) scope. In particular, 
>>> this implies that the entities participating can generally be 
>>> assumed to be cooperative, as there is an umpire to remove any 
>>> uncooperative players from the field.
>>>
>>> To avoid needless ambiguity, simply saying E.164 numbers and leaving 
>>> the door open to other identifiers that happen to fit might work.
>>>
>>> whether

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 28 Apr 2015 21:56:27 +0000

I don't understand why E.164 is "clearly the baseline".

I'll repeat my question from last week.

...what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group?  i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: April 28, 2015 4:35 PM
To: McGarry, Tom
Cc: Steve Donovan; [email-masked]
Subject: Re: [Modern] Revised MODERN Charter

> the relevant other identifiers. Clearly E164s are the baseline.

Keep in mind "scope" has been a sensitive topic so far. It seems to me so far that the "other telephony related identifiers" is kind of a "we'll know it when we see it" category. That's going to get pushback during the formal review process--so it would be helpful to have a clear definition.

If that's not possible, we _might_ be able to get away with language saying that E164s are the primary scope, but the working group may consider other identifiers that it finds to be closely enough related.
(That needs wordsmithing.)

Ben.

>>> whether the "other telephony related identifiers" were still assumed
>>> to be things that look like TNs.
>>>
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
>>> ilman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7H
>>> ufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgi
>>> F34PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7Huf
>> veeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34
>> PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 28 Apr 2015 22:06:54 -0500

Pierce,

Are you suggesting that a milestone be added to the charter to summarize 
the existing E.164 number management systems that exist in the world?

If so, this could be made part of the first deliverable.

This does not seem appropriate level of information to be included in 
the charter.

Regards,

Steve (responding as MODERN working group chair)

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 29 Apr 2015 03:42:24 +0000

Nope.  I'm suggesting you elaborate on why you think MODERN ought to be engaged in developing a framework for managing telephone numbers.

What are the problems you want MODERN to solve based on the framework you're proposing MODERN ought to develop?

Sent from my iPad

> On Apr 28, 2015, at 10:07 PM, Steve Donovan <[email-masked]> wrote:
>
> Pierce,
>
> Are you suggesting that a milestone be added to the charter to summarize the existing E.164 number management systems that exist in the world?
>
> This does not seem appropriate level of information to be included in the charter.
>
> Regards,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Apr 2015 11:26:17 +0000

My suspicion is that whatever we develop will work for just about any unique identifier, but the E.164 space offers more challenging requirements compared to the slowly-changing namespaces mentioned below. There are likely 3-4 orders of magnitude more entries, some of the data is more privacy sensitive (see CNAM), the number of entities interacting with the data is substantial (may not just be traditional carriers), there may be more of a need for distributed allocation,  and the transaction rate is much higher and includes interactions among entities that don't necessarily fully "like" each other (gaining and losing providers, say).

Sent: Tuesday, April 28, 2015 5:35 PM

Ben.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Apr 2015 11:38:01 +0000

Pierce,

since you and your organization probably have first-hand experience with the existing system, particularly as you transition to all-IP, I'd be very interested in hearing what you see as deficiencies or problems.

My general take is that just about anything can be made to work ("with enough thrust, pigs can fly"), but that I suspect nobody would design a new system to replicate what has evolved over decades. I'm not sure the charter has to spell out every problem in detail, but a general motivation seems useful.

My general notions are:
- lack of flexibility (e.g., difficult to add fields without a very elaborate and lengthy process typically spanning years)
- lack of distribution (hard or impossible to have more than one administrator for each database)
- complexity (we hear a fair amount about rural call completion problems which aren't helped by small providers struggling to keep numbers straight)
- difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms

Henning

________________________________
From: Gorman, Pierce A [CTO] [[email-masked]]
Sent: Monday, April 27, 2015 10:36 AM
To: Henning Schulzrinne; Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: RE: [Modern] Revised MODERN Charter

To David’s point, what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group?  i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: April 25, 2015 7:37 AM
To: Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

To: Richard Shockey

Modern mailing list

---

From: Steve Donovan <[email-masked]>
Date: Wed, 29 Apr 2015 07:30:29 -0500

Based on Ben's suggestions below, I've propose the following changes to 
the relevant paragraphs.

Steve

On 4/24/15 3:11 PM, Ben Campbell wrote:
>>> industry customs. Is the "enrollment data" the same as the CNAM 
>>> data? Right now, pretty much anyone can query CNAM for any number 
>>> (see OpenCNAM and other API services).
> While I agree that the charter needs to talk about security and 
> privacy, I think we may be putting the cart before the horse trying in 
> to define what needs to be private an what needs to be secure in 
> advance of the work. Can we word things in a way to require the 
> working group to decide what "things" have privacy and security 
> implications? (Likely as part of the framework.)
SRD> The architecture overview document already calls out the need to 
address security and privacy considerations.  Is that sufficient?
> resolving TNs. <Sentences about acquisition mechanism>. <Sentences 
> about resolution mechanism>.
SRD> I've added the wording Ben suggested and combined the paragraphs as 
follows:

"The working group will define a framework for the roles and functions 
involved in managing and resolving TNs in an IP environment.  It will 
also define protocol mechanisms for acquiring and resolving TNs.  The 
protocol mechanism for acquiring TNs, which will provide an enrollment 
process for the individuals and entities that use and manage TNs. TNs 
may either be managed in a hierarchical tree, or in a distributed 
peer-to-peer architecture.  Privacy of the enrollment data and security 
of the resource will be primary considerations.  The protocol mechanism 
for resolving TNs which will allow entities such as service providers, 
devices, and applications to access data related to TNs, possibly 
including caller name data (CNAM).  Maintaining reliability, real time 
application performance, security and privacy are primary 
considerations.  The working group will take into consideration existing 
IETF work including ENUM, SPEERMINT, and DRINKS."
>> SRD>  How about "or after the initial MODERN working group 
>> deliverable are complete".
>
> _always_ be rechartered. I think the point is that these things are 
> out of scope for _this_ charter, but we don't preclude them from being 
> done elsewhere or in the future.
SRD> Taking Richard's suggestion, I propose the following for this 
paragraph (note: the wording on "other telephony identifiers" will be 
addressed separately):

"The work of this group will focus on E.164 telephone numbers and other 
telephony related identifiers due to the changing telecom environment 
and interest expressed by telecommunications industry regulators to 
support more flexible regulatory models than exist today.  There is an 
expectation that aspects of the architecture and protocols defined by 
the working group will be reusable for other user-focused identifiers.  
Any such extensions or reuse of MODERN mechanisms are out of scope.  
Solutions and mechanisms created by the working group will be flexible 
enough to accommodate different policies, e.g., by different regulatory 
agencies."
>>> purposes face obsolescence as the voice communications 
>>> infrastructure evolves to IP technology and new applications for TNs 
>>> become possible.  The traditional model of a TN having an 
>>> association to a single service provider and a single application is 
>>> breaking down.  Its use as a network locator is going away, but its 
>>> use as an identifier for an individual or an organization will 
>>> remain for some time. Devices, applications, and network tools 
>>> increasingly need to manage TNs, including requesting and acquiring 
>>> TN delegations from authorities.
>>>
>>> The working group will define a framework for the roles and 
>>> functions involved in managing and resolving TNs in an IP 
>>> environment. This includes a protocol mechanism for acquiring TNs, 
>>> which will provide an enrollment process for the individuals and 
>>> entities that use and manage TNs. TNs may either be managed in a 
>>> hierarchical tree, or in a distributed peer-to-peer architecture.  
>>> Privacy of the enrollment data and security of the resource will be 
>>> primary considerations.
>>>
>>> Additionally, the working group will deliver a protocol mechanism 
>>> for resolving TNs which will allow entities such as service 
>>> providers, devices, and applications to access data related to TNs, 
>>> possibly including caller name data (CNAM). Maintaining reliability, 
>>> real time application performance, security and privacy are primary 
>>> by the working group will be flexible enough to accommodate 
>>> different policies, e.g., by different regulatory agencies.
>>>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 29 Apr 2015 07:35:25 -0500

Why not limit the charter to E.164 numbers and expect the working group 
to recharter if it finds other telephony identifiers that the group 
feels apply?

Steve

On 4/28/15 4:35 PM, Ben Campbell wrote:
> during the formal review process--so it would be helpful to have a 
> clear definition.
>
> consider other identifiers that it finds to be closely enough 
> related.  (That needs wordsmithing.)
>
> Ben.
>
>
>>
>> Sent from my iPhone
>>
>>>> I'm not sure it matters if the identifier is numeric or not, but 
>>>> the unifying principle seems to be that there is a clear delegation 
>>>> i.e., a well-known set of national laws apply) scope. In 
>>>> particular, this implies that the entities participating can 
>>>> generally be assumed to be cooperative, as there is an umpire to 
>>>> remove any uncooperative players from the field.
>>>>
>>>> To avoid needless ambiguity, simply saying E.164 numbers and 
>>>> leaving the door open to other identifiers that happen to fit might 
>>>> work.
>>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 29 Apr 2015 09:07:25 -0500

On 29 Apr 2015, at 7:35, Steve Donovan wrote:

> Why not limit the charter to E.164 numbers and expect the working 
> group to recharter if it finds other telephony identifiers that the 
> group feels apply?

I would be okay with that.

>>> blocks (in the US these are called central office codes and 
>>> thousands blocks) and identifiers for service providers (I could see 
>>> these taking both alpha and numeric forms). There are identifiers 
>>> for switches, points of interconnect, trunk groups, etc. Not all of 
>>> these are shared between networks (sometimes only bilaterally) and 
>>> some of these will have an analog in an IP environment, some will 
>>> not.
>>>
>>> I was thinking it would be the job of the working group to figure 
>>> out the relevant other identifiers. Clearly E164s are the baseline.
>>
>>
>> Keep in mind "scope" has been a sensitive topic so far. It seems to 
>> me so far that the "other telephony related identifiers" is kind of a 
>>>>> the unifying principle seems to be that there is a clear 
>>>>> delegation chain, within a confined geographic (mostly in the 
>>>>> legal sense, i.e., a well-known set of national laws apply) scope. 
>>>>> In particular, this implies that the entities participating can 
>>>>> leaving the door open to other identifiers that happen to fit 
>>>>> might work.
>>>>>

---

From: "McGarry, Tom" <[email-masked]>
Date: Wed, 29 Apr 2015 17:09:02 +0000

I have no objections. 

Sent from my iPhone

> On Apr 29, 2015, at 10:07 AM, Ben Campbell <[email-masked]> wrote:
> 
>> Why not limit the charter to E.164 numbers and expect the working group to recharter if it finds other telephony identifiers that the group feels apply?
> 
>>> If that's not possible, we _might_ be able to get away with language saying that E164s are the primary scope, but the working group may consider other identifiers that it finds to be closely enough related.  (That needs wordsmithing.)
>>> 
>>> Ben.
>>> 
>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIFaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=vsFeUr82JCJmVqV_PWof--HRtnf076sru5cahduRQyQ&s=URLmKTjjI78q6UZ5IGmfJUWL7lliZc4wJVWzB3ZH334&e=
>>>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 29 Apr 2015 17:22:43 +0000

Thank you Henning.  Your list of general notions is what I was encouraging Steve Donovan, et al, to do.

I didn't volunteer any items even though I could think of some because I'm not convinced the MODERN WG needs to include in its charter anything to do with respect to "managing" E.164 telephone numbers.

As you say, "nobody would design a new system to replicate what has evolved over decades".

I think your list of notions is useful input, but it would seem like it ought to be directed at the existing organization(s) with authority and responsibility to manage E.164 telephone numbers.

If they identify (or have identified already) a need for new protocols (really?) or request that the IETF develop a framework, then certainly MODERN could be a good place to respond to that request.  Has that happened?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368  M: 816-210-8623
[email-masked]

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: April 29, 2015 6:38 AM
To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: RE: [Modern] Revised MODERN Charter

Pierce,

My general notions are:

Henning

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: April 25, 2015 7:37 AM
To: Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

To: Richard Shockey

Modern mailing list

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Apr 2015 21:45:32 +0000

I gather that some of those organizations responsible for managing numbers are part of the list discussion...

-----Original Message-----
From: Gorman, Pierce A [CTO] [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2015 1:23 PM
To: Henning Schulzrinne; Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: RE: [Modern] Revised MODERN Charter

Best regards,

Pierce Gorman
Core Network Planning

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: April 29, 2015 6:38 AM
To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: RE: [Modern] Revised MODERN Charter

Pierce,

My general notions are:

Henning

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: April 25, 2015 7:37 AM
To: Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

To: Richard Shockey

Modern mailing list

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 29 Apr 2015 21:49:34 +0000

I apologize Henning.  I don't understand what you meant in your last response.  What is "the list discussion"?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Gorman, Pierce A [CTO] [mailto:[email-masked]]
Sent: Wednesday, April 29, 2015 1:23 PM
To: Henning Schulzrinne; Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: RE: [Modern] Revised MODERN Charter

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: April 29, 2015 6:38 AM
To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: RE: [Modern] Revised MODERN Charter

Pierce,

My general notions are:

Henning

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: April 25, 2015 7:37 AM
To: Ben Campbell; Richard Shockey
Cc: Modern List; McGarry, Tom
Subject: Re: [Modern] Revised MODERN Charter

To: Richard Shockey

Modern mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 07:16:39 -0500

Pierce,

I don't understand the relevance of your question.

The scope of work for the MODERN working group was discussed at the 
MODERN BOF during IETF 92.  Consensus was reached that the IETF should 
do the work outlined in the charter.  If I recall correctly the response 
to that question was unanimous but it is possible that I missed some 
isolated negative hums.  This consensus clearly includes protocol work.  
Whether they are new protocols depends on what the working group produces.

The primary open question that needed to be addressed in the charter was 
the set of identifiers that the working group would address. Thus the 
proposal to limit the scope of work to E.164 numbers.

You can find the minutes from the meeting here:

https://www.ietf.org/proceedings/92/minutes/minutes-92-modern

Regards,

Steve

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Apr 2015 14:09:17 +0000

Steve, not sure I understand your response. 

1)	All decisions in the meeting room need to be confirmed on list, and this is essentially the thread that is doing that. So it is perfectly appropriate to question anything discussed in the face-to-face meeting as part of that thread.

2)	Your use of "unanimous" is incorrect (and indeed irrelevant to the discussion) and I do not believe that word was used in the meeting room. IETF needs "rough consensus".

3)	If any work is performed, I do believe this should be limited to E.164, with no scope for extension without rechartering. (And that is not saying I believe this is needed as a product, merely that I have no objection to the work being done.) It may well be up to other SDOs to apply the principles of any resultant RFC to other identifiers if they feel the need. Certainly before IETF starts work on any SMS identifiers, as was suggested in a prior mail, there should be a communication with 3GPP and possibly GSMA as to whether there is a use case for such a mechanism in that respect, as all SMS work apart from some IANA registrations lies in those organisations.

Regards

Keith

> From: Modern [mailto:[email-masked]] On Behalf Of 
> Steve Donovan
> Sent: 30 April 2015 13:17
> To: [email-masked]
> The scope of work for the MODERN working group was discussed 
> at the MODERN BOF during IETF 92.  Consensus was reached that 
> the IETF should do the work outlined in the charter.  If I 
> recall correctly the response to that question was unanimous 
> but it is possible that I missed some isolated negative hums. 
>  This consensus clearly includes protocol work.  
> The primary open question that needed to be addressed in the 
> charter was the set of identifiers that the working group 
> would address. Thus the proposal to limit the scope of work 
> to E.164 numbers.
> 
> > Thank you Henning.  Your list of general notions is what I 
> was encouraging Steve Donovan, et al, to do.
> >
> > I didn't volunteer any items even though I could think of 
> some because I'm not convinced the MODERN WG needs to include 
> in its charter anything to do with respect to "managing" 
> E.164 telephone numbers.
> >
> > I think your list of notions is useful input, but it would 
> seem like it ought to be directed at the existing 
> organization(s) with authority and responsibility to manage 
> E.164 telephone numbers.
> >
> > If they identify (or have identified already) a need for 
> new protocols (really?) or request that the IETF develop a 
> framework, then certainly MODERN could be a good place to 
> respond to that request.  Has that happened?
> >
> > Best regards,
> >
> >
> > Pierce Gorman
> > Core Network Planning
> > since you and your organization probably have first-hand 
> experience with the existing system, particularly as you 
> transition to all-IP, I'd be very interested in hearing what 
> you see as deficiencies or problems.
> >
> > My general take is that just about anything can be made to 
> work ("with enough thrust, pigs can fly"), but that I suspect 
> nobody would design a new system to replicate what has 
> evolved over decades. I'm not sure the charter has to spell 
> out every problem in detail, but a general motivation seems useful.
> >
> > My general notions are:
> > - lack of flexibility (e.g., difficult to add fields without a very 
> > elaborate and lengthy process typically spanning years)
> > - complexity (we hear a fair amount about rural call completion 
> > problems which aren't helped by small providers struggling to keep 
> > numbers straight)
> > - difficulty of adopting more modern allocation (e.g., 
> "blocks" of 1) 
> > and porting mechanisms
> >
> > Henning
> >
> > David Holmes has made the point in the past that it is 
> important to list out what are the issues or problems to be 
> solved that drive the work effort.
> >
> >
> >
> > To David's point, what are the flaws or inadequacies of the 
> current administration and conservation of the E.164 
> telephone numbers that require or benefit from an IETF work 
> group?  i.e., what is wrong with INC/NANC/NANP, NPAC, and 
> LERG that requires MODERN to fix it?
> >
> >
> >
> environment. This includes a protocol mechanism for acquiring 
> TNs, which will provide an enrollment process for the 
> individuals and entities that use and manage TNs.
> >
> >
> >
> > Best regards,
> >
> >
> >
> >
> >
> > Pierce Gorman
> >
> > Core Network Planning
> >
> > O: 913-439-4368
> >
> > [email-masked]
> >
> >
> >
> >
> >
> > I'm not sure it matters if the identifier is numeric or 
> not, but the unifying principle seems to be that there is a 
> clear delegation chain, within a confined geographic (mostly 
> in the legal sense, i.e., a well-known set of national laws 
> apply) scope. In particular, this implies that the entities 
> participating can generally be assumed to be cooperative, as 
> there is an umpire to remove any uncooperative players from the field.
> >
> >
> >
> > I don't think it's a priority, but SMS shortcodes seem 
> similar enough to fit into the same mechanism.
> >
> >
> >
> > To avoid needless ambiguity, simply saying E.164 numbers 
> and leaving the door open to other identifiers that happen to 
> fit might work.
> >
> >
> >
> > Okay, so Skype IDs were a bad example--but my question was 
> about whether the "other telephony related identifiers" were 
> still assumed to be things that look like TNs.
> >
> >
> >
> >
> >
> > 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: "Ben Campbell" <[email-masked]>
Date: Thu, 30 Apr 2015 09:29:29 -0500

(As individual except where marked)

On 30 Apr 2015, at 9:09, DRAGE, Keith (Keith) wrote:

> 1)	All decisions in the meeting room need to be confirmed on list, and 
> this is essentially the thread that is doing that. So it is perfectly 
> appropriate to question anything discussed in the face-to-face meeting 
> as part of that thread.
>
> 2)	Your use of "unanimous" is incorrect (and indeed irrelevant to the 
> discussion) and I do not believe that word was used in the meeting 
> room. IETF needs "rough consensus".

I took Steve's meaning to be that we had a lot of people in the room who 
expressed a need for the work, in answer to Pierce's question that could 
be interpreted to ask whether the right people have expressed a need for 
the work.

<AD-Hat>
That being said, Keith's point is important. But from a process 
perspective, also remember there is no working group yet to confirm 
consensus with. The larger audience for this will be the IESG and the 
community during the review of the charter.
</AD-Hat>

>
> 3)	If any work is performed, I do believe this should be limited to 
> E.164, with no scope for extension without rechartering. (And that is 
> not saying I believe this is needed as a product, merely that I have 
> no objection to the work being done.) It may well be up to other SDOs 
> to apply the principles of any resultant RFC to other identifiers if 
> they feel the need. Certainly before IETF starts work on any SMS 
> identifiers, as was suggested in a prior mail, there should be a 
> communication with 3GPP and possibly GSMA as to whether there is a use 
> case for such a mechanism in that respect, as all SMS work apart from 
> some IANA registrations lies in those organisations.
>

Given the concerns about scope, I think this is a good approach. It's 
worth trying to be generic where it makes sense, but we don't want to 
get wrapped around proving we meet requirements for an ever expanding 
set of identifiers without good reason.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 09:59:34 -0500

On 4/30/15 9:29 AM, Ben Campbell wrote:
>> 1)    All decisions in the meeting room need to be confirmed on list, 
>> and this is essentially the thread that is doing that. So it is 
>> perfectly appropriate to question anything discussed in the 
>> face-to-face meeting as part of that thread.
SRD> Agreed.  The question in Pierce's email that I was questioning the 
relevance of was whether or not the IETF has received a request for 
protocol development.  This is not a prerequisite to the IETF starting 
work on new protocols.
>>
>> 2)    Your use of "unanimous" is incorrect (and indeed irrelevant to 
>> the discussion) and I do not believe that word was used in the 
>> meeting room. IETF needs "rough consensus".
>
> I took Steve's meaning to be that we had a lot of people in the room 
> who expressed a need for the work, in answer to Pierce's question that 
> could be interpreted to ask whether the right people have expressed a 
> need for the work.
SRD> Yes, I meant to point out that this had already been discussed 
during the BOF and that there was significant (in my view) support for 
the need for work.  There were also many who indicated a willingness to 
actually do the work.
> community during the review of the charter.
SRD> Understood.
>
>>
>> 3)    If any work is performed, I do believe this should be limited 
>> to E.164, with no scope for extension without rechartering. (And that 
>> is not saying I believe this is needed as a product, merely that I 
>> have no objection to the work being done.) It may well be up to other 
>> SDOs to apply the principles of any resultant RFC to other 
>> identifiers if they feel the need. Certainly before IETF starts work 
>> on any SMS identifiers, as was suggested in a prior mail, there 
>> should be a communication with 3GPP and possibly GSMA as to whether 
>> there is a use case for such a mechanism in that respect, as all SMS 
>> work apart from some IANA registrations lies in those organisations.
>>
>
SRD> I reviewed the minutes and it was discussed/agreed in the room that 
the scope should be limited to E.164 numbers.  It feels like this 
discussion is leading in that same direction.  As such, I propose 
removing the words "and other telephony related identifiers" from the 
paragraph before the list of deliverables.  I'll send out a revised 
proposed charter shortly.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 10:06:31 -0500

I propose adding the following to the first paragraph.  This is a 
slightly wordsmithed version of Henning's list:

A sample of problems with existing mechanisms include:

- lack of flexibility (for example, it can be difficult to add fields 
without a very elaborate and lengthy process typically spanning years)

- lack of distribution (for example, it is hard or impossible to have 
more than one administrator for each database)

- complexity (leading, for example, to a fair amount of rural call 
completion problems which aren't helped by small providers struggling to 
keep numbers straight)

- difficulty of adopting more modern allocation (e.g., "blocks" of 1) 
and porting mechanisms

Steve

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Apr 2015 12:57:56 -0400

Let me reiterate. Read the minutes!

There was nothing anywhere near strong consensus, no less unanimous consensus, the IETF should do the work.

The consensus we did come to was that the work in the charter as presented at the BOF was NOT necessarily useful or well-scoped. I do not think anyone disputed whether it was solvable. Likewise, it was one of those 49-51, you had to be there, when it came to whether to form a work group.

What I am reading on the list is people are falling more on the side of “not useful.” I will follow-up with what I think will be useful in a separate email thread.

> On Apr 30, 2015, at 8:16 AM, Steve Donovan <[email-masked]> wrote:
> 
> Pierce,
> 
> The scope of work for the MODERN working group was discussed at the MODERN BOF during IETF 92.  Consensus was reached that the IETF should do the work outlined in the charter.  If I recall correctly the response to that question was unanimous but it is possible that I missed some isolated negative hums.  This consensus clearly includes protocol work.  Whether they are new protocols depends on what the working group produces.
> 
> The primary open question that needed to be addressed in the charter was the set of identifiers that the working group would address. Thus the proposal to limit the scope of work to E.164 numbers.
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 12:17:45 -0500

Eric,

My assertion of significant support (I'll not use the word unanimous as 
Kieth has pointed out it isn't correctly used in this context) was in 
the answer to question 5.  From the minutes:

Q5: Does the community think that, given the charter discussion, a WG
should be formed?
Consensus:
Yes, but charter needs work.

Earlier questions had less clear consensus.  My recollection of this 
question was that I did not hear any hums in the negative.

Steve

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Apr 2015 13:19:22 -0400

Without consensus on Q1-4, is Q5 relevant?

> On Apr 30, 2015, at 1:17 PM, Steve Donovan <[email-masked]> wrote:
> 
> Eric,
> 
> My assertion of significant support (I'll not use the word unanimous as Kieth has pointed out it isn't correctly used in this context) was in the answer to question 5.  From the minutes:
> 
> Earlier questions had less clear consensus.  My recollection of this question was that I did not hear any hums in the negative.
> 
> Steve
> 
>>>> From: Henning Schulzrinne [
>>>> mailto:[email-masked]
>>>> ]
>>>> From: Gorman, Pierce A [CTO] [
>>>> [email-masked]
>>>> ]
>>>> From: Modern [
>>>> mailto:[email-masked]
>>>> ] On Behalf Of Henning Schulzrinne
>>>> From: Modern [
>>>> [email-masked]] on behalf of Ben Campbell [[email-masked]
>>>> ]
>>>>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 30 Apr 2015 12:28:01 -0500

Questions 1 and 2 were about the charter.

Questions 3 and 4 were not consensus questions, they were asking if 
people were willing to do the work.

Question 5 was about the need to form a working group.

Personally, I consider the combined answers to questions 3-5 to be 
relevant.  This is, of course, contingent upon fixing the charter.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Apr 2015 17:28:32 +0000

Yes, actually. But neither Q3 nor Q4 was a consensus call, and there was a
positive consensus on Q1, so your suggestion that there was no consensus
Q1-Q4 is... okay, about as fair as Steve's suggestion that there was
unanimity.

Jon Peterson
Neustar, Inc.

On 4/30/15, 10:19 AM, "Eric Burger" <[email-masked]> wrote:

>>> The consensus we did come to was that the work in the charter as
>>>presented at the BOF was NOT necessarily useful or well-scoped. I do
>>>not think anyone disputed whether it was solvable. Likewise, it was one
>>>of those 49-51, you had to be there, when it came to whether to form a
>>>work group.
>>> 
>>> What I am reading on the list is people are falling more on the side
>>>of "not useful." I will follow-up with what I think will be useful in a
>>>separate email thread.
>>> 
>>> 
>>> 
>>>>do the work outlined in the charter.  If I recall correctly the
>>>>response to that question was unanimous but it is possible that I
>>>>missed some isolated negative hums.  This consensus clearly includes
>>>>protocol work.  Whether they are new protocols depends on what the
>>>>working group produces.
>>>> 
>>>> The primary open question that needed to be addressed in the charter
>>>>was the set of identifiers that the working group would address. Thus
>>>>the proposal to limit the scope of work to E.164 numbers.
>>>> 
>>>>> I didn't volunteer any items even though I could think of some
>>>>>because I'm not convinced the MODERN WG needs to include in its
>>>>>charter anything to do with respect to "managing" E.164 telephone
>>>>>numbers.
>>>>> 
>>>>> I think your list of notions is useful input, but it would seem like
>>>>>it ought to be directed at the existing organization(s) with
>>>>>authority and responsibility to manage E.164 telephone numbers.
>>>>> 
>>>>> If they identify (or have identified already) a need for new
>>>>>protocols (really?) or request that the IETF develop a framework,
>>>>>then certainly MODERN could be a good place to respond to that
>>>>>request.  Has that happened?
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> 
>>>>> Pierce Gorman
>>>>> Core Network Planning
>>>>> since you and your organization probably have first-hand experience
>>>>>with the existing system, particularly as you transition to all-IP,
>>>>>I'd be very interested in hearing what you see as deficiencies or
>>>>>problems.
>>>>> 
>>>>> My general take is that just about anything can be made to work
>>>>>("with enough thrust, pigs can fly"), but that I suspect nobody would
>>>>>design a new system to replicate what has evolved over decades. I'm
>>>>>not sure the charter has to spell out every problem in detail, but a
>>>>>general motivation seems useful.
>>>>> 
>>>>> My general notions are:
>>>>> David Holmes has made the point in the past that it is important to
>>>>>list out what are the issues or problems to be solved that drive the
>>>>>work effort.
>>>>> 
>>>>> 
>>>>> 
>>>>> To David's point, what are the flaws or inadequacies of the current
>>>>>administration and conservation of the E.164 telephone numbers that
>>>>>require or benefit from an IETF work group?  i.e., what is wrong with
>>>>>INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
>>>>> 
>>>>> 
>>>>> 
>>>>>entities that use and manage TNs.
>>>>> 
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Pierce Gorman
>>>>> 
>>>>> Core Network Planning
>>>>> 
>>>>> O: 913-439-4368
>>>>> 
>>>>> 
>>>>> [email-masked]
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>chain, within a confined geographic (mostly in the legal sense, i.e.,
>>>>>a well-known set of national laws apply) scope. In particular, this
>>>>>implies that the entities participating can generally be assumed to
>>>>>be cooperative, as there is an umpire to remove any uncooperative
>>>>>players from the field.
>>>>> 
>>>>> 
>>>>> 
>>>>> 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: "Ben Campbell" <[email-masked]>
Date: Thu, 30 Apr 2015 12:42:53 -0500

> Without consensus on Q1-4, is Q5 relevant?

I think it is. If the answer to Q5 was that no one cared about the work, 
we would not be spending cycles working to refine the charter. OTOH, 
coming up with an acceptable charter is still a prerequisite for 
starting a working group. There's no guaranty of success.

>> My assertion of significant support (I'll not use the word unanimous 
>> as Kieth has pointed out it isn't correctly used in this context) was 
>> in the answer to question 5.  From the minutes:
>>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 30 Apr 2015 18:12:34 +0000

Thank you Keith.  I'm a newbie when it comes to standards discussions and I appreciate your assistance.

Steve,

One of the main concerns I have with the proposed MODERN charter is the confusion being generated between the IETF MODERN WG and existing NANP SDOs.

I've talked with our internal numbering folks who represent Sprint in the INC/NANC organizations and they definitely do not understand why IETF is is chartering a WG that "...will define a framework for the roles and functions involved in managing and resolving TNs..." which "will provide an enrollment process for the individuals and entities that use and manage TNs."

I would have a similar concern if INC decided to convene a group to determine how to better manage IP addresses because INC was dissatisfied with:

     * management of IP addressing by multiple independent RIRs
     * challenges associated with resolving TNs to IPs across slowly evolving multiple versions of IP addresses
     * private versus public addressing
     * increased costs dealing with IP network address and port translation across operational boundaries of varying complexity and security requirements

I would feel that it was incumbent upon INC to liason with IETF and ARIN to address concerns, and not create a new INC WG proposing to usurp ARIN and manage what ARIN is responsible for.

I use ARIN in my hypothetical example because I'm specifically concerned about management of numbers in the NANP.   CC=1 is the only E.164 namespace we're a participant in managing.  I assume non-NA numbering management organizations (e.g., ITU) can comfortably ignore MODERN but that NANC cannot (and vice-versa).

For discussion's sake, let's say I hadn't questioned this part of the MODERN charter, and work proceeded quickly generating a quality framework that had "rough consensus".  How will MODERN go about implementing this framework?  Will MODERN WG not then be in the position of reaching out to INC/NANC for discussions?

I'll offer additional concerns I think are of a more practical nature.

There is a Joint Task Force WG under the auspices of the SIP Forum and ATIS PTSC which covered much of this same ground MODERN is proposing in its charter.  The JTF produced two technical reports; a routing TR, and an inter-carrier all-IP NNI TR.  The routing TR largely conisists of multiple proposals on how to manage, provision, and resolve telephone numbers and IP addresses.

Also, the FCC and NANC authorized transition of number portability management from Neustar to iconective.

NPAC transition planning is an example where MODERN might offer benefit to NANC regarding development of enrollment, metadata, and provisioning protocol mechanisms.  But this assumes the SDOs are working together and not independently of one another.

As it is, I assume NANC (NAPM LLC) will work independently of MODERN to manage the transition.  And I assume there is some (small?) risk of potentially changing the underlying number management problem set MODERN is proposing to address while MODERN is in-flight addressing it.  (As a nit, I'll also mention I think the proposed MODERN charter implies number management is a single database problem ignoring LERG and LNP.)

I'm reminded of jokes regarding light bulb installation.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: April 30, 2015 9:09 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Modern] Revised MODERN Charter

1)All decisions in the meeting room need to be confirmed on list, and this is essentially the thread that is doing that. So it is perfectly appropriate to question anything discussed in the face-to-face meeting as part of that thread.

2)Your use of "unanimous" is incorrect (and indeed irrelevant to the discussion) and I do not believe that word was used in the meeting room. IETF needs "rough consensus".

3)If any work is performed, I do believe this should be limited to E.164, with no scope for extension without rechartering. (And that is not saying I believe this is needed as a product, merely that I have no objection to the work being done.) It may well be up to other SDOs to apply the principles of any resultant RFC to other identifiers if they feel the need. Certainly before IETF starts work on any SMS identifiers, as was suggested in a prior mail, there should be a communication with 3GPP and possibly GSMA as to whether there is a use case for such a mechanism in that respect, as all SMS work apart from some IANA registrations lies in those organisations.

Regards

Keith

> From: Modern [mailto:[email-masked]] On Behalf Of Steve
> Donovan
> missed some isolated negative hums.
> some because I'm not convinced the MODERN WG needs to include in its
> charter anything to do with respect to "managing"
> E.164 telephone numbers.
> >
> new protocols (really?) or request that the IETF develop a framework,
> experience with the existing system, particularly as you transition to
> all-IP, I'd be very interested in hearing what you see as deficiencies
> or problems.
> >
> work ("with enough thrust, pigs can fly"), but that I suspect nobody
> would design a new system to replicate what has evolved over decades.
> I'm not sure the charter has to spell out every problem in detail, but
> a general motivation seems useful.
> >
> > My general notions are:
> important to list out what are the issues or problems to be solved
> that drive the work effort.
> >
> >
> >
> current administration and conservation of the E.164 telephone numbers
> that require or benefit from an IETF work group?  i.e., what is wrong
> with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
> >
> >
> >
> functions involved in managing and resolving TNs in an IP environment.
> This includes a protocol mechanism for acquiring TNs, which will
> provide an enrollment process for the individuals and entities that
> use and manage TNs.
> >
> >
> >
> > Best regards,
> >
> >
> >
> >
> >
> > Pierce Gorman
> >
> > Core Network Planning
> >
> > O: 913-439-4368
> >
> > [email-masked]
> >
> >
> >
> >
> >
> not, but the unifying principle seems to be that there is a clear
> delegation chain, within a confined geographic (mostly in the legal
> sense, i.e., a well-known set of national laws
> participating can generally be assumed to be cooperative, as there is
> an umpire to remove any uncooperative players from the field.
> >
> >
> >
> and leaving the door open to other identifiers that happen to fit
> might work.
> >
> >
> >
> about whether the "other telephony related identifiers" were still
> assumed to be things that look like TNs.
> >
> >
> >
> >
> >
> 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.
> >
> 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: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Apr 2015 19:39:14 +0000

Well, wind back the stack a bit here. This mailing list (and proposed
working group) exists as a result of an FCC workshop that discussed ways
to shake up number administration and explore alternative models. It
encompassed not just traditional service providers, but also VoIP
providers who are not "official" carriers today, as well as enterprise
vendors. Both of those communities have spoken up at the workshop, at the
BoF, and so on.

I think the most important distinction between the proposed MODERN work
and the other efforts you describe is that an IETF working group will
develop protocols and not actually, you know, develop policy or issue
numbers or manage subscribers or what have you. An IETF protocol
"framework" is a very different thing that what, say, ATIS or the SIP
Forum would ordinarily develop as a "framework" - it would be an abstract
architecture modeling how various actors might use protocol tools. MODERN
proposes to build plumbing that will enable people that include, but are
not limited to, traditional telephony service providers, to implement new
ways of assigning, delegating and securing telephone numbers. MODERN does
not propose to tell anyhow how they should do it.

So I don't think the comparison to ARIN, say, really holds.

Jon Peterson
Neustar, Inc.

On 4/30/15, 11:12 AM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>One of the main concerns I have with the proposed MODERN charter is the
>confusion being generated between the IETF MODERN WG and existing NANP
>SDOs.
>
>I've talked with our internal numbering folks who represent Sprint in the
>INC/NANC organizations and they definitely do not understand why IETF is
>is chartering a WG that "...will define a framework for the roles and
>functions involved in managing and resolving TNs..." which "will provide
>manage TNs."
>I would have a similar concern if INC decided to convene a group to
>determine how to better manage IP addresses because INC was dissatisfied
>with:
>
>     * challenges associated with resolving TNs to IPs across slowly
>evolving multiple versions of IP addresses
>     * increased costs dealing with IP network address and port
>translation across operational boundaries of varying complexity and
>security requirements
>
>I would feel that it was incumbent upon INC to liason with IETF and ARIN
>to address concerns, and not create a new INC WG proposing to usurp ARIN
>and manage what ARIN is responsible for.
>
>I use ARIN in my hypothetical example because I'm specifically concerned
>about management of numbers in the NANP.   CC=1 is the only E.164
>namespace we're a participant in managing.  I assume non-NA numbering
>management organizations (e.g., ITU) can comfortably ignore MODERN but
>that NANC cannot (and vice-versa).
>
>For discussion's sake, let's say I hadn't questioned this part of the
>MODERN charter, and work proceeded quickly generating a quality framework
>that had "rough consensus".  How will MODERN go about implementing this
>framework?  Will MODERN WG not then be in the position of reaching out to
>INC/NANC for discussions?
>
>There is a Joint Task Force WG under the auspices of the SIP Forum and
>ATIS PTSC which covered much of this same ground MODERN is proposing in
>its charter.  The JTF produced two technical reports; a routing TR, and
>an inter-carrier all-IP NNI TR.  The routing TR largely conisists of
>multiple proposals on how to manage, provision, and resolve telephone
>numbers and IP addresses.
>
>NPAC transition planning is an example where MODERN might offer benefit
>to NANC regarding development of enrollment, metadata, and provisioning
>protocol mechanisms.  But this assumes the SDOs are working together and
>not independently of one another.
>
>As it is, I assume NANC (NAPM LLC) will work independently of MODERN to
>manage the transition.  And I assume there is some (small?) risk of
>potentially changing the underlying number management problem set MODERN
>is proposing to address while MODERN is in-flight addressing it.  (As a
>nit, I'll also mention I think the proposed MODERN charter implies number
>management is a single database problem ignoring LERG and LNP.)
>
>1)All decisions in the meeting room need to be confirmed on list, and
>appropriate to question anything discussed in the face-to-face meeting as
>part of that thread.
>
>2)Your use of "unanimous" is incorrect (and indeed irrelevant to the
>discussion) and I do not believe that word was used in the meeting room.
>IETF needs "rough consensus".
>
>3)If any work is performed, I do believe this should be limited to E.164,
>with no scope for extension without rechartering. (And that is not saying
>I believe this is needed as a product, merely that I have no objection to
>the work being done.) It may well be up to other SDOs to apply the
>principles of any resultant RFC to other identifiers if they feel the
>need. Certainly before IETF starts work on any SMS identifiers, as was
>suggested in a prior mail, there should be a communication with 3GPP and
>possibly GSMA as to whether there is a use case for such a mechanism in
>that respect, as all SMS work apart from some IANA registrations lies in
>those organisations.
>
>Regards
>
>Keith
>
>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: "McGarry, Tom" <[email-masked]>
Date: Thu, 30 Apr 2015 20:11:36 +0000

WRT questions about the problem space:
The first paragraph says:
-  existing mechanisms are facing obsolescence, ie., IP replacing PSTN
-  traditional model of TN to 1 SP/1 app is breaking down
-  use a network locator is going away (but it's use as a personal identifier is still relevant)
-  devices, apps and network tools increasingly need to manage TNs, eg., not just carriers
There were two presentations that went into more detail on the problem space. 
There were non-telcos in the room that expressed strong support for a need to improve processes and capabilities wrt TN management. 

WRT what's wrong with NANPA/PA/LERG/NPAC:
For all intents and purposes these are spreadsheet-based solutions. My company has to screen scrape some of these websites to collect number administration information. We'd very much like to improve these processes. 
The one that isn't spreadsheet based, NPAC, is special purpose built for PSTN systems which have to be jury-rigged to work for IP networks. 
While the question was US-specific we work with number administration all over the world and they all need improvement, I'm sure others would agree. 

WRT INC, NANC and NPAC transition:
This idea for MODERN originated as a result of an FCC order and an FCC industry meeting. The FCC and others involved work very closely with INC and of course NANC. 
While this is also a US-specific question at least one other regulator is supportive of the concept and as I mentioned other non-telcos that do business outside of the U.S. are supportive. 
The NPAC transition is a very specific task which is unrelated to work that will occur in MODERN. 

Sent from my iPhone

> On Apr 30, 2015, at 2:13 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_92_minutes_minutes-2D92-2Dmodern&d=AwIFBA&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=tKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6qQs&s=xopj1tqPN5PGIHrrSzra_u7RKrg6MYYqy2MU_HtXnNs&e= 
>> 
>> Regards,
>> 
>> Steve
>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIFBA&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=tKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6qQs&s=NMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e= 
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIFBA&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=tKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6qQs&s=NMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIFBA&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=tKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6qQs&s=NMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIFBA&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=tKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6qQs&s=NMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIFBA&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=tKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6qQs&s=NMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Apr 2015 16:52:12 -0400

> On Apr 30, 2015, at 4:11 PM, McGarry, Tom <[email-masked]> wrote:
> 

True, but not relevant.

> -  traditional model of TN to 1 SP/1 app is breaking down

This is a vision, as embodied by ENUM. However, other than within a given enhanced service platform which runs multiple apps on the same TN (TTCi did that in 1992), do we see this in the wild? Moreover, from the network’s perspective, that looks like a single app.

Are there *any* instances of a TN *not* being managed by a single SP? Is this something desirable? How would the network decide which SP is managing the TN? How would the network decide which (if?) SP terminates the call? Is it by service type (voice, video, fax, Uber, Twillio app X, Twillio app Y, Facebook, …)? If by service type, do we lock them in now (great for interoperability, but kills innovation) or do we leave it open (can you say diffserv?)?

> -  use a network locator is going away (but it's use as a personal identifier is still relevant)

Use of a TN as a geographic locator went away in 1998 (thanks Neustar!) and the use of a TN as a media locator went away in 2001 (thanks Tom!). However, I have not heard of a TN going away as a network locator. Any examples?

> -  devices, apps and network tools increasingly need to manage TNs, eg., not just carriers

Examples?

> While the question was US-specific we work with number administration all over the world and they all need improvement, I'm sure others would agree.

I think we DO have agreement what we have today is less than ideal. The question is whether there is interest in replacing the system. Note that the interest of a few non-PSTN app developers is irrelevant. The interest of incumbent carriers is irrelevant. In this case, and as discussed in other threads, we are talking about E.164 identifiers. E.164 identifiers are things that the ITU-T and national regulators, well, regulate. If the FCC, Ofcom, Bundesnetzagentur, Minsvyaz, ARCEP, CRTC, et al. says, “change the system,” then we know there is a market for a replacement of the system. Until then, we could create the bestest way for number management, and nobody would care.

> While this is also a US-specific question at least one other regulator is supportive of the concept and as I mentioned other non-telcos that do business outside of the U.S. are supportive.

What does ‘supportive’ mean?

> The NPAC transition is a very specific task which is unrelated to work that will occur in MODERN.

Agreed.