Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

From: Alissa Cooper <[email-masked]>
Date: Thu, 25 Jun 2015 08:44:22 -0300

Would appreciate people’s thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

> From: "Zhang, Jie" <[email-masked]>
> Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
> Date: June 23, 2015 at 1:56:42 PM GMT-3
> To: "[email-masked]" <[email-masked]>
> Cc: "Jamoussi, Bilel" <[email-masked]>
> 
> Dear Sir/Madam,
> 
> Below please find comments from the ITU Telecommunication Standardization Bureau on the proposed IETF working group MODERN.
> 
> 1.	Potential impacts on Recommendation ITU-T E.164 and E.164.1 
> It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers?
> 2.	Entities participating in the defined mechanisms
> The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS?
> 3.	Status of Telephone numbers in the defined mechanisms
> Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group?
> 4.	Regulatory issues
> The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used".
> 5.	Relationship with .Tel
> DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers.
> 6.	Relationship with related existing or concluded WGs
> It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated.
> 7.	The name of this new WG
> The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent.
> 
> Best regards,
> 
> Jie Zhang
> Advisor, ITU-T SG2
> International Telecommunication Union
> Place des Nations
> CH-1211 Geneva , Switzerland 
> Tel :+41 22 730 5855
> [email-masked]
> www.itu.int
> www.itu150.org
> 
> 
> -----Original Message-----
> From: new-work [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Friday, June 12, 2015 8:47 PM
> To: [email-masked]
> Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
> 
> A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.
> 
> Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>  Tom McGarry <[email-masked]>
>  Steve Donovan <[email-masked]>
> 
> Assigned Area Director:
>  Alissa Cooper <[email-masked]>
> 
> Mailing list
>  Address: [email-masked]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
>  Archive: http://www.ietf.org/mail-archive/web/modern/
> 
> Charter:
> 
> 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. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved.
> 
> The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment.  The working group will also identify protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs, with a preference for use of existing protocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. 
> 
> The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. Maintaining reliability, real-time application performance, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM.
> 
> The work of this group will focus on TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate communication with another user of a service. 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 for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies.
> 
> The working 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
> 
> Milestones:
> 
> TBD
> 
> _______________________________________________
> new-work mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/new-work
>

---

From: Richard Shockey <[email-masked]>
Date: Thu, 25 Jun 2015 15:10:08 -0400

DEL *.* ?

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

From:  Modern <[email-masked]> on behalf of Alissa Cooper
<[email-masked]>
Date:  Thursday, June 25, 2015 at 7:44 AM
To:  <[email-masked]>
Subject:  [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Would appreciate people¹s thoughts on whether any charter edits may be
warranted in response to these comments, and/or whether a separate response
may be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

> Below please find comments from the ITU Telecommunication Standardization
> Bureau on the proposed IETF working group MODERN.
> 
> It is stated at the beginning of the Charter that 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. And it is
> mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone
> Numbers". Does that mean the mechanism being referred to here only deals with
> Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1
> which are core recommendations on Telephone Numbers?
> The Charter states that the protocol mechanism for resolving TNs will allow
> entities such as service providers, devices, and applications to access data
> related to TNs. But it is not clear what kind of entities can participate in
> the mechanisms defined by this MODERN working group. Would it be restricted to
> the entities who have been assigned a TN or a block of TNS?
> Several operations related to TNs are mentioned in the Charter, including
> requesting, acquiring, resolving and associating. It is also stated that the
> protocol mechanism for acquiring TNs will provide an enrollment process for
> the entities that use and manage TNs. Does that mean Telephone numbers with
> various status, such as assigned, spare and reclaimed numbers will all be
> managed in the mechanisms defined by the MODERN working group?
> 4. Regulatory issues
> The Charter states that Solutions and mechanisms created by the working group
> will be flexible enough to accommodate different policies for TN assignment
> and management, for example those established by different regulatory
> agencies. We would like to bring your attention to the fact that the E.164
> international public telecommunication numbering plan is a politically
> significant numbering resource with direct implications on national
> sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014)
> recognized "the existing role and sovereignty of ITU Member States with
> respect to allocation and management of their country code numbering resources
> as enshrined in Recommendation ITU-T E.164", and further instructed the ITU
> Secretary-General and the Directors of three Bureaux (Telecommunication
> Standardization, Development, and Radiocommunication) to "take any necessary
> action to ensure the sovereignty of ITU Member States with regard to
> Recommendation ITU-T E.164 numbering plans whatever the application in which
> they are used".
> DNS-based use of international numbering resources has been discussed in ITU-T
> Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director
> has also exchanged letters with ICANN on issues related to registering digit
> strings in the .TEL domain. A representative from ICANN participated in the
> ITU-T SG2 meeting (28 May - June 2014) and provided some background on the
> TELNIC application. A correspondence group under ITU-T SG2 was also set up in
> this regard. We would like to know how the work of this new WG would relate to
> issues related to registering digit strings in the .TEL domain and other
> DNS-based use of telephone numbers.
> It is stated in the Charter that the working group will take into
> consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and
> SCIM. Detailed description of the relationship between this new WG and the
> above mentioned other existing or concluded WGs would be appreciated.
> The name of this new WG is "Managing, Ordering, Distributing, Exposing, &
> Registering telephone Numbers (modern)". But in the Charter, ordering,
> exposing and registering TNs are not mentioned, which seems to be a little bit
> inconsistent.
> 
> Best regards,
> 
> Jie Zhang
> Advisor, ITU-T SG2
> A new IETF working group has been proposed in the Applications and Real-Time
> Area. The IESG has not made any determination yet. The following draft charter
> was submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.
> 
> 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. Devices, applications, and network tools increasingly need to
> manage TNs, including requesting and acquiring TN delegations from
> authorities. The output of the working group should make distribution,
> acquisition, and management of TNs simpler for all entities involved.
> 
> The working group will define an information management framework for the
> roles and functions involved in associating information with one or more TNs
> in an IP environment.  The working group will also identify protocol
> mechanisms to support the interactions between the functions defined by the
> framework. This includes either recommending or defining protocol mechanisms
> for acquiring, associating and resolving TNs, with a preference for use of
> existing protocol mechanisms. TNs may either be managed in a hierarchical
> tree, or in a distributed registry. The protocol mechanism for acquiring TNs
> will provide an enrollment process for the entities that use and manage TNs.
> 
> The protocol mechanism for resolving TNs will allow entities such as service
> providers, devices, and applications to access data related to TNs.
> Maintaining reliability, real-time application performance, and security and
> privacy for both the data and the protocol interactions are primary
> considerations. The working group will take into consideration existing IETF
> work including STIR, ENUM, SPEERMINT, DRINKS and SCIM.
> 
> The work of this group will focus on TNs, as defined in RFC3966, and blocks of
> TNs, that are used to initiate communication with another user of a service.
> 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 for the MODERN
> working group. Solutions and mechanisms created by the working group will be
> flexible enough to accommodate different policies for TN assignment and
> management, for example those established by different regulatory agencies.
> 
> - A description of the enrollment processes for existing and new TNs including
> any modifications to metadata related to those TNs
> 

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 25 Jun 2015 19:32:04 +0000

Which part Richard?  The charter, or the ITU-T concerns?  :)

Best regards,

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

From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: June 25, 2015 2:10 PM
To: Alissa Cooper; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

DEL *.* ?

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

From: Modern <[email-masked]<mailto:[email-masked]>> on behalf of Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 25, 2015 at 7:44 AM
To: <[email-masked]<mailto:[email-masked]>>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Would appreciate people's thoughts on whether any charter edits may be warranted in response to these comments, and/or whether a separate response may be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

From: "Zhang, Jie" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
Date: June 23, 2015 at 1:56:42 PM GMT-3
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jamoussi, Bilel" <[email-masked]<mailto:[email-masked]>>

Dear Sir/Madam,

Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland
Tel :+41 22 730 5855
[email-masked]<mailto:[email-masked]>
www.itu.int<http://www.itu.int>
www.itu150.org<http://www.itu150.org>

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:
 Tom McGarry <[email-masked]<mailto:[email-masked]>>
 Steve Donovan <[email-masked]<mailto:[email-masked]>>

Assigned Area Director:
 Alissa Cooper <[email-masked]<mailto:[email-masked]>>

Mailing list
 Address: [email-masked]<mailto:[email-masked]>
 To Subscribe: https://www.ietf.org/mailman/listinfo/modern
 Archive: http://www.ietf.org/mail-archive/web/modern/

Charter:

Milestones:

TBD

_______________________________________________
new-work mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/new-work

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

________________________________

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: Thu, 25 Jun 2015 21:47:44 +0200

Not creating the group would resolve the ITU-T concerns, so it would be a
"del *.*".

Ignoring the ITU-T concerns would, in my opinion, lead to even more concerns
being expressed subsequently.

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of Gorman, Pierce A
[CTO]
Sent: Thursday, June 25, 2015 21:32
To: Richard Shockey; Alissa Cooper; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Which part Richard?  The charter, or the ITU-T concerns?  J

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,

DEL *.* ?

- 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

Would appreciate people's thoughts on whether any charter edits may be
warranted in response to these comments, and/or whether a separate response
may be useful for addressing some of the questions below.

Alissa

Begin forwarded message:

Subject: RE: [new-work] WG Review: Managing, Ordering, Distributing,
Exposing, & Registering telephone Numbers (modern)

Dear Sir/Madam,

1.            Potential impacts on Recommendation ITU-T E.164 and E.164.1 
It is stated at the beginning of the Charter that 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. And it is
mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone
Numbers". Does that mean the mechanism being referred to here only deals
with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and
E.164.1 which are core recommendations on Telephone Numbers?
2.            Entities participating in the defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow
entities such as service providers, devices, and applications to access data
related to TNs. But it is not clear what kind of entities can participate in
the mechanisms defined by this MODERN working group. Would it be restricted
to the entities who have been assigned a TN or a block of TNS?
3.            Status of Telephone numbers in the defined mechanisms
Several operations related to TNs are mentioned in the Charter, including
requesting, acquiring, resolving and associating. It is also stated that the
protocol mechanism for acquiring TNs will provide an enrollment process for
the entities that use and manage TNs. Does that mean Telephone numbers with
various status, such as assigned, spare and reclaimed numbers will all be
managed in the mechanisms defined by the MODERN working group?
4.            Regulatory issues
The Charter states that Solutions and mechanisms created by the working
group will be flexible enough to accommodate different policies for TN
assignment and management, for example those established by different
regulatory agencies. We would like to bring your attention to the fact that
the E.164 international public telecommunication numbering plan is a
politically significant numbering resource with direct implications on
national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev.
BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member
States with respect to allocation and management of their country code
numbering resources as enshrined in Recommendation ITU-T E.164", and further
instructed the ITU Secretary-General and the Directors of three Bureaux
(Telecommunication Standardization, Development, and Radiocommunication) to
"take any necessary action to ensure the sovereignty of ITU Member States
with regard to Recommendation ITU-T E.164 numbering plans whatever the
application in which they are used".
5.            Relationship with .Tel
DNS-based use of international numbering resources has been discussed in
ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB
Director has also exchanged letters with ICANN on issues related to
registering digit strings in the .TEL domain. A representative from ICANN
participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some
background on the TELNIC application. A correspondence group under ITU-T SG2
was also set up in this regard. We would like to know how the work of this
new WG would relate to issues related to registering digit strings in the
.TEL domain and other DNS-based use of telephone numbers.
6.            Relationship with related existing or concluded WGs
It is stated in the Charter that the working group will take into
consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and
SCIM. Detailed description of the relationship between this new WG and the
above mentioned other existing or concluded WGs would be appreciated.
7.            The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, &
Registering telephone Numbers (modern)". But in the Charter, ordering,
exposing and registering TNs are not mentioned, which seems to be a little
bit inconsistent.

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &
Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Time
Area. The IESG has not made any determination yet. The following draft
charter was submitted, and is provided for informational purposes only.
Please send your comments to the IESG mailing list (iesg at ietf.org) by
2015-06-22.

Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers
(modern)
------------------------------------------------
Current Status: Proposed WG

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]

Charter:

The work of this group will focus on TNs, as defined in RFC3966, and blocks
of TNs, that are used to initiate communication with another user of a
service. 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 for the MODERN working group. Solutions and mechanisms
created by the working group will be flexible enough to accommodate
different policies for TN assignment and management, for example those
established by different regulatory agencies.

- 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

Milestones:

TBD

  _____  

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, 25 Jun 2015 22:31:15 +0000

This effort is intended to create tools and solutions to enable flexibility in the process of managing numbers among national administrators, service and application providers, and consumers.  Entities can choose to use these tools or not.  These tools are not for the ITU-T's processes or role, nor for how national administrators interact with the ITU-T.  But of course we want your input and feedback, so thanks for sending this along.  More comments in line below.

From: Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <[email-masked]<mailto:[email-masked]>>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Alissa

Begin forwarded message:

1. Potential impacts on Recommendation ITU-T E.164 and E.164.1
It is stated at the beginning of the Charter that 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. And it is mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone Numbers". Does that mean the mechanism being referred to here only deals with Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1 which are core recommendations on Telephone Numbers?
There will be no impacts on E.164 and E.164.1.

2. Entities participating in the defined mechanisms
The Charter states that the protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. But it is not clear what kind of entities can participate in the mechanisms defined by this MODERN working group. Would it be restricted to the entities who have been assigned a TN or a block of TNS?
Who participates in numbering processes within countries is subject to regulation.  The WG cannot make any decisions with regard to this.  I expect the WG to define "roles" within the number management processes; e.g., administrator, telecom carrier, application provider, consumer, etc.; and how those roles could interact with each other.  This will be a baseline for what tools and solutions would be useful to facilitate those interactions.

3. Status of Telephone numbers in the defined mechanisms
Several operations related to TNs are mentioned in the Charter, including requesting, acquiring, resolving and associating. It is also stated that the protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. Does that mean Telephone numbers with various status, such as assigned, spare and reclaimed numbers will all be managed in the mechanisms defined by the MODERN working group?
I would expect proposed solutions to be able to address the status of a telephone number.

4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used".
We are aware of Resolution 133 and will certainly respect it.  I would propose adding the following text after the first sentence in the last full paragraph – "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164."

5. Relationship with .Tel
DNS-based use of international numbering resources has been discussed in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director has also exchanged letters with ICANN on issues related to registering digit strings in the .TEL domain. A representative from ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and provided some background on the TELNIC application. A correspondence group under ITU-T SG2 was also set up in this regard. We would like to know how the work of this new WG would relate to issues related to registering digit strings in the .TEL domain and other DNS-based use of telephone numbers.
The WG will not create any new namespace that would require regulatory oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule out the WG leveraging existing namespaces as part of proposed solutions.  But it's too early to say anything specific about that.  There is nothing in the charter that references .tel.

6. Relationship with related existing or concluded WGs
It is stated in the Charter that the working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. Detailed description of the relationship between this new WG and the above mentioned other existing or concluded WGs would be appreciated.
I agree.  I would modify that sentence to add the following at the end - "as well as other relevant industry and standards organizations."

7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent.
The IETF often has fun with creating WG names.  : )  But the charter is where to look for the scope of work.  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information … with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs".  The functions you believe were left out of the charter will be part of one or more of these processes.

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 25 Jun 2015 23:54:53 +0000

Litmus test: E.164 plus
Private numbers in the format above
At issue:
A model where the carrier has to pay for giving a DB in the cloud our numbers and then pay to query
So when did the IETF get into this....

Sent from my iPhone

On Jun 25, 2015, at 6:31 PM, McGarry, Tom <[email-masked]<mailto:[email-masked]>> wrote:

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org<http://ietf.org>) by 2015-06-22.

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

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

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 17:09:23 +0200

Thank you for this clarification.

Since the intent is to create tools and solutions that would be used by
national regulators, presumably they should be involved in the development
of the tools.  

As far as I know, national regulators from most countries don't normally
participate in the IETF, for a number of reasons, including the IETF's
decision-making process and the fact that the IETF works in English.
National regulators do participate in ITU-T, for a number of reasons,
including the ITU's decision-making process and the fact that documents are
translated into the six UN languages before they are formally approved (and
some discussions takes place with interpretation in six languages).

If the intent is to develop tools that would be used only in the USA at
first, then I would suggest that it would be more appropriate to develop
them in a forum such as ATIS or an ad-hoc group created specifically for the
purpose. If the US experience proved successful, then the tools could be
proposed for adoption elsewhere, for example through ITU-T.

If the intent is to develop tools for use in many countries right at the
start, then I would suggest that the appropriate forum would be ITU-T, not
IETF, for the reasons outlined above.

Thus, I formally object to the creation of this new working group, and this
even if the Charter is modified as suggested below.

Please see additional comments inline.

Thanks and best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

This effort is intended to create tools and solutions to enable flexibility
in the process of managing numbers among national administrators, service
and application providers, and consumers.  Entities can choose to use these
tools or not.  These tools are not for the ITU-T's processes or role, nor
for how national administrators interact with the ITU-T.  But of course we
want your input and feedback, so thanks for sending this along.  More
comments in line below.  

From: Alissa Cooper <[email-masked]>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <[email-masked]>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Alissa

Begin forwarded message:

Dear Sir/Madam,

>RH: Given the scope of the work, I think that it is too early to say
whether there would be an impact. Those Recommendations are regularly
updated, in particular E.164.1, so there is nothing wrong with envisaging
changes, with the recognition of course that the changes would have to be
proposed to ITI-T Study Group 2 and agreed by that group.

Who participates in numbering processes within countries is subject to
regulation.  The WG cannot make any decisions with regard to this.  I expect
the WG to define "roles" within the number management processes; e.g.,
administrator, telecom carrier, application provider, consumer, etc.; and
how those roles could interact with each other.  This will be a baseline for
what tools and solutions would be useful to facilitate those interactions.  

>RH: Even that might be subject to, or affect, national regulations.  That
is, the definition of a "role" may well depend on national regulations.

I would expect proposed solutions to be able to address the status of a
telephone number.

>RH: Since the terms "assigned", "spare" and "reclaimed" are defined in
ITU-T Recommendations (albeit sometimes implicitly), addressing the status
of a telephone number might well impact E.164 or E.164.1.

4. Regulatory issues

We are aware of Resolution 133 and will certainly respect it.  I would
propose adding the following text after the first sentence in the last full
paragraph - "The group acknowledges ITU Plenipotentiary Conference
Resolution 133 which recognizes the existing role and sovereignty of ITU
Member States with respect to allocation and management of their country
code numbering resources as enshrined in Recommendation ITU-T E.164."  

>RH: That certainly would be a helpful addition. In addition to the above, I
would suggest adding "The group's outputs would be consistent with the
provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1,
E.190 and the Recommendations referenced therein."  

>RH: For the sake of clarity I reiterate that I oppose the creation of this
group even if the Charter is modified to include the text above.

The WG will not create any new namespace that would require regulatory
oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule out the WG leveraging
existing namespaces as part of proposed solutions.  But it's too early to
say anything specific about that.  There is nothing in the charter that
references .tel.  

I agree.  I would modify that sentence to add the following at the end - "as
well as other relevant industry and standards organizations."

The IETF often has fun with creating WG names.  : )  But the charter is
where to look for the scope of work.  The charter uses the following phrases
"distribution, acquisition and management of TNs", "functions involved in
associating information . with TNs", "associating, acquiring and resolving
TNs", "access data related to TNs", and "mechanisms for resolving
information related to TNs".  The functions you believe were left out of the
charter will be part of one or more of these processes.  

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]

Charter:

Milestones:

TBD

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Jun 2015 16:34:32 +0000

Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are responsible for ccTLDs, surely the IETF is not a suitable body for managing the DNS! And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error.

All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers. This makes the IETF really different from places like the ITU, where the products of work have some binding effect on the world.

Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it. But we're just building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part.

Finally, I'm not really sure how much I would expect "national regulators" to literally use the tools proposed in this work. They are tools for the use of a diverse industry of enterprises, carriers, end users, and so on. Many use cases under consideration would not have a national regulator as an actor. This work was in part instigated by an FCC workshop, yes, and someone associated with the FCC spoke at the MODERN BoF. But I don't anticipate that the FCC would be propping up servers to deploy this work - surely they would leave that to industry.

Jon Peterson
Neustar, Inc.

From: Richard Hill <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Since the intent is to create tools and solutions that would be used by national regulators, presumably they should be involved in the development of the tools.

As far as I know, national regulators from most countries don’t normally participate in the IETF, for a number of reasons, including the IETF’s decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU’s decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages).

If the intent is to develop tools that would be used only in the USA at first, then I would suggest that it would be more appropriate to develop them in a forum such as ATIS or an ad-hoc group created specifically for the purpose. If the US experience proved successful, then the tools could be proposed for adoption elsewhere, for example through ITU-T.

If the intent is to develop tools for use in many countries right at the start, then I would suggest that the appropriate forum would be ITU-T, not IETF, for the reasons outlined above.

Thus, I formally object to the creation of this new working group, and this even if the Charter is modified as suggested below.

Thanks and best,
Richard

From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Alissa

Begin forwarded message:

>RH: Given the scope of the work, I think that it is too early to say whether there would be an impact. Those Recommendations are regularly updated, in particular E.164.1, so there is nothing wrong with envisaging changes, with the recognition of course that the changes would have to be proposed to ITI-T Study Group 2 and agreed by that group.

>RH: Even that might be subject to, or affect, national regulations.  That is, the definition of a “role” may well depend on national regulations.

>RH: Since the terms “assigned”, “spare” and “reclaimed” are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.

4. Regulatory issues

>RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding “The group’s outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein.”

>RH: For the sake of clarity I reiterate that I oppose the creation of this group even if the Charter is modified to include the text above.

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 26 Jun 2015 16:55:19 +0000

"Many use cases under consideration would not have a national regulator as an actor."  - J. Peterson

I've struggled with this point.  What are the "many" use cases?  For example, I've not been able to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.  What is this use case?

This continues to baffle me.  Why is the IETF proposing to develop protocol tools to manage telephone numbers?  What is broken about the existing system(s)?

And I really struggle with how this is supposed to work because there are so many different kinds of telephone numbers such as service numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs, IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG, SMS800, et cetera.

And the administration is distributed (in the US) at national and state levels.

Has anyone from any of the US or international number management administrative organizations requested that the IETF build tools for them?  If they don't use them, who will?  And how can they integrate with an existing system?  Sorry Jon.  Still lost.

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

From: Modern [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Jon Peterson
Neustar, Inc.

As far as I know, national regulators from most countries don't normally participate in the IETF, for a number of reasons, including the IETF's decision-making process and the fact that the IETF works in English. National regulators do participate in ITU-T, for a number of reasons, including the ITU's decision-making process and the fact that documents are translated into the six UN languages before they are formally approved (and some discussions takes place with interpretation in six languages).

Thanks and best,
Richard

Alissa

Begin forwarded message:

>RH: Even that might be subject to, or affect, national regulations.  That is, the definition of a "role" may well depend on national regulations.

>RH: Since the terms "assigned", "spare" and "reclaimed" are defined in ITU-T Recommendations (albeit sometimes implicitly), addressing the status of a telephone number might well impact E.164 or E.164.1.

4. Regulatory issues
The Charter states that Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. We would like to bring your attention to the fact that the E.164 international public telecommunication numbering plan is a politically significant numbering resource with direct implications on national sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164", and further instructed the ITU Secretary-General and the Directors of three Bureaux (Telecommunication Standardization, Development, and Radiocommunication) to "take any necessary action to ensure the sovereignty of ITU Member States with regard to Recommendation ITU-T E.164 numbering plans whatever the application in which they are used".
We are aware of Resolution 133 and will certainly respect it.  I would propose adding the following text after the first sentence in the last full paragraph - "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which recognizes the existing role and sovereignty of ITU Member States with respect to allocation and management of their country code numbering resources as enshrined in Recommendation ITU-T E.164."

>RH: That certainly would be a helpful addition. In addition to the above, I would suggest adding "The group's outputs would be consistent with the provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1, E.190 and the Recommendations referenced therein."

7. The name of this new WG
The name of this new WG is "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)". But in the Charter, ordering, exposing and registering TNs are not mentioned, which seems to be a little bit inconsistent.
The IETF often has fun with creating WG names.  : )  But the charter is where to look for the scope of work.  The charter uses the following phrases "distribution, acquisition and management of TNs", "functions involved in associating information ... with TNs", "associating, acquiring and resolving TNs", "access data related to TNs", and "mechanisms for resolving information related to TNs".  The functions you believe were left out of the charter will be part of one or more of these processes.

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Jun 2015 16:59:52 +0000

One would be an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX. Another would be a VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier. I ran through such use cases at the MODERN BoF.

Jon Peterson
Neustar, Inc.

From: <Gorman>, "Pierce A [CTO]" <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, Richard Hill <[email-masked]<mailto:[email-masked]>>, "McGarry, Tom" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

“Many use cases under consideration would not have a national regulator as an actor.”  - J. Peterson

I’ve struggled with this point.  What are the “many” use cases?  For example, I’ve not been able to envision the use case that would require a device to use a MODERN protocol tool to acquire an RFC 3966 telephone number.  What is this use case?

Has anyone from any of the US or international number management administrative organizations requested that the IETF build tools for them?  If they don’t use them, who will?  And how can they integrate with an existing system?  Sorry Jon.  Still lost.

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

From: Modern [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; [email-masked]<mailto:[email-masked]>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Jon Peterson
Neustar, Inc.

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 19:02:33 +0200

A "VoIP service provider who wants to receive a block of new numbers through
a delegation from a carrier" might well be subject to national regulation,
so the national regulator might well be involved in that use case.

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Friday, June 26, 2015 19:00
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

One would be an enterprise IP phone that has just been deployed and wants to
acquire a new number from an IP PBX. Another would be a VoIP service
provider who wants to receive a block of new numbers through a delegation
from a carrier. I ran through such use cases at the MODERN BoF.

Jon Peterson

Neustar, Inc.

From: <Gorman>, "Pierce A [CTO]" <[email-masked]>
Date: Friday, June 26, 2015 at 9:55 AM
To: Jon Peterson <[email-masked]>, Richard Hill <[email-masked]>,
"McGarry, Tom" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

"Many use cases under consideration would not have a national regulator as
an actor."  - J. Peterson

I've struggled with this point.  What are the "many" use cases?  For
example, I've not been able to envision the use case that would require a
device to use a MODERN protocol tool to acquire an RFC 3966 telephone
number.  What is this use case?

This continues to baffle me.  Why is the IETF proposing to develop protocol
tools to manage telephone numbers?  What is broken about the existing
system(s)?

And I really struggle with how this is supposed to work because there are so
many different kinds of telephone numbers such as service numbers (e.g.,
211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs,
IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,
SMS800, et cetera.

And the administration is distributed (in the US) at national and state
levels.

Has anyone from any of the US or international number management
administrative organizations requested that the IETF build tools for them?
If they don't use them, who will?  And how can they integrate with an
existing system?  Sorry Jon.  Still lost.

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

 

Your arguments here could equally well be applied to any important resource
on which the IETF does protocol work - like, say, the DNS. The IETF manages
the DNS protocol and publishes RFCs about it. But since national authorities
are responsible for ccTLDs, surely the IETF is not a suitable body for
managing the DNS! And it isn't. But it is a suitable body for managing the
protocol work on the DNS. Other, effectively unrelated entities handle the
administrative dimensions of operating the DNS, and yes, at those bodies
there are lots of national regulators and they worry about the sorts of
things you are worrying about here. The IETF just produces tools, and that
is all MODERN proposes to do. Trying to characterize this effort otherwise
is simply an error.

All work at the IETF is done by a coalition of the willing. If it turns out
that the coalition is not representative of the needs of the community, then
what happens? Well, the work built here doesn't get used. The only people
who wasted any time or effort were the members of that coalition. No
national interests can possibly be harmed by that, even if the failed work
involved ways of talking about telephone numbers. This makes the IETF really
different from places like the ITU, where the products of work have some
binding effect on the world.

Virtually all proposed work at the IETF also faces a coalition of the
unwilling. People who aren't interested, or who think the work should be
done elsewhere, or that the work simply shouldn't be done at all. But I
maintain your "formal objection" treats the scope of the proposed work as
being different than it is, and I'd agree that if this proposed work
required regulatory oversight, that the IETF shouldn't do it. But we're just
building some protocol tools. There is also related work here for ATIS to
do, and I'm sure ATIS or some other body could later take some the protocol
tools developed in the IETF and conduct an experiment with various carriers
to see if it works for that interest group or not, and that would be
interesting information. But the IETF doesn't do that part, and doesn't
aspire to do that part.

Finally, I'm not really sure how much I would expect "national regulators"
to literally use the tools proposed in this work. They are tools for the use
of a diverse industry of enterprises, carriers, end users, and so on. Many
use cases under consideration would not have a national regulator as an
actor. This work was in part instigated by an FCC workshop, yes, and someone
associated with the FCC spoke at the MODERN BoF. But I don't anticipate that
the FCC would be propping up servers to deploy this work - surely they would
leave that to industry. 

Jon Peterson

Neustar, Inc.

From: Richard Hill <[email-masked]>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Thanks and best,

Richard

 

 

Alissa

Begin forwarded message:

Dear Sir/Madam,

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]

Charter:

Milestones:

TBD

 

  _____

---

From: "McGarry, Tom" <[email-masked]>
Date: Fri, 26 Jun 2015 17:11:22 +0000

They most likely would be involved in deciding whether that use case can happen (one entity delegating numbers to another), but it is unlikely they would be involved in the actual interaction.  Even if there are cases where they would, there are certainly cases where they wouldn't.  This is why the solutions need to be flexible enough to account for different policies.

From: Richard Hill <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 1:02 PM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, Pierce Gorman <[email-masked]<mailto:[email-masked]>>, Tom Mcgarry <[email-masked]<mailto:[email-masked]>>, Modern List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

A “VoIP service provider who wants to receive a block of new numbers through a delegation from a carrier” might well be subject to national regulation, so the national regulator might well be involved in that use case.

Best,
Richard

From: Modern [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Friday, June 26, 2015 19:00
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; [email-masked]<mailto:[email-masked]>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Jon Peterson
Neustar, Inc.

Pierce Gorman
Core Network Planning
O: 913-439-4368

Jon Peterson
Neustar, Inc.

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland
Tel :+41 22 730 5855
[email-masked]<mailto:[email-masked]>
www.itu.int<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.itu.int&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=5M98G2GioG65s0_ab1CHv41eER1DM6D6gqu02A0-A7g&e=>
www.itu150.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.itu150.org&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=J46TiDCm0B5jxt7HyS9mH5_Lex91q7CsVVpZN9YwzPQ&e=>

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]<mailto:[email-masked]>
 To Subscribe: https://www.ietf.org/mailman/listinfo/modern<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=dZEd7U4loOL3-XNQkWPTwM8ML4ykOMVPdvtFp0gMn38&e=>
 Archive: http://www.ietf.org/mail-archive/web/modern/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_mail-2Darchive_web_modern_&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=DLmpmzX0rv4n5QrtGQIZfC37Hd9CyJaWHs9bJyEdysE&e=>

Charter:

Milestones:

TBD

_______________________________________________
new-work mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/new-work<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_new-2Dwork&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=EcVaN7qVLNnf1eCKlOTmH7aMZOq6kgOgoECz5umKsJQ&e=>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Jun 2015 17:11:57 +0000

A lot hinges on how you understand involvement there. Surely a regulator could set policies that determine if and how a carrier delegates numbers, say. There may be environments where a carrier could not delegate numbers in the fashion I described. And perhaps if MODERN designed a flow that worked that way, that particular flow wold not be relevant to an environment where regulatory policy disallowed it. Whether or not that makes the regulator an "actor" in the protocol flow is a semantic question. I wouldn't think so.

Jon Peterson
Neustar, Inc.

From: Richard Hill <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 at 10:02 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, "'Gorman, Pierce A [CTO]'" <[email-masked]<mailto:[email-masked]>>, "McGarry, Tom" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Best,
Richard

Jon Peterson
Neustar, Inc.

Pierce Gorman
Core Network Planning
O: 913-439-4368

Jon Peterson
Neustar, Inc.

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 19:15:28 +0200

Dear Jon,

Thank you for the thoughtful reply.

Please see embedded comments below.

Thanks and best,

Richard

From: Peterson, Jon [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 18:35
To: Richard Hill; McGarry, Tom; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Your arguments here could equally well be applied to any important resource
on which the IETF does protocol work - like, say, the DNS. The IETF manages
the DNS protocol and publishes RFCs about it. But since national authorities
are responsible for ccTLDs,

>RH: The degree of involvement of national authorities with ccTLDs varies
greatly, but I'm not aware of any that regulate ccTLDs to the same extent
that telephone numbers are regulated. Further, the protocols and policies
for the DNS were mostly developed before anybody thought that there should
be any government involvement. And today ICANN develops most of the
policies, even if the IETF is developing the protocols. So it is not an
appropriate analogy.

surely the IETF is not a suitable body for managing the DNS!

>RH: The IETF does not manage the DNS. ICANN manages the DNS, to the extent
that it requires top level management.

And it isn't. But it is a suitable body for managing the protocol work on
the DNS. Other, effectively unrelated entities handle the administrative
dimensions of operating the DNS, and yes, at those bodies there are lots of
national regulators and they worry about the sorts of things you are
worrying about here. The IETF just produces tools, and that is all MODERN
proposes to do. Trying to characterize this effort otherwise is simply an
error.

>RH: I'm not convinced that you can develop tools that don't affect
policies.  Indeed, it seems to me that the policies will condition whether
certain tools are useable or not.

involved ways of talking about telephone numbers.

>RH: That is true if nobody uses the work. It is not true if some country,
say the US, adopts the outputs and then lobbies to have them adopted
elsewhere.  That can lead to serious friction and pushback. Better to
involve all concerned parties early in the game.

This makes the IETF really different from places like the ITU, where the
products of work have some binding effect on the world.

>RH> ITU-T Recommendations are no more (or less) binding that IETF RFCs or
ISO Standards.

required regulatory oversight, that the IETF shouldn't do it.

>RH: I see that we agree on the principles but not the details. I don't see
how the proposed work would not have regulatory impacts in at least some
(probably many) countries, even if it has no impact in the US. Again, if the
idea is to develop tools that would first be used in the US, then the work
should be done in a US-only body. If the idea is to develop tools that would
be used in many countries, then I think that the ITU-T is a more suitable
forum. 

But we're just building some protocol tools. There is also related work here
for ATIS to do, and I'm sure ATIS or some other body could later take some
the protocol tools developed in the IETF and conduct an experiment with
various carriers to see if it works for that interest group or not, and that
would be interesting information. But the IETF doesn't do that part, and
doesn't aspire to do that part.

>RH: I still don't understand why you think that IETF is uniquely well
positioned to do this work. Surely nobody would suggest that the IETF should
develop standards for nuts and bolts, when ISO is doing that. So why should
the IETF develop standards (or tools) for telephone numbers when the ITU-T
is doing that?

>RH: That may well be true for the US, but it may well not be true in other
countries. Which is why I think that the work is better done in a forum
where you are more likely to get inputs from national regulators. If the
inputs are of the form "go ahead, we don't care", then that is fine. But if
you do the work in the IETF, you are not likely to get inputs from national
regulators.

Jon Peterson

Neustar, Inc.

Thanks and best,

Richard

 

 

Alissa

Begin forwarded message:

Dear Sir/Madam,

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]

Charter:

Milestones:

TBD

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 19:16:56 +0200

Dear Tom,

Thank you for this. My point is that you are more likely to be able to
develop solutions with the requisite flexibility if you get inputs from
national regulators early on. And that that is more likely to happen if the
matters are discussed in ITU-T.

Best,

Richard

From: McGarry, Tom [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 19:11
To: Richard Hill; Peterson, Jon; 'Gorman, Pierce A [CTO]'; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

They most likely would be involved in deciding whether that use case can
happen (one entity delegating numbers to another), but it is unlikely they
would be involved in the actual interaction.  Even if there are cases where
they would, there are certainly cases where they wouldn't.  This is why the
solutions need to be flexible enough to account for different policies.  

From: Richard Hill <[email-masked]>
Date: Friday, June 26, 2015 1:02 PM
To: Jon Peterson <[email-masked]>, Pierce Gorman
<[email-masked]>, Tom Mcgarry <[email-masked]>, Modern
List <[email-masked]>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Best,

Richard

 

Jon Peterson

Neustar, Inc.

 

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

 

Jon Peterson

Neustar, Inc.

Thanks and best,

Richard

 

 

Alissa

Begin forwarded message:

Dear Sir/Madam,

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2
International Telecommunication Union
Place des Nations
CH-1211 Geneva , Switzerland 
Tel :+41 22 730 5855
[email-masked]
www.itu.int
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.itu.int&d=AwMFAg&c=
MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM8uK
80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=5M98G2GioG65s0_ab1CHv41eER1DM6D6gqu
02A0-A7g&e=> 
www.itu150.org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.itu150.org&d=AwMFAg
&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=gM
8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=J46TiDCm0B5jxt7HyS9mH5_Lex91q7Cs
VVpZN9YwzPQ&e=> 

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]
 To Subscribe: https://www.ietf.org/mailman/listinfo/modern
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_modern&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1o
oNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=dZEd7U4lo
OL3-XNQkWPTwM8ML4ykOMVPdvtFp0gMn38&e=> 
 Archive: http://www.ietf.org/mail-archive/web/modern/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_mail-2Darc
hive_web_modern_&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ
1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=DLmpmzX
0rv4n5QrtGQIZfC37Hd9CyJaWHs9bJyEdysE&e=> 

Charter:

Milestones:

TBD

_______________________________________________
new-work mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/new-work
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_new-2Dwork&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLex
tZ1ooNcfp01IYIaVqsORjI&m=gM8uK80LXL2UAv_UlkXlBEacnW7oQNFFrqmwrf-cmwc&s=EcVaN
7qVLNnf1eCKlOTmH7aMZOq6kgOgoECz5umKsJQ&e=> 

  _____

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 26 Jun 2015 17:17:47 +0000

"One would be an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX."  There are two existing protocols which spring to mind which solve this problem; MGCP and SIP. I'm sure others can point to other similar protocols as well (e.g., NCS).   And I would argue the enterprise IP phone doesn't get a new number, the IP PBX does.  The phone merely gets associated with the number provisioned in the IP PBX in order to originate or terminate calls through the IP PBX.

I wasn't able to attend the MODERN BoF so I'm not familiar with the many use cases.  In your example of the VoIP service provider I have questions.  Has it been determined that there are no suitable existing number provisioning or number management protocols?  ESPP and TERQ spring to mind as examples of protocols which have been previously developed by the IETF for such purposes and I'm sure there are other examples as well.

And is a special protocol required for this example?  Numerous peering relationships are managed using spreadsheets in e-mail.  It may be manual, inelegant and prone to error, but it certainly is cheap and is often used.  Have there been VoIP providers that have claimed they are disadvantaged because they don't have a special protocol for provisioning subtended number blocks with their carrier?

Best regards,

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

From: Peterson, Jon [mailto:[email-masked]]
Sent: June 26, 2015 12:00 PM
To: Gorman, Pierce A [CTO]; Richard Hill; McGarry, Tom; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Jon Peterson
Neustar, Inc.

Pierce Gorman
Core Network Planning
O: 913-439-4368

Jon Peterson
Neustar, Inc.

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Jun 2015 17:43:21 +0000

The entire point of my raising the DNS analogy was indeed that the IETF only creates the tools, not the policies, and that we're not proposing to do anything else here in MODERN. We know the IETF doesn't determine numbering policy. No one is confused about that (well, no one advocating for MODERN, anyway). Furthermore, the overwhelming majority of the protocol decisions that the IETF makes about the DNS aren't really matters of policy. They are matters like choosing between two proposed ways that a particular bit-field might be filled to enable a new application. The application in question may not ultimately apply everywhere that the DNS is used, and nor do we always know in advance if the application will ever have any real impact on the world. But this is what the IETF does and where its expertise lies.

Ultimately, it's why the IETF is the right place to do work like this, because the proposed MODERN work is that sort of low-level protocol work. We understand how to create protocols like this, how to encode them, how to secure them, and we have some interested vendors willing to work on implementation. The MODERN work is not being designed exclusively with US interests in mind, but like all IETF work, it will be determined by our consensus process, forged from the coalition of the willing who want to do this work - we certainly welcome non-US involvement. Our mailing lists and process are open (see OpenStand).

Jon Peterson
Neustar, Inc.

From: Richard Hill <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 at 10:15 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, "McGarry, Tom" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Dear Jon,

Thanks and best,
Richard

Your arguments here could equally well be applied to any important resource on which the IETF does protocol work - like, say, the DNS. The IETF manages the DNS protocol and publishes RFCs about it. But since national authorities are responsible for ccTLDs,

>RH: The degree of involvement of national authorities with ccTLDs varies greatly, but I’m not aware of any that regulate ccTLDs to the same extent that telephone numbers are regulated. Further, the protocols and policies for the DNS were mostly developed before anybody thought that there should be any government involvement. And today ICANN develops most of the policies, even if the IETF is developing the protocols. So it is not an appropriate analogy.

>RH: The IETF does not manage the DNS. ICANN manages the DNS, to the extent that it requires top level management.

And it isn't. But it is a suitable body for managing the protocol work on the DNS. Other, effectively unrelated entities handle the administrative dimensions of operating the DNS, and yes, at those bodies there are lots of national regulators and they worry about the sorts of things you are worrying about here. The IETF just produces tools, and that is all MODERN proposes to do. Trying to characterize this effort otherwise is simply an error.

>RH: I’m not convinced that you can develop tools that don’t affect policies.  Indeed, it seems to me that the policies will condition whether certain tools are useable or not.

All work at the IETF is done by a coalition of the willing. If it turns out that the coalition is not representative of the needs of the community, then what happens? Well, the work built here doesn't get used. The only people who wasted any time or effort were the members of that coalition. No national interests can possibly be harmed by that, even if the failed work involved ways of talking about telephone numbers.

>RH: That is true if nobody uses the work. It is not true if some country, say the US, adopts the outputs and then lobbies to have them adopted elsewhere.  That can lead to serious friction and pushback. Better to involve all concerned parties early in the game.

This makes the IETF really different from places like the ITU, where the products of work have some binding effect on the world.

>RH> ITU-T Recommendations are no more (or less) binding that IETF RFCs or ISO Standards.

Virtually all proposed work at the IETF also faces a coalition of the unwilling. People who aren't interested, or who think the work should be done elsewhere, or that the work simply shouldn't be done at all. But I maintain your "formal objection" treats the scope of the proposed work as being different than it is, and I'd agree that if this proposed work required regulatory oversight, that the IETF shouldn't do it.

>RH: I see that we agree on the principles but not the details. I don’t see how the proposed work would not have regulatory impacts in at least some (probably many) countries, even if it has no impact in the US. Again, if the idea is to develop tools that would first be used in the US, then the work should be done in a US-only body. If the idea is to develop tools that would be used in many countries, then I think that the ITU-T is a more suitable forum.

But we're just building some protocol tools. There is also related work here for ATIS to do, and I'm sure ATIS or some other body could later take some the protocol tools developed in the IETF and conduct an experiment with various carriers to see if it works for that interest group or not, and that would be interesting information. But the IETF doesn't do that part, and doesn't aspire to do that part.

>RH: I still don’t understand why you think that IETF is uniquely well positioned to do this work. Surely nobody would suggest that the IETF should develop standards for nuts and bolts, when ISO is doing that. So why should the IETF develop standards (or tools) for telephone numbers when the ITU-T is doing that?

>RH: That may well be true for the US, but it may well not be true in other countries. Which is why I think that the work is better done in a forum where you are more likely to get inputs from national regulators. If the inputs are of the form “go ahead, we don’t care”, then that is fine. But if you do the work in the IETF, you are not likely to get inputs from national regulators.

Jon Peterson
Neustar, Inc.

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Jun 2015 17:49:45 +0000

I think if someone wanted to propose a SIP extension, say, that let a new phone acquire a semi-permanent telephone number from an IP PBX, that would be a candidate solution for that part of MODERN's scope. Again, we're not deliberating about solutions now, just over whether the problem space is worth exploring.

Also, although TeRQ was proposed, we didn't bring it to RFC, in part because we deferred forming a TeRQ working group to look at this broader problem space. TeRQ would be a candidate protocol for fulfilling some of MODERN's scope as well.

I don't know that MODERN will replace all forms of peering out there in the world, and in some cases, spreadsheets surely will still be used. With a broader IP transition looming, I guess the idea is that we should try to build some tools that could make things a bit easier when all of this migrates to IP. That requires some crystal-ball gazing, some informed guessing. But even if we get it wrong, we'll probably learn some lessons that will be valuable to the industry for the transition.

Jon Peterson
Neustar, Inc.

From: <Gorman>, "Pierce A [CTO]" <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 at 10:17 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, Richard Hill <[email-masked]<mailto:[email-masked]>>, "McGarry, Tom" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

“One would be an enterprise IP phone that has just been deployed and wants to acquire a new number from an IP PBX.”  There are two existing protocols which spring to mind which solve this problem; MGCP and SIP. I’m sure others can point to other similar protocols as well (e.g., NCS).   And I would argue the enterprise IP phone doesn’t get a new number, the IP PBX does.  The phone merely gets associated with the number provisioned in the IP PBX in order to originate or terminate calls through the IP PBX.

I wasn’t able to attend the MODERN BoF so I’m not familiar with the many use cases.  In your example of the VoIP service provider I have questions.  Has it been determined that there are no suitable existing number provisioning or number management protocols?  ESPP and TERQ spring to mind as examples of protocols which have been previously developed by the IETF for such purposes and I’m sure there are other examples as well.

And is a special protocol required for this example?  Numerous peering relationships are managed using spreadsheets in e-mail.  It may be manual, inelegant and prone to error, but it certainly is cheap and is often used.  Have there been VoIP providers that have claimed they are disadvantaged because they don’t have a special protocol for provisioning subtended number blocks with their carrier?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368

Jon Peterson
Neustar, Inc.

Pierce Gorman
Core Network Planning
O: 913-439-4368

Jon Peterson
Neustar, Inc.

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: Richard Shockey <[email-masked]>
Date: Fri, 26 Jun 2015 13:32:14 -0400

In line.

From:  Modern <[email-masked]> on behalf of
"[email-masked]" <[email-masked]>
Date:  Friday, June 26, 2015 at 12:55 PM
To:  "Peterson, Jon" <[email-masked]>, Richard Hill
<[email-masked]>, "McGarry, Tom" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

³Many use cases under consideration would not have a national regulator as
an actor.²  - J. Peterson
 
I¹ve struggled with this point.  What are the ³many² use cases?  For
example, I¹ve not been able to envision the use case that would require a
device to use a MODERN protocol tool to acquire an RFC 3966 telephone
number.  What is this use case?

 

RS > Excellent point as you well know there has not been any formal
communication from the NANC ( the US FAC ) to the IETF on this issue.  The
IETF as we all know does actually respond to regulatory requests ..if you
look at nearly all of the PROVREG and WHOIS issues they are in direct
response to ICANN requests or mandates.

I can testify to the fact that some other NRA¹s are interested in new ideas
about number administration and they are desperate to first  find solutions
to the robocall spoofing problems but each jurisdiction is at various points
in the overall PSTN Transition and it is not clear a US centric solution
would be appropriate.

That said there was universal consensus that the STIR proposition was needed
and the IETF was the only appropriate body to revise 4474 in order to enable
a PKI infrastructure but beyond 4474bis I think there will need to be some
debate on how NRA¹s actually attempt to implement the protocol and design
the PKI system.

 If they don¹t use them, who will?  And how can they integrate with an
existing system?  Sorry Jon.  Still lost.

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

 

Jon Peterson

Neustar, Inc.

 

As far as I know, national regulators from most countries don¹t normally
participate in the IETF, for a number of reasons, including the IETF¹s
decision-making process and the fact that the IETF works in English.
National regulators do participate in ITU-T, for a number of reasons,
including the ITU¹s decision-making process and the fact that documents are
translated into the six UN languages before they are formally approved (and
some discussions takes place with interpretation in six languages).

 

Thanks and best,
Richard

 

 

Alissa

Begin forwarded message:

 
>RH: Given the scope of the work, I think that it is too early to say whether
there would be an impact. Those Recommendations are regularly updated, in
particular E.164.1, so there is nothing wrong with envisaging changes, with the
recognition of course that the changes would have to be proposed to ITI-T Study
Group 2 and agreed by that group.

>RH: Even that might be subject to, or affect, national regulations.  That is,
the definition of a ³role² may well depend on national regulations.

>RH: Since the terms ³assigned², ³spare² and ³reclaimed² are defined in ITU-T
Recommendations (albeit sometimes implicitly), addressing the status of a
telephone number might well impact E.164 or E.164.1.

paragraph  "The group acknowledges ITU Plenipotentiary Conference
 
>RH: That certainly would be a helpful addition. In addition to the above, I
would suggest adding ³The group¹s outputs would be consistent with the
provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1,
E.190 and the Recommendations referenced therein.²

associating information Š with TNs", "associating, acquiring and resolving
> www.itu.int <http://www.itu.int>
> www.itu150.org <http://www.itu150.org>
> 
>

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 20:18:36 +0200

Dear Jon,

Thank you for this and please see inline comments below.

Thanks and best,

Richard

Sent: Friday, June 26, 2015 19:43

The entire point of my raising the DNS analogy was indeed that the IETF only
creates the tools, not the policies, and that we're not proposing to do
anything else here in MODERN. We know the IETF doesn't determine numbering
policy. No one is confused about that (well, no one advocating for MODERN,
anyway). Furthermore, the overwhelming majority of the protocol decisions
that the IETF makes about the DNS aren't really matters of policy. They are
matters like choosing between two proposed ways that a particular bit-field
might be filled to enable a new application. 

>RH: Again, I'm not convinced that this applies to telephone numbers. I
still don't see how the things you wish to develop would not be related to
regulatory policies.

The application in question may not ultimately apply everywhere that the DNS
is used, and nor do we always know in advance if the application will ever
have any real impact on the world. But this is what the IETF does and where
its expertise lies.

>RH: For sure the IETF has expertise regarding the DNS. But I didn't realize
that it had expertise regarding telephone numbers.

Ultimately, it's why the IETF is the right place to do work like this,
because the proposed MODERN work is that sort of low-level protocol work. 

>RH: Again, I not convinced that is the case: the things that you want to do
are not, in my view, low-level protocol work and I don't think that the IETF
has lots of people who are experts in telephone numbers.  Neustar is a
member of ITU-T. What's the disadvantage to you of doing the work there,
where you could benefit from the inputs of other folks who have expertise in
telephone numbers?

We understand how to create protocols like this, how to encode them, how to
secure them, and we have some interested vendors willing to work on
implementation. 

>RH: It would be good to hear from the other interested vendors.

The MODERN work is not being designed exclusively with US interests in mind,

>RH: It would be good to hear from any of the non-US folks who would be
interested in this work.

but like all IETF work, it will be determined by our consensus process,

>RH: I look forward to finding out whether there is rough consensus to
create this working group.

forged from the coalition of the willing who want to do this work - we
certainly welcome non-US involvement.

>RH: As I said before, you are more likely to get that if you do the work in
ITU-T, or at least formally inform them of what you are doing and liaise
with them.

You will find the IETF and ITU-T collaboration guidelines at:

  http://www.itu.int/rec/T-REC-A.Sup3-201207-I 

That document has been approved by both entities.  I cite some portions
here:

"Early identification of topics of mutual interest will allow for
constructive efforts between the two organizations based on mutual respect."

"An IETF working group should also evaluate and identify areas of
relationship with the ITU-T and document the collaboration with the ITU-T
study group in its charter." 

"During the course of ITU-T and IETF collaboration, it is important to share
working drafts and documents among the technical working groups." 

"It is envisaged that the processes of clauses 2.5.1 and 2.5.2 will often be
used simultaneously by both an IETF working group and an ITU-T study group
to collaborate on a topic of mutual interest." 

Our mailing lists and process are open (see OpenStand).

>RH: Yes, but they are English-only.

Jon Peterson

Neustar, Inc.

From: Richard Hill <[email-masked]>
Date: Friday, June 26, 2015 at 10:15 AM
To: Jon Peterson <[email-masked]>, "McGarry, Tom"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Dear Jon,

Thanks and best,

Richard

 

ISO Standards.

Jon Peterson

Neustar, Inc.

Thanks and best,

Richard

 

 

Alissa

Begin forwarded message:

Dear Sir/Madam,

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]

Charter:

Milestones:

TBD

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 20:30:13 +0000

Since the nesting is getting confusing, let me add a few general points that refer to a number of different discussion items:

* My sense is that a number of national regulators are well aware of the MODERN work. NANC has been kept in the loop, and their input on requirements (e.g., through their Future of Numbering (FON) effort) has informed and will continue to inform the discussion.

* Everyone involved understands that any viable efforts need to be neutral in terms of regulatory policy decisions (such as who the actors are and what precise rights they have), as these vary by geography and change over time. It would help the discussion to move beyond this general insight and identify any specific concerns that need to be addressed.

* I'm not sure other standards bodies have demonstrated equivalent IP-based design experience, but (as noted) I suspect everybody welcomes inputs from as many interested parties as possible.

* The type and number of entities that are in the numbering ecosystem is increasing, at least in some jurisdictions. See the recent FCC R&O on number access by interconnected VoIP providers as an example, or the use of phone numbers for vehicular (telematics) and IOT systems further down the pipeline. There is a general tendency to automate and standardize the process of service creation, including the assignment of identifiers (here, phone numbers), even if one discounts the SDN/NFV hype.

* The current number porting model (in the US) predates the Internet and leaves room for improvement from a consumer and carrier perspective.

* The current assignment model (at least in the US) is not a model of efficiency and flexibility. There are numerous examples, but the most recent difficult transition process of the LNPA is a high-profile one.

* Traditional carriers may not be the only "customers". In IETF work, there's sometimes the danger of equating the installed base with the total market.

As always, participation in the IETF process is voluntary. If there are no volunteers, there will be no documents. If the output doesn't meet the need of NRAs, their designated number administration entities or other entities in the numbering ecosystem, the volunteers will have wasted their time, but nobody else will be harmed.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 20:36:51 +0000

As far as I can tell, there is really no assignment problem for special numbers (N11, say), given their static nature and the small pool. One goal that I see is to rationalize the current set of databases; their design seems to best be explained by historical, rather than technical, reasons. In many ways, 800 numbers do share similarities in the basic problem set (need to allocate, track who has been assigned numbers, etc.), so a good test of generality and "policy neutrality" may well be whether the same basic protocols and interfaces work for both traditional subscriber and toll-free numbers. I'm not sure why mobile numbers differ in some fundamental way that would affect protocols and data structures.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 20:54:01 +0000

My sense is that national regulatory staff have started to pay more attention to the IETF, but they are generally not protocol engineers. It is not obvious that most of my colleagues, however skilled they are in legal, policy and economic matters, would want to debate the use of JSON formats and protocol timers. I don't get the sense that the NRA participants in the ITU-T processes are typically Internet protocol engineers, either...

Thus, my suggestion would be that the ITU-T could play a constructive role by providing requirements and vetting work ("does this fit into the universe of requirements out there that we know about"). However, I think that's best done based on concrete work since it may turn out that many aspects will essentially have no policy implications. (As an example, if a protocol designates an abstract entity as being authorized to do something, there's not much need to enumerate all the entities in the real world that may wear that hat now or in the future since that's an operational problem, not a protocol design issue.) This fits into the fashionable "agile" software development model where you create something and get feedback early (and are prepared to discard work), rather than getting stuck forever in a requirements process.

Henning

________________________________
From: Modern [[email-masked]] on behalf of Richard Hill [[email-masked]]
Sent: Friday, June 26, 2015 11:09 AM
To: 'McGarry, Tom'; [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Thanks and best,
Richard

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 22:55:30 +0200

Please see inline.

> From: Modern [mailto:[email-masked]] On Behalf Of Henning
> Schulzrinne
> Sent: Friday, June 26, 2015 22:30
> To: [email-masked]
> Since the nesting is getting confusing, let me add a few general points
> that refer to a number of different discussion items:
> 
> * My sense is that a number of national regulators

Can you specify which national regulators are aware of the creation of the
proposed working group, other than the FCC, which I presume you are
representing in this discussion?

> are well aware of
> the MODERN work. NANC has been kept in the loop, and their input on
> requirements (e.g., through their Future of Numbering (FON) effort)

Can you please give the URL for the cited documents?

> has
> informed and will continue to inform the discussion.
> 
> * Everyone involved understands that any viable efforts need to be
> neutral in terms of regulatory policy decisions (such as who the actors
> are and what precise rights they have), as these vary by geography and
> change over time. It would help the discussion to move beyond this
> general insight and identify any specific concerns that need to be
> addressed.

I'm sorry if I am not being clear. My concern is that, unless you bring the
national regulators into the discussion, you won't know what their specific
concerns are. And this precisely because the regulatory policies vary
considerably by geography.

> 
> * I'm not sure other standards bodies have demonstrated equivalent IP-
> based design experience, but (as noted) I suspect everybody welcomes
> inputs from as many interested parties as possible.

I'm not sure that I understand what the IP-based specifics are of the
project.  As I understand it, the idea is to develop protocols for
specifying requests to get numbers, etc. How is that specifically tied to
TCP/IP?

> 
> * The type and number of entities that are in the numbering ecosystem
> is increasing, at least in some jurisdictions. See the recent FCC R&O
> on number access by interconnected VoIP providers as an example, or the
> use of phone numbers for vehicular (telematics) and IOT systems further
> down the pipeline. There is a general tendency to automate and
> standardize the process of service creation, including the assignment
> of identifiers (here, phone numbers), even if one discounts the SDN/NFV
> hype.

Agreed. I have no doubt that the work is useful, the question is how to make
it most useful and in which forum to carry out the work.

> 
> * The current number porting model (in the US) predates the Internet
> and leaves room for improvement from a consumer and carrier
> perspective.

No kidding. The US numbering plan is, in my view, obsolete and badly in need
of reform. But US industry and US authorities don't seem to agree (or at
least they didn't last time I checked a couple of years ago).

But I don't see what this has to do with the proposed working group or the
IETF.  Decisions regarding the US numbering plan are in the remit of the FCC
(but correct me if I'm wrong about that).

> 
> * The current assignment model (at least in the US) is not a model of
> efficiency and flexibility. There are numerous examples, but the most
> recent difficult transition process of the LNPA is a high-profile one.

This is no doubt correct, but, again, changes in the assignment model are in
the remit of the FCC, not the IETF (again, correct me if I'm wrong about
that).

> 
> * Traditional carriers may not be the only "customers". In IETF work,
> there's sometimes the danger of equating the installed base with the
> total market.

Indeed, I think that carriers should not be the only recipients of telephone
numbers. But, again, that is a policy question that is not in the remit of
the IETF (but correct me if I'm wrong about that).

> 
> As always, participation in the IETF process is voluntary. If there are
> no volunteers, there will be no documents. If the output doesn't meet
> the need of NRAs, their designated number administration entities or
> other entities in the numbering ecosystem, the volunteers will have
> wasted their time, but nobody else will be harmed.

As I said before, I think the risk is that something gets developed that
makes sense for the US, and the US then tries to convince other countries to
use it. That will likely result in push back and bad blood.

If the idea is to develop something that can be used in many countries, then
better to get the national regulatory authorities involved up front, and I
doubt that they will flock to IETF.

If the idea is to develop something that will only be used in the US, at
least for now, then it would be, in my view, more appropriate to develop the
solutions in a US-only body, not in the IETF.

> [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 20:57:42 +0000

I'm not quite sure I understand your paragraph below, but one of the models discussed would (technically, leaving policy/regulatory issues aside) allow a carrier to bypass the middle man and avoid paying third parties for database services. Obviously, as I suspect we both agree, the "who pays whom" discussion is well beyond the scope of protocol work.

________________________________
From: Modern [[email-masked]] on behalf of DOLLY, MARTIN C [[email-masked]]
Sent: Thursday, June 25, 2015 7:54 PM
To: McGarry, Tom
Cc: [email-masked]
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Litmus test: E.164 plus

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 22:58:28 +0200

Again, things vary according to countries.

In the US, you don't use specific area codes for mobile numbers. Elsewhere
they do. So mobile numbers are, in some ways, different from fixed numbers
in many countries.

Also, assignment criteria for special numbers (short codes) differ widely by
country.  As do the solutions adopted for number portability.

This seems to me to argue that you need to get significant input from
national regulators around the world if you want to develop truly
policy-neutral solutions.

Best,
Richard

> Sent: Friday, June 26, 2015 22:37
> To: [email-masked]
> As far as I can tell, there is really no assignment problem for special
> numbers (N11, say), given their static nature and the small pool. One
> goal that I see is to rationalize the current set of databases; their
> design seems to best be explained by historical, rather than technical,
> reasons. In many ways, 800 numbers do share similarities in the basic
> problem set (need to allocate, track who has been assigned numbers,
> etc.), so a good test of generality and "policy neutrality" may well be
> whether the same basic protocols and interfaces work for both
> traditional subscriber and toll-free numbers. I'm not sure why mobile
> numbers differ in some fundamental way that would affect protocols and
> data structures.
> 
> And I really struggle with how this is supposed to work because there
> are so many different kinds of telephone numbers such as service
> numbers (e.g., 211, 911, etc.), Toll Free numbers, mobile numbers,
> wireline numbers, TLDNs, IMRNs, ported numbers, and multiple
> administrative databases, NPAC, LERG, SMS800, et cetera.
>

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 23:04:01 +0200

Indeed I agree that a constructive approach would be to do this work in
cooperation between the IETF and the ITU-T, because, as you correctly say,
they typically draw different types of experts as participants.

And I do agree that it is better to present some concrete proposals and ask
whether they have policy implications, rather than to ask for abstract
requirements which may be difficult to formulate.

But I still don't understand why the people who wish to develop the proposed
protocols don't simply send their proposals to ITU-T Study Group 2 and see
how that group reacts.  

And, to begin with, why nobody seems to have thought of sending the draft
working group charter to ITU-T Study Group 2 to see what they thought of it.

Best,
Richard

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, June 26, 2015 22:54
> To: Richard Hill; 'McGarry, Tom'; [email-masked]
> My sense is that national regulatory staff have started to pay more
> attention to the IETF, but they are generally not protocol engineers.
> It is not obvious that most of my colleagues, however skilled they are
> in legal, policy and economic matters, would want to debate the use of
> JSON formats and protocol timers. I don't get the sense that the NRA
> participants in the ITU-T processes are typically Internet protocol
> engineers, either...
> 
> Thus, my suggestion would be that the ITU-T could play a constructive
> role by providing requirements and vetting work ("does this fit into
> the universe of requirements out there that we know about"). However, I
> think that's best done based on concrete work since it may turn out
> that many aspects will essentially have no policy implications. (As an
> example, if a protocol designates an abstract entity as being
> authorized to do something, there's not much need to enumerate all the
> entities in the real world that may wear that hat now or in the future
> since that's an operational problem, not a protocol design issue.) This
> fits into the fashionable "agile" software development model where you
> create something and get feedback early (and are prepared to discard
> work), rather than getting stuck forever in a requirements process.
> 
> Henning
> 
> national regulators, presumably they should be involved in the
> development of the tools.
> 
> As far as I know, national regulators from most countries don't
> normally participate in the IETF, for a number of reasons, including
> the IETF's decision-making process and the fact that the IETF works in
> English. National regulators do participate in ITU-T, for a number of
> reasons, including the ITU's decision-making process and the fact that
> documents are translated into the six UN languages before they are
> formally approved (and some discussions takes place with interpretation
> in six languages).
> 
> first, then I would suggest that it would be more appropriate to
> develop them in a forum such as ATIS or an ad-hoc group created
> specifically for the purpose. If the US experience proved successful,
> then the tools could be proposed for adoption elsewhere, for example
> through ITU-T.
> 
> If the intent is to develop tools for use in many countries right at
> the start, then I would suggest that the appropriate forum would be
> ITU-T, not IETF, for the reasons outlined above.
> 
> Thus, I formally object to the creation of this new working group, and
> this even if the Charter is modified as suggested below.
> 
> This effort is intended to create tools and solutions to enable
> flexibility in the process of managing numbers among national
> administrators, service and application providers, and consumers.
> Entities can choose to use these tools or not.  These tools are not for
> the ITU-T's processes or role, nor for how national administrators
> interact with the ITU-T.  But of course we want your input and
> feedback, so thanks for sending this along.  More comments in line
> below.
> 
> 
> warranted in response to these comments, and/or whether a separate
> response may be useful for addressing some of the questions below.
> 
> Alissa
> 
> Begin forwarded message:
> 
> 
> Cc: "Jamoussi, Bilel"
> <[email-masked]<mailto:[email-masked]>>
> Dear Sir/Madam,
> 
> Below please find comments from the ITU Telecommunication
> Standardization Bureau on the proposed IETF working group MODERN.
> 
> 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1 It is
> stated at the beginning of the Charter that 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.
> And it is mentioned that TNs are defined in RFC 3966 "The tel URI for
> Telephone Numbers". Does that mean the mechanism being referred to here
> only deals with Tel URI? Would there be any impact on Recommendation
> ITU-E E.164 and E.164.1 which are core recommendations on Telephone
> Numbers?
> updated, in particular E.164.1, so there is nothing wrong with
> envisaging changes, with the recognition of course that the changes
> would have to be proposed to ITI-T Study Group 2 and agreed by that
> group.
> 
> 2. Entities participating in the defined mechanisms The Charter states
> that the protocol mechanism for resolving TNs will allow entities such
> as service providers, devices, and applications to access data related
> to TNs. But it is not clear what kind of entities can participate in
> the mechanisms defined by this MODERN working group. Would it be
> restricted to the entities who have been assigned a TN or a block of
> TNS?
> regulation.  The WG cannot make any decisions with regard to this.  I
> expect the WG to define "roles" within the number management processes;
> e.g., administrator, telecom carrier, application provider, consumer,
> etc.; and how those roles could interact with each other.  This will be
> a baseline for what tools and solutions would be useful to facilitate
> those interactions.
> 
> >RH: Even that might be subject to, or affect, national regulations.
> That is, the definition of a "role" may well depend on national
> regulations.
> 
> 3. Status of Telephone numbers in the defined mechanisms Several
> operations related to TNs are mentioned in the Charter, including
> requesting, acquiring, resolving and associating. It is also stated
> that the protocol mechanism for acquiring TNs will provide an
> enrollment process for the entities that use and manage TNs. Does that
> mean Telephone numbers with various status, such as assigned, spare and
> reclaimed numbers will all be managed in the mechanisms defined by the
> MODERN working group?
> ITU-T Recommendations (albeit sometimes implicitly), addressing the
> status of a telephone number might well impact E.164 or E.164.1.
> 
> 4. Regulatory issues
> regulatory agencies. We would like to bring your attention to the fact
> that the E.164 international public telecommunication numbering plan is
> a politically significant numbering resource with direct implications
> on national sovereignty. ITU Plenipotentiary Conference Resolution 133
> (Rev. BUSAN, 2014) recognized "the existing role and sovereignty of ITU
> Member States with respect to allocation and management of their
> country code numbering resources as enshrined in Recommendation ITU-T
> E.164", and further instructed the ITU Secretary-General and the
> Directors of three Bureaux (Telecommunication Standardization,
> Development, and Radiocommunication) to "take any necessary action to
> ensure the sovereignty of ITU Member States with regard to
> Recommendation ITU-T E.164 numbering plans whatever the application in
> which they are used".
> propose adding the following text after the first sentence in the last
> full paragraph - "The group acknowledges ITU Plenipotentiary Conference
> Resolution 133 which recognizes the existing role and sovereignty of
> ITU Member States with respect to allocation and management of their
> country code numbering resources as enshrined in Recommendation ITU-T
> E.164."
> 
> >RH: That certainly would be a helpful addition. In addition to the
> above, I would suggest adding "The group's outputs would be consistent
> with the provisions of relevant ITU-T Recommendations, in particular
> E.164, E.164.1, E.190 and the Recommendations referenced therein."
> 
> >RH: For the sake of clarity I reiterate that I oppose the creation of
> this group even if the Charter is modified to include the text above.
> 
> 
> DNS-based use of international numbering resources has been discussed
> in ITU-T Study Group 2 (SG2) since its meeting of 17-26 September 2013.
> TSB Director has also exchanged letters with ICANN on issues related to
> registering digit strings in the .TEL domain. A representative from
> ICANN participated in the ITU-T SG2 meeting (28 May - June 2014) and
> provided some background on the TELNIC application. A correspondence
> group under ITU-T SG2 was also set up in this regard. We would like to
> know how the work of this new WG would relate to issues related to
> registering digit strings in the .TEL domain and other DNS-based use of
> telephone numbers.
> oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule out the WG
> leveraging existing namespaces as part of proposed solutions.  But it's
> too early to say anything specific about that.  There is nothing in the
> charter that references .tel.
> 
> 6. Relationship with related existing or concluded WGs It is stated in
> the Charter that the working group will take into consideration
> existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM.
> Detailed description of the relationship between this new WG and the
> I agree.  I would modify that sentence to add the following at the end
> - "as well as other relevant industry and standards organizations."
> 
> The name of this new WG is "Managing, Ordering, Distributing, Exposing,
> & Registering telephone Numbers (modern)". But in the Charter,
> ordering, exposing and registering TNs are not mentioned, which seems
> to be a little bit inconsistent.
> where to look for the scope of work.  The charter uses the following
> phrases "distribution, acquisition and management of TNs", "functions
> involved in associating information . with TNs", "associating,
> acquiring and resolving TNs", "access data related to TNs", and
> "mechanisms for resolving information related to TNs".  The functions
> you believe were left out of the charter will be part of one or more of
> these processes.
> 
> 
> Best regards,
> 
> Jie Zhang
> Advisor, ITU-T SG2
> Subject: [new-work] WG Review: Managing, Ordering, Distributing,
> A new IETF working group has been proposed in the Applications and
> Real-Time Area. The IESG has not made any determination yet. The
> following draft charter was submitted, and is provided for
> informational purposes only. Please send your comments to the IESG
> mailing list (iesg at ietf.org) by 2015-06-22.
> 
>  Steve Donovan
> <[email-masked]<mailto:[email-masked]>>
> 
> Assigned Area Director:
> 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. Devices, applications, and network tools
> increasingly need to manage TNs, including requesting and acquiring TN
> delegations from authorities. The output of the working group should
> make distribution, acquisition, and management of TNs simpler for all
> entities involved.
> 
> The working group will define an information management framework for
> the roles and functions involved in associating information with one or
> more TNs in an IP environment.  The working group will also identify
> protocol mechanisms to support the interactions between the functions
> defined by the framework. This includes either recommending or defining
> protocol mechanisms for acquiring, associating and resolving TNs, with
> a preference for use of existing protocol mechanisms. TNs may either be
> managed in a hierarchical tree, or in a distributed registry. The
> protocol mechanism for acquiring TNs will provide an enrollment process
> for the entities that use and manage TNs.
> 
> The protocol mechanism for resolving TNs will allow entities such as
> service providers, devices, and applications to access data related to
> TNs. Maintaining reliability, real-time application performance, and
> security and privacy for both the data and the protocol interactions
> are primary considerations. The working group will take into
> consideration existing IETF work including STIR, ENUM, SPEERMINT,
> DRINKS and SCIM.
> 
> The work of this group will focus on TNs, as defined in RFC3966, and
> blocks of TNs, that are used to initiate communication with another
> user of a service. 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 for the MODERN working
> group. Solutions and mechanisms created by the working group will be

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 21:04:40 +0000

I think we all agree that the criteria for "who gets what numbers", including restrictions on what numbers can be assigned for what services, are beyond the scope of the discussion. They are not currently in the existing SS7 or SOAP-based protocols, for example, and thus I'm still unsure how they would enter a protocol (rather than implementation) discussion. 

I would indeed encourage input from regulators or, as an aggregator of sorts, the ITU-T on porting models. I know Ofcom and others have done some work in this area already.

________________________________________
From: Richard Hill [[email-masked]]
Sent: Friday, June 26, 2015 4:58 PM
To: Henning Schulzrinne; [email-masked]
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Best,
Richard

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 23:09:16 +0200

Regarding numbering portability, you may be interested in this ITU-T
document:

  http://www.itu.int/rec/T-REC-E.164-201406-I!Sup2 

Best,
Richard

> Sent: Friday, June 26, 2015 23:05
> To: Richard Hill; [email-masked]
> I think we all agree that the criteria for "who gets what numbers",
> including restrictions on what numbers can be assigned for what
> services, are beyond the scope of the discussion. They are not
> currently in the existing SS7 or SOAP-based protocols, for example, and
> thus I'm still unsure how they would enter a protocol (rather than
> implementation) discussion.
> 
> I would indeed encourage input from regulators or, as an aggregator of
> sorts, the ITU-T on porting models. I know Ofcom and others have done
> some work in this area already.
> 
> In the US, you don't use specific area codes for mobile numbers.
> Elsewhere they do. So mobile numbers are, in some ways, different from
> fixed numbers in many countries.
> 
> Also, assignment criteria for special numbers (short codes) differ
> widely by country.  As do the solutions adopted for number portability.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 21:09:57 +0000

Rather than individuals sending drafts to ITU-T SG2, it may well be more productive to have engineering-level discussions here and then, as there are concrete and specific proposals that have received some technical vetting, solicit feedback early from any number of parties, including SG2. Obviously, the IETF mailing lists and drafts are freely accessible without membership requirement, so any interested party can take a look at any time or they can wait until there's a more specific or baked proposal. Trying to prevent technical work doesn't seem to help progress, however.

Henning

________________________________________
From: Richard Hill [[email-masked]]
Sent: Friday, June 26, 2015 5:04 PM
To: Henning Schulzrinne; 'McGarry, Tom'; [email-masked]
Subject: RE: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Best,
Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 21:22:23 +0000

Thanks for the document. However, it seems to address a somewhat different problem, namely how to route calls in a number-ported environment. In case that isn't clear, I'm pretty sure nobody here is proposing implementing or specifying call routing, with or without porting, in this working group. The part that is more relevant to number administration is the interaction between consumer (subscriber) and the gaining/losing carrier so that the gaining carrier can update any call routing instructions, for example.

To make this more concrete, this may involve a process where the gaining carrier, once ready to offer service, sends a protocol message to the losing carrier or where the possession of credentials by one or more of the participants (consumer/subscriber, gaining/losing carrier) is used to effect the change in number holding. Beyond the scope of the effort is any update of call routing (SS7, say) databases. In practice, as today, numbering-related database information is likely to influence those databases, but the details seem beyond the scope of this effort.

In many cases, the protocol work is likely to simply specify the message, with processes such as third-party verification ("did you really mean to change carriers?") or policies ("must be ported only after party X has agreed and check Y has completed") well outside the scope of any IETF work.

Henning

Sent: Friday, June 26, 2015 5:09 PM

Best,
Richard

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 26 Jun 2015 23:23:18 +0200

Indeed there are at least two ways to proceed.

One would be for Neustar, which is an ITU-T member, and other interested
parties to submit their proposals directly to ITU-T for discussion.

The other would be for this group to start to do some work and then to
liaise it to ITU-T Study Group 2.  But the first step would be to
communicate the draft charter to ITU-T Study Group 2 to see if they have any
comments.

Personally, I think that the first approach above would be the best if the
intent is to develop solutions that would be used in several countries,
because it would be faster.

In case people don't know, work such as this is carried out in ITU-T in what
they call "Rapporteur Groups" or "Editor Groups". Those groups can (and
should) meet outside of the official ITU meeting so they can allow (indeed
encourage) participation from entities that are not ITU members.

And if the intent is to develop US-only solutions, then I still don't see
why the IETF should be involved: do the work in a US-only body.

Best,
Richard

> Sent: Friday, June 26, 2015 23:10
> Rather than individuals sending drafts to ITU-T SG2, it may well be
> more productive to have engineering-level discussions here and then, as
> there are concrete and specific proposals that have received some
> technical vetting, solicit feedback early from any number of parties,
> including SG2. Obviously, the IETF mailing lists and drafts are freely
> accessible without membership requirement, so any interested party can
> take a look at any time or they can wait until there's a more specific
> or baked proposal. Trying to prevent technical work doesn't seem to
> help progress, however.
> 
> Henning
> 
> cooperation between the IETF and the ITU-T, because, as you correctly
> say, they typically draw different types of experts as participants.
> 
> And I do agree that it is better to present some concrete proposals and
> ask whether they have policy implications, rather than to ask for
> abstract requirements which may be difficult to formulate.
> 
> But I still don't understand why the people who wish to develop the
> proposed protocols don't simply send their proposals to ITU-T Study
> Group 2 and see how that group reacts.
> 
> And, to begin with, why nobody seems to have thought of sending the
> draft working group charter to ITU-T Study Group 2 to see what they
> thought of it.
> 
> Best,
> Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Jun 2015 21:52:24 +0000

I'll let other NRA staff speak for themselves, but a number were present during the IETF Dallas BOF, from what I recall.

The NANC documents can be found at

http://nanc-chair.org/

FTN 7 is probably the most relevant effort. (I haven't actively participated in the effort since this is an advisory committee to the FCC, but I think we have NANC participants on the mailing list who might be willing to provide updates; contact information is provided on the meeting slides.)

The protocols being discussed have two "IP" angles: They are based on IP itself (rather than, say, TCAP) and they are likely most relevant in all-IP (VoIP) environments where both new entrants and carriers transitioning to an all-IP environment are more likely to use new number management approaches that are not encumbered by legacy constraints. As you well know, many of those VoIP protocols have their technical home in the IETF.

I don't think anybody is proposing changing the US numbering plan (e.g., the number of digits in a phone number or fixed-vs-variable length) and that is well outside the scope of any IETF effort that I could imagine. I'm more concerned with the hodge-podge of numbering-related databases that have emerged over the decades and all made sense at some point.

For number porting (i.e., the change of the carrier or other authorized entity that controls attributes related to a phone number), this has been a chicken-and-egg problem to some extent: From my experience, policy makers tend to want to have access to tools before making rules, so it is helpful to have a set of technical options available that then allow policy flexibility at a much more rapid pace than the current change order model, including real-world experimentation before making policy changes.

We don't seem to be communicating on the "assignment model". I'm talking about the technical entities that manage the assignment, not who can get what numbers. (This is indeed, as we all seem to agree but seem to be repeating again and again, an NRA issue well beyond IETF scope.) The LNPA pain that you may not be familiar with is the transition, after a competitive bidding process, between the previous contracted number management entity and the new one. Having engineering options that bypass or minimize such disputes, should an NRA want to avail themselves of those, is one interest of mine.

My point about "new entrants" is simply that incumbents are not the only audience for this. We may not know exactly who will be playing in this sandbox in ten years (and neither the ITU nor the IETF are in the sandbox admission policing business), but it's pretty clear that there will be new kids on the playground.

Henning

Sent: Friday, June 26, 2015 4:55 PM

Please see inline.

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 27 Jun 2015 10:31:42 +0200

Dear Henning,

Thank you for this and please see embedded comments below.

Best,
Richard

> Sent: Friday, June 26, 2015 23:52
> I'll let other NRA staff speak for themselves,

I see two other people from FCC on this list, and one each from the Swiss
and UK national regulatory authorities. I don't see anybody else. But maybe
I missed some.

> but a number were
> present during the IETF Dallas BOF, from what I recall.
> 

That's the North American Numbering Plan, which concerns mostly the US, with
some input from Canada, since the other countries are mostly too small to
have much of a stake in whatever is decided.

> 
> FTN 7 is probably the most relevant effort. (I haven't actively
> participated in the effort since this is an advisory committee to the
> FCC, but I think we have NANC participants on the mailing list who
> might be willing to provide updates; contact information is provided on
> the meeting slides.)

I suppose that you are referring to this:

  http://nanc-chair.org/docs/mtg_docs/Jun15_FoN_Report.pptx 

That presentation says "The Working Group will investigate new telephone
numbering assignment approaches and future telephone number assignment
requirements."

So it is about changes that may require changes to current regulatory
policies.

But maybe you were referring to a different document.

> 
> The protocols being discussed have two "IP" angles: They are based on
> IP itself (rather than, say, TCAP) and they are likely most relevant in
> all-IP (VoIP) environments where both new entrants and carriers
> transitioning to an all-IP environment are more likely to use new
> number management approaches that are not encumbered by legacy
> constraints. 

Yes, but as I understand the charter, the proposed work is mostly about
figuring out how best to automate certain information flows.  In my
experience, that quickly leads to thinking about business process
engineering, as we did for Electronic Data Interchange (EDI). In the USA,
much of that work was done by ANSI, with the IETF contribution being limited
to protocols for transmitting data.

That is, the IETF did not get into the EDI equivalents of "managing,
distributing, registering", etc.

>As you well know, many of those VoIP protocols have their
> technical home in the IETF.

Yes, and as you also know well, some of the VoIP protocols have their
technical home in the ITU-T.  Indeed you wrote an article comparing SIP to
H.323, at:

  http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf 

There seem to be divergent opinions regarding the relative merits of H.323
and SIP, and on which has greater market share, but for sure both are widely
deployed, see:

  http://www.packetizer.com/ipmc/h323_vs_sip/  

http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00
80092947.shtml 

  http://www.dailypayload.com/content/3111 

And some people think that both are obsolete and should/will be replaced by
something newer, see for example:

  https://bloggeek.me/h323-sip-xmpp-js/ 

Be that as it may, the codecs standardized by ITU-T seem still to be widely
used, so apparently ITU-T is also able to produce ways of packaging bits
that are commercially useful.

But, as I said above, I doubt that the thrust of the work of the proposed
Working Group would actually be about how to package bits.  It seems to me
that it will be more related to business processes and business process
engineering, which is not an area in which the IETF has traditionally been
active.

> 
> I don't think anybody is proposing changing the US numbering plan
> (e.g., the number of digits in a phone number or fixed-vs-variable
> length) 

Pity because, as I said before, I think that that is long overdue.  I didn't
say it before, but I think that the whole idea of using one E.164 geographic
country code for many countries is a deleterious relic of the past, a
"legacy system" in the worst sense of the term. In my view, the US should
take "1" for itself and the other countries should get new codes (or, if the
US were willing to share more equitably, it could move to 11 and free up 9
codes).

And the US could take advantage of that change to expand its numbering plan.
(As you know, most countries have expanded their numbering plans during the
past 20 years.)

>and that is well outside the scope of any IETF effort that I
> could imagine. 

True. But it would not necessarily outside the scope of ITU-T Study Group 2,
if everybody agreed that the matter should be discussed in ITU-T.

But maybe that's one of the reasons why some people would prefer not to
bring the matter to the ITU: they wish to ensure that the scope of the
discussions is restricted.

That's certainly a legitimate desire, but I would submit that it would be
better fulfilled by creating an ad-hoc group to discuss the matter. As
several people have pointed out, IETF is open, so you never know what will
be brought into discussions.

>I'm more concerned with the hodge-podge of numbering-
> related databases that have emerged over the decades and all made sense
> at some point.

Indeed. But, again, this is not a matter of figuring out how to package
bits. It is a business process issue. And the IETF has not typically been
involved in those sorts of issues, at least not for what concerns telephone
numbers.  Whereas ITU-T Study Group 2 has considered such matters.

> 
> For number porting (i.e., the change of the carrier or other authorized
> entity that controls attributes related to a phone number), this has
> been a chicken-and-egg problem to some extent: From my experience,
> policy makers tend to want to have access to tools before making rules,
> so it is helpful to have a set of technical options available that then
> allow policy flexibility at a much more rapid pace than the current
> change order model, including real-world experimentation before making
> policy changes.

Agreed. But, again, this is an argument in favor of conducting the
discussions in an environment where there will be policy makers.  And more
policy makers participate in ITU-T than in IETF.

> 
> We don't seem to be communicating on the "assignment model". I'm
> talking about the technical entities that manage the assignment, not
> who can get what numbers. 

I did understand that distinction. But which technical entities do what is a
policy matter, not a protocol issue.  In the US, the technical management is
performed by a private sector entity. That is not the case elsewhere.  So,
elsewhere, anything related to the management of the assignments involves
the national regulator.

>(This is indeed, as we all seem to agree but
> seem to be repeating again and again, an NRA issue well beyond IETF
> scope.) The LNPA pain that you may not be familiar with is the
> transition, after a competitive bidding process, between the previous
> contracted number management entity and the new one. Having engineering
> options that bypass or minimize such disputes, should an NRA want to
> avail themselves of those, is one interest of mine.

I don't follow the US developments closely, but I had heard that Neustar
lost its contract, or might lose its contract, or something to that effect.

Perhaps you could provide more detail on what you outline above, so that we
all have the same level of understanding of what is happening in the US.

> 
> My point about "new entrants" is simply that incumbents are not the
> only audience for this. We may not know exactly who will be playing in
> this sandbox in ten years (and neither the ITU nor the IETF are in the
> sandbox admission policing business),

Actually the ITU is in the sandbox admission business, for the
non-geographic country codes (881, 882, 883).  For many years there were few
requests, about 1-2 per year. But things have picked up now and they are
getting several requests per year.

And ITU is in the policing business, even if it has no enforcement powers,
with respect to misuse of E.164 numbers.

Both issues may be related to some of the work of the proposed Working
Group.

> but it's pretty clear that there
> will be new kids on the playground.

In my view, there would be more new kids if the legacy US numbering plan
were reformed.

For example, if you had dedicated area codes for mobile, then some mobile
operators could envisage offering "caller pays" pricing plans. I know that
some people think that "receiver pays" is the only model that makes sense,
but in fact most of the world uses "caller pays".

And the proportion of people who move to relatively expensive flat rate
plans might be different if they could choose between caller pays and
receiver pays.

> > Since the nesting is getting confusing, let me add a few general
> > points that refer to a number of different discussion items:
> >
> Can you specify which national regulators are aware of the creation of
> the proposed working group, other than the FCC, which I presume you are
> specifying requests to get numbers, etc. How is that specifically tied
> to TCP/IP?
> 
> 
> >
> No kidding. The US numbering plan is, in my view, obsolete and badly in
> need of reform. But US industry and US authorities don't seem to agree
> (or at least they didn't last time I checked a couple of years ago).
> 
> 
> >
> This is no doubt correct, but, again, changes in the assignment model
> are in the remit of the FCC, not the IETF (again, correct me if I'm
> wrong about that).
> 
> >
> Indeed, I think that carriers should not be the only recipients of
> telephone numbers. But, again, that is a policy question that is not in
> the remit of the IETF (but correct me if I'm wrong about that).

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Jun 2015 19:54:02 -0400

On the one hand, neither MGCP nor SIP do number assignments for phones. It is irrelevant for MGCP, because the soft switch handles the numbers. On the SIP side, phone provisioning is the purview of the SIPForum device configuration specification.

On the other hand, Cullen’s use case of a large enterprise doing its own allocations of numbers across multiple campuses, and as such down to the phone, was compelling to me. I do not think it has regulatory issues, and it is a real problem that his customers would like to see solved.

Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of other vendors and large enterprises would be interested. Any comments from those folks?

> On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
[snip]

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 27 Jun 2015 13:07:06 +0000

Numbers are a valuable resource.
Traditionally, the FCC assigns the numbers to service providers, to which the FCC regulates and can punish with fines, etc…. I do not believe the FCC will assign numbers to anyone that they cannot PUNISH if abuse occurs.
Yes there have been experiments assigning to non-traditional SPs, but these came with “conditions”
WRT assigning numbers to Enterprises, where is the line drawn between assigning to Cisco versus Hot Dog vendor???

From: Modern [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Friday, June 26, 2015 7:54 PM
To: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368

---

From: Chris Wendt <[email-masked]>
Date: Sat, 27 Jun 2015 09:24:31 -0400

Hi Jon,

I’m trying to figure out the logic in the DNS analogy.

“Acquiring” a telephone number and “Acquiring” an IP address are both processes that involve little protocol work and lots of governance to avoid wild-west attitude toward allocation of each currently as i understand.

The only analogy I can think about here is DNS manages FQDNs and records associated with IP addresses and maybe calling-name or STIR certificates would be a potential similar association to a telephone number?  

Point is, I think the analogy is at the wrong level of process in the lifecycle of IP addresses and where DNS protocols are involved.

Maybe I’m taking the importance of the analogy to far, but i think there was a lot of emphasis on this analogy in the presentations.  I also do think they can be very helpful and/or hurtful if portrayed the right way.  In either case, it does seem an important and interesting distinction to understand, because unless i’m misinterpreting the point of your analogy, is that IETF gets involved in DNS management protocols so therefore it makes sense for IETF to develop protocols associated with number management?  To me, i would say that is incorrect association and actually hurts your argument.

-Chris

> On Jun 26, 2015, at 12:34 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> From: Richard Hill <[email-masked] <mailto:[email-masked]>>
> To: "McGarry, Tom" <[email-masked] <mailto:[email-masked]>>, "[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]>
> From: Alissa Cooper <[email-masked] <mailto:[email-masked]>>
> To: Modern List <[email-masked] <mailto:[email-masked]>>
> From: "Zhang, Jie" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "Jamoussi, Bilel" <[email-masked] <mailto:[email-masked]>>
>> Dear Sir/Madam,
>> 
>> [email-masked] <mailto:[email-masked]>
>> www.itu.int <http://www.itu.int/>
>> www.itu150.org <http://www.itu150.org/>
>> 
>> 
>> From: new-work [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of The IESG
>> To: [email-masked] <mailto:[email-masked]>
>>  Tom McGarry <[email-masked] <mailto:[email-masked]>>
>>  Steve Donovan <[email-masked] <mailto:[email-masked]>>
>> 
>> Assigned Area Director:
>>  Alissa Cooper <[email-masked] <mailto:[email-masked]>>
>> 
>> Mailing list
>>  Address: [email-masked] <mailto:[email-masked]>
>>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern <https://www.ietf.org/mailman/listinfo/modern>
>>  Archive: http://www.ietf.org/mail-archive/web/modern/ <http://www.ietf.org/mail-archive/web/modern/>
>> 
>> Charter:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/new-work <https://www.ietf.org/mailman/listinfo/new-work>
>>  
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jun 2015 18:32:44 +0000

Can't speak for Jon or what he has in mind, but the closest DNS analogy I can think of is the set of registrar-registry protocols (EPP), RFC 5730 et al, as well as the recent output of the WEIRDS working group (RDAP, RFC 7480). I believe both are mentioned in the draft charter. With the usual danger of analogies, both illustrate the basic concept of separating policy (who can get what names, e.g., trademark and name character set issues) and the nuts-and-bolts "request domain name" protocol operation. For RDAP, the protocol does not specify what information needs to be provided, how it is verified or who gets to access it, just the basic retrieval of JSON objects.

Whether you want to use the analogy of DHCP, i.e., short term assignment of domain names and IP addresses to authorized hosts, is a more tricky issue, but I don't think anybody has proposed using DHCP for assigning phone numbers to SIP UAs, except indirectly (through the SIP configuration protocol mechanisms).

________________________________
From: Modern [[email-masked]] on behalf of Chris Wendt [[email-masked]]
Sent: Saturday, June 27, 2015 9:24 AM
To: Peterson, Jon
Cc: Richard Hill; [email-masked]; McGarry, Tom
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Hi Jon,

-Chris

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jun 2015 18:43:53 +0000

Martin,

this was discussed at some length during the BoF. The idea is that, as today, a carrier or other authorized entity assigns a block of numbers to a large enterprise. For example, Columbia University has the 212 854 xxxx block (among others). Within the enterprise, these are then delegated, automatically, to various sub-units. This does not change the responsibility of the carrier, just automates a manual process. Indeed, a number of traditional certificated carriers apparently have been delegating numbers to their VoIP partners, whether those are consumer companies like Vonage or Skype or web API providers, like Twilio.

You may also find
https://www.fcc.gov/document/fcc-releases-voip-direct-access-numbering-report-and-order
of interest. It doesn't involve hot dog vendors, or Cisco (unless they turn their WebEx business into iVoIP).

Henning

________________________________
From: Modern [[email-masked]] on behalf of DOLLY, MARTIN C [[email-masked]]
Sent: Saturday, June 27, 2015 9:07 AM
To: Eric Burger; [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jun 2015 18:56:30 +0000

I don't think a discussion on H.323 vs. SIP is productive or relevant here, nor attempts to raise issues about the US numbering plan.

You had asked about interactions with the US NRA; NANC is the advisory body and I have provided a link. I did not claim that they do anything except deal with the NANP. I think it would be helpful if you didn't try to extrapolate beyond what I say.

You can get the official statements about the LNPA from the FCC web site; for example,

https://apps.fcc.gov/edocs_public/attachmatch/DA-15-554A1.pdf

As noted earlier and discussed during the BoF, this particular model is one model of several, but they basically fall into the "one administrator" (whether the NRA directly or a contracted third party seems to matter little from a technical perspective) or "many administrators" (somewhat similar to the US 800# RespOrg model, albeit one layer down, or the US TV whitespace database).

You keep repeating the same assertions, and arguments about separating technology (protocols) from policy do not seem to convince you, so I don't think the discussion is particularly productive at this point. I look forward to your constructive contributions to the working group.

Henning

Sent: Saturday, June 27, 2015 4:31 AM

Dear Henning,

Best,
Richard

---

From: Richard Shockey <[email-masked]>
Date: Sat, 27 Jun 2015 18:57:00 -0400

From:  Modern <[email-masked]> on behalf of Eric Burger
<[email-masked]>
Date:  Friday, June 26, 2015 at 7:54 PM
To:  "[email-masked]" <[email-masked]>
Subject:  Re: [Modern] [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

On the one hand, neither MGCP nor SIP do number assignments for phones. It
is irrelevant for MGCP, because the soft switch handles the numbers. On the
SIP side, phone provisioning is the purview of the SIPForum device
configuration specification.

RS> Which I can testify has not gone very far for a variety of reasons.

***

On the other hand, Cullen¹s use case of a large enterprise doing its own
allocations of numbers across multiple campuses, and as such down to the
phone, was compelling to me. I do not think it has regulatory issues, and it
is a real problem that his customers would like to see solved.

RS> You are correct. It is actually a sensible use case there but
complicated by the problem that large enterprises still cross multiple LATA
boundaries in the US and managing blocks from multiple states is a royal
<fill in the blank>.  That is still a problem with US National Numbering
policy that has yet to be resolved in the context of the PSTN Transition.

US Numbering is WAY WAY far advanced even though the NANC is <fill in the
blank>.  LATA¹s will go away but we are not there yet and the FCC still is
avoiding the underlying regulatory vision to the public necessary to make
actual progress. 

If you eliminate the geographic or access means of numbering things get
simpler.  Yes as Brother Henning points out a TN is really a domain name and
that is why this discussion actually is important and makes sense. IBM or
Ford or Cisco could assign one single NPA to all of its employees for its
business communications but you go tell citizens in Vermont Alaska or Maine
PEI Yukon etc they have to dial 10 digits for all calls.

http://www.shockey.us/index.php/download_file/view/13/142/

The unspoken issue here is where does the initial work get done and I¹m not
currently convinced the IETF is the right place to do it.

OK I¹ll finally say it.

The IETF has not traditionally been hospitable to the concerns of service
providers. There is a reason 3GPP ETSI ATIS exist.

Collectively we understand that there is a problem in the US with
numbering/routing  databases and that the problem is manifesting itself
first in the North American market since the level of SIP/IMS deployments
now far exceed anything in Europe or AsiaPac.  The PSTN Transition is no
longer a idea its an inevitability.  And yes.. Contrary to everything Henry
Sinnreich and other used to preach ..TN are still here and I still don¹t see
SIP URI¹s on the side of pizza delivery cars.

Even within the FCC and the Commissioners there is some divergent views on
what is actually at stake here.

https://www.fcc.gov/article/fcc-15-70a6

The debate in the UK w/ BT is just starting.

http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/t
elecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help-it-b
attle-US-tech-giants.html

***

Besides Cisco, I would presume Avaya, Unify, Oracle, and a handful of other
vendors and large enterprises would be interested. Any comments from those
folks?

RS> Besides Cisco everyone seems to like their vendor specific presumed
customer lock in solutions and even those are being disrupted by BYOD
solutions. That will of course change over time when we do point to point
video calling using E.164.

> ³One would be an enterprise IP phone that has just been deployed and wants to
> acquire a new number from an IP PBX.²  There are two existing protocols which
> spring to mind which solve this problem; MGCP and SIP. I¹m sure others can
> point to other similar protocols as well (e.g., NCS).   And I would argue the
> enterprise IP phone doesn¹t get a new number, the IP PBX does.  The phone
> merely gets associated with the number provisioned in the IP PBX in order to
> originate or terminate calls through the IP PBX.
>  
> I wasn¹t able to attend the MODERN BoF so I¹m not familiar with the many use
> cases.  In your example of the VoIP service provider I have questions.  Has it
> been determined that there are no suitable existing number provisioning or
> number management protocols?  ESPP and TERQ spring to mind as examples of
> protocols which have been previously developed by the IETF for such purposes
> and I¹m sure there are other examples as well.
>  
> And is a special protocol required for this example?  Numerous peering
> relationships are managed using spreadsheets in e-mail.  It may be manual,
> inelegant and prone to error, but it certainly is cheap and is often used.
> Have there been VoIP providers that have claimed they are disadvantaged
> because they don¹t have a special protocol for provisioning subtended number
> blocks with their carrier?
>  
> Best regards,
>  
>  
> Pierce Gorman
> Core Network Planning
> O: 913-439-4368
> [email-masked]
[snip]

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 28 Jun 2015 08:02:32 +0200

Thanks and best,

Richard

Sent: Sunday, June 28, 2015 00:57

 

SNIP

>RH: I find that the paper cited above is excellent and I would urge
everybody who has a serious interest in these discussions to read it
carefully.  In Switzerland, we have full geographic portability for fixed
numbers (as well as portability for mobile numbers), so users have to dial
10 digits for all calls (including the leading zero, as in 022 840 1021).
The same is true in most European countries, but in some cases the number of
digits in greater. Given the size of the US population (vs. the 8 million of
Switzerland), it seems to me that the US should envisage moving to 12
digits, or at least 11.

The unspoken issue here is where does the initial work get done and I'm not
currently convinced the IETF is the right place to do it. 

OK I'll finally say it.

>RH: People who have been around a long time and who are cynical might be
tempted to recall the misunderstandings between the bell-heads and the
net-heads.  But I don't think that that is relevant any  more. What is
relevant is who tends to participate in which group.  As far as I know, the
people who understand the concerns of service providers (and carriers) don't
typically participate in IETF. So I agree that IETF is not the right place
to start this work.  But I do agree that the work should be started.  Those
who wish to drive the work forward should pick an appropriate forum.

Collectively we understand that there is a problem in the US with
numbering/routing  databases and that the problem is manifesting itself
first in the North American market since the level of SIP/IMS deployments
now far exceed anything in Europe or AsiaPac.  The PSTN Transition is no
longer a idea its an inevitability.  And yes.. Contrary to everything Henry
Sinnreich and other used to preach ..TN are still here and I still don't see
SIP URI's on the side of pizza delivery cars.

>RH: Interesting post from at least two points of view. First, while I
haven't looked at the Swiss regulations in detail, it seems to me that they
already don't require traditional PSTN, because service providers (including
the incumbent Swisscom) are offering IP-only packages for data and voice.
The only reason I don't have one is that, for now, they only offer up to 3
distinct telephone numbers as part of the offer, whereas I have 10 numbers
with ISDN (if you remember ISDN, you are an "old hand"; if you remember
rotary dials, analog phones, and Blue Boxes, you are an <fill in the
blank>).

>RH: Second,  I've spent most of my career in the highly competitive
computer business. Calls for deregulation are in effect calls to create a
competitive market. I'm all in favor of competition, so I think that it's
great that regulated companies are calling for competition. But I'm obliged
to remind them of the old adage "Be careful what you wish for, because your
wish may be granted".

***

>RH: As we all know, proprietary solutions are used to reduce competition
and create opportunities for higher profits. Good regulations reduce the
opportunities to do that and increase competition at all levels.  Which is
not to say that everything should be regulated. Quite the contrary,
regulation should be imposed only when it is clear that a particular market
is not competitive. And that should be done sparingly.

On Jun 26, 2015, at 1:17 PM, Gorman, Pierce A [CTO]
<[email-masked]> wrote:

"One would be an enterprise IP phone that has just been deployed and wants
to acquire a new number from an IP PBX."  There are two existing protocols
which spring to mind which solve this problem; MGCP and SIP. I'm sure others
can point to other similar protocols as well (e.g., NCS).   And I would
argue the enterprise IP phone doesn't get a new number, the IP PBX does.
The phone merely gets associated with the number provisioned in the IP PBX
in order to originate or terminate calls through the IP PBX.

I wasn't able to attend the MODERN BoF so I'm not familiar with the many use
cases.  In your example of the VoIP service provider I have questions.  Has
it been determined that there are no suitable existing number provisioning
or number management protocols?  ESPP and TERQ spring to mind as examples of
protocols which have been previously developed by the IETF for such purposes
and I'm sure there are other examples as well.

because they don't have a special protocol for provisioning subtended number

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

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

[snip]

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 28 Jun 2015 08:52:13 +0200

Dear Henning,

Best,
Richard

> Sent: Saturday, June 27, 2015 20:57
> I don't think a discussion on H.323 vs. SIP is productive or relevant
> here,

I was under the impression that you were referring to SIP as evidence that
the IETF has expertise regarding VoIP, so I thought that it was appropriate
to point out that the ITU-T also has expertise regarding VoIP.  I apologize
if I misunderstood your intent.

> nor attempts to raise issues about the US numbering plan.

I'm not so sure about that. The US numbering plan is very different from
most other numbering plans, so solutions that cater to the US situation
might not be appropriate elsewhere.

In other words, it might be appropriate to understand the ways in which the
situation in the US is different from the situation elsewhere.

> 
> You had asked about interactions with the US NRA; NANC is the advisory
> body and I have provided a link. I did not claim that they do anything
> except deal with the NANP. I think it would be helpful if you didn't
> try to extrapolate beyond what I say.

I didn't think that I was extrapolating, but I apologize if I did.

> https://apps.fcc.gov/edocs_public/attachmatch/DA-15-554A1.pdf

Thank you. So, if I understand correctly, the Local Number Portability
Administrator contract might be moved from Neustar to Telcordia (iconectiv).

> 
> As noted earlier and discussed during the BoF, this particular model is
> one model of several, but they basically fall into the "one
> administrator" (whether the NRA directly or a contracted third party
> seems to matter little from a technical perspective) or "many
> administrators" (somewhat similar to the US 800# RespOrg model, albeit
> one layer down, or the US TV whitespace database).

Yes, and the business processes might be different, even within each of
those two models.

> 
> You keep repeating the same assertions, and arguments about separating
> technology (protocols) from policy do not seem to convince you, so I
> don't think the discussion is particularly productive at this point.

I have indeed repeatedly raised the same points, but I haven't see any
replies that I would consider satisfactory. The points that I have raised
are:

1. If the intent is to develop solutions that would apply to many countries,
then the discussions should take place in a forum were national regulators
participate. The obvious forum is ITU-T Study Group 2.

2. If the intent is to, at least for now, develop solutions that would apply
in the US, then the discussions should take place in a US forum, such as
ATIS.

3. In any case, there are surely underlying business process, economic, and
regulatory issues, so the matter is not purely technical and participation
of people with the requisite knowledge and background should be encouraged.
I doubt that this is purely about packaging bits, and I doubt that the IETF
will attract all the people who should be involved.

4. In any case, the ITU-T should be involved or at least informed, for
example through liaisons.
 
>I look forward to your constructive contributions to the working group.

I still think that this group should not be created within the IETF, so I
hope that I won't have to contribute to it.

And I trust that you appreciate and support my constructive contributions to
date, in particular my suggestions regarding the text of the proposed
Charter and liaising with ITU-T.

> That's the North American Numbering Plan, which concerns mostly the US,
> with some input from Canada, since the other countries are mostly too
> small to have much of a stake in whatever is decided.
> 
> >
> > might be willing to provide updates; contact information is provided
> > on the meeting slides.)
> 
> That presentation says "The Working Group will investigate new
> telephone numbering assignment approaches and future telephone number
> assignment requirements."
> 
> > IP itself (rather than, say, TCAP) and they are likely most relevant
> > in all-IP (VoIP) environments where both new entrants and carriers
> engineering, as we did for Electronic Data Interchange (EDI). In the
> USA, much of that work was done by ANSI, with the IETF contribution
> being limited to protocols for transmitting data.
> 
> >As you well know, many of those VoIP protocols have their  technical
> >home in the IETF.
> 
> technical home in the ITU-T.  Indeed you wrote an article comparing SIP
> to H.323, at:
> 
> There seem to be divergent opinions regarding the relative merits of
> H.323 and SIP, and on which has greater market share, but for sure both
> are widely deployed, see:
> 
> And some people think that both are obsolete and should/will be
> replaced by something newer, see for example:
> 
> Be that as it may, the codecs standardized by ITU-T seem still to be
> widely used, so apparently ITU-T is also able to produce ways of
> packaging bits that are commercially useful.
> 
> But, as I said above, I doubt that the thrust of the work of the
> proposed Working Group would actually be about how to package bits.  It
> seems to me that it will be more related to business processes and
> business process engineering, which is not an area in which the IETF
> has traditionally been active.
> 
> >
> Pity because, as I said before, I think that that is long overdue.  I
> didn't say it before, but I think that the whole idea of using one
> E.164 geographic country code for many countries is a deleterious relic
> of the past, a "legacy system" in the worst sense of the term. In my
> view, the US should take "1" for itself and the other countries should
> get new codes (or, if the US were willing to share more equitably, it
> could move to 11 and free up 9 codes).
> 
> (As you know, most countries have expanded their numbering plans during
> the past 20 years.)
> 
> >and that is well outside the scope of any IETF effort that I  could
> >imagine.
> 
> True. But it would not necessarily outside the scope of ITU-T Study
> Group 2, if everybody agreed that the matter should be discussed in
> ITU-T.
> 
> That's certainly a legitimate desire, but I would submit that it would
> be better fulfilled by creating an ad-hoc group to discuss the matter.
> As several people have pointed out, IETF is open, so you never know
> what will be brought into discussions.
> 
> >I'm more concerned with the hodge-podge of numbering-  related
> >databases that have emerged over the decades and all made sense  at
> >some point.
> 
> bits. It is a business process issue. And the IETF has not typically
> been involved in those sorts of issues, at least not for what concerns
> telephone numbers.  Whereas ITU-T Study Group 2 has considered such
> matters.
> 
> 
> 
> 
> 
> >(This is indeed, as we all seem to agree but  seem to be repeating
> >again and again, an NRA issue well beyond IETF
> I don't follow the US developments closely, but I had heard that
> Neustar lost its contract, or might lose its contract, or something to
> that effect.
> 
> Perhaps you could provide more detail on what you outline above, so
> that we all have the same level of understanding of what is happening
> in the US.
> 
> >
> Actually the ITU is in the sandbox admission business, for the non-
> geographic country codes (881, 882, 883).  For many years there were
> few requests, about 1-2 per year. But things have picked up now and
> they are getting several requests per year.
> 
> And ITU is in the policing business, even if it has no enforcement
> powers, with respect to misuse of E.164 numbers.
> 
> In my view, there would be more new kids if the legacy US numbering
> plan were reformed.
> 
> For example, if you had dedicated area codes for mobile, then some
> mobile operators could envisage offering "caller pays" pricing plans. I
> know that some people think that "receiver pays" is the only model that
> makes sense, but in fact most of the world uses "caller pays".
> 
> > the proposed working group, other than the FCC, which I presume you
> > are representing in this discussion?
> >
> > > are well aware of
> > No kidding. The US numbering plan is, in my view, obsolete and badly
> > in need of reform. But US industry and US authorities don't seem to
> > agree (or at least they didn't last time I checked a couple of years
> ago).
> >
> >
> > >
> > > * The current assignment model (at least in the US) is not a model
> > > of efficiency and flexibility. There are numerous examples, but the
> > > most recent difficult transition process of the LNPA is a
> > > high-profile
> > one.
> >
> > > * Traditional carriers may not be the only "customers". In IETF
> > > work, there's sometimes the danger of equating the installed base
> > > with the total market.
> >
> > telephone numbers. But, again, that is a policy question that is not
> > in the remit of the IETF (but correct me if I'm wrong about that).
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 28 Jun 2015 13:37:32 +0000

Henning,

Thank you for the explanation and link to the report and order. I was already aware of these use cases. 

My comment was to the examples on the mailing list.

Thank you,

Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Saturday, June 27, 2015 2:44 PM
To: DOLLY, MARTIN C; Eric Burger; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Martin,

You may also find

Henning

Numbers are a valuable resource.
Traditionally, the FCC assigns the numbers to service providers, to which the FCC regulates and can punish with fines, etc.... I do not believe the FCC will assign numbers to anyone that they cannot PUNISH if abuse occurs.
Yes there have been experiments assigning to non-traditional SPs, but these came with "conditions"
WRT assigning numbers to Enterprises, where is the line drawn between assigning to Cisco versus Hot Dog vendor???

On the other hand, Cullen's use case of a large enterprise doing its own allocations of numbers across multiple campuses, and as such down to the phone, was compelling to me. I do not think it has regulatory issues, and it is a real problem that his customers would like to see solved.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 29 Jun 2015 04:06:45 +0000

I'm struggling with this.

Maybe the public network use case can exist that tells a provider that the number has been assigned, but I cannot envisage the private network use case as being possible without also transferring attributes, e.g. class of service, how to route to that number, etc, that are associated with that number, and under which that number is used. It therefore becomes something much more in the network management sphere than a number assignment problem. And network management is not something that is defined in any of the charters I have seen.

And if it is not a network management protocol, what is the interaction of such a new assignment protocol with any network management protocol that may also be assigning the numbers. along with the other attributes of the so created users.

regards

Keith

P.S. As for "and it is a real problem that his customers would like to see solved", I do not remember Cullen actually saying that, and none of the other enterprise vendors seem to have weighed in on this.

  _____

   Sent: 27 June 2015 00:54

      Best regards,

      Pierce Gorman
      Core Network Planning
      O: 913-439-4368

   [snip]

---

From: "Ben Campbell" <[email-masked]>
Date: Sun, 28 Jun 2015 23:58:07 -0500

On 28 Jun 2015, at 23:06, DRAGE, Keith (Keith) wrote:

> P.S. As for "and it is a real problem that his customers would like 
> to see solved", I do not remember Cullen actually saying that, and 
> none of the other enterprise vendors seem to have weighed in on this.

(no hats)

Speaking just for myself (as are we all, right? ;-) ) : I've mentioned 
before that I would like to see this solved. That has not changed.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Jun 2015 15:11:06 +0000

This is straying far afield, but a few quick remarks:

* The US numbering system does have extension points that would allow transitioning to longer numbers, but I haven't heard anybody proposing this seriously. Partially, it's because the number utilization is low (800M out of 10B theoretically possible numbers), so while individual area codes continue to be split, there is no shortage of numbers as such, particularly as the need for prefix dialing disappears with the use of mobile and VoIP. (Right now, a bunch of area codes can't be assigned since they are short numbers, such as N11.) Most of the increased demand is from non-human users (think parking and water meters) and they generally don't care about geographic area codes. We can take bets as to whether the US will transition first to the metric system or variable-length numbers. At least a presidential candidate has proposed the former and there's probably more value to that transition.

As geographic numbering decreases somewhat in importance, due to mobile, I suspect that we should essentially look at numbers as either fixed-length (NANP) or variable-length strings, and the trade-offs aren't obvious. It could well be that non-human users of phone numbers if they ever get beyond the rather limited applications envisioned so far, use longer strings, just as some such applications have started to use non-dialable numbers (pANI).

I suspect that there are millions of places where software, from spreadsheets to databases and billing systems, in North America assumes fixed-length strings, so you're suggesting another Y2K-level effort, with no obvious benefit.

* The different dialing plans are a pain, but unifying them into permissive 10D dialing does not require changing to a European-style variable-length plan. They are mainly used since many people are used to dialing local numbers as seven digits in the NANP (just like they dial numbers without area codes elsewhere), but I suspect that the distinction between local and non-local will gradually fade as mobile dominates.

* We have lots of issues in MODERN, but shy service providers doesn't seem to be one of them... Given the additional flexibility and "cutting out the middle man" advantages, I would hope that they'd actually see this effort as being to their benefit.

ATIS and the ITU do fine and important work (and they clearly have a lot to contribute in this space in terms of requirements and operational practices, so liaisons are all good), but they have not been in the protocol engineering business for a while. For the ITU, ISDN was indeed probably the last such major effort, followed by ISDN-over-IP (aka H.323).

Henning

From: Modern <[email-masked]<mailto:[email-masked]>> on behalf of Eric Burger <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 26, 2015 at 7:54 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

SNIP

If you eliminate the geographic or access means of numbering things get simpler.  Yes as Brother Henning points out a TN is really a domain name and that is why this discussion actually is important and makes sense. IBM or Ford or Cisco could assign one single NPA to all of its employees for its business communications but you go tell citizens in Vermont Alaska or Maine PEI Yukon etc they have to dial 10 digits for all calls.

>RH: I find that the paper cited above is excellent and I would urge everybody who has a serious interest in these discussions to read it carefully.  In Switzerland, we have full geographic portability for fixed numbers (as well as portability for mobile numbers), so users have to dial 10 digits for all calls (including the leading zero, as in 022 840 1021).  The same is true in most European countries, but in some cases the number of digits in greater. Given the size of the US population (vs. the 8 million of Switzerland), it seems to me that the US should envisage moving to 12 digits, or at least 11.

The unspoken issue here is where does the initial work get done and I’m not currently convinced the IETF is the right place to do it.

OK I’ll finally say it.

The IETF has not traditionally been hospitable to the concerns of service providers. There is a reason 3GPP ETSI ATIS exist.

>RH: People who have been around a long time and who are cynical might be tempted to recall the misunderstandings between the bell-heads and the net-heads.  But I don’t think that that is relevant any  more. What is relevant is who tends to participate in which group.  As far as I know, the people who understand the concerns of service providers (and carriers) don’t typically participate in IETF. So I agree that IETF is not the right place to start this work.  But I do agree that the work should be started.  Those who wish to drive the work forward should pick an appropriate forum.

Collectively we understand that there is a problem in the US with numbering/routing  databases and that the problem is manifesting itself first in the North American market since the level of SIP/IMS deployments now far exceed anything in Europe or AsiaPac.  The PSTN Transition is no longer a idea its an inevitability.  And yes.. Contrary to everything Henry Sinnreich and other used to preach ..TN are still here and I still don’t see SIP URI’s on the side of pizza delivery cars.

Even within the FCC and the Commissioners there is some divergent views on what is actually at stake here.

http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/telecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help-it-battle-US-tech-giants.html

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 29 Jun 2015 22:50:48 +0200

Indeed we are straying afield, but I'd like to offer one clarification.

Many (maybe most, but I haven't checked) European numbering plans are
fixed-length.

I don't like variable-length numbering plans, including for the reason
mentioned by Henning below. When I'm asked for advice, I always advise
fixed-length, with a sufficient number of digits.

Best,
Richard

> Sent: lundi, 29. juin 2015 17:11
> To: Richard Hill; 'Richard Shockey'; [email-masked]
> Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering,
> * The US numbering system does have extension points that would allow
> transitioning to longer numbers, but I haven't heard anybody proposing
> this seriously. Partially, it's because the number utilization is low
> (800M out of 10B theoretically possible numbers), so while individual
> area codes continue to be split, there is no shortage of numbers as
> such, particularly as the need for prefix dialing disappears with the
> use of mobile and VoIP. (Right now, a bunch of area codes can't be
> assigned since they are short numbers, such as N11.) Most of the
> increased demand is from non-human users (think parking and water
> meters) and they generally don't care about geographic area codes. We
> can take bets as to whether the US will transition first to the metric
> system or variable-length numbers. At least a presidential candidate
> has proposed the former and there's probably more value to that
> transition.
> 
> As geographic numbering decreases somewhat in importance, due to
> mobile, I suspect that we should essentially look at numbers as either
> fixed-length (NANP) or variable-length strings, and the trade-offs
> aren't obvious. It could well be that non-human users of phone numbers
> if they ever get beyond the rather limited applications envisioned so
> far, use longer strings, just as some such applications have started to
> use non-dialable numbers (pANI).
> 
> I suspect that there are millions of places where software, from
> spreadsheets to databases and billing systems, in North America assumes
> fixed-length strings, so you're suggesting another Y2K-level effort,
> with no obvious benefit.
> 
> * The different dialing plans are a pain, but unifying them into
> permissive 10D dialing does not require changing to a European-style
> variable-length plan. They are mainly used since many people are used
> to dialing local numbers as seven digits in the NANP (just like they
> dial numbers without area codes elsewhere), but I suspect that the
> distinction between local and non-local will gradually fade as mobile
> dominates.
> 
> * We have lots of issues in MODERN, but shy service providers doesn't
> seem to be one of them... Given the additional flexibility and "cutting
> out the middle man" advantages, I would hope that they'd actually see
> this effort as being to their benefit.
> 
> ATIS and the ITU do fine and important work (and they clearly have a
> lot to contribute in this space in terms of requirements and
> operational practices, so liaisons are all good), but they have not
> been in the protocol engineering business for a while. For the ITU,
> ISDN was indeed probably the last such major effort, followed by ISDN-
> over-IP (aka H.323).
> 
> Henning
> 
> From: Modern <[email-masked]<mailto:[email-masked]>>
> on behalf of Eric Burger
> <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> simpler.  Yes as Brother Henning points out a TN is really a domain
> name and that is why this discussion actually is important and makes
> sense. IBM or Ford or Cisco could assign one single NPA to all of its
> employees for its business communications but you go tell citizens in
> Vermont Alaska or Maine PEI Yukon etc they have to dial 10 digits for
> all calls.
> 
> carefully.  In Switzerland, we have full geographic portability for
> fixed numbers (as well as portability for mobile numbers), so users
> have to dial 10 digits for all calls (including the leading zero, as in
> 022 840 1021).  The same is true in most European countries, but in
> some cases the number of digits in greater. Given the size of the US
> population (vs. the 8 million of Switzerland), it seems to me that the
> US should envisage moving to 12 digits, or at least 11.
> 
> The unspoken issue here is where does the initial work get done and I'm
> not currently convinced the IETF is the right place to do it.
> 
> OK I'll finally say it.
> 
> The IETF has not traditionally been hospitable to the concerns of
> service providers. There is a reason 3GPP ETSI ATIS exist.
> 
> >RH: People who have been around a long time and who are cynical might
> be tempted to recall the misunderstandings between the bell-heads and
> the net-heads.  But I don't think that that is relevant any  more. What
> is relevant is who tends to participate in which group.  As far as I
> know, the people who understand the concerns of service providers (and
> carriers) don't typically participate in IETF. So I agree that IETF is
> not the right place to start this work.  But I do agree that the work
> should be started.  Those who wish to drive the work forward should
> pick an appropriate forum.
> 
> first in the North American market since the level of SIP/IMS
> deployments now far exceed anything in Europe or AsiaPac.  The PSTN
> Transition is no longer a idea its an inevitability.  And yes..
> Contrary to everything Henry Sinnreich and other used to preach ..TN
> are still here and I still don't see SIP URI's on the side of pizza
> delivery cars.
> 
> http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelec
> oms/telecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-
> to-help-it-battle-US-tech-giants.html
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 29 Jun 2015 14:14:42 -0700

Tom and all,

Thanks for proposing some edits. I have reflected them with minor tweaks in the latest version of the charter — http://datatracker.ietf.org/doc/charter-ietf-modern/

The chartering of MODERN was approved on the IESG telechat last week (which I unfortunately missed since I was at the ICANN meeting). I will let these edits sit for a day before hitting the approval button.

I think the discussion that resulted from the comments relating to ITU-T SG 2 has been a useful airing at this stage in the game and a helpful reminder to everyone to make sure we keep interested parties in the loop on this one. Personally I will certainly keep that in mind as the group reaches milestones where further external review might be appropriate. But in any event we have consensus to move forward with chartering.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 29 Jun 2015 14:19:12 -0700

Hi Richard,

> working group charter to ITU-T Study Group 2 to see what they thought of it.

That is indeed the purpose of the new-work mailing list and the external review period for IETF WG charters. The message that began this thread was a response from an ITU-T SG 2 advisor. So the process is working exactly as intended.

As I noted in my other message, I’m glad the ITU-T related discussion took place at this stage. We do have a quorum of people who want to see the protocol work for this done in the IETF. Generally speaking if a bunch of folks want to come to the IETF to do a piece of protocol work that is not being done elsewhere then I see no reason to prevent that.

Alissa

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 29 Jun 2015 21:49:09 +0000

Alissa,

The internal SDO folks I rely on for learning about IETF procedures are unavailable.  Does the "consensus" reached at the "IESG telechat" that occurred last week constitute the official commissioning of the IETF MODERN working group?

The reason I ask is I wanted to formulate a response to the dozens of e-mails from over the weekend, but don't want to bother if it is now (and was?) moot.

Best regards,

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

From: Modern [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: June 29, 2015 4:15 PM
To: McGarry, Tom
Cc: [email-masked]
Subject: [Modern] charter edits

Tom and all,

Thanks for proposing some edits. I have reflected them with minor tweaks in the latest version of the charter - http://datatracker.ietf.org/doc/charter-ietf-modern/

Alissa

On Jun 25, 2015, at 3:31 PM, McGarry, Tom <[email-masked]<mailto:[email-masked]>> wrote:

Alissa

Begin forwarded message:

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Chairs:

Assigned Area Director:

Mailing list

Charter:

Milestones:

TBD

---

From: Richard Shockey <[email-masked]>
Date: Mon, 29 Jun 2015 18:00:36 -0400

This IMHO is a arbitrary move. There is not consensus.

From:  Modern <[email-masked]> on behalf of Alissa Cooper
<[email-masked]>
Date:  Monday, June 29, 2015 at 5:14 PM
To:  "McGarry, Tom" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  [Modern] charter edits

Tom and all,

Thanks for proposing some edits. I have reflected them with minor tweaks in
the latest version of the charter ‹
http://datatracker.ietf.org/doc/charter-ietf-modern/

The chartering of MODERN was approved on the IESG telechat last week (which
I unfortunately missed since I was at the ICANN meeting). I will let these
edits sit for a day before hitting the approval button.

I think the discussion that resulted from the comments relating to ITU-T SG
2 has been a useful airing at this stage in the game and a helpful reminder
to everyone to make sure we keep interested parties in the loop on this one.
Personally I will certainly keep that in mind as the group reaches
milestones where further external review might be appropriate. But in any
event we have consensus to move forward with chartering.

Alissa

On Jun 25, 2015, at 3:31 PM, McGarry, Tom <[email-masked]> wrote:

> 
> This effort is intended to create tools and solutions to enable flexibility in
> the process of managing numbers among national administrators, service and
> application providers, and consumers.  Entities can choose to use these tools
> or not.  These tools are not for the ITU-T's processes or role, nor for how
> national administrators interact with the ITU-T.  But of course we want your
> input and feedback, so thanks for sending this along.  More comments in line
> below.  
> 
> 
> Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing,
> administrator, telecom carrier, application provider, consumer, etc.; and how
> those roles could interact with each other.  This will be a baseline for what
> tools and solutions would be useful to facilitate those interactions.
>> 
>> respect to allocation and management of their country code numbering
>> resources as enshrined in Recommendation ITU-T E.164", and further instructed
>> the ITU Secretary-General and the Directors of three Bureaux
> We are aware of Resolution 133 and will certainly respect it.  I would propose
> adding the following text after the first sentence in the last full paragraph
>  "The group acknowledges ITU Plenipotentiary Conference Resolution 133 which
> recognizes the existing role and sovereignty of ITU Member States with respect
> to allocation and management of their country code numbering resources as
> enshrined in Recommendation ITU-T E.164."
>> 
> existing namespaces as part of proposed solutions.  But it's too early to say
> anything specific about that.  There is nothing in the charter that references
> .tel.  
>> 
> The IETF often has fun with creating WG names.  : )  But the charter is where
> to look for the scope of work.  The charter uses the following phrases
> TNs", "access data related to TNs", and "mechanisms for resolving information
> related to TNs".  The functions you believe were left out of the charter will
> be part of one or more of these processes.
>> 
>> 
>> Best regards,
>> 
>> Jie Zhang
>> Advisor, ITU-T SG2
>> Please send your comments to the IESG mailing list (iesg at ietf.org
>> <http://ietf.org> ) by 2015-06-22.
>> 
>> created by the working group will be flexible enough to accommodate different
>> policies for TN assignment and management, for example those established by
>> different regulatory agencies.
>>

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 30 Jun 2015 00:39:31 +0200

I don't know much about IETF procedures, but it seems to me that several of
the questions listed in 2.1 of RFC 2418 have not yet been addressed
satisfactorily.  

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: mardi, 30. juin 2015 00:01
To: Alissa Cooper; McGarry, Tom
Cc: [email-masked]
Subject: Re: [Modern] charter edits

Tom and all,

Thanks for proposing some edits. I have reflected them with minor tweaks in
the latest version of the charter -
http://datatracker.ietf.org/doc/charter-ietf-modern/

Alissa

 

 

Alissa

Begin forwarded message:

Dear Sir/Madam,

4. Regulatory issues

Best regards,

Jie Zhang
Advisor, ITU-T SG2

-----Original Message-----
From: new-work [mailto:[email-masked]] On Behalf Of The IESG
Sent: Friday, June 12, 2015 8:47 PM
To: [email-masked]
Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &

Chairs:

Assigned Area Director:

Mailing list
 Address: [email-masked]

Charter:

Milestones:

TBD

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Jun 2015 18:11:46 -0500

> This IMHO is a arbitrary move. There is not consensus.

Consensus has nothing to do with it.

You're confusing working group formation with the technical content of 
documents. Documents follow the standard of "rough consensus".

Working group formation has a rather different standard, based on 
whether there is a large enough group of qualified people willing to 
engage in the work. While this standard may have informally existed 
prior to the formation of XMPP, the precedent cemented its place in IETF 
operation at that time: the IESG stood behind a general statement that 
working group formation does not take into account the existence or 
nature of opposition to the work moving forward. In fact, the XMPP BOF 
chairs quite pointedly refused to even call the question of opposition 
-- despite clear calls to do so -- under direct orders of their 
sponsoring AD.

This precedent came into play again with the chartering of the CODEC 
working group similarly relying on the presence of willing participants, 
notwithstanding the volume and vehemence of objections from those who 
would prefer the work not happen.

The ultimate decision here resides in the hands of the IESG under the 
guidance of the sponsoring AD. This is done by evaluating the chance of 
working group success, not by measuring consensus. If you had wanted to 
stop this train, you would have had to convince the IESG that success 
would be unlikely.

But I think we're watching the caboose of that train receding rapidly 
into the distance, making the discussion somewhat moot at this point.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Jun 2015 18:19:11 -0700

I think private network case is already happening. There are more and more PBX that integrate with cloud providers such as Tropo or Twillio to get phone numbers using a simple API. I'm very happy to see modern is charted as I hope it will define a standardized API for this. The fact that right now each PBX has to code to each different non-standard API is not optimal for anyone. That applications are doing this makes a pretty compelling case that it is both possible and a desireable thing to standardize this API.

From Cisco point of view, the idea that Tropo can hand out numbers to a hot dog cart is even more exciting to Cisco than handing them out to large enterprises but both are exciting. Getting them to large enterprises reduces cost, improves user experience with easy number plans and more. Getting them to a hot dog cart enables whole new classes of innovation and applications on the internet.  The way this is happening today does not change the responsibilities of the carrier that the regulators care about but it shows how the tools modern is developing are somewhat separated from the policy in various countries. Tropo offers numbers in many countries with different regulation using the same API. 

Cullen

> On Jun 28, 2015, at 9:06 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Jun 2015 20:56:10 -0500

On 6/29/15 20:19, Cullen Jennings wrote:
> I think private network case is already happening. There are more and more PBX that integrate with cloud providers such as Tropo or Twillio to get phone numbers using a simple API.

And, really, ever since we ruled this out of scope for MARTINI, it's 
been a pretty big gap in SIP PBX deployments.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 02:00:35 +0000

Please explain the number assignment process 

Sent from my iPhone

> On Jun 29, 2015, at 9:56 PM, Adam Roach <[email-masked]> wrote:
> 
> And, really, ever since we ruled this out of scope for MARTINI, it's been a pretty big gap in SIP PBX deployments.
> 
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Jun 2015 21:16:15 -0500

In this context, there isn't one.

MARTINI was predicated on a continuation of having VISPs do 
excruciatingly manual things like emailing -- or in some cases faxing 
--  spreadsheets to their customers detailing number ranges. I think I 
still have the one I got from our VISP back in the Estacado days when I 
was running our PBX. I can dig it up and forward it to you if you really 
don't know how number assignment works at that level. Basically, it's a 
lot of human reading and human typing. If you're lucky, you don't have 
to get a fax machine involved, so you can at least copy and paste.

But emailing or faxing spreadsheets around is a brutally primitive and 
error-prone way to get this kind of thing done. I'm a little surprised 
it took this long for anyone to make a serious run at some standardized 
form of automation.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 02:24:13 +0000

How is that applicable? Scope question?

Sent from my iPhone

> On Jun 29, 2015, at 10:16 PM, Adam Roach <[email-masked]> wrote:
> 
> MARTINI was predicated on a continuation of having VISPs do excruciatingly manual things like emailing -- or in some cases faxing --  spreadsheets to their customers detailing number ranges. I think I still have the one I got from our VISP back in the Estacado days when I was running our PBX. I can dig it up and forward it to you if you really don't know how number assignment works at that level. Basically, it's a lot of human reading and human typing. If you're lucky, you don't have to get a fax machine involved, so you can at least copy and paste.
> 
> But emailing or faxing spreadsheets around is a brutally primitive and error-prone way to get this kind of thing done. I'm a little surprised it took this long for anyone to make a serious run at some standardized form of automation.
> 
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Jun 2015 22:27:28 -0500

We discussed this exact use case in Dallas. From Jon's presentation:

https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-29%2022.12.37.png?dl=0

It's also described in the charter. In fact, it's really the main thrust 
of the work: the charter repeatedly talks about acquiring, managing, and 
resolving TNs. This is the "acquring" part.

So now, as I'm reflecting on it, I'm a little confused about what *you* 
think MODERN will be doing. Perhaps whatever you're worried about isn't 
actually happening.

/a

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 29 Jun 2015 22:38:49 -0500

I have to wonder if everyone means the same thing when they say 
"managing". I.e. managing how you get TNs to a lot of 
telephone-like-clients vs managing numbering plans, assignment policy, 
etc.

On 29 Jun 2015, at 22:27, Adam Roach wrote:

> It's also described in the charter. In fact, it's really the main 
> thrust of the work: the charter repeatedly talks about acquiring, 
> managing, and resolving TNs. This is the "acquring" part.
>
> So now, as I'm reflecting on it, I'm a little confused about what 
> *you* think MODERN will be doing. Perhaps whatever you're worried 
> about isn't actually happening.
>
> /a
>
>
>>> excruciatingly manual things like emailing -- or in some cases 
>>> faxing --  spreadsheets to their customers detailing number ranges. 
>>> I think I still have the one I got from our VISP back in the 
>>> Estacado days when I was running our PBX. I can dig it up and 
>>> forward it to you if you really don't know how number assignment 
>>> works at that level. Basically, it's a lot of human reading and 
>>> human typing. If you're lucky, you don't have to get a fax machine 
>>> involved, so you can at least copy and paste.
>>>
>>> But emailing or faxing spreadsheets around is a brutally primitive 
>>> and error-prone way to get this kind of thing done. I'm a little 
>>> surprised it took this long for anyone to make a serious run at some 
>>> standardized form of automation.
>>>
>>> /a
>>>
>>>>>> I think private network case is already happening. There are more 
>>>>>> and more PBX that integrate with cloud providers such as Tropo or 
>>>>>> Twillio to get phone numbers using a simple API.
>>>>> And, really, ever since we ruled this out of scope for MARTINI, 
>>>>> it's been a pretty big gap in SIP PBX deployments.
>>>>>
>>>>> /a
>>>>>

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 30 Jun 2015 06:10:21 +0200

Dear Ben,

Thank you for this very constructive comment. I think that you may well have
identified a key concern.  In my experience, when people refer to "managing"
something (e.g. numbers or people) they usually refer to the entire business
process, including rules for how to do it, and not just to the mechanical
implementation of the rules.

The first paragraph of the charter says:

"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. Devices, applications, and  network tools increasingly need to
manage TNs, including requesting and acquiring TN delegations from
authorities. The output of the working group should make distribution,
acquisition, and management of TNs simpler for all entities involved."

The rest of the charter focuses on mechanics, but that opening paragraph
seems to me to imply that the scope of the group's work could be broader
than just mechanical implementation of existing rules.

If the idea is to "manage how you get telephone numbers", as opposed to
"managing telephone numbers", then I would suggest that the first paragraph
should read:

"The MODERN working group will define a set of Internet-based mechanisms for
the purposes of acquiring and resolving telephone numbers (TNs) in an IP
environment. Devices, applications, and  network tools increasingly need to
request and acquire TN delegations from authorities. The output of the
working group should make distribution, acquisition, and management of TNs
simpler for all entities involved."

And the title of the group might be changed to "Requesting, Acquiring,
Distributing, Exposing, and Registering telephone numbers in an IP
environment".

Best,
Richard

> From: Modern [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Tuesday, June 30, 2015 05:39
> To: Adam Roach
> Cc: [email-masked]; DOLLY, MARTIN C
> "managing". I.e. managing how you get TNs to a lot of telephone-like-
> clients vs managing numbering plans, assignment policy, etc.
> 
> 
> > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-
> 29%2022
> > .12.37.png?dl=0
> >

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 30 Jun 2015 04:57:54 +0000

I'd rather not get wrapped around a semantic axle of what "managing
telephone numbers" versus "manage how you get telephone numbers" means.
Acquisition largely is about managing how you get numbers. Various
provisioning exercises may follow after acquisition, and I think those
operations fall within the realm we typically call management. I think we
have a management area here in the IETF, it is not concerned with the
business process, say.

And well, at the risk of being blithe, I think MODERN as an backronym
befits the work better than RADER or something.

Jon Peterson
Neustar, Inc.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 10:52:24 +0000

Not exactly

Sent from my iPhone

> On Jun 29, 2015, at 11:27 PM, Adam Roach <[email-masked]> wrote:
> 
> It's also described in the charter. In fact, it's really the main thrust of the work: the charter repeatedly talks about acquiring, managing, and resolving TNs. This is the "acquring" part.
> 
> So now, as I'm reflecting on it, I'm a little confused about what *you* think MODERN will be doing. Perhaps whatever you're worried about isn't actually happening.
> 
> /a
> 
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 30 Jun 2015 08:31:36 -0500

I agree that we should not remove the word "manage", because some usages 
of that word still apply. I brought it up because I was getting the 
impression that people were talking past each other.

I do think we may already have some axle wrapping going on, though. A 
few words more clearly stating what sort of management we have in mind 
might be useful. Maybe something like "managing the distribution and 
transfer"  (at the risk of either of those also being loaded terms...)

On 29 Jun 2015, at 23:57, Peterson, Jon wrote:

>> Thank you for this very constructive comment. I think that you may 
>> well
>> have
>> "The MODERN working group will define a set of Internet-based 
>> mechanisms
>> for
>> environment. Devices, applications, and  network tools increasingly 
>> need
>> to
>> "The MODERN working group will define a set of Internet-based 
>> mechanisms
>> for
>> environment. Devices, applications, and  network tools increasingly 
>> need
>> to
>>> telephone-like-

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Jun 2015 13:50:55 +0000

One of the dangers of the noun-heavy charter languages we tend to write is that the actions get lost. In my simple view, this is partially a "mother, may I have a cookie" protocol, i.e., the supplicant asks the entity holding a pool of numbers to (temporarily) be assigned such a number. This isn't fundamentally different from the operation of EPP or, in a more remote sense, DHCP. In all of these cases, there's a separable policy function that determines whether the answer is "yes, here you are" or "no, you can't have one".

In the numbering space, we may have to worry about things that don't matter as much elsewhere, as in "I want a number from area code 212", "I want a mobile number" or "can I get my old number 212 555 1234 back?" or "I need a block of a 1000 numbers". Whether the cookie dispenser allows any of these requests from a particular entity is somebody else's problem (including the ITU and ATIS, along with NRAs).

Fundamentally, the abstract operation isn't different (except in the "who can ask and for what") whether the hot dog vendor asks their VoIP provider or Verizon asks the LNPA. However, it is unlikely that the hot dog vendor will have to fill out an NRUF, for example.

I think one of the productive exercises and where the expertise of people like Richard is particularly helpful is to identify the invariants and variations at the technical level. I'm not worried about number string lengths (any reasonable protocol will support any string of digits or symbols of any length), but more things like "can we assume an identifier for the assigned-to entity?"

I don't think we consider EPP or DHCP management protocols; they are not in the OPS area, for example.

In the "working code spirit", a small team of Columbia students is playing around with a pre-MODERN prototype; see http://e164.space for the current snapshot.

Henning

________________________________________
From: Modern [[email-masked]] on behalf of Ben Campbell [[email-masked]]
Sent: Tuesday, June 30, 2015 9:31 AM
To: Peterson, Jon
Cc: [email-masked]; Richard Hill; Adam Roach; DOLLY, MARTIN C
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 30 Jun 2015 13:50:36 +0000

First of all, Jons presentation has no status (it was one of a number of presentations made at the meeting as to a single individuals view of what might be useful); what matters is the charter. 

However what is clear to me is that we have no consensus agreement on what this group is meant to be doing or what the charter actually means. Otherwise this discussion would not be occurring.

At the simplest it appears to me that people were stating a data model where a telephone number is associated with a specific owner, and nothing more than that. 

However if you dive into various people's proposed use cases, it appears that more than that is envisaged. So for example to run any enterprise system, that telephone number would need to be assocated with various other data either:

-	in the end device itself, that controls how that telephone number fits with the functions that the end device provides, any security certificates, or relates to other identifiers in the device; and/or

-	in some server belonging to the enterprise where the end users service policy is policed, and added functionality may also be provided.

Now the first bullet above is device configuration, and the second bullet above is network management.

So I believe some people are talking as if the problem MODERN is meant to solve also includes device configuration and network management, as I have described above, and that is certainly considerably more that a simple allocation problem.

So which is it? In this new protocol, what data model will the end point of the protocol end up with? 

Keith 

> From: Modern [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 30 June 2015 04:27
> To: DOLLY, MARTIN C
> Cc: [email-masked]
> Subject: Re: [Modern] [new-work] WG Review: Managing, 
> Ordering, Distributing, Exposing, & Registering telephone 
> Numbers (modern)
> 
> It's also described in the charter. In fact, it's really the 
> main thrust of the work: the charter repeatedly talks about 
> acquiring, managing, and resolving TNs. This is the "acquring" part.
> 
> So now, as I'm reflecting on it, I'm a little confused about 
> what *you* think MODERN will be doing. Perhaps whatever 
> you're worried about isn't actually happening.
> 
> /a
> 
> 
> >> MARTINI was predicated on a continuation of having VISPs 
> do excruciatingly manual things like emailing -- or in some 
> cases faxing --  spreadsheets to their customers detailing 
> number ranges. I think I still have the one I got from our 
> VISP back in the Estacado days when I was running our PBX. I 
> can dig it up and forward it to you if you really don't know 
> how number assignment works at that level. Basically, it's a 
> lot of human reading and human typing. If you're lucky, you 
> don't have to get a fax machine involved, so you can at least 
> copy and paste.
> >>
> >> But emailing or faxing spreadsheets around is a brutally 
> primitive and error-prone way to get this kind of thing done. 
> I'm a little surprised it took this long for anyone to make a 
> serious run at some standardized form of automation.
> >>
> >> /a
> >>
> >>>>> I think private network case is already happening. 
> There are more and more PBX that integrate with cloud 
> providers such as Tropo or Twillio to get phone numbers using 
> a simple API.
> >>>> And, really, ever since we ruled this out of scope for 
> MARTINI, it's been a pretty big gap in SIP PBX deployments.
> >>>>
> >>>> /a
> >>>>

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 30 Jun 2015 15:54:16 +0200

Dear Ben,

Thank you for this.

How about the following for the first paragraph:

"The MODERN working group will define a set of Internet-based mechanisms for
the purposes of managing the acquisition and resolution of telephone numbers
(TNs) in an IP environment. Devices, applications, and network tools
increasingly need to request and acquire TN delegations from authorities.
The output of the working group should make distribution, acquisition, and
management of TNs simpler for all entities involved."

And the title could be "Managing the acquisition, ordering, distribution,
and registration of telephone numbers in an IP environment".

Best,
Richard

> Sent: Tuesday, June 30, 2015 15:32
> To: Peterson, Jon
> I agree that we should not remove the word "manage", because some
> usages of that word still apply. I brought it up because I was getting
> the impression that people were talking past each other.
> 
> > operations fall within the realm we typically call management. I
> think
> > we have a management area here in the IETF, it is not concerned with
> > the business process, say.
> >
> >> well have identified a key concern.  In my experience, when people
> >> refer to "managing"
> >> something (e.g. numbers or people) they usually refer to the entire
> >> business process, including rules for how to do it, and not just to
> >> the mechanical implementation of the rules.
> >>
> >> mechanisms for the purposes of managing and resolving telephone
> >> numbers (TNs) in an IP environment. Devices, applications, and
> >> network tools increasingly need to manage TNs, including requesting
> >> and acquiring TN delegations from authorities. The output of the
> >> working group should make distribution, acquisition, and management
> >> of TNs simpler for all entities involved."
> >>
> >> The rest of the charter focuses on mechanics, but that opening
> >> paragraph seems to me to imply that the scope of the group's work
> >> could be broader than just mechanical implementation of existing
> >> rules.
> >>
> >> If the idea is to "manage how you get telephone numbers", as opposed
> >> to "managing telephone numbers", then I would suggest that the first
> >> paragraph should read:
> >>
> >> mechanisms for the purposes of acquiring and resolving telephone
> >> numbers (TNs) in an IP environment. Devices, applications, and
> >> network tools increasingly need to request and acquire TN
> delegations
> >> from authorities. The output of the working group should make
> >> distribution, acquisition, and management of TNs simpler for all
> >> entities involved."
> >>
> >> And the title of the group might be changed to "Requesting,
> >> Acquiring, Distributing, Exposing, and Registering telephone numbers
> >> in an IP environment".
> >>
> >> Best,
> >> Richard
> >>
> >>>>>> human typing. If you're lucky, you don't have to get a fax
> >>>>>> machine involved, so you can at least copy and paste.
> >>>>>>
> I'm
> >>>>>> a little surprised it took this long for anyone to make a
> serious
> >>>>>> run at
> >>> some
> >>>>>>>>> and more PBX that integrate with cloud providers such as
> Tropo
> >>> or
> MARTINI,

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 30 Jun 2015 15:58:37 +0200

I agree with Henning's comments below (and thank him for the kind words).

But I'm not able to access the cited URL:

 http://e164.space 

It seems to be password protected.  (Pity they have adopted some of the bad
features of the ITU.)

Best,
Richard

> Sent: Tuesday, June 30, 2015 15:51
> To: Ben Campbell; Peterson, Jon
> One of the dangers of the noun-heavy charter languages we tend to write
> is that the actions get lost. In my simple view, this is partially a
> "mother, may I have a cookie" protocol, i.e., the supplicant asks the
> entity holding a pool of numbers to (temporarily) be assigned such a
> number. This isn't fundamentally different from the operation of EPP
> or, in a more remote sense, DHCP. In all of these cases, there's a
> separable policy function that determines whether the answer is "yes,
> here you are" or "no, you can't have one".
> 
> In the numbering space, we may have to worry about things that don't
> matter as much elsewhere, as in "I want a number from area code 212",
> "I want a mobile number" or "can I get my old number 212 555 1234
> back?" or "I need a block of a 1000 numbers". Whether the cookie
> dispenser allows any of these requests from a particular entity is
> somebody else's problem (including the ITU and ATIS, along with NRAs).
> 
> Fundamentally, the abstract operation isn't different (except in the
> "who can ask and for what") whether the hot dog vendor asks their VoIP
> provider or Verizon asks the LNPA. However, it is unlikely that the hot
> dog vendor will have to fill out an NRUF, for example.
> 
> I think one of the productive exercises and where the expertise of
> people like Richard is particularly helpful is to identify the
> invariants and variations at the technical level. I'm not worried about
> number string lengths (any reasonable protocol will support any string
> of digits or symbols of any length), but more things like "can we
> assume an identifier for the assigned-to entity?"
> 
> In the "working code spirit", a small team of Columbia students is
> playing around with a pre-MODERN prototype; see http://e164.space for
> the current snapshot.
> 
> Henning
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 30 Jun 2015 09:57:10 -0400

On 6/29/15, 11:11 AM, "Modern on behalf of Henning Schulzrinne"
<[email-masked] on behalf of [email-masked]> wrote:

>area codes continue to be split, there is no shortage of numbers as such,
>particularly as the need for prefix dialing disappears with the use of
>mobile and VoIP. (Right now, a bunch of area codes can't be assigned
>since they are short numbers, such as N11.) Most of the increased demand
>is from non-human users (think parking and water meters) and they
>generally don't care about geographic area codes. We can take bets as to
>whether the US will transition first to the metric system or
>variable-length numbers.

LOL !  

>At least a presidential candidate has proposed the former and there's
>probably more value to that transition.

And WhatsAPP guys etc preforming arbitrage on the SMS service. The data
does indicate US operators are actually smarter by devising a more ³One
Rate² tm like service model w/ predictable pricing that has actually lead
to higher ARPU than the EU etc.  Yes Virginia there are business models
here that can drive protocol.

>
>As geographic numbering decreases somewhat in importance, due to mobile,
>I suspect that we should essentially look at numbers as either
>fixed-length (NANP) or variable-length strings, and the trade-offs aren't
>obvious. It could well be that non-human users of phone numbers if they
>ever get beyond the rather limited applications envisioned so far, use
>longer strings, just as some such applications have started to use
>non-dialable numbers (pANI).

Right.  I do have to admit it is getting more interesting for IoT and
phone numbers.  Certainly we know some of the basic APP¹s  utility meters,
Amazon Kindle devices, cars etc but literally today I got a CPAP device
that ³phones in² my sleep data.

>fixed-length strings, so you're suggesting another Y2K-level effort, with
>no obvious benefit.
>
>variable-length plan. They are mainly used since many people are used to
>dialing local numbers as seven digits in the NANP (just like they dial
>numbers without area codes elsewhere), but I suspect that the distinction
>between local and non-local will gradually fade as mobile dominates.
>
>ATIS and the ITU do fine and important work (and they clearly have a lot
>to contribute in this space in terms of requirements and operational
>practices, so liaisons are all good), but they have not been in the
>protocol engineering business for a while. For the ITU, ISDN was indeed
>probably the last such major effort, followed by ISDN-over-IP (aka H.323).

Well at what point is this actually an open source vs a open
standards/protocol 
effort?  It strikes me the former vs that latter.

>From: Modern <[email-masked]<mailto:[email-masked]>> on
>behalf of Eric Burger
>simpler.  Yes as Brother Henning points out a TN is really a domain name
>and that is why this discussion actually is important and makes sense.
>IBM or Ford or Cisco could assign one single NPA to all of its employees
>for its business communications but you go tell citizens in Vermont
>Alaska or Maine PEI Yukon etc they have to dial 10 digits for all calls.
>
>>fixed numbers (as well as portability for mobile numbers), so users have
>>to dial 10 digits for all calls (including the leading zero, as in 022
>>840 1021).  The same is true in most European countries, but in some
>>cases the number of digits in greater. Given the size of the US
>The unspoken issue here is where does the initial work get done and I¹m
>>net-heads.  But I don¹t think that that is relevant any  more. What is
>>relevant is who tends to participate in which group.  As far as I know,
>>the people who understand the concerns of service providers (and
>>carriers) don¹t typically participate in IETF. So I agree that IETF is
>>should be started.  Those who wish to drive the work forward should pick
>>an appropriate forum.
>
>longer a idea its an inevitability.  And yes.. Contrary to everything
>Henry Sinnreich and other used to preach ..TN are still here and I still
>don¹t see SIP URI¹s on the side of pizza delivery cars.
>
>http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms
>/telecoms/11696314/BT-aims-to-shut-down-traditional-phone-network-to-help-
>it-battle-US-tech-giants.html
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 30 Jun 2015 14:39:40 +0000

IETF is about isolating a solveable problem and solving it. 

You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue. 

Keith

> Sent: 30 June 2015 03:16
> --  spreadsheets to their customers detailing number ranges. 
> forward it to you if you really don't know how number 
> assignment works at that level. Basically, it's a lot of 
> human reading and human typing. If you're lucky, you don't 
> have to get a fax machine involved, so you can at least copy 
> and paste.
> 
> >>> I think private network case is already happening. There 
> are more and more PBX that integrate with cloud providers 
> such as Tropo or Twillio to get phone numbers using a simple API.

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Jun 2015 10:15:44 -0500

> First of all, Jons presentation has no status (it was one of a number of presentations made at the meeting as to a single individuals view of what might be useful); what matters is the charter.

Of course. That's why I cited the charter in my response as well.

The reason I brought Jon's slide into it is that, even though Martin's 
responses appear to be coming from some kind of specially commissioned 
magic eight ball, he seemed to be expressing surprise that this use case 
was even on the table -- almost as if it were his first time hearing 
about it. My point was that he was in the front row in Dallas, not 20 
feet from the screen where this slide was shown.

> In this new protocol, what data model will the end point of the protocol end up with?

If we had to have a design down to the data model level before we 
chartered a working group, then the IETF would be nothing more than a 
rubber stamp factory. I understand that one could do that and still call 
oneself an SDO, but it means that the real work would be happening 
elsewhere. The IETF chooses not to operate that way, instead taking in 
problems and creating solutions.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Jun 2015 10:23:21 -0500

It's good to know that what you're worried about isn't exactly 
happening. I'm glad we could get this behind us.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 16:26:37 +0000

Adam,

If I was at the mic for every point in Jon's presentations, there would be no room for anyone else to speak :) Just because they were in Jon's slides, does not mean there was meeting consensus.

I will have to listen to the meeting again...

Henning's response to me was reasonable, numbers will not be assigned to Cisco, but a number request is given to them but the number is still assigned to the RESPONSIBLE service provider.

If Google wants to be regulated as as, please step up to the bar.

I will put my other comments on a separate thread.

Martin

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 11:16 AM
To: DRAGE, Keith (Keith); DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

The reason I brought Jon's slide into it is that, even though Martin's responses appear to be coming from some kind of specially commissioned magic eight ball, he seemed to be expressing surprise that this use case was even on the table -- almost as if it were his first time hearing about it. My point was that he was in the front row in Dallas, not 20 feet from the screen where this slide was shown.

> In this new protocol, what data model will the end point of the protocol end up with?

If we had to have a design down to the data model level before we chartered a working group, then the IETF would be nothing more than a rubber stamp factory. I understand that one could do that and still call oneself an SDO, but it means that the real work would be happening elsewhere. The IETF chooses not to operate that way, instead taking in problems and creating solutions.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Jun 2015 11:31:23 -0500

> You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue.

The MARTINI charter was silent on the issue of whether the AORs being 
registered were explicit or implicit. Making them implicit was a 
simplification, but not a necessary one. We could have been explicit 
about the AORs being registered and still been well within the charter.

My point is that this simplification left a hole in the story, and that 
MODERN's work is well positioned to fill that hole.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 16:33:33 +0000

AOR of the device? Or what?

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 12:31 PM
To: DRAGE, Keith (Keith); DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

> You make this sound like MARTINI was originally meant to solve world hunger, and somehow got scoped down, which is untrue.

The MARTINI charter was silent on the issue of whether the AORs being registered were explicit or implicit. Making them implicit was a simplification, but not a necessary one. We could have been explicit about the AORs being registered and still been well within the charter.

My point is that this simplification left a hole in the story, and that MODERN's work is well positioned to fill that hole.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 30 Jun 2015 09:41:22 -0700

> On Jun 29, 2015, at 7:00 PM, DOLLY, MARTIN C <[email-masked]> wrote:

I  think I would summarize that number assignment process as the entity wanting a number needs to provide account information to identify themselves. And credit cards are a surprising strong form of that. Then the entity asks for a number in a given area code. 

I'll use AT&T API as an example but others are similar. Some nice docs at https://developer.att.com/sdks-plugins/enhanced-webrtc

Roughly speaking the steps are:

Create and account along with things like a credit card or way to bill 

Request some phones numbers - you can specify what area codes you want

Use your account info to get a OAuth2 token that is used for rest of requests

Optionally provide some E911 info for each number 

Say where to to route incoming calls and / or  sms to

For the Tropo flow, you get a number simply by doing a HTTP post saying you want a number and country / area code you want it in to a URL that manages the addresses for your applications. You can see the doc at and it returns the new number. The application is already associated with who to bill.  More docs at https://www.tropo.com/docs/rest/tutorials/adding-number-based-prefix

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Jun 2015 11:44:04 -0500

> AOR of the device? Or what?

AORs (plural) associated with the PBX making the registration request. 
Reviewing section 4 of RFC 6140 may be illustrative.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 16:45:43 +0000

Registration request to what?

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 12:44 PM
To: DOLLY, MARTIN C; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Jun 2015 11:47:17 -0500

Section 4. RFC 6140. Read it.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 16:47:19 +0000

Providing this information to whom?

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 16:48:55 +0000

We did not support that work. This is new work, so please explain. Thank you.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 12:47 PM
To: DOLLY, MARTIN C; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Jun 2015 11:57:24 -0500

As amusing as it might be to spoon-feed you the overview sections of 
various RFCs, I'm afraid that it's neither productive nor on-topic. If 
you have legitimate questions, you have pointers for finding the answers 
yourself.

/a

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jun 2015 16:59:18 +0000

I do not believe that is in the charter of this group then.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 12:57 PM
To: DOLLY, MARTIN C; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

As amusing as it might be to spoon-feed you the overview sections of various RFCs, I'm afraid that it's neither productive nor on-topic. If you have legitimate questions, you have pointers for finding the answers yourself.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Jun 2015 17:19:28 +0000

This is not a set of documents - it's a mock-up of a distributed number allocation system (obviously, if you believe you actually obtained a number from that system you can use for anything real, I also have a bridge nearby in Brooklyn that I'm happy to sell you).

You'll need to request an account to get access to the sandbox; you get to play-act a carrier number administrator. (I know that while others dreamed as kids about being train engineers and fire fighters, members of this mailing list said in kindergarten "Dad, when I grow up, I want to assign telephone numbers.") We obviously can't just let anybody administer numbers...

(Your) feedback is appreciated.

The current mock-up model (which is a web implementation feature, not a protocol one) is that there are consumer and OCN/carrier code admins. The former get to see information only about their number (such as a porting PIN), the latter get to request numbers and update information for their OCN/carrier code.

Henning

________________________________________
From: Richard Hill [[email-masked]]
Sent: Tuesday, June 30, 2015 9:58 AM
To: Henning Schulzrinne; 'Ben Campbell'; 'Peterson, Jon'
Cc: [email-masked]; 'Adam Roach'; 'DOLLY, MARTIN C'
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

 http://e164.space

Best,
Richard

---

From: Richard Shockey <[email-masked]>
Date: Tue, 30 Jun 2015 14:00:55 -0400

Adam MARTINI was exactly the kind of problem Keith described "is about
isolating a solveable problem and solving it.²

This entire enterprise has all of the charisticts of ending world hunger
which means its deployability within the 21 Century is questionable.

On 6/30/15, 12:31 PM, "Modern on behalf of Adam Roach"
<[email-masked] on behalf of [email-masked]> wrote:

>> You make this sound like MARTINI was originally meant to solve world
>>hunger, and somehow got scoped down, which is untrue.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Jun 2015 18:40:33 +0000

[snipping a lot]

I don't see the contradiction. I think the symbiotic relationship between the two is being discussed at the IETF "plenary" level (both literally as a lunch talk in Dallas and more as "across the leadership"). Unless you just want to leave the protocol formats to whoever decides to build the first open source implementation and then everybody reverse-engineering the on-the-wire bits, there has to be a spec somewhere and I'd rather have such specs developed with the input of domain experts such as yourself and Richard or the operational input of people working for carriers.

There's an interesting article on this topic at

https://www.internetsociety.org/sites/default/files/Journal_March%202.pdf

I do believe that this work would make good material for the IETF Hackathon in the future, possibly in conjunction with some of the WebRTC work.

________________________________________
From: Richard Shockey [[email-masked]]
Sent: Tuesday, June 30, 2015 9:57 AM

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Jun 2015 18:49:30 +0000

I think of the phone number as a key into a logical (not necessarily physical) database with a variety of fields (and a change log), some that are near-universal and others that are highly-specific to countries, use cases or even companies. We do the same for domain names, e.g., technical and administrative contacts or for DHCP, where an IP address is associated with a set of service records (e.g., for a SIP proxy, LIS or LoST server in our technical neighborhood).

Much of that information exists already and is in the AT&T and Tropos APIs, the LNPA or LERG. Examples include:

* OCN/carrier code (some kind of assignment identifier is probably unavoidable)
* number state (available, locked, etc.)
* reachability (URLs)
* cryptographic keying materials

All but the first and maybe second are likely to be optional. As usual, there would be suitable extension points, e.g., to accommodate storing 911 address information that only makes sense in certain relationships (not for the LNPA, but for a carrier-customer relationship). All the usual stuff applies that the veterans in this group do by rote: IANA considerations, privacy considerations, security considerations, ...

Henning

________________________________________
From: Modern [[email-masked]] on behalf of DRAGE, Keith (Keith) [[email-masked]]
Sent: Tuesday, June 30, 2015 9:50 AM
To: Adam Roach; DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Keith

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 30 Jun 2015 20:07:56 +0000

Adam,

The IP PBX use case that Cullen Jennings documented is sensible, but also small scale, and if that was all the MODERN charter proposed to do, then there would probably be no lack of consensus (as compared to where we are in reality).

The reality is if that was all MODERN would attempt, then its leading proponents would be very dissatisfied.

Some are frustrated with the existing multi-database and multi-regulatory organizational structure of number and routing information management in carrier-based telecommunications and believe they see a possibility to bypass this situation through a protocol and data model (of a super-database?) work effort in the IETF.  Apparently this is a political and commerical matter with the emphasis on the former.

As witness to this, it has been said on this reflector that " The LNPA pain. . . . . is the transition, after a competitive bidding process, between the previous contracted number management entity and the new one. Having engineering options that bypass or minimize such disputes, should an NRA want to avail themselves of those, is one interest . . . "

I'm sympathetic to your and the other proponents' interests, but remain unconvinced of the IETF approach being invoked here through fiat.

So, while the work of MODERN is aimed to solve certain [relatively minor?] specific allocation implementation issues:
     1.  This may not represent the overwhelming interests of current or future operators; &
     2.  Specifically MODERN must consider application to the current architectures used for allocation, management, & use of E.164 resource, including LERG, NPAC, Point Code Data, and SMS800 in the US.
     3.  IETF should formally liaise with those major national & international bodies that support the allocation, administration & usage of numbering data bases including ITU, NANC, LNPA WG, INC, and the FoN; both before the WG is activated, & to help steer its work.

Best regards,

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

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: June 29, 2015 10:27 PM
To: DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

/a

---

From: Richard Shockey <[email-masked]>
Date: Tue, 30 Jun 2015 16:10:23 -0400

Fair point. 

<cynic hat on> I was thinking about the WebRTC work but at the rate that
is progressing we¹ll see the Chicago Cubs win the World Series before its
done. 

On 6/30/15, 2:40 PM, "Modern on behalf of Henning Schulzrinne"
<[email-masked] on behalf of [email-masked]> wrote:

>[snipping a lot]
>
>I don't see the contradiction. I think the symbiotic relationship between
>the two is being discussed at the IETF "plenary" level (both literally as
>a lunch talk in Dallas and more as "across the leadership"). Unless you
>just want to leave the protocol formats to whoever decides to build the
>first open source implementation and then everybody reverse-engineering
>the on-the-wire bits, there has to be a spec somewhere and I'd rather
>have such specs developed with the input of domain experts such as
>yourself and Richard or the operational input of people working for
>carriers.
>
>I do believe that this work would make good material for the IETF
>Hackathon in the future, possibly in conjunction with some of the WebRTC
>work.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Jun 2015 20:31:53 +0000

This is not a huge community - an overlapping set of people participate in all of the organizations you mention. As important as formal liaisons are the informal outreach activities that all of us participate in, whether wearing a hat of a certain color or shape, or otherwise. I've been trying to make sure INC and NANC/FON are kept in the loop and hope that others will do the same, both within their own organization (since most large carriers have representatives in those bodies) and externally.

My experience has been that concrete (strawman) proposals and questions get the most useful answers from external organizations, as long as everybody is willing to reconsider their initial notions and ideas. The sooner we can get to the gory (and boring) details, the sooner we'll make progress - or figure out that the problem is not amenable to an IETF solution.

As discussed during the FCC workshop, if the MODERN effort is successful, I suspect that legacy databases will continue to exist as interfaces, making it largely invisible to those carriers who prefer things to remain as-is.

Henning

________________________________________
From: Modern [[email-masked]] on behalf of Gorman, Pierce A [CTO] [[email-masked]]
Sent: Tuesday, June 30, 2015 4:07 PM
To: Adam Roach; DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Adam,

Best regards,

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

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: June 29, 2015 10:27 PM
To: DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

/a

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 30 Jun 2015 14:01:21 -0700

I’d like to ask that each person participating in this discussion remember to be respectful of one another’s points of view and focus on constructive dialogue. If you feel that you’re wasting cycles on the current threads then feel free to change the subject to something more productive; likewise if you feel someone else is wasting your cycles, don’t feel compelled to respond.

To review the process that got us to the current point:

The conclusion from the BoF in Dallas was that there was rough consensus in the room in support of forming the WG but that the charter and problem scope needed refinement (feel free to review the minutes: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process of refinement took place on this list over several months following the BoF. The charter was put out for review on June 12 with comments requested to be sent to the IESG by June 22. The IESG considered the two ITU-T related comments received (both after the deadline) and issued no blocking comments on the charter but asked that edits be considered on the basis of comments received. There were no other comments received or indications provided to the IESG about the readiness of this work for chartering. I’m still working on edits (Richard Hill pointed out that I missed his suggestions) and milestones are in the works as well. Thus this WG is being formed according to the usual process.

Alissa