From nobody Mon Apr 20 07:45:55 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9931E1B2E4E for ; Mon, 20 Apr 2015 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI8Z-e8zXeWv for ; Mon, 20 Apr 2015 07:45:51 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672861B2E4D for ; Mon, 20 Apr 2015 07:45:47 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t3KEj4aW029385 for ; Mon, 20 Apr 2015 10:45:46 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1tvy8a0b1g-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Apr 2015 10:45:46 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Mon, 20 Apr 2015 10:45:45 -0400 From: "McGarry, Tom" To: Modern List Thread-Topic: Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEew== Date: Mon, 20 Apr 2015 14:45:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.168.132.27] Content-Type: multipart/alternative; boundary="_000_D15A89552440Btommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7776 signatures=670574 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.19886903024747e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999691671959393 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999691671959393 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999691671959393 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504200120 Archived-At: Subject: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:45:53 -0000 --_000_D15A89552440Btommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following changes were made from the version we went over in the BoF: * The fourth paragraph defines the identifiers to be worked on as "E.16= 4 telephone numbers and telephony related identifiers" * The fourth paragraph describes the motivation as "the changing teleco= mmunications environment and interest expressed by telecommunications indus= try regulators" * The fourth paragraph acknowledges that while the work of a proposed w= orking group could be reusable for other identifiers, the work will focus o= n E.164 telephone numbers and other telephony related identifiers * The word "document" has been deleted from the list of deliverables to= allow flexibility for combining deliverables CHARTER TEXT: The MODERN working group will define a set of Internet-based mechanisms for= the purposes of managing and resolving telephone numbers (TNs) in an IP en= vironment. Existing mechanisms for these purposes face obsolescence as the= voice communications infrastructure evolves to IP technology and new appli= cations for TNs become possible. The traditional model of a TN having an a= ssociation to a single service provider and a single application is breakin= g down. Its use as a network locator is going away, but its use as an iden= tifier for an individual or an organization will remain for some time. Devi= ces, applications, and network tools increasingly need to manage TNs, inclu= ding requesting and acquiring TN delegations from authorities. The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. TNs may either b= e managed in a hierarchical tree, or in a distributed peer-to-peer architec= ture. Privacy of the enrollment data and security of the resource will be = primary considerations. Additionally, the working group will deliver a protocol mechanism for resol= ving TNs which will allow entities such as service providers, devices, and = applications to access data related to TNs, possibly including caller name = data (CNAM). Maintaining reliability, real time application performance, s= ecurity and privacy are primary considerations. The working group will tak= e into consideration existing IETF work including ENUM, SPEERMINT, and DRIN= KS. The work of this group will focus on E.164 telephone numbers and other tele= phony related identifiers due to the changing telecom environment and inter= est expressed by telecommunications industry regulators to support more fle= xible regulatory models than exist today. There is an expectation that asp= ects of the architecture and protocols defined by the working group will be= reusable for other user-focused identifiers. Extensions to the MODERN def= ined architecture and protocols can occur outside of the MODERN working gro= up, either in parallel with the MODERN working group or after the MODERN wo= rking group is complete. Solutions and mechanisms created by the working g= roup will be flexible enough to accommodate different policies, e.g., by di= fferent regulatory agencies. The work group will deliver the following: - An architecture overview, including high level requirements and sec= urity/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 informat= ion associated with enrollments - A description of mechanisms for resolving information related to TN= s --_000_D15A89552440Btommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The following changes were made from the version we went over in the B= oF:
  • The fourth paragraph defines the identifiers to be worked on as "E= .164 telephone numbers and telephony related identifiers"
  • The = fourth paragraph describes the motivation as "the changing telecommuni= cations environment and interest expressed by telecommunications industry r= egulators"
  • The fourth paragraph acknowledges that while the wo= rk of a proposed working group could be reusable for other identifiers, the= work will focus on E.164 telephone numbers and other telephony related ide= ntifiers
  • The word "document" has been deleted from the li= st of deliverables to allow flexibility for combining deliverables

    • CHARTER TEXT:

    The MODERN working group will define a set of Intern= et-based mechanisms for the purposes of managing and resolving telephone nu= mbers (TNs) in an IP environment.  Existing mechanisms for these purpo= ses face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs becom= e possible.  The traditional model of a TN having an association to a = single service provider and a single application is breaking down.  It= s use as a network locator is going away, but its use as an identifier for an individual or an organization will rem= ain for some time. Devices, applications, and network tools increasingly ne= ed to manage TNs, including requesting and acquiring TN delegations from au= thorities.

     

    The working group will define a framework for the ro= les and functions involved in managing and resolving TNs in an IP environme= nt. This includes a protocol mechanism for acquiring TNs, which will provid= e an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hiera= rchical tree, or in a distributed peer-to-peer architecture.  Privacy = of the enrollment data and security of the resource will be primary conside= rations.

     

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

     

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

     

    The work group will deliver the following:

     

    -       An architecture overview, including high level require= ments 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 con= tact information associated with enrollments

    -       A description of mechanisms for resolving information = related to TNs

    --_000_D15A89552440Btommcgarryneustarbiz_-- From nobody Wed Apr 22 18:36:00 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45171B2CF4 for ; Wed, 22 Apr 2015 18:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIogiLQ2DyYL for ; Wed, 22 Apr 2015 18:35:57 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF61B2CF1 for ; Wed, 22 Apr 2015 18:35:55 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "McGarry, Tom" , Modern List Thread-Topic: Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51Zz5sa Date: Thu, 23 Apr 2015 01:35:53 +0000 References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 01:35:59 -0000 Quick comments: "security of the resource" - unclear what "resource" refers to and what sec= urity threats we worry about. Disruption by third parties? Rogue number man= ager? We don't have to go into great detail, but I think we agree that we g= enerally assume that the managers are vetted and trusted and that any misbe= havior would be dealt with outside a protocol context. (In the US, this is = known as the FCC Enforcement Bureau - I guess you could call it the protoco= l police in this role.) More substantially, we might want to specify more precisely what privacy ri= sk we're worried about. After all, all TN managers will have access to the = enrollment data. It also isn't obvious whether enrollment data includes who= is-like information or (say) simply the OCN. I suspect that this will depen= d on national regulators and industry customs. Is the "enrollment data" the= same as the CNAM data? Right now, pretty much anyone can query CNAM for an= y number (see OpenCNAM and other API services). There is a bit of duplication between the "Additionally" paragraph and the = next one, as both seem to include resolution and mention varying design req= uirements lists. Might be crisper to wrap the list of desirables into one. This also implies that the lookup to CNAM and the unspecified resolution ar= e different, but it seems likely that there's a single query -> data operat= ion, possibly with qualifiers and differentiated data availability. "or after the MODERN" - I wouldn't preclude re-chartering after the complet= ion of the initial tasks. ________________________________ From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom [Tom.McGar= ry@neustar.biz] Sent: Monday, April 20, 2015 10:45 AM To: Modern List Subject: [Modern] Revised MODERN Charter The following changes were made from the version we went over in the BoF: * The fourth paragraph defines the identifiers to be worked on as "E.16= 4 telephone numbers and telephony related identifiers" * The fourth paragraph describes the motivation as "the changing teleco= mmunications environment and interest expressed by telecommunications indus= try regulators" * The fourth paragraph acknowledges that while the work of a proposed w= orking group could be reusable for other identifiers, the work will focus o= n E.164 telephone numbers and other telephony related identifiers * The word "document" has been deleted from the list of deliverables to= allow flexibility for combining deliverables CHARTER TEXT: The MODERN working group will define a set of Internet-based mechanisms for= the purposes of managing and resolving telephone numbers (TNs) in an IP en= vironment. Existing mechanisms for these purposes face obsolescence as the= voice communications infrastructure evolves to IP technology and new appli= cations for TNs become possible. The traditional model of a TN having an a= ssociation to a single service provider and a single application is breakin= g down. Its use as a network locator is going away, but its use as an iden= tifier for an individual or an organization will remain for some time. Devi= ces, applications, and network tools increasingly need to manage TNs, inclu= ding requesting and acquiring TN delegations from authorities. The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. TNs may either b= e managed in a hierarchical tree, or in a distributed peer-to-peer architec= ture. Privacy of the enrollment data and security of the resource will be = primary considerations. Additionally, the working group will deliver a protocol mechanism for resol= ving TNs which will allow entities such as service providers, devices, and = applications to access data related to TNs, possibly including caller name = data (CNAM). Maintaining reliability, real time application performance, s= ecurity and privacy are primary considerations. The working group will tak= e into consideration existing IETF work including ENUM, SPEERMINT, and DRIN= KS. The work of this group will focus on E.164 telephone numbers and other tele= phony related identifiers due to the changing telecom environment and inter= est expressed by telecommunications industry regulators to support more fle= xible regulatory models than exist today. There is an expectation that asp= ects of the architecture and protocols defined by the working group will be= reusable for other user-focused identifiers. Extensions to the MODERN def= ined architecture and protocols can occur outside of the MODERN working gro= up, either in parallel with the MODERN working group or after the MODERN wo= rking group is complete. Solutions and mechanisms created by the working g= roup will be flexible enough to accommodate different policies, e.g., by di= fferent regulatory agencies. The work group will deliver the following: - An architecture overview, including high level requirements and sec= urity/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 informat= ion associated with enrollments - A description of mechanisms for resolving information related to TN= s From nobody Fri Apr 24 09:01:15 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000D81A1BF2 for ; Fri, 24 Apr 2015 09:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXgdipLDZCZm for ; Fri, 24 Apr 2015 09:01:07 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14021B2F8B for ; Fri, 24 Apr 2015 09:01:07 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:56288 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ylg2L-000A0v-Lh for modern@ietf.org; Fri, 24 Apr 2015 09:01:07 -0700 Message-ID: <553A68C1.2050502@usdonovans.com> Date: Fri, 24 Apr 2015 11:01:05 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:01:14 -0000 Henning, Please see comments inline. Regards, Steve On 4/22/15 8:35 PM, Henning Schulzrinne wrote: > Quick comments: > > "security of the resource" - unclear what "resource" refers to and what security threats we worry about. Disruption by third parties? Rogue number manager? We don't have to go into great detail, but I think we agree that we generally assume that the managers are vetted and trusted and that any misbehavior would be dealt with outside a protocol context. (In the US, this is known as the FCC Enforcement Bureau - I guess you could call it the protocol police in this role.) SRD> I read it as the resource being the identifier. > > More substantially, we might want to specify more precisely what privacy risk we're worried about. After all, all TN managers will have access to the enrollment data. It also isn't obvious whether enrollment data includes whois-like information or (say) simply the OCN. I suspect that this will depend on national regulators and industry customs. Is the "enrollment data" the same as the CNAM data? Right now, pretty much anyone can query CNAM for any number (see OpenCNAM and other API services). SRD> Does this need to be specified in the charter? > > There is a bit of duplication between the "Additionally" paragraph and the next one, as both seem to include resolution and mention varying design requirements lists. Might be crisper to wrap the list of desirables into one. SRD> The second paragraph focuses on the managing aspect mentioned in the first sentence of that paragraph. The "Additionally" paragraph deals with the resolving aspect. Maybe if we make the first sentence a separate paragraph? > > This also implies that the lookup to CNAM and the unspecified resolution are different, but it seems likely that there's a single query -> data operation, possibly with qualifiers and differentiated data availability. > > "or after the MODERN" - I wouldn't preclude re-chartering after the completion of the initial tasks. SRD> How about "or after the initial MODERN working group deliverable are complete". > > ________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom [Tom.McGarry@neustar.biz] > Sent: Monday, April 20, 2015 10:45 AM > To: Modern List > Subject: [Modern] Revised MODERN Charter > > The following changes were made from the version we went over in the BoF: > > * The fourth paragraph defines the identifiers to be worked on as "E.164 telephone numbers and telephony related identifiers" > * The fourth paragraph describes the motivation as "the changing telecommunications environment and interest expressed by telecommunications industry regulators" > * The fourth paragraph acknowledges that while the work of a proposed working group could be reusable for other identifiers, the work will focus on E.164 telephone numbers and other telephony related identifiers > * The word "document" has been deleted from the list of deliverables to allow flexibility for combining deliverables > > CHARTER TEXT: > The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment. Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible. The traditional model of a TN having an association to a single service provider and a single application is breaking down. Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. > > The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the enrollment data and security of the resource will be primary considerations. > > Additionally, the working group will deliver a protocol mechanism for resolving TNs which will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS. > > The work of this group will focus on E.164 telephone numbers and other telephony related identifiers due to the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Extensions to the MODERN defined architecture and protocols can occur outside of the MODERN working group, either in parallel with the MODERN working group or after the MODERN working group is complete. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies. > > The work group will deliver the following: > > > - An architecture overview, including high level requirements and security/privacy considerations > > - A description of the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs > > - A description of protocol mechanisms for accessing contact information associated with enrollments > > - A description of mechanisms for resolving information related to TNs > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Fri Apr 24 13:12:03 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D81A1ABB for ; Fri, 24 Apr 2015 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io4hBY7FYhwZ for ; Fri, 24 Apr 2015 13:12:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74BA1A1A87 for ; Fri, 24 Apr 2015 13:11:59 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3OKBnqL054011 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 15:11:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Steve Donovan" Date: Fri, 24 Apr 2015 15:11:48 -0500 Message-ID: <11756C43-4750-4AC0-8D26-D673E1801B6C@nostrum.com> In-Reply-To: <553A68C1.2050502@usdonovans.com> References: <553A68C1.2050502@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: modern@ietf.org Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:12:02 -0000 On 24 Apr 2015, at 11:01, Steve Donovan wrote: > Henning, > > Please see comments inline. > > Regards, > > Steve > > On 4/22/15 8:35 PM, Henning Schulzrinne wrote: >> Quick comments: >> >> "security of the resource" - unclear what "resource" refers to and >> what security threats we worry about. Disruption by third parties? >> Rogue number manager? We don't have to go into great detail, but I >> think we agree that we generally assume that the managers are vetted >> and trusted and that any misbehavior would be dealt with outside a >> protocol context. (In the US, this is known as the FCC Enforcement >> Bureau - I guess you could call it the protocol police in this role.) > SRD> I read it as the resource being the identifier. >> >> More substantially, we might want to specify more precisely what >> privacy risk we're worried about. After all, all TN managers will >> have access to the enrollment data. It also isn't obvious whether >> enrollment data includes whois-like information or (say) simply the >> OCN. I suspect that this will depend on national regulators and >> industry customs. Is the "enrollment data" the same as the CNAM data? >> Right now, pretty much anyone can query CNAM for any number (see >> OpenCNAM and other API services). > SRD> Does this need to be specified in the charter? While I agree that the charter needs to talk about security and privacy, I think we may be putting the cart before the horse trying in to define what needs to be private an what needs to be secure in advance of the work. Can we word things in a way to require the working group to decide what "things" have privacy and security implications? (Likely as part of the framework.) >> >> There is a bit of duplication between the "Additionally" paragraph >> and the next one, as both seem to include resolution and mention >> varying design requirements lists. Might be crisper to wrap the list >> of desirables into one. > SRD> The second paragraph focuses on the managing aspect mentioned in > the first sentence of that paragraph. The "Additionally" paragraph > deals with the resolving aspect. Maybe if we make the first sentence > a separate paragraph? I suggest something like the following: "The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. It will also define protocol mechanisms for acquiring, [managing?], and resolving TNs. . . >> >> This also implies that the lookup to CNAM and the unspecified >> resolution are different, but it seems likely that there's a single >> query -> data operation, possibly with qualifiers and differentiated >> data availability. >> >> "or after the MODERN" - I wouldn't preclude re-chartering after the >> completion of the initial tasks. > SRD> How about "or after the initial MODERN working group deliverable > are complete". I find it odd when charters talk about rechartering--charters can _always_ be rechartered. I think the point is that these things are out of scope for _this_ charter, but we don't preclude them from being done elsewhere or in the future. >> >> ________________________________ >> From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom >> [Tom.McGarry@neustar.biz] >> Sent: Monday, April 20, 2015 10:45 AM >> To: Modern List >> Subject: [Modern] Revised MODERN Charter >> >> The following changes were made from the version we went over in the >> BoF: >> >> * The fourth paragraph defines the identifiers to be worked on as >> "E.164 telephone numbers and telephony related identifiers" >> * The fourth paragraph describes the motivation as "the changing >> telecommunications environment and interest expressed by >> telecommunications industry regulators" >> * The fourth paragraph acknowledges that while the work of a >> proposed working group could be reusable for other identifiers, the >> work will focus on E.164 telephone numbers and other telephony >> related identifiers >> * The word "document" has been deleted from the list of >> deliverables to allow flexibility for combining deliverables >> >> CHARTER TEXT: >> The MODERN working group will define a set of Internet-based >> mechanisms for the purposes of managing and resolving telephone >> numbers (TNs) in an IP environment. Existing mechanisms for these >> purposes face obsolescence as the voice communications infrastructure >> evolves to IP technology and new applications for TNs become >> possible. The traditional model of a TN having an association to a >> single service provider and a single application is breaking down. >> Its use as a network locator is going away, but its use as an >> identifier for an individual or an organization will remain for some >> time. Devices, applications, and network tools increasingly need to >> manage TNs, including requesting and acquiring TN delegations from >> authorities. >> >> The working group will define a framework for the roles and functions >> involved in managing and resolving TNs in an IP environment. This >> includes a protocol mechanism for acquiring TNs, which will provide >> an enrollment process for the individuals and entities that use and >> manage TNs. TNs may either be managed in a hierarchical tree, or in a >> distributed peer-to-peer architecture. Privacy of the enrollment >> data and security of the resource will be primary considerations. >> >> Additionally, the working group will deliver a protocol mechanism for >> resolving TNs which will allow entities such as service providers, >> devices, and applications to access data related to TNs, possibly >> including caller name data (CNAM). Maintaining reliability, real >> time application performance, security and privacy are primary >> considerations. The working group will take into consideration >> existing IETF work including ENUM, SPEERMINT, and DRINKS. >> >> The work of this group will focus on E.164 telephone numbers and >> other telephony related identifiers due to the changing telecom >> environment and interest expressed by telecommunications industry >> regulators to support more flexible regulatory models than exist >> today. There is an expectation that aspects of the architecture and >> protocols defined by the working group will be reusable for other >> user-focused identifiers. Extensions to the MODERN defined >> architecture and protocols can occur outside of the MODERN working >> group, either in parallel with the MODERN working group or after the >> MODERN working group is complete. Solutions and mechanisms created >> by the working group will be flexible enough to accommodate different >> policies, e.g., by different regulatory agencies. >> >> The work group will deliver the following: >> >> >> - An architecture overview, including high level requirements >> and security/privacy considerations >> >> - A description of the enrollment processes for existing and >> new TNs including any modifications to metadata related to those TNs >> >> - A description of protocol mechanisms for accessing contact >> information associated with enrollments >> >> - A description of mechanisms for resolving information related >> to TNs >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Fri Apr 24 13:15:10 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914271A1B88 for ; Fri, 24 Apr 2015 13:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTB5HC3asRCA for ; Fri, 24 Apr 2015 13:15:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE331A1B7F for ; Fri, 24 Apr 2015 13:15:07 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3OKEum3054241 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 15:15:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "McGarry, Tom" Date: Fri, 24 Apr 2015 15:14:56 -0500 Message-ID: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Modern List Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:15:08 -0000 On 20 Apr 2015, at 9:45, McGarry, Tom wrote: [...] > The work of this group will focus on E.164 telephone numbers and other > telephony related identifiers due to the changing telecom environment > and interest expressed by telecommunications industry regulators to > support more flexible regulatory models than exist today. Are "other telephony related identifiers" still assumed to be numbers? Or in other words, is my Skype ID in or out of scope? [...] From nobody Fri Apr 24 14:03:41 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942281AC39F for ; Fri, 24 Apr 2015 14:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAwYIpvUpz2J for ; Fri, 24 Apr 2015 14:03:38 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 041D41AC3B0 for ; Fri, 24 Apr 2015 14:03:37 -0700 (PDT) Received: (qmail 7466 invoked by uid 0); 24 Apr 2015 21:03:37 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 24 Apr 2015 21:03:37 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id KwjU1q00v1MNPNq01wjY9K; Fri, 24 Apr 2015 14:43:37 -0600 X-Authority-Analysis: v=2.1 cv=bfL4Do/B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=HpcNlDGhtQ0A:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=e9J7MTPGsLIA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8 a=RuqhIGRliY7fX58gc8sA:9 a=wPNLvfGTeEIA:10 a=rKrVYePj7rwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=ctOA5K5U8t895BIVwZovAljJqFlI+n1TucZWxmUIAcs=; b=EeCdmZOBEG1na3j9dEPqGZhbX2GSrsRKE5pTWWyVTexREAF09aiZZhLF2q5J4gtWW31Eu/q/DiFuyS8kT9+GiI5qBDdOfG3gFUi/x+qjyopZcjdONM7y23ZOl6eivFOZ; Received: from [108.56.131.201] (port=60944 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YlkRc-0004V1-Df; Fri, 24 Apr 2015 14:43:28 -0600 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Fri, 24 Apr 2015 16:43:23 -0400 From: Richard Shockey To: Ben Campbell , "McGarry, Tom" Message-ID: Thread-Topic: [Modern] Revised MODERN Charter References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> In-Reply-To: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: Modern List Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:03:39 -0000 Out hopefully=8Athat is a private proprietary namespace. On 4/24/15, 4:14 PM, "Ben Campbell" wrote: >On 20 Apr 2015, at 9:45, McGarry, Tom wrote: > >[...] > >> The work of this group will focus on E.164 telephone numbers and other >> telephony related identifiers due to the changing telecom environment >> and interest expressed by telecommunications industry regulators to >> support more flexible regulatory models than exist today. > >Are "other telephony related identifiers" still assumed to be numbers? >Or in other words, is my Skype ID in or out of scope? > >[...] > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Fri Apr 24 14:06:31 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E281AC3C7 for ; Fri, 24 Apr 2015 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XAh0Q5DbAYn for ; Fri, 24 Apr 2015 14:06:29 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id C3B401A92FC for ; Fri, 24 Apr 2015 14:06:29 -0700 (PDT) Received: (qmail 11355 invoked by uid 0); 24 Apr 2015 21:06:26 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 24 Apr 2015 21:06:26 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id KwmN1q0021MNPNq01wmRek; Fri, 24 Apr 2015 14:46:26 -0600 X-Authority-Analysis: v=2.1 cv=bfL4Do/B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=HpcNlDGhtQ0A:10 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=e9J7MTPGsLIA:10 a=wSSEduB7FGhpXoyV29cA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=vhu9EX15N2HYBIaZ7uxJhOgIVn9jmxgWS4YkeLpuOc0=; b=KOqXxob8IFYAhy39d0LKd8wsLbei9pO0TOZFb+Muunaj7/lsSOQNAgIZ6yhBwZ1jeKHC5p6UxaJyYv2WE/moWKHrurh8J/rjrFZ/IHoLzv2ix4hR/02I0iO+lBq61g/K; Received: from [108.56.131.201] (port=60945 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YlkUP-0006hM-Hu; Fri, 24 Apr 2015 14:46:21 -0600 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Fri, 24 Apr 2015 16:46:17 -0400 From: Richard Shockey To: Ben Campbell , Steve Donovan Message-ID: Thread-Topic: [Modern] Revised MODERN Charter References: <553A68C1.2050502@usdonovans.com> <11756C43-4750-4AC0-8D26-D673E1801B6C@nostrum.com> In-Reply-To: <11756C43-4750-4AC0-8D26-D673E1801B6C@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: modern@ietf.org Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:06:30 -0000 >>> >>> "or after the MODERN" - I wouldn't preclude re-chartering after the >>> completion of the initial tasks. >> SRD> How about "or after the initial MODERN working group deliverable >> are complete". > >I find it odd when charters talk about rechartering--charters can >_always_ be rechartered. I think the point is that these things are out >of scope for _this_ charter, but we don't preclude them from being done >elsewhere or in the future. > Just say what what the WG will not do is the point. >>> From nobody Fri Apr 24 14:10:04 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6FA1AC3D6 for ; Fri, 24 Apr 2015 14:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0N3LtJyfEQQ for ; Fri, 24 Apr 2015 14:10:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465CE1AC3D5 for ; Fri, 24 Apr 2015 14:10:02 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3OL9p7T058764 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 16:10:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Richard Shockey" Date: Fri, 24 Apr 2015 16:09:51 -0500 Message-ID: In-Reply-To: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:10:03 -0000 On 24 Apr 2015, at 15:43, Richard Shockey wrote: > Out hopefullyŠthat is a private proprietary namespace. Okay, so Skype IDs were a bad example--but my question was about whether the "other telephony related identifiers" were still assumed to be things that look like TNs. > > > > > On 4/24/15, 4:14 PM, "Ben Campbell" wrote: > >> On 20 Apr 2015, at 9:45, McGarry, Tom wrote: >> >> [...] >> >>> The work of this group will focus on E.164 telephone numbers and >>> other >>> telephony related identifiers due to the changing telecom >>> environment >>> and interest expressed by telecommunications industry regulators to >>> support more flexible regulatory models than exist today. >> >> Are "other telephony related identifiers" still assumed to be >> numbers? >> Or in other words, is my Skype ID in or out of scope? >> >> [...] >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern From nobody Fri Apr 24 14:13:57 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502231AC3E5 for ; Fri, 24 Apr 2015 14:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5aKuNYFNGDD for ; Fri, 24 Apr 2015 14:13:53 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 25F941AC3DF for ; Fri, 24 Apr 2015 14:13:53 -0700 (PDT) Received: (qmail 19201 invoked by uid 0); 24 Apr 2015 21:13:53 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 24 Apr 2015 21:13:53 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id Kwtk1q00c1MNPNq01wtnoD; Fri, 24 Apr 2015 14:53:53 -0600 X-Authority-Analysis: v=2.1 cv=Avp9goNP c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=HpcNlDGhtQ0A:10 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=e9J7MTPGsLIA:10 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=xRyF7I7MHQUl-L16-PQA:9 a=e3R2S0mvJP_NxlaB:21 a=5SsSfZj6aDgSzVSu:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=iE1RIkxpocaniDLUQXWeF83lRHfwKrRgEMfWCiGOg7s=; b=OP7z1DlI4dOtZ65SQp2oULrV8RtVN9rGgcQfNeouYFQ2l2KB4Kw2V+nPeufZKf5yLBD2+RLbexqA7tE7NbeYPGckqF4UV/iv/1tX7bT5R9PHd0juDt8jEVrSCFxHiD3k; Received: from [108.56.131.201] (port=60948 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YlkbY-00046R-70; Fri, 24 Apr 2015 14:53:44 -0600 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Fri, 24 Apr 2015 16:53:36 -0400 From: Richard Shockey To: Henning Schulzrinne , "McGarry, Tom" , Modern List Message-ID: Thread-Topic: [Modern] Revised MODERN Charter Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:13:55 -0000 It would be very nice to keep CNAM CNIT issues away from MODERN at this time. The first order of business in CNIT is to define what is the thing or things one queries for. There may be more than one possible data object. How that data is retrieved could be a subject for MODERN but may not be. MODERN is better focused on a generic set of protocols for the retrieval and or provisioning of E.164 data or meta data and the security mechanisms surrounding it. On 4/22/15, 9:35 PM, "Henning Schulzrinne" wrote: >Quick comments: > >"security of the resource" - unclear what "resource" refers to and what >security threats we worry about. Disruption by third parties? Rogue >number manager? We don't have to go into great detail, but I think we >agree that we generally assume that the managers are vetted and trusted >and that any misbehavior would be dealt with outside a protocol context. >(In the US, this is known as the FCC Enforcement Bureau - I guess you >could call it the protocol police in this role.) > >More substantially, we might want to specify more precisely what privacy >risk we're worried about. After all, all TN managers will have access to >the enrollment data. It also isn't obvious whether enrollment data >includes whois-like information or (say) simply the OCN. I suspect that >this will depend on national regulators and industry customs. Is the >"enrollment data" the same as the CNAM data? Right now, pretty much >anyone can query CNAM for any number (see OpenCNAM and other API >services). > >There is a bit of duplication between the "Additionally" paragraph and >the next one, as both seem to include resolution and mention varying >design requirements lists. Might be crisper to wrap the list of >desirables into one. > >This also implies that the lookup to CNAM and the unspecified resolution >are different, but it seems likely that there's a single query -> data >operation, possibly with qualifiers and differentiated data availability. > >"or after the MODERN" - I wouldn't preclude re-chartering after the >completion of the initial tasks. > >________________________________ >From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom >[Tom.McGarry@neustar.biz] >Sent: Monday, April 20, 2015 10:45 AM >To: Modern List >Subject: [Modern] Revised MODERN Charter > >The following changes were made from the version we went over in the BoF: > > * The fourth paragraph defines the identifiers to be worked on as >"E.164 telephone numbers and telephony related identifiers" > * The fourth paragraph describes the motivation as "the changing >telecommunications environment and interest expressed by >telecommunications industry regulators" > * The fourth paragraph acknowledges that while the work of a proposed >working group could be reusable for other identifiers, the work will >focus on E.164 telephone numbers and other telephony related identifiers > * The word "document" has been deleted from the list of deliverables >to allow flexibility for combining deliverables > >CHARTER TEXT: >The MODERN working group will define a set of Internet-based mechanisms >for the purposes of managing and resolving telephone numbers (TNs) in an >IP environment. Existing mechanisms for these purposes face obsolescence >as the voice communications infrastructure evolves to IP technology and >new applications for TNs become possible. The traditional model of a TN >having an association to a single service provider and a single >application is breaking down. Its use as a network locator is going >away, but its use as an identifier for an individual or an organization >will remain for some time. Devices, applications, and network tools >increasingly need to manage TNs, including requesting and acquiring TN >delegations from authorities. > >The working group will define a framework for the roles and functions >involved in managing and resolving TNs in an IP environment. This >includes a protocol mechanism for acquiring TNs, which will provide an >enrollment process for the individuals and entities that use and manage >TNs. TNs may either be managed in a hierarchical tree, or in a >distributed peer-to-peer architecture. Privacy of the enrollment data >and security of the resource will be primary considerations. > >Additionally, the working group will deliver a protocol mechanism for >resolving TNs which will allow entities such as service providers, >devices, and applications to access data related to TNs, possibly >including caller name data (CNAM). Maintaining reliability, real time >application performance, security and privacy are primary considerations. > The working group will take into consideration existing IETF work >including ENUM, SPEERMINT, and DRINKS. > >The work of this group will focus on E.164 telephone numbers and other >telephony related identifiers due to the changing telecom environment and >interest expressed by telecommunications industry regulators to support >more flexible regulatory models than exist today. There is an >expectation that aspects of the architecture and protocols defined by the >working group will be reusable for other user-focused identifiers. >Extensions to the MODERN defined architecture and protocols can occur >outside of the MODERN working group, either in parallel with the MODERN >working group or after the MODERN working group is complete. Solutions >and mechanisms created by the working group will be flexible enough to >accommodate different policies, e.g., by different regulatory agencies. > >The work group will deliver the following: > > >- An architecture overview, including high level requirements and >security/privacy considerations > >- A description of the enrollment processes for existing and new >TNs including any modifications to metadata related to those TNs > >- A description of protocol mechanisms for accessing contact >information associated with enrollments > >- A description of mechanisms for resolving information related to >TNs > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Fri Apr 24 15:00:19 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B42D1ACE13 for ; Fri, 24 Apr 2015 15:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvFe1vrVOgUm for ; Fri, 24 Apr 2015 15:00:16 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id CADAA1ACE11 for ; Fri, 24 Apr 2015 15:00:16 -0700 (PDT) Received: (qmail 9697 invoked by uid 0); 24 Apr 2015 22:00:14 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 24 Apr 2015 22:00:14 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id Kxg81q00G1MNPNq01xgB3a; Fri, 24 Apr 2015 15:40:14 -0600 X-Authority-Analysis: v=2.1 cv=Avp9goNP c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=HpcNlDGhtQ0A:10 a=CYtdG_-2rjoA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=e9J7MTPGsLIA:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8 a=_iRgRo_oFXXGA4eUZwUA:9 a=4VmKGKSqCdEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=6O3EmrdqCgct+N8R63MqHmbRbbMKF7onhvIyHOot28Q=; b=NI7wpKtVCrb0g60G9V/CzePZBa5BYaoi181XH80scBZqZ7lOo3V7PzCXlg+BMMM6jIvF6wUDmH/5b1BJDooUkeG+fiTA2QdlE59WN2ncrG1aLNuyPoV6Nr5sKiRrEmg2; Received: from [108.56.131.201] (port=61503 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YllKQ-0004LL-Os; Fri, 24 Apr 2015 15:40:08 -0600 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Fri, 24 Apr 2015 17:40:02 -0400 From: Richard Shockey To: Ben Campbell Message-ID: Thread-Topic: [Modern] Revised MODERN Charter References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="Big5" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 22:00:18 -0000 Ok like IMSI=A1=A6s certainly. Regulated namespace identifiers are certainly in scope.=20 Telephony Identifiers governed by National Regulatory Authorities etc and the meta data associated with them. On 4/24/15, 5:09 PM, "Ben Campbell" wrote: >On 24 Apr 2015, at 15:43, Richard Shockey wrote: > >> Out hopefully?that is a private proprietary namespace. > >Okay, so Skype IDs were a bad example--but my question was about whether >the "other telephony related identifiers" were still assumed to be >things that look like TNs. > >> >> >> >> >> On 4/24/15, 4:14 PM, "Ben Campbell" wrote: >> >>> On 20 Apr 2015, at 9:45, McGarry, Tom wrote: >>> >>> [...] >>> >>>> The work of this group will focus on E.164 telephone numbers and >>>> other >>>> telephony related identifiers due to the changing telecom >>>> environment >>>> and interest expressed by telecommunications industry regulators to >>>> support more flexible regulatory models than exist today. >>> >>> Are "other telephony related identifiers" still assumed to be >>> numbers? >>> Or in other words, is my Skype ID in or out of scope? >>> >>> [...] >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern From nobody Fri Apr 24 16:26:17 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5053D1A8AE5 for ; Fri, 24 Apr 2015 16:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erQuKb-jQQB5 for ; Fri, 24 Apr 2015 16:26:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E8E1A8AC3 for ; Fri, 24 Apr 2015 16:26:13 -0700 (PDT) Received: from BL2FFO11HUB030.protection.gbl (10.173.161.54) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.1.154.14; Fri, 24 Apr 2015 23:26:12 +0000 Received: from BL2FFO11OLC016.protection.gbl (10.173.160.31) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.1.154.14; Fri, 24 Apr 2015 23:26:11 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; neustar.biz; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm1.corp.sprint.com (144.230.32.80) by BL2FFO11OLC016.mail.protection.outlook.com (10.173.160.82) with Microsoft SMTP Server (TLS) id 15.1.154.14 via Frontend Transport; Fri, 24 Apr 2015 23:26:11 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3ONOCDr013304; Fri, 24 Apr 2015 19:26:10 -0400 Received: from plswe13m02.ad.sprint.com (plswe13m02.corp.sprint.com [144.229.214.21]) by preapdm1.corp.sprint.com with ESMTP id 1tyvwjg55p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2015 19:26:10 -0400 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 24 Apr 2015 18:26:09 -0500 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.1044.021; Fri, 24 Apr 2015 18:26:09 -0500 From: "Holmes, David W [CTO]" To: Richard Shockey , Ben Campbell Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQftoR2k8Akyajg0yqTM/Gb5QrX51cy5Qw Date: Fri, 24 Apr 2015 23:26:08 +0000 Message-ID: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(13464003)(189002)(51704005)(479174004)(86362001)(6806004)(93886004)(97756001)(46406003)(24736003)(2656002)(47776003)(50466002)(15975445007)(5250100002)(102836002)(92566002)(2950100001)(46102003)(62966003)(77156002)(108616004)(33646002)(106466001)(85326001)(106116001)(19580405001)(87936001)(50986999)(76176999)(5001770100001)(54356999)(23726002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB030; H:preapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB030; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB010; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:BL2FFO11HUB030; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB030; X-Forefront-PRVS: 05568D1FF7 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2015 23:26:11.2642 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB030 X-OriginatorOrg: sprint.com Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 23:26:16 -0000 Richard, I assume you are joking? E212 IMSI is NOT a good example, it is definitely out of scope (& is no bus= iness for) MODERN or IETF in general. It's a non-public-domain routing ad= dress, NOT a "telephony identifier"; if it were, then logically IP addresse= s would be also . . . OK, so it actually appears that the first order of business for MODERN shou= ld be to define what a "telephoney identifier" actually is, as part of the = charter definition? ~David Holmes / Sprint -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, April 24, 2015 2:40 PM To: Ben Campbell Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter Ok like IMSI's certainly. Regulated namespace identifiers are certainly in = scope. Telephony Identifiers governed by National Regulatory Authorities etc and t= he meta data associated with them. On 4/24/15, 5:09 PM, "Ben Campbell" wrote: >On 24 Apr 2015, at 15:43, Richard Shockey wrote: > >> Out hopefully?that is a private proprietary namespace. > >Okay, so Skype IDs were a bad example--but my question was about >whether the "other telephony related identifiers" were still assumed to >be things that look like TNs. > >> >> >> >> >> On 4/24/15, 4:14 PM, "Ben Campbell" wrote: >> >>> On 20 Apr 2015, at 9:45, McGarry, Tom wrote: >>> >>> [...] >>> >>>> The work of this group will focus on E.164 telephone numbers and >>>> other telephony related identifiers due to the changing telecom >>>> environment and interest expressed by telecommunications industry >>>> regulators to support more flexible regulatory models than exist >>>> today. >>> >>> Are "other telephony related identifiers" still assumed to be >>> numbers? >>> Or in other words, is my Skype ID in or out of scope? >>> >>> [...] >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 nobody Sat Apr 25 05:37:12 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B21A7003 for ; Sat, 25 Apr 2015 05:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxj9WgBdVmPy for ; Sat, 25 Apr 2015 05:37:09 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 58B111A7000 for ; Sat, 25 Apr 2015 05:37:07 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Ben Campbell , Richard Shockey Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5R Date: Sat, 25 Apr 2015 12:37:06 +0000 References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:37:11 -0000 I'm not sure it matters if the identifier is numeric or not, but the unifyi= ng principle seems to be that there is a clear delegation chain, within a c= onfined geographic (mostly in the legal sense, i.e., a well-known set of na= tional laws apply) scope. In particular, this implies that the entities par= ticipating can generally be assumed to be cooperative, as there is an umpir= e to remove any uncooperative players from the field.=0A= =0A= I don't think it's a priority, but SMS shortcodes seem similar enough to fi= t into the same mechanism.=0A= =0A= To avoid needless ambiguity, simply saying E.164 numbers and leaving the do= or open to other identifiers that happen to fit might work.=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com]=0A= Sent: Friday, April 24, 2015 5:09 PM=0A= To: Richard Shockey=0A= Cc: Modern List; McGarry, Tom=0A= Subject: Re: [Modern] Revised MODERN Charter=0A= =0A= On 24 Apr 2015, at 15:43, Richard Shockey wrote:=0A= =0A= > Out hopefully=8Athat is a private proprietary namespace.=0A= =0A= Okay, so Skype IDs were a bad example--but my question was about whether=0A= the "other telephony related identifiers" were still assumed to be=0A= things that look like TNs.=0A= =0A= From nobody Mon Apr 27 07:29:34 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02071A1A9B for ; Mon, 27 Apr 2015 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt9Pvcv9vuhn for ; Mon, 27 Apr 2015 07:29:32 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C335E1A1AA3 for ; Mon, 27 Apr 2015 07:29:31 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:57871 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ymk2L-0005ee-Jt for modern@ietf.org; Mon, 27 Apr 2015 07:29:30 -0700 Message-ID: <553E47C9.204@usdonovans.com> Date: Mon, 27 Apr 2015 09:29:29 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 14:29:33 -0000 SMS shortcodes were one of the reasons we left in the "other telephony related identifiers" language. I support, however, limiting the scope to E.164 numbers for the initial charter. Steve On 4/25/15 7:37 AM, Henning Schulzrinne wrote: > I'm not sure it matters if the identifier is numeric or not, but the unifying principle seems to be that there is a clear delegation chain, within a confined geographic (mostly in the legal sense, i.e., a well-known set of national laws apply) scope. In particular, this implies that the entities participating can generally be assumed to be cooperative, as there is an umpire to remove any uncooperative players from the field. > > I don't think it's a priority, but SMS shortcodes seem similar enough to fit into the same mechanism. > > To avoid needless ambiguity, simply saying E.164 numbers and leaving the door open to other identifiers that happen to fit might work. > > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com] > Sent: Friday, April 24, 2015 5:09 PM > To: Richard Shockey > Cc: Modern List; McGarry, Tom > Subject: Re: [Modern] Revised MODERN Charter > > On 24 Apr 2015, at 15:43, Richard Shockey wrote: > >> Out hopefullyŠthat is a private proprietary namespace. > Okay, so Skype IDs were a bad example--but my question was about whether > the "other telephony related identifiers" were still assumed to be > things that look like TNs. > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Mon Apr 27 07:38:33 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEEC1A1B12 for ; Mon, 27 Apr 2015 07:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p9MnAvoWBSJ for ; Mon, 27 Apr 2015 07:38:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363721A1B13 for ; Mon, 27 Apr 2015 07:37:21 -0700 (PDT) Received: from BN1BFFO11FD056.protection.gbl (10.58.144.30) by BN1BFFO11HUB053.protection.gbl (10.58.144.200) with Microsoft SMTP Server (TLS) id 15.1.154.14; Mon, 27 Apr 2015 14:37:01 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; neustar.biz; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD056.mail.protection.outlook.com (10.58.145.11) with Microsoft SMTP Server (TLS) id 15.1.154.14 via Frontend Transport; Mon, 27 Apr 2015 14:37:01 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3REYOWi023446; Mon, 27 Apr 2015 09:37:00 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm2.corp.sprint.com with ESMTP id 1u08pysje2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2015 09:37:00 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 27 Apr 2015 09:36:59 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Mon, 27 Apr 2015 09:36:59 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne , Ben Campbell , Richard Shockey Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQfstU4kycWLjRaEypfCEYVmuNDp1c9NeAgAAHZYCAAQMSAIAC2bnA Date: Mon, 27 Apr 2015 14:36:59 +0000 Message-ID: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.49] Content-Type: multipart/alternative; boundary="_000_b6d249c567b94bc1a2fe3c5793cc1925PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(448002)(199003)(13464003)(377454003)(189002)(87936001)(2656002)(19625215002)(86362001)(92566002)(108616004)(106466001)(2950100001)(2900100001)(54356999)(76176999)(50986999)(6806004)(77156002)(19580405001)(5001770100001)(19580395003)(62966003)(16236675004)(106116001)(19300405004)(84326002)(46102003)(33646002)(19617315012)(24736003)(5250100002)(15975445007)(102836002)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB053; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:BN1BFFO11HUB053; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB053; X-Forefront-PRVS: 0559FB9674 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2015 14:37:01.5661 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB053 Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 14:38:31 -0000 --_000_b6d249c567b94bc1a2fe3c5793cc1925PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable David Holmes has made the point in the past that it is important to list ou= t what are the issues or problems to be solved that drive the work effort. To David's point, what are the flaws or inadequacies of the current adminis= tration and conservation of the E.164 telephone numbers that require or ben= efit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC= , and LERG that requires MODERN to fix it? My question is aimed specifically at the section in the charter which reads= : The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: April 25, 2015 7:37 AM To: Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter I'm not sure it matters if the identifier is numeric or not, but the unifyi= ng principle seems to be that there is a clear delegation chain, within a c= onfined geographic (mostly in the legal sense, i.e., a well-known set of na= tional laws apply) scope. In particular, this implies that the entities par= ticipating can generally be assumed to be cooperative, as there is an umpir= e to remove any uncooperative players from the field. I don't think it's a priority, but SMS shortcodes seem similar enough to fi= t into the same mechanism. To avoid needless ambiguity, simply saying E.164 numbers and leaving the do= or open to other identifiers that happen to fit might work. ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com] Sent: Friday, April 24, 2015 5:09 PM To: Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter On 24 Apr 2015, at 15:43, Richard Shockey wrote: > Out hopefully=A9that is a private proprietary namespace. Okay, so Skype IDs were a bad example--but my question was about whether th= e "other telephony related identifiers" were still assumed to be things tha= t look like TNs. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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. --_000_b6d249c567b94bc1a2fe3c5793cc1925PLSWE13M08adsprintcom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

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

     

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

     

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

     

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

     

    Best regards,

     

     

    Pierce Gorman

    Core Network Planning

    O: 913-439-4368

    pierce.gorman@sprint.com

     

     

    -----Original Message-----
    From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne
    Sent: April 25, 2015 7:37 AM
    To: Ben Campbell; Richard Shockey
    Cc: Modern List; McGarry, Tom
    Subject: Re: [Modern] Revised MODERN Charter

     

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

     

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

     

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

     

    ________________________________________

    From: Modern [modern-bounces@ietf.org] on behalf = of Ben Campbell [ben@nostrum.com]

    Sent: Friday, April 24, 2015 5:09 PM

    To: Richard Shockey

    Cc: Modern List; McGarry, Tom

    Subject: Re: [Modern] Revised MODERN Charter=

     

    On 24 Apr 2015, at 15:43, Richard Shockey wrote:<= o:p>

     

    > Out hopefully=A9that is a private proprietar= y namespace.

     

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

     

     

    _______________________________________________

    Modern mailing list

    Modern@ietf.org

    https://www.i= etf.org/mailman/listinfo/modern



    This e-mail may contain Sprint proprietary information intended for the sol= e 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.
     --_000_b6d249c567b94bc1a2fe3c5793cc1925PLSWE13M08adsprintcom_-- From nobody Tue Apr 28 13:56:07 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEBF1A89F5 for ; Tue, 28 Apr 2015 13:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXIj48ZYtuCM for ; Tue, 28 Apr 2015 13:55:45 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D1F1A893A for ; Tue, 28 Apr 2015 13:53:24 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t3SKqwxe019628; Tue, 28 Apr 2015 16:53:23 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1u2e9k0a7g-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2015 16:53:23 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 28 Apr 2015 16:53:22 -0400 From: "McGarry, Tom" To: Steve Donovan Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOJJICAAbqIGw== Date: Tue, 28 Apr 2015 20:53:22 +0000 Message-ID: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , <553E47C9.204@usdonovans.com> In-Reply-To: <553E47C9.204@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-28_07:2015-04-28,2015-04-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.17554879561521e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504280230 Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 20:55:59 -0000 The other telephony related identifiers includes things like number blocks = (in the US these are called central office codes and thousands blocks) and = identifiers for service providers (I could see these taking both alpha and = numeric forms). There are identifiers for switches, points of interconnect,= trunk groups, etc. Not all of these are shared between networks (sometimes= only bilaterally) and some of these will have an analog in an IP environme= nt, some will not.=20 I was thinking it would be the job of the working group to figure out the r= elevant other identifiers. Clearly E164s are the baseline.=20 Sent from my iPhone > On Apr 27, 2015, at 10:29 AM, Steve Donovan wr= ote: >=20 > SMS shortcodes were one of the reasons we left in the "other telephony re= lated identifiers" language. >=20 > I support, however, limiting the scope to E.164 numbers for the initial c= harter. >=20 > Steve >=20 >> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >> I'm not sure it matters if the identifier is numeric or not, but the uni= fying principle seems to be that there is a clear delegation chain, within = a confined geographic (mostly in the legal sense, i.e., a well-known set of= national laws apply) scope. In particular, this implies that the entities = participating can generally be assumed to be cooperative, as there is an um= pire to remove any uncooperative players from the field. >>=20 >> I don't think it's a priority, but SMS shortcodes seem similar enough to= fit into the same mechanism. >>=20 >> To avoid needless ambiguity, simply saying E.164 numbers and leaving the= door open to other identifiers that happen to fit might work. >>=20 >> ________________________________________ >> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@no= strum.com] >> Sent: Friday, April 24, 2015 5:09 PM >> To: Richard Shockey >> Cc: Modern List; McGarry, Tom >> Subject: Re: [Modern] Revised MODERN Charter >>=20 >>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>=20 >>> Out hopefully=8Athat is a private proprietary namespace. >> Okay, so Skype IDs were a bad example--but my question was about whether >> the "other telephony related identifiers" were still assumed to be >> things that look like TNs. >>=20 >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufv= eeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastB= FXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastBF= Xs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D=20 From nobody Tue Apr 28 14:35:22 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A351A89AF for ; Tue, 28 Apr 2015 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtzJq9qDYYX2 for ; Tue, 28 Apr 2015 14:35:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A841A8998 for ; Tue, 28 Apr 2015 14:35:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3SLZ66v062196 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 16:35:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "McGarry, Tom" Date: Tue, 28 Apr 2015 16:35:06 -0500 Message-ID: <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> In-Reply-To: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:35:20 -0000 On 28 Apr 2015, at 15:53, McGarry, Tom wrote: > The other telephony related identifiers includes things like number = > blocks (in the US these are called central office codes and thousands = > blocks) and identifiers for service providers (I could see these = > taking both alpha and numeric forms). There are identifiers for = > switches, points of interconnect, trunk groups, etc. Not all of these = > are shared between networks (sometimes only bilaterally) and some of = > these will have an analog in an IP environment, some will not. > > I was thinking it would be the job of the working group to figure out = > the relevant other identifiers. Clearly E164s are the baseline. Keep in mind "scope" has been a sensitive topic so far. It seems to me = so far that the "other telephony related identifiers" is kind of a = "we'll know it when we see it" category. That's going to get pushback = during the formal review process--so it would be helpful to have a clear = definition. If that's not possible, we _might_ be able to get away with language = saying that E164s are the primary scope, but the working group may = consider other identifiers that it finds to be closely enough related. = (That needs wordsmithing.) Ben. > > Sent from my iPhone > >> On Apr 27, 2015, at 10:29 AM, Steve Donovan = >> wrote: >> >> SMS shortcodes were one of the reasons we left in the "other = >> telephony related identifiers" language. >> >> I support, however, limiting the scope to E.164 numbers for the = >> initial charter. >> >> Steve >> >>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >>> I'm not sure it matters if the identifier is numeric or not, but the = >>> unifying principle seems to be that there is a clear delegation = >>> chain, within a confined geographic (mostly in the legal sense, = >>> i.e., a well-known set of national laws apply) scope. In particular, = >>> this implies that the entities participating can generally be = >>> assumed to be cooperative, as there is an umpire to remove any = >>> uncooperative players from the field. >>> >>> I don't think it's a priority, but SMS shortcodes seem similar = >>> enough to fit into the same mechanism. >>> >>> To avoid needless ambiguity, simply saying E.164 numbers and leaving = >>> the door open to other identifiers that happen to fit might work. >>> >>> ________________________________________ >>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell = >>> [ben@nostrum.com] >>> Sent: Friday, April 24, 2015 5:09 PM >>> To: Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: Re: [Modern] Revised MODERN Charter >>> >>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>> >>>> Out hopefully=C5=A0that is a private proprietary namespace. >>> Okay, so Skype IDs were a bad example--but my question was about = >>> whether >>> the "other telephony related identifiers" were still assumed to be >>> things that look like TNs. >>> >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB= 7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF= 34PastBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7= HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF3= 4PastBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Tue Apr 28 14:56:35 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36A1A8A64 for ; Tue, 28 Apr 2015 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNEasIkKOqIO for ; Tue, 28 Apr 2015 14:56:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669ED1A8A5F for ; Tue, 28 Apr 2015 14:56:31 -0700 (PDT) Received: from BN1AFFO11FD054.protection.gbl (10.58.52.31) by BN1AFFO11HUB033.protection.gbl (10.58.52.144) with Microsoft SMTP Server (TLS) id 15.1.154.14; Tue, 28 Apr 2015 21:56:29 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm2.corp.sprint.com (144.230.32.81) by BN1AFFO11FD054.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.1.154.14 via Frontend Transport; Tue, 28 Apr 2015 21:56:29 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3SLUs0a040785; Tue, 28 Apr 2015 17:56:29 -0400 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm2.corp.sprint.com with ESMTP id 1u2f0ts274-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2015 17:56:29 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 28 Apr 2015 16:56:28 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 28 Apr 2015 16:56:27 -0500 From: "Gorman, Pierce A [CTO]" To: Ben Campbell , "McGarry, Tom" Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iu4kycWLjRaEypfCEYVmuNDp1c4sYAgAAH84CAAAdlgIAAvf5RgAOJJICAAbqIG4AAX3sA//+x1mA= Date: Tue, 28 Apr 2015 21:56:27 +0000 Message-ID: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> In-Reply-To: <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(448002)(189002)(377454003)(479174004)(51704005)(199003)(24454002)(13464003)(5250100002)(19580405001)(77156002)(85326001)(47776003)(24736003)(23676002)(62966003)(19580395003)(33646002)(5001770100001)(87936001)(2656002)(6806004)(575784001)(86362001)(46102003)(106116001)(2950100001)(54356999)(92566002)(76176999)(102836002)(15975445007)(93886004)(106466001)(50986999)(50466002)(2900100001)(108616004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB033; H:preapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB033; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:BN1AFFO11HUB033; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB033; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2015 21:56:29.9193 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB033 Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:56:34 -0000 SSBkb24ndCB1bmRlcnN0YW5kIHdoeSBFLjE2NCBpcyAiY2xlYXJseSB0aGUgYmFzZWxpbmUiLg0K DQpJJ2xsIHJlcGVhdCBteSBxdWVzdGlvbiBmcm9tIGxhc3Qgd2Vlay4NCg0KLi4ud2hhdCBhcmUg dGhlIGZsYXdzIG9yIGluYWRlcXVhY2llcyBvZiB0aGUgY3VycmVudCBhZG1pbmlzdHJhdGlvbiBh bmQgY29uc2VydmF0aW9uIG9mIHRoZSBFLjE2NCB0ZWxlcGhvbmUgbnVtYmVycyB0aGF0IHJlcXVp cmUgb3IgYmVuZWZpdCBmcm9tIGFuIElFVEYgd29yayBncm91cD8gIGkuZS4sIHdoYXQgaXMgd3Jv bmcgd2l0aCBJTkMvTkFOQy9OQU5QLCBOUEFDLCBhbmQgTEVSRyB0aGF0IHJlcXVpcmVzIE1PREVS TiB0byBmaXggaXQ/DQoNCk15IHF1ZXN0aW9uIGlzIGFpbWVkIHNwZWNpZmljYWxseSBhdCB0aGUg c2VjdGlvbiBpbiB0aGUgY2hhcnRlciB3aGljaCByZWFkczoNCg0KVGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBkZWZpbmUgYSBmcmFtZXdvcmsgZm9yIHRoZSByb2xlcyBhbmQgZnVuY3Rpb25zIGludm9s dmVkIGluIG1hbmFnaW5nIGFuZCByZXNvbHZpbmcgVE5zIGluIGFuIElQIGVudmlyb25tZW50LiBU aGlzIGluY2x1ZGVzIGEgcHJvdG9jb2wgbWVjaGFuaXNtIGZvciBhY3F1aXJpbmcgVE5zLCB3aGlj aCB3aWxsIHByb3ZpZGUgYW4gZW5yb2xsbWVudCBwcm9jZXNzIGZvciB0aGUgaW5kaXZpZHVhbHMg YW5kIGVudGl0aWVzIHRoYXQgdXNlIGFuZCBtYW5hZ2UgVE5zLg0KDQpCZXN0IHJlZ2FyZHMsDQoN Cg0KUGllcmNlIEdvcm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQpPOiA5MTMtNDM5LTQzNjgN CnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJlbiBDYW1wYmVsbA0KU2VudDogQXByaWwgMjgsIDIwMTUgNDozNSBQTQ0KVG86IE1jR2Fy cnksIFRvbQ0KQ2M6IFN0ZXZlIERvbm92YW47IG1vZGVybkBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtNb2Rlcm5dIFJldmlzZWQgTU9ERVJOIENoYXJ0ZXINCg0KT24gMjggQXByIDIwMTUsIGF0IDE1 OjUzLCBNY0dhcnJ5LCBUb20gd3JvdGU6DQoNCj4gVGhlIG90aGVyIHRlbGVwaG9ueSByZWxhdGVk IGlkZW50aWZpZXJzIGluY2x1ZGVzIHRoaW5ncyBsaWtlIG51bWJlcg0KPiBibG9ja3MgKGluIHRo ZSBVUyB0aGVzZSBhcmUgY2FsbGVkIGNlbnRyYWwgb2ZmaWNlIGNvZGVzIGFuZCB0aG91c2FuZHMN Cj4gYmxvY2tzKSBhbmQgaWRlbnRpZmllcnMgZm9yIHNlcnZpY2UgcHJvdmlkZXJzIChJIGNvdWxk IHNlZSB0aGVzZQ0KPiB0YWtpbmcgYm90aCBhbHBoYSBhbmQgbnVtZXJpYyBmb3JtcykuIFRoZXJl IGFyZSBpZGVudGlmaWVycyBmb3INCj4gc3dpdGNoZXMsIHBvaW50cyBvZiBpbnRlcmNvbm5lY3Qs IHRydW5rIGdyb3VwcywgZXRjLiBOb3QgYWxsIG9mIHRoZXNlDQo+IGFyZSBzaGFyZWQgYmV0d2Vl biBuZXR3b3JrcyAoc29tZXRpbWVzIG9ubHkgYmlsYXRlcmFsbHkpIGFuZCBzb21lIG9mDQo+IHRo ZXNlIHdpbGwgaGF2ZSBhbiBhbmFsb2cgaW4gYW4gSVAgZW52aXJvbm1lbnQsIHNvbWUgd2lsbCBu b3QuDQo+DQo+IEkgd2FzIHRoaW5raW5nIGl0IHdvdWxkIGJlIHRoZSBqb2Igb2YgdGhlIHdvcmtp bmcgZ3JvdXAgdG8gZmlndXJlIG91dA0KPiB0aGUgcmVsZXZhbnQgb3RoZXIgaWRlbnRpZmllcnMu IENsZWFybHkgRTE2NHMgYXJlIHRoZSBiYXNlbGluZS4NCg0KDQpLZWVwIGluIG1pbmQgInNjb3Bl IiBoYXMgYmVlbiBhIHNlbnNpdGl2ZSB0b3BpYyBzbyBmYXIuIEl0IHNlZW1zIHRvIG1lIHNvIGZh ciB0aGF0IHRoZSAib3RoZXIgdGVsZXBob255IHJlbGF0ZWQgaWRlbnRpZmllcnMiIGlzIGtpbmQg b2YgYSAid2UnbGwga25vdyBpdCB3aGVuIHdlIHNlZSBpdCIgY2F0ZWdvcnkuIFRoYXQncyBnb2lu ZyB0byBnZXQgcHVzaGJhY2sgZHVyaW5nIHRoZSBmb3JtYWwgcmV2aWV3IHByb2Nlc3MtLXNvIGl0 IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBhIGNsZWFyIGRlZmluaXRpb24uDQoNCklmIHRoYXQn cyBub3QgcG9zc2libGUsIHdlIF9taWdodF8gYmUgYWJsZSB0byBnZXQgYXdheSB3aXRoIGxhbmd1 YWdlIHNheWluZyB0aGF0IEUxNjRzIGFyZSB0aGUgcHJpbWFyeSBzY29wZSwgYnV0IHRoZSB3b3Jr aW5nIGdyb3VwIG1heSBjb25zaWRlciBvdGhlciBpZGVudGlmaWVycyB0aGF0IGl0IGZpbmRzIHRv IGJlIGNsb3NlbHkgZW5vdWdoIHJlbGF0ZWQuDQooVGhhdCBuZWVkcyB3b3Jkc21pdGhpbmcuKQ0K DQpCZW4uDQoNCg0KPg0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+DQo+PiBPbiBBcHIgMjcsIDIw MTUsIGF0IDEwOjI5IEFNLCBTdGV2ZSBEb25vdmFuDQo+PiA8c3Jkb25vdmFuQHVzZG9ub3ZhbnMu Y29tPiB3cm90ZToNCj4+DQo+PiBTTVMgc2hvcnRjb2RlcyB3ZXJlIG9uZSBvZiB0aGUgcmVhc29u cyB3ZSBsZWZ0IGluIHRoZSAib3RoZXINCj4+IHRlbGVwaG9ueSByZWxhdGVkIGlkZW50aWZpZXJz IiBsYW5ndWFnZS4NCj4+DQo+PiBJIHN1cHBvcnQsIGhvd2V2ZXIsIGxpbWl0aW5nIHRoZSBzY29w ZSB0byBFLjE2NCBudW1iZXJzIGZvciB0aGUNCj4+IGluaXRpYWwgY2hhcnRlci4NCj4+DQo+PiBT dGV2ZQ0KPj4NCj4+PiBPbiA0LzI1LzE1IDc6MzcgQU0sIEhlbm5pbmcgU2NodWx6cmlubmUgd3Jv dGU6DQo+Pj4gSSdtIG5vdCBzdXJlIGl0IG1hdHRlcnMgaWYgdGhlIGlkZW50aWZpZXIgaXMgbnVt ZXJpYyBvciBub3QsIGJ1dCB0aGUNCj4+PiB1bmlmeWluZyBwcmluY2lwbGUgc2VlbXMgdG8gYmUg dGhhdCB0aGVyZSBpcyBhIGNsZWFyIGRlbGVnYXRpb24NCj4+PiBjaGFpbiwgd2l0aGluIGEgY29u ZmluZWQgZ2VvZ3JhcGhpYyAobW9zdGx5IGluIHRoZSBsZWdhbCBzZW5zZSwNCj4+PiBpLmUuLCBh IHdlbGwta25vd24gc2V0IG9mIG5hdGlvbmFsIGxhd3MgYXBwbHkpIHNjb3BlLiBJbiBwYXJ0aWN1 bGFyLA0KPj4+IHRoaXMgaW1wbGllcyB0aGF0IHRoZSBlbnRpdGllcyBwYXJ0aWNpcGF0aW5nIGNh biBnZW5lcmFsbHkgYmUNCj4+PiBhc3N1bWVkIHRvIGJlIGNvb3BlcmF0aXZlLCBhcyB0aGVyZSBp cyBhbiB1bXBpcmUgdG8gcmVtb3ZlIGFueQ0KPj4+IHVuY29vcGVyYXRpdmUgcGxheWVycyBmcm9t IHRoZSBmaWVsZC4NCj4+Pg0KPj4+IEkgZG9uJ3QgdGhpbmsgaXQncyBhIHByaW9yaXR5LCBidXQg U01TIHNob3J0Y29kZXMgc2VlbSBzaW1pbGFyDQo+Pj4gZW5vdWdoIHRvIGZpdCBpbnRvIHRoZSBz YW1lIG1lY2hhbmlzbS4NCj4+Pg0KPj4+IFRvIGF2b2lkIG5lZWRsZXNzIGFtYmlndWl0eSwgc2lt cGx5IHNheWluZyBFLjE2NCBudW1iZXJzIGFuZCBsZWF2aW5nDQo+Pj4gdGhlIGRvb3Igb3BlbiB0 byBvdGhlciBpZGVudGlmaWVycyB0aGF0IGhhcHBlbiB0byBmaXQgbWlnaHQgd29yay4NCj4+Pg0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBGcm9tOiBN b2Rlcm4gW21vZGVybi1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgQmVuIENhbXBiZWxs DQo+Pj4gW2JlbkBub3N0cnVtLmNvbV0NCj4+PiBTZW50OiBGcmlkYXksIEFwcmlsIDI0LCAyMDE1 IDU6MDkgUE0NCj4+PiBUbzogUmljaGFyZCBTaG9ja2V5DQo+Pj4gQ2M6IE1vZGVybiBMaXN0OyBN Y0dhcnJ5LCBUb20NCj4+PiBTdWJqZWN0OiBSZTogW01vZGVybl0gUmV2aXNlZCBNT0RFUk4gQ2hh cnRlcg0KPj4+DQo+Pj4+IE9uIDI0IEFwciAyMDE1LCBhdCAxNTo0MywgUmljaGFyZCBTaG9ja2V5 IHdyb3RlOg0KPj4+Pg0KPj4+PiBPdXQgaG9wZWZ1bGx5xaB0aGF0IGlzIGEgcHJpdmF0ZSBwcm9w cmlldGFyeSBuYW1lc3BhY2UuDQo+Pj4gT2theSwgc28gU2t5cGUgSURzIHdlcmUgYSBiYWQgZXhh bXBsZS0tYnV0IG15IHF1ZXN0aW9uIHdhcyBhYm91dA0KPj4+IHdoZXRoZXIgdGhlICJvdGhlciB0 ZWxlcGhvbnkgcmVsYXRlZCBpZGVudGlmaWVycyIgd2VyZSBzdGlsbCBhc3N1bWVkDQo+Pj4gdG8g YmUgdGhpbmdzIHRoYXQgbG9vayBsaWtlIFROcy4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBNb2Rlcm4gbWFpbGluZyBs aXN0DQo+Pj4gTW9kZXJuQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWENCj4+PiBpbG1hbl9saXN0 aW5mb19tb2Rlcm4mZD1Bd0lGLWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JnI9NEtsbTMyaUI3 SA0KPj4+IHVmdmVlSURjTGV4dFoxb29OY2ZwMDFJWUlhVnFzT1JqSSZtPVZjU0p3ZE1obkpSWm9u Q09NbDBwbmI1ZFpuZkVQRWdpDQo+Pj4gRjM0UGFzdEJGWHMmcz1VSWZmeVZZUVdjV3RrVzZnb2FH V0ZzUjdIRll1VUxaejZuYnZscExFb01zJmU9DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE1vZGVybiBtYWlsaW5nIGxpc3QNCj4+IE1v ZGVybkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpDQo+PiBsbWFuX2xpc3RpbmZvX21vZGVybiZk PUF3SUYtZyZjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmcj00S2xtMzJpQjdIdWYNCj4+IHZlZUlE Y0xleHRaMW9vTmNmcDAxSVlJYVZxc09SakkmbT1WY1NKd2RNaG5KUlpvbkNPTWwwcG5iNWRabmZF UEVnaUYzNA0KPj4gUGFzdEJGWHMmcz1VSWZmeVZZUVdjV3RrVzZnb2FHV0ZzUjdIRll1VUxaejZu YnZscExFb01zJmU9DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IE1vZGVybiBtYWlsaW5nIGxpc3QNCj4gTW9kZXJuQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNb2Rlcm4gbWFpbGluZyBsaXN0 DQpNb2Rlcm5AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW9kZXJuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWls IG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHBy b2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0K From nobody Tue Apr 28 20:07:14 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346B61A871F for ; Tue, 28 Apr 2015 20:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j62OGpNQ54K7 for ; Tue, 28 Apr 2015 20:07:02 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E131A86F7 for ; Tue, 28 Apr 2015 20:06:58 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:62859 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnIKt-0008lN-65; Tue, 28 Apr 2015 20:06:57 -0700 Message-ID: <55404ACE.3030001@usdonovans.com> Date: Tue, 28 Apr 2015 22:06:54 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Gorman, Pierce A [CTO]" , Ben Campbell , "McGarry, Tom" References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 03:07:04 -0000 Pierce, Are you suggesting that a milestone be added to the charter to summarize the existing E.164 number management systems that exist in the world? If so, this could be made part of the first deliverable. This does not seem appropriate level of information to be included in the charter. Regards, Steve (responding as MODERN working group chair) On 4/28/15 4:56 PM, Gorman, Pierce A [CTO] wrote: > I don't understand why E.164 is "clearly the baseline". > > I'll repeat my question from last week. > > ...what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it? > > My question is aimed specifically at the section in the charter which reads: > > The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: April 28, 2015 4:35 PM > To: McGarry, Tom > Cc: Steve Donovan; modern@ietf.org > Subject: Re: [Modern] Revised MODERN Charter > > On 28 Apr 2015, at 15:53, McGarry, Tom wrote: > >> The other telephony related identifiers includes things like number >> blocks (in the US these are called central office codes and thousands >> blocks) and identifiers for service providers (I could see these >> taking both alpha and numeric forms). There are identifiers for >> switches, points of interconnect, trunk groups, etc. Not all of these >> are shared between networks (sometimes only bilaterally) and some of >> these will have an analog in an IP environment, some will not. >> >> I was thinking it would be the job of the working group to figure out >> the relevant other identifiers. Clearly E164s are the baseline. > > Keep in mind "scope" has been a sensitive topic so far. It seems to me so far that the "other telephony related identifiers" is kind of a "we'll know it when we see it" category. That's going to get pushback during the formal review process--so it would be helpful to have a clear definition. > > If that's not possible, we _might_ be able to get away with language saying that E164s are the primary scope, but the working group may consider other identifiers that it finds to be closely enough related. > (That needs wordsmithing.) > > Ben. > > >> Sent from my iPhone >> >>> On Apr 27, 2015, at 10:29 AM, Steve Donovan >>> wrote: >>> >>> SMS shortcodes were one of the reasons we left in the "other >>> telephony related identifiers" language. >>> >>> I support, however, limiting the scope to E.164 numbers for the >>> initial charter. >>> >>> Steve >>> >>>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >>>> I'm not sure it matters if the identifier is numeric or not, but the >>>> unifying principle seems to be that there is a clear delegation >>>> chain, within a confined geographic (mostly in the legal sense, >>>> i.e., a well-known set of national laws apply) scope. In particular, >>>> this implies that the entities participating can generally be >>>> assumed to be cooperative, as there is an umpire to remove any >>>> uncooperative players from the field. >>>> >>>> I don't think it's a priority, but SMS shortcodes seem similar >>>> enough to fit into the same mechanism. >>>> >>>> To avoid needless ambiguity, simply saying E.164 numbers and leaving >>>> the door open to other identifiers that happen to fit might work. >>>> >>>> ________________________________________ >>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell >>>> [ben@nostrum.com] >>>> Sent: Friday, April 24, 2015 5:09 PM >>>> To: Richard Shockey >>>> Cc: Modern List; McGarry, Tom >>>> Subject: Re: [Modern] Revised MODERN Charter >>>> >>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>>> >>>>> Out hopefullyÅ that is a private proprietary namespace. >>>> Okay, so Skype IDs were a bad example--but my question was about >>>> whether the "other telephony related identifiers" were still assumed >>>> to be things that look like TNs. >>>> >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>>> ilman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7H >>>> ufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgi >>>> F34PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e= >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai >>> lman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7Huf >>> veeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34 >>> PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e= >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > Modern mailing list > Modern@ietf.org > 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 nobody Tue Apr 28 20:42:48 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D311A906C for ; Tue, 28 Apr 2015 20:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE9F7bLbESuV for ; Tue, 28 Apr 2015 20:42:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054F71A8A15 for ; Tue, 28 Apr 2015 20:42:43 -0700 (PDT) Received: from BN1BFFO11FD036.protection.gbl (10.58.144.31) by BN1BFFO11HUB048.protection.gbl (10.58.144.195) with Microsoft SMTP Server (TLS) id 15.1.154.14; Wed, 29 Apr 2015 03:42:27 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1BFFO11FD036.mail.protection.outlook.com (10.58.144.99) with Microsoft SMTP Server (TLS) id 15.1.154.14 via Frontend Transport; Wed, 29 Apr 2015 03:42:27 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3T36qw6038998; Tue, 28 Apr 2015 22:42:26 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm1.corp.sprint.com with ESMTP id 1u08ja0bv4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2015 22:42:26 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 28 Apr 2015 23:42:25 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 28 Apr 2015 22:42:24 -0500 From: "Gorman, Pierce A [CTO]" To: Steve Donovan Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iu4kycWLjRaEypfCEYVmuNDp1c4sYAgAAH84CAAAdlgIAAvf5RgAOJJICAAbqIG4AAX3sA//+x1mCAAKreAP//tho9 Date: Wed, 29 Apr 2015 03:42:24 +0000 Message-ID: <3E62019B-6CDA-4FBB-9B00-1C790256A67D@sprint.com> References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> , <55404ACE.3030001@usdonovans.com> In-Reply-To: <55404ACE.3030001@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(24454002)(199003)(51704005)(377454003)(189002)(479174004)(50466002)(54356999)(86362001)(82746002)(85326001)(83716003)(23746002)(76176999)(50986999)(110136001)(5250100002)(575784001)(6806004)(2656002)(47776003)(19580395003)(19580405001)(106466001)(106116001)(87936001)(33656002)(36756003)(46102003)(77156002)(92566002)(62966003)(93886004)(2900100001)(2950100001)(15975445007)(5001960100001)(102836002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB048; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB048; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB048; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB048; X-Forefront-PRVS: 05610E64EE X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2015 03:42:27.2450 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB048 Archived-At: Cc: Ben Campbell , "modern@ietf.org" , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 03:42:47 -0000 Nope. I'm suggesting you elaborate on why you think MODERN ought to be eng= aged in developing a framework for managing telephone numbers. What are the problems you want MODERN to solve based on the framework you'r= e proposing MODERN ought to develop? Sent from my iPad > On Apr 28, 2015, at 10:07 PM, Steve Donovan wr= ote: > > Pierce, > > Are you suggesting that a milestone be added to the charter to summarize = the existing E.164 number management systems that exist in the world? > > If so, this could be made part of the first deliverable. > > This does not seem appropriate level of information to be included in the= charter. > > Regards, > > Steve (responding as MODERN working group chair) > >> On 4/28/15 4:56 PM, Gorman, Pierce A [CTO] wrote: >> I don't understand why E.164 is "clearly the baseline". >> >> I'll repeat my question from last week. >> >> ...what are the flaws or inadequacies of the current administration and = conservation of the E.164 telephone numbers that require or benefit from an= IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG t= hat requires MODERN to fix it? >> >> My question is aimed specifically at the section in the charter which re= ads: >> >> The working group will define a framework for the roles and functions in= volved in managing and resolving TNs in an IP environment. This includes a = protocol mechanism for acquiring TNs, which will provide an enrollment proc= ess for the individuals and entities that use and manage TNs. >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: April 28, 2015 4:35 PM >> To: McGarry, Tom >> Cc: Steve Donovan; modern@ietf.org >> Subject: Re: [Modern] Revised MODERN Charter >> >>> On 28 Apr 2015, at 15:53, McGarry, Tom wrote: >>> >>> The other telephony related identifiers includes things like number >>> blocks (in the US these are called central office codes and thousands >>> blocks) and identifiers for service providers (I could see these >>> taking both alpha and numeric forms). There are identifiers for >>> switches, points of interconnect, trunk groups, etc. Not all of these >>> are shared between networks (sometimes only bilaterally) and some of >>> these will have an analog in an IP environment, some will not. >>> >>> I was thinking it would be the job of the working group to figure out >>> the relevant other identifiers. Clearly E164s are the baseline. >> >> Keep in mind "scope" has been a sensitive topic so far. It seems to me s= o far that the "other telephony related identifiers" is kind of a "we'll kn= ow it when we see it" category. That's going to get pushback during the for= mal review process--so it would be helpful to have a clear definition. >> >> If that's not possible, we _might_ be able to get away with language say= ing that E164s are the primary scope, but the working group may consider ot= her identifiers that it finds to be closely enough related. >> (That needs wordsmithing.) >> >> Ben. >> >> >>> Sent from my iPhone >>> >>>> On Apr 27, 2015, at 10:29 AM, Steve Donovan >>>> wrote: >>>> >>>> SMS shortcodes were one of the reasons we left in the "other >>>> telephony related identifiers" language. >>>> >>>> I support, however, limiting the scope to E.164 numbers for the >>>> initial charter. >>>> >>>> Steve >>>> >>>>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >>>>> I'm not sure it matters if the identifier is numeric or not, but the >>>>> unifying principle seems to be that there is a clear delegation >>>>> chain, within a confined geographic (mostly in the legal sense, >>>>> i.e., a well-known set of national laws apply) scope. In particular, >>>>> this implies that the entities participating can generally be >>>>> assumed to be cooperative, as there is an umpire to remove any >>>>> uncooperative players from the field. >>>>> >>>>> I don't think it's a priority, but SMS shortcodes seem similar >>>>> enough to fit into the same mechanism. >>>>> >>>>> To avoid needless ambiguity, simply saying E.164 numbers and leaving >>>>> the door open to other identifiers that happen to fit might work. >>>>> >>>>> ________________________________________ >>>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell >>>>> [ben@nostrum.com] >>>>> Sent: Friday, April 24, 2015 5:09 PM >>>>> To: Richard Shockey >>>>> Cc: Modern List; McGarry, Tom >>>>> Subject: Re: [Modern] Revised MODERN Charter >>>>> >>>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>>>> >>>>>> Out hopefully=8Athat is a private proprietary namespace. >>>>> Okay, so Skype IDs were a bad example--but my question was about >>>>> whether the "other telephony related identifiers" were still assumed >>>>> to be things that look like TNs. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= a >>>>> ilman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm3= 2iB7H >>>>> ufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEg= i >>>>> F34PastBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= i >>>> lman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32i= B7Huf >>>> veeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF3= 4 >>>> PastBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> 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 n= ot the intended recipient, please contact the sender and delete all copies = of the message. > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 nobody Wed Apr 29 04:26:24 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8C1B2C32 for ; Wed, 29 Apr 2015 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7qgQMbOzke0 for ; Wed, 29 Apr 2015 04:26:20 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id F254B1A8752 for ; Wed, 29 Apr 2015 04:26:19 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Ben Campbell , "McGarry, Tom" Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOJJICAAbqIG4AATrcAgACjhgk= Date: Wed, 29 Apr 2015 11:26:17 +0000 References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> , <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> In-Reply-To: <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 11:26:22 -0000 My suspicion is that whatever we develop will work for just about any uniqu= e identifier, but the E.164 space offers more challenging requirements comp= ared to the slowly-changing namespaces mentioned below. There are likely 3-= 4 orders of magnitude more entries, some of the data is more privacy sensit= ive (see CNAM), the number of entities interacting with the data is substan= tial (may not just be traditional carriers), there may be more of a need fo= r distributed allocation, and the transaction rate is much higher and incl= udes interactions among entities that don't necessarily fully "like" each o= ther (gaining and losing providers, say).=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com]=0A= Sent: Tuesday, April 28, 2015 5:35 PM=0A= To: McGarry, Tom=0A= Cc: Steve Donovan; modern@ietf.org=0A= Subject: Re: [Modern] Revised MODERN Charter=0A= =0A= On 28 Apr 2015, at 15:53, McGarry, Tom wrote:=0A= =0A= > The other telephony related identifiers includes things like number=0A= > blocks (in the US these are called central office codes and thousands=0A= > blocks) and identifiers for service providers (I could see these=0A= > taking both alpha and numeric forms). There are identifiers for=0A= > switches, points of interconnect, trunk groups, etc. Not all of these=0A= > are shared between networks (sometimes only bilaterally) and some of=0A= > these will have an analog in an IP environment, some will not.=0A= >=0A= > I was thinking it would be the job of the working group to figure out=0A= > the relevant other identifiers. Clearly E164s are the baseline.=0A= =0A= =0A= Keep in mind "scope" has been a sensitive topic so far. It seems to me=0A= so far that the "other telephony related identifiers" is kind of a=0A= "we'll know it when we see it" category. That's going to get pushback=0A= during the formal review process--so it would be helpful to have a clear=0A= definition.=0A= =0A= If that's not possible, we _might_ be able to get away with language=0A= saying that E164s are the primary scope, but the working group may=0A= consider other identifiers that it finds to be closely enough related.=0A= (That needs wordsmithing.)=0A= =0A= Ben.=0A= =0A= =0A= >=0A= > Sent from my iPhone=0A= >=0A= >> On Apr 27, 2015, at 10:29 AM, Steve Donovan=0A= >> wrote:=0A= >>=0A= >> SMS shortcodes were one of the reasons we left in the "other=0A= >> telephony related identifiers" language.=0A= >>=0A= >> I support, however, limiting the scope to E.164 numbers for the=0A= >> initial charter.=0A= >>=0A= >> Steve=0A= >>=0A= >>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote:=0A= >>> I'm not sure it matters if the identifier is numeric or not, but the=0A= >>> unifying principle seems to be that there is a clear delegation=0A= >>> chain, within a confined geographic (mostly in the legal sense,=0A= >>> i.e., a well-known set of national laws apply) scope. In particular,=0A= >>> this implies that the entities participating can generally be=0A= >>> assumed to be cooperative, as there is an umpire to remove any=0A= >>> uncooperative players from the field.=0A= >>>=0A= >>> I don't think it's a priority, but SMS shortcodes seem similar=0A= >>> enough to fit into the same mechanism.=0A= >>>=0A= >>> To avoid needless ambiguity, simply saying E.164 numbers and leaving=0A= >>> the door open to other identifiers that happen to fit might work.=0A= >>>=0A= >>> ________________________________________=0A= >>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell=0A= >>> [ben@nostrum.com]=0A= >>> Sent: Friday, April 24, 2015 5:09 PM=0A= >>> To: Richard Shockey=0A= >>> Cc: Modern List; McGarry, Tom=0A= >>> Subject: Re: [Modern] Revised MODERN Charter=0A= >>>=0A= >>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote:=0A= >>>>=0A= >>>> Out hopefully=8Athat is a private proprietary namespace.=0A= >>> Okay, so Skype IDs were a bad example--but my question was about=0A= >>> whether=0A= >>> the "other telephony related identifiers" were still assumed to be=0A= >>> things that look like TNs.=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> Modern mailing list=0A= >>> Modern@ietf.org=0A= >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Huf= veeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34Past= BFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D=0A= >>=0A= >> _______________________________________________=0A= >> Modern mailing list=0A= >> Modern@ietf.org=0A= >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufv= eeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastB= FXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D=0A= >=0A= > _______________________________________________=0A= > Modern mailing list=0A= > Modern@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/modern=0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= From nobody Wed Apr 29 04:38:06 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658021B2C4E for ; Wed, 29 Apr 2015 04:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL-QvYaGpyMN for ; Wed, 29 Apr 2015 04:38:02 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 797A11B2C4D for ; Wed, 29 Apr 2015 04:38:02 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" , Ben Campbell , Richard Shockey Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOLPICAAq06ow== Date: Wed, 29 Apr 2015 11:38:01 +0000 References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 11:38:05 -0000 Pierce, since you and your organization probably have first-hand experience with th= e existing system, particularly as you transition to all-IP, I'd be very in= terested in hearing what you see as deficiencies or problems. My general take is that just about anything can be made to work ("with enou= gh thrust, pigs can fly"), but that I suspect nobody would design a new sys= tem to replicate what has evolved over decades. I'm not sure the charter ha= s to spell out every problem in detail, but a general motivation seems usef= ul. My general notions are: - lack of flexibility (e.g., difficult to add fields without a very elabora= te and lengthy process typically spanning years) - lack of distribution (hard or impossible to have more than one administra= tor for each database) - complexity (we hear a fair amount about rural call completion problems wh= ich aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and p= orting mechanisms Henning ________________________________ From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] Sent: Monday, April 27, 2015 10:36 AM To: Henning Schulzrinne; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter David Holmes has made the point in the past that it is important to list ou= t what are the issues or problems to be solved that drive the work effort. To David=92s point, what are the flaws or inadequacies of the current admin= istration and conservation of the E.164 telephone numbers that require or b= enefit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NP= AC, and LERG that requires MODERN to fix it? My question is aimed specifically at the section in the charter which reads= : The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: April 25, 2015 7:37 AM To: Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter I'm not sure it matters if the identifier is numeric or not, but the unifyi= ng principle seems to be that there is a clear delegation chain, within a c= onfined geographic (mostly in the legal sense, i.e., a well-known set of na= tional laws apply) scope. In particular, this implies that the entities par= ticipating can generally be assumed to be cooperative, as there is an umpir= e to remove any uncooperative players from the field. I don't think it's a priority, but SMS shortcodes seem similar enough to fi= t into the same mechanism. To avoid needless ambiguity, simply saying E.164 numbers and leaving the do= or open to other identifiers that happen to fit might work. ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com] Sent: Friday, April 24, 2015 5:09 PM To: Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter On 24 Apr 2015, at 15:43, Richard Shockey wrote: > Out hopefully=8Athat is a private proprietary namespace. Okay, so Skype IDs were a bad example--but my question was about whether th= e "other telephony related identifiers" were still assumed to be things tha= t look like TNs. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 nobody Wed Apr 29 05:30:38 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614161B2C60 for ; Wed, 29 Apr 2015 05:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3IRQthOdEYo for ; Wed, 29 Apr 2015 05:30:34 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9A81B2C5F for ; Wed, 29 Apr 2015 05:30:34 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:63495 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnR8I-0000SG-GZ for modern@ietf.org; Wed, 29 Apr 2015 05:30:32 -0700 Message-ID: <5540CEE5.5070103@usdonovans.com> Date: Wed, 29 Apr 2015 07:30:29 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <553A68C1.2050502@usdonovans.com> <11756C43-4750-4AC0-8D26-D673E1801B6C@nostrum.com> In-Reply-To: <11756C43-4750-4AC0-8D26-D673E1801B6C@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 12:30:36 -0000 Based on Ben's suggestions below, I've propose the following changes to the relevant paragraphs. Steve On 4/24/15 3:11 PM, Ben Campbell wrote: > On 24 Apr 2015, at 11:01, Steve Donovan wrote: > >> Henning, >> >> Please see comments inline. >> >> Regards, >> >> Steve >> >> On 4/22/15 8:35 PM, Henning Schulzrinne wrote: >>> Quick comments: >>> >>> "security of the resource" - unclear what "resource" refers to and >>> what security threats we worry about. Disruption by third parties? >>> Rogue number manager? We don't have to go into great detail, but I >>> think we agree that we generally assume that the managers are vetted >>> and trusted and that any misbehavior would be dealt with outside a >>> protocol context. (In the US, this is known as the FCC Enforcement >>> Bureau - I guess you could call it the protocol police in this role.) >> SRD> I read it as the resource being the identifier. >>> >>> More substantially, we might want to specify more precisely what >>> privacy risk we're worried about. After all, all TN managers will >>> have access to the enrollment data. It also isn't obvious whether >>> enrollment data includes whois-like information or (say) simply the >>> OCN. I suspect that this will depend on national regulators and >>> industry customs. Is the "enrollment data" the same as the CNAM >>> data? Right now, pretty much anyone can query CNAM for any number >>> (see OpenCNAM and other API services). >> SRD> Does this need to be specified in the charter? > > While I agree that the charter needs to talk about security and > privacy, I think we may be putting the cart before the horse trying in > to define what needs to be private an what needs to be secure in > advance of the work. Can we word things in a way to require the > working group to decide what "things" have privacy and security > implications? (Likely as part of the framework.) SRD> The architecture overview document already calls out the need to address security and privacy considerations. Is that sufficient? >>> >>> There is a bit of duplication between the "Additionally" paragraph >>> and the next one, as both seem to include resolution and mention >>> varying design requirements lists. Might be crisper to wrap the list >>> of desirables into one. >> SRD> The second paragraph focuses on the managing aspect mentioned in >> the first sentence of that paragraph. The "Additionally" paragraph >> deals with the resolving aspect. Maybe if we make the first sentence >> a separate paragraph? > > I suggest something like the following: > > "The working group will define a framework for the roles and functions > involved in managing and resolving TNs in an IP environment. It will > also define protocol mechanisms for acquiring, [managing?], and > resolving TNs. . about resolution mechanism>. SRD> I've added the wording Ben suggested and combined the paragraphs as follows: "The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. It will also define protocol mechanisms for acquiring and resolving TNs. The protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the enrollment data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs which will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS." > > >>> >>> This also implies that the lookup to CNAM and the unspecified >>> resolution are different, but it seems likely that there's a single >>> query -> data operation, possibly with qualifiers and differentiated >>> data availability. >>> >>> "or after the MODERN" - I wouldn't preclude re-chartering after the >>> completion of the initial tasks. >> SRD> How about "or after the initial MODERN working group >> deliverable are complete". > > I find it odd when charters talk about rechartering--charters can > _always_ be rechartered. I think the point is that these things are > out of scope for _this_ charter, but we don't preclude them from being > done elsewhere or in the future. SRD> Taking Richard's suggestion, I propose the following for this paragraph (note: the wording on "other telephony identifiers" will be addressed separately): "The work of this group will focus on E.164 telephone numbers and other telephony related identifiers due to the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies." > >>> >>> ________________________________ >>> From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom >>> [Tom.McGarry@neustar.biz] >>> Sent: Monday, April 20, 2015 10:45 AM >>> To: Modern List >>> Subject: [Modern] Revised MODERN Charter >>> >>> The following changes were made from the version we went over in the >>> BoF: >>> >>> * The fourth paragraph defines the identifiers to be worked on as >>> "E.164 telephone numbers and telephony related identifiers" >>> * The fourth paragraph describes the motivation as "the changing >>> telecommunications environment and interest expressed by >>> telecommunications industry regulators" >>> * The fourth paragraph acknowledges that while the work of a >>> proposed working group could be reusable for other identifiers, the >>> work will focus on E.164 telephone numbers and other telephony >>> related identifiers >>> * The word "document" has been deleted from the list of >>> deliverables to allow flexibility for combining deliverables >>> >>> CHARTER TEXT: >>> The MODERN working group will define a set of Internet-based >>> mechanisms for the purposes of managing and resolving telephone >>> numbers (TNs) in an IP environment. Existing mechanisms for these >>> purposes face obsolescence as the voice communications >>> infrastructure evolves to IP technology and new applications for TNs >>> become possible. The traditional model of a TN having an >>> association to a single service provider and a single application is >>> breaking down. Its use as a network locator is going away, but its >>> use as an identifier for an individual or an organization will >>> remain for some time. Devices, applications, and network tools >>> increasingly need to manage TNs, including requesting and acquiring >>> TN delegations from authorities. >>> >>> The working group will define a framework for the roles and >>> functions involved in managing and resolving TNs in an IP >>> environment. This includes a protocol mechanism for acquiring TNs, >>> which will provide an enrollment process for the individuals and >>> entities that use and manage TNs. TNs may either be managed in a >>> hierarchical tree, or in a distributed peer-to-peer architecture. >>> Privacy of the enrollment data and security of the resource will be >>> primary considerations. >>> >>> Additionally, the working group will deliver a protocol mechanism >>> for resolving TNs which will allow entities such as service >>> providers, devices, and applications to access data related to TNs, >>> possibly including caller name data (CNAM). Maintaining reliability, >>> real time application performance, security and privacy are primary >>> considerations. The working group will take into consideration >>> existing IETF work including ENUM, SPEERMINT, and DRINKS. >>> >>> The work of this group will focus on E.164 telephone numbers and >>> other telephony related identifiers due to the changing telecom >>> environment and interest expressed by telecommunications industry >>> regulators to support more flexible regulatory models than exist >>> today. There is an expectation that aspects of the architecture and >>> protocols defined by the working group will be reusable for other >>> user-focused identifiers. Extensions to the MODERN defined >>> architecture and protocols can occur outside of the MODERN working >>> group, either in parallel with the MODERN working group or after the >>> MODERN working group is complete. Solutions and mechanisms created >>> by the working group will be flexible enough to accommodate >>> different policies, e.g., by different regulatory agencies. >>> >>> The work group will deliver the following: >>> >>> >>> - An architecture overview, including high level requirements >>> and security/privacy considerations >>> >>> - A description of the enrollment processes for existing and >>> new TNs including any modifications to metadata related to those TNs >>> >>> - A description of protocol mechanisms for accessing contact >>> information associated with enrollments >>> >>> - A description of mechanisms for resolving information >>> related to TNs >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Wed Apr 29 05:35:31 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8321B2C5E for ; Wed, 29 Apr 2015 05:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4uIcqaA22Rq for ; Wed, 29 Apr 2015 05:35:28 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6081B2C5B for ; Wed, 29 Apr 2015 05:35:28 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:63507 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnRD3-0006dr-9s; Wed, 29 Apr 2015 05:35:27 -0700 Message-ID: <5540D00D.20605@usdonovans.com> Date: Wed, 29 Apr 2015 07:35:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell , "McGarry, Tom" References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> In-Reply-To: <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Cc: "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 12:35:30 -0000 Why not limit the charter to E.164 numbers and expect the working group to recharter if it finds other telephony identifiers that the group feels apply? Steve On 4/28/15 4:35 PM, Ben Campbell wrote: > On 28 Apr 2015, at 15:53, McGarry, Tom wrote: > >> The other telephony related identifiers includes things like number >> blocks (in the US these are called central office codes and thousands >> blocks) and identifiers for service providers (I could see these >> taking both alpha and numeric forms). There are identifiers for >> switches, points of interconnect, trunk groups, etc. Not all of these >> are shared between networks (sometimes only bilaterally) and some of >> these will have an analog in an IP environment, some will not. >> >> I was thinking it would be the job of the working group to figure out >> the relevant other identifiers. Clearly E164s are the baseline. > > > Keep in mind "scope" has been a sensitive topic so far. It seems to me > so far that the "other telephony related identifiers" is kind of a > "we'll know it when we see it" category. That's going to get pushback > during the formal review process--so it would be helpful to have a > clear definition. > > If that's not possible, we _might_ be able to get away with language > saying that E164s are the primary scope, but the working group may > consider other identifiers that it finds to be closely enough > related. (That needs wordsmithing.) > > Ben. > > >> >> Sent from my iPhone >> >>> On Apr 27, 2015, at 10:29 AM, Steve Donovan >>> wrote: >>> >>> SMS shortcodes were one of the reasons we left in the "other >>> telephony related identifiers" language. >>> >>> I support, however, limiting the scope to E.164 numbers for the >>> initial charter. >>> >>> Steve >>> >>>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >>>> I'm not sure it matters if the identifier is numeric or not, but >>>> the unifying principle seems to be that there is a clear delegation >>>> chain, within a confined geographic (mostly in the legal sense, >>>> i.e., a well-known set of national laws apply) scope. In >>>> particular, this implies that the entities participating can >>>> generally be assumed to be cooperative, as there is an umpire to >>>> remove any uncooperative players from the field. >>>> >>>> I don't think it's a priority, but SMS shortcodes seem similar >>>> enough to fit into the same mechanism. >>>> >>>> To avoid needless ambiguity, simply saying E.164 numbers and >>>> leaving the door open to other identifiers that happen to fit might >>>> work. >>>> >>>> ________________________________________ >>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell >>>> [ben@nostrum.com] >>>> Sent: Friday, April 24, 2015 5:09 PM >>>> To: Richard Shockey >>>> Cc: Modern List; McGarry, Tom >>>> Subject: Re: [Modern] Revised MODERN Charter >>>> >>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>>> >>>>> Out hopefullyÅ that is a private proprietary namespace. >>>> Okay, so Skype IDs were a bad example--but my question was about >>>> whether >>>> the "other telephony related identifiers" were still assumed to be >>>> things that look like TNs. >>>> >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e= >>>> >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_modern&d=AwIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=VcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34PastBFXs&s=UIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e= >>> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > From nobody Wed Apr 29 07:10:58 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AB71A914D for ; Wed, 29 Apr 2015 07:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-HagEe6LmM4 for ; Wed, 29 Apr 2015 07:10:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A52E1A1B8A for ; Wed, 29 Apr 2015 07:07:37 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3TE7PRO079670 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2015 09:07:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Steve Donovan" Date: Wed, 29 Apr 2015 09:07:25 -0500 Message-ID: In-Reply-To: <5540D00D.20605@usdonovans.com> References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> <5540D00D.20605@usdonovans.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "modern@ietf.org" , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 14:10:57 -0000 On 29 Apr 2015, at 7:35, Steve Donovan wrote: > Why not limit the charter to E.164 numbers and expect the working = > group to recharter if it finds other telephony identifiers that the = > group feels apply? I would be okay with that. > > Steve > > On 4/28/15 4:35 PM, Ben Campbell wrote: >> On 28 Apr 2015, at 15:53, McGarry, Tom wrote: >> >>> The other telephony related identifiers includes things like number = >>> blocks (in the US these are called central office codes and = >>> thousands blocks) and identifiers for service providers (I could see = >>> these taking both alpha and numeric forms). There are identifiers = >>> for switches, points of interconnect, trunk groups, etc. Not all of = >>> these are shared between networks (sometimes only bilaterally) and = >>> some of these will have an analog in an IP environment, some will = >>> not. >>> >>> I was thinking it would be the job of the working group to figure = >>> out the relevant other identifiers. Clearly E164s are the baseline. >> >> >> Keep in mind "scope" has been a sensitive topic so far. It seems to = >> me so far that the "other telephony related identifiers" is kind of a = >> "we'll know it when we see it" category. That's going to get pushback = >> during the formal review process--so it would be helpful to have a = >> clear definition. >> >> If that's not possible, we _might_ be able to get away with language = >> saying that E164s are the primary scope, but the working group may = >> consider other identifiers that it finds to be closely enough = >> related. (That needs wordsmithing.) >> >> Ben. >> >> >>> >>> Sent from my iPhone >>> >>>> On Apr 27, 2015, at 10:29 AM, Steve Donovan = >>>> wrote: >>>> >>>> SMS shortcodes were one of the reasons we left in the "other = >>>> telephony related identifiers" language. >>>> >>>> I support, however, limiting the scope to E.164 numbers for the = >>>> initial charter. >>>> >>>> Steve >>>> >>>>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >>>>> I'm not sure it matters if the identifier is numeric or not, but = >>>>> the unifying principle seems to be that there is a clear = >>>>> delegation chain, within a confined geographic (mostly in the = >>>>> legal sense, i.e., a well-known set of national laws apply) scope. = >>>>> In particular, this implies that the entities participating can = >>>>> generally be assumed to be cooperative, as there is an umpire to = >>>>> remove any uncooperative players from the field. >>>>> >>>>> I don't think it's a priority, but SMS shortcodes seem similar = >>>>> enough to fit into the same mechanism. >>>>> >>>>> To avoid needless ambiguity, simply saying E.164 numbers and = >>>>> leaving the door open to other identifiers that happen to fit = >>>>> might work. >>>>> >>>>> ________________________________________ >>>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell = >>>>> [ben@nostrum.com] >>>>> Sent: Friday, April 24, 2015 5:09 PM >>>>> To: Richard Shockey >>>>> Cc: Modern List; McGarry, Tom >>>>> Subject: Re: [Modern] Revised MODERN Charter >>>>> >>>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>>>> >>>>>> Out hopefully=C5=A0that is a private proprietary namespace. >>>>> Okay, so Skype IDs were a bad example--but my question was about = >>>>> whether >>>>> the "other telephony related identifiers" were still assumed to be >>>>> things that look like TNs. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32= iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEg= iF34PastBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32i= B7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgi= F34PastBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> From nobody Wed Apr 29 10:09:09 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599841ACD2D for ; Wed, 29 Apr 2015 10:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrCDhbjA9iLy for ; Wed, 29 Apr 2015 10:09:05 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D421C1ACD19 for ; Wed, 29 Apr 2015 10:09:04 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t3TH39UE009368; Wed, 29 Apr 2015 13:09:04 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1u33a1r0p8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2015 13:09:03 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Wed, 29 Apr 2015 13:09:02 -0400 From: "McGarry, Tom" To: Ben Campbell Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOJJICAAbqIG4AATrcAgAD7jICAABm0gP//77Hf Date: Wed, 29 Apr 2015 17:09:02 +0000 Message-ID: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <553E47C9.204@usdonovans.com> <04B60605-F4F1-4D2C-B331-CF706FB13414@nostrum.com> <5540D00D.20605@usdonovans.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-29_05:2015-04-29,2015-04-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=6.35385632996588e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504290205 Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:09:08 -0000 I have no objections.=20 Sent from my iPhone > On Apr 29, 2015, at 10:07 AM, Ben Campbell wrote: >=20 >> On 29 Apr 2015, at 7:35, Steve Donovan wrote: >>=20 >> Why not limit the charter to E.164 numbers and expect the working group = to recharter if it finds other telephony identifiers that the group feels a= pply? >=20 > I would be okay with that. >=20 >>=20 >> Steve >>=20 >>> On 4/28/15 4:35 PM, Ben Campbell wrote: >>>> On 28 Apr 2015, at 15:53, McGarry, Tom wrote: >>>>=20 >>>> The other telephony related identifiers includes things like number bl= ocks (in the US these are called central office codes and thousands blocks)= and identifiers for service providers (I could see these taking both alpha= and numeric forms). There are identifiers for switches, points of intercon= nect, trunk groups, etc. Not all of these are shared between networks (some= times only bilaterally) and some of these will have an analog in an IP envi= ronment, some will not. >>>>=20 >>>> I was thinking it would be the job of the working group to figure out = the relevant other identifiers. Clearly E164s are the baseline. >>>=20 >>>=20 >>> Keep in mind "scope" has been a sensitive topic so far. It seems to me = so far that the "other telephony related identifiers" is kind of a "we'll k= now it when we see it" category. That's going to get pushback during the fo= rmal review process--so it would be helpful to have a clear definition. >>>=20 >>> If that's not possible, we _might_ be able to get away with language sa= ying that E164s are the primary scope, but the working group may consider o= ther identifiers that it finds to be closely enough related. (That needs w= ordsmithing.) >>>=20 >>> Ben. >>>=20 >>>=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Apr 27, 2015, at 10:29 AM, Steve Donovan wrote: >>>>>=20 >>>>> SMS shortcodes were one of the reasons we left in the "other telephon= y related identifiers" language. >>>>>=20 >>>>> I support, however, limiting the scope to E.164 numbers for the initi= al charter. >>>>>=20 >>>>> Steve >>>>>=20 >>>>>> On 4/25/15 7:37 AM, Henning Schulzrinne wrote: >>>>>> I'm not sure it matters if the identifier is numeric or not, but the= unifying principle seems to be that there is a clear delegation chain, wit= hin a confined geographic (mostly in the legal sense, i.e., a well-known se= t of national laws apply) scope. In particular, this implies that the entit= ies participating can generally be assumed to be cooperative, as there is a= n umpire to remove any uncooperative players from the field. >>>>>>=20 >>>>>> I don't think it's a priority, but SMS shortcodes seem similar enoug= h to fit into the same mechanism. >>>>>>=20 >>>>>> To avoid needless ambiguity, simply saying E.164 numbers and leaving= the door open to other identifiers that happen to fit might work. >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [be= n@nostrum.com] >>>>>> Sent: Friday, April 24, 2015 5:09 PM >>>>>> To: Richard Shockey >>>>>> Cc: Modern List; McGarry, Tom >>>>>> Subject: Re: [Modern] Revised MODERN Charter >>>>>>=20 >>>>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>>>>>=20 >>>>>>> Out hopefully=8Athat is a private proprietary namespace. >>>>>> Okay, so Skype IDs were a bad example--but my question was about whe= ther >>>>>> the "other telephony related identifiers" were still assumed to be >>>>>> things that look like TNs. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Modern mailing list >>>>>> Modern@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7= HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34P= astBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >>>>>=20 >>>>> _______________________________________________ >>>>> Modern mailing list >>>>> Modern@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_modern&d=3DAwIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7H= ufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVcSJwdMhnJRZonCOMl0pnb5dZnfEPEgiF34Pa= stBFXs&s=3DUIffyVYQWcWtkW6goaGWFsR7HFYuULZz6nbvlpLEoMs&e=3D >>>>=20 >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_modern&d=3DAwIFaQ&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hu= fveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DvsFeUr82JCJmVqV_PWof--HRtnf076sru5cahd= uRQyQ&s=3DURLmKTjjI78q6UZ5IGmfJUWL7lliZc4wJVWzB3ZH334&e=3D >>>=20 From nobody Wed Apr 29 10:23:11 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB121ACD78 for ; Wed, 29 Apr 2015 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdQTpryNweGZ for ; Wed, 29 Apr 2015 10:23:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF0D1ACD6A for ; Wed, 29 Apr 2015 10:23:07 -0700 (PDT) Received: from BN1BFFO11FD012.protection.gbl (10.58.144.32) by BN1BFFO11HUB053.protection.gbl (10.58.144.200) with Microsoft SMTP Server (TLS) id 15.1.154.14; Wed, 29 Apr 2015 17:22:47 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; neustar.biz; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1BFFO11FD012.mail.protection.outlook.com (10.58.144.75) with Microsoft SMTP Server (TLS) id 15.1.160.8 via Frontend Transport; Wed, 29 Apr 2015 17:22:47 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3TGlZ9B015084; Wed, 29 Apr 2015 12:22:46 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm1.corp.sprint.com with ESMTP id 1u08ja2g85-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2015 12:22:46 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 29 Apr 2015 13:22:44 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 29 Apr 2015 12:22:44 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne , Ben Campbell , Richard Shockey Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQfstU4kycWLjRaEypfCEYVmuNDp1c9NeAgAAHZYCAAQMSAIAC2bnAgANfGICAAAj84A== Date: Wed, 29 Apr 2015 17:22:43 +0000 Message-ID: References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.26] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(189002)(377454003)(199003)(24454002)(13464003)(6806004)(47776003)(85326001)(46102003)(108616004)(24736003)(33646002)(102836002)(5250100002)(106466001)(15975445007)(86362001)(93886004)(50986999)(54356999)(2900100001)(5001920100001)(2656002)(87936001)(2950100001)(19580395003)(92566002)(76176999)(50466002)(77156002)(19580405001)(106116001)(62966003)(5001770100001)(5001960100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB053; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB053; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB053; X-Forefront-PRVS: 05610E64EE X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2015 17:22:47.1131 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB053 Archived-At: Cc: Modern List , "McGarry, Tom" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:23:10 -0000 Thank you Henning. Your list of general notions is what I was encouraging = Steve Donovan, et al, to do. I didn't volunteer any items even though I could think of some because I'm = not convinced the MODERN WG needs to include in its charter anything to do = with respect to "managing" E.164 telephone numbers. As you say, "nobody would design a new system to replicate what has evolved= over decades". I think your list of notions is useful input, but it would seem like it oug= ht to be directed at the existing organization(s) with authority and respon= sibility to manage E.164 telephone numbers. If they identify (or have identified already) a need for new protocols (rea= lly?) or request that the IETF develop a framework, then certainly MODERN c= ould be a good place to respond to that request. Has that happened? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 M: 816-210-8623 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: April 29, 2015 6:38 AM To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter Pierce, since you and your organization probably have first-hand experience with th= e existing system, particularly as you transition to all-IP, I'd be very in= terested in hearing what you see as deficiencies or problems. My general take is that just about anything can be made to work ("with enou= gh thrust, pigs can fly"), but that I suspect nobody would design a new sys= tem to replicate what has evolved over decades. I'm not sure the charter ha= s to spell out every problem in detail, but a general motivation seems usef= ul. My general notions are: - lack of flexibility (e.g., difficult to add fields without a very elabora= te and lengthy process typically spanning years) - lack of distribution (hard or impossible to have more than one administra= tor for each database) - complexity (we hear a fair amount about rural call completion problems wh= ich aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and p= orting mechanisms Henning ________________________________ From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] Sent: Monday, April 27, 2015 10:36 AM To: Henning Schulzrinne; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter David Holmes has made the point in the past that it is important to list ou= t what are the issues or problems to be solved that drive the work effort. To David's point, what are the flaws or inadequacies of the current adminis= tration and conservation of the E.164 telephone numbers that require or ben= efit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC= , and LERG that requires MODERN to fix it? My question is aimed specifically at the section in the charter which reads= : The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: April 25, 2015 7:37 AM To: Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter I'm not sure it matters if the identifier is numeric or not, but the unifyi= ng principle seems to be that there is a clear delegation chain, within a c= onfined geographic (mostly in the legal sense, i.e., a well-known set of na= tional laws apply) scope. In particular, this implies that the entities par= ticipating can generally be assumed to be cooperative, as there is an umpir= e to remove any uncooperative players from the field. I don't think it's a priority, but SMS shortcodes seem similar enough to fi= t into the same mechanism. To avoid needless ambiguity, simply saying E.164 numbers and leaving the do= or open to other identifiers that happen to fit might work. ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com] Sent: Friday, April 24, 2015 5:09 PM To: Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter On 24 Apr 2015, at 15:43, Richard Shockey wrote: > Out hopefully=A9that is a private proprietary namespace. Okay, so Skype IDs were a bad example--but my question was about whether th= e "other telephony related identifiers" were still assumed to be things tha= t look like TNs. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 nobody Wed Apr 29 14:45:37 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E427A1A0364 for ; Wed, 29 Apr 2015 14:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44s8RLs4PIvT for ; Wed, 29 Apr 2015 14:45:34 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 18F481A038C for ; Wed, 29 Apr 2015 14:45:33 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Gorman, Pierce A [CTO]'" Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOLPICAAq06o4AApb6AgAAGHyA= Date: Wed, 29 Apr 2015 21:45:32 +0000 References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Modern List Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 21:45:37 -0000 I gather that some of those organizations responsible for managing numbers = are part of the list discussion... -----Original Message----- From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]=20 Sent: Wednesday, April 29, 2015 1:23 PM To: Henning Schulzrinne; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter Thank you Henning. Your list of general notions is what I was encouraging = Steve Donovan, et al, to do. I didn't volunteer any items even though I could think of some because I'm = not convinced the MODERN WG needs to include in its charter anything to do = with respect to "managing" E.164 telephone numbers. As you say, "nobody would design a new system to replicate what has evolved= over decades". I think your list of notions is useful input, but it would seem like it oug= ht to be directed at the existing organization(s) with authority and respon= sibility to manage E.164 telephone numbers. If they identify (or have identified already) a need for new protocols (rea= lly?) or request that the IETF develop a framework, then certainly MODERN c= ould be a good place to respond to that request. Has that happened? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 M: 816-210-8623 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: April 29, 2015 6:38 AM To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter Pierce, since you and your organization probably have first-hand experience with th= e existing system, particularly as you transition to all-IP, I'd be very in= terested in hearing what you see as deficiencies or problems. My general take is that just about anything can be made to work ("with enou= gh thrust, pigs can fly"), but that I suspect nobody would design a new sys= tem to replicate what has evolved over decades. I'm not sure the charter ha= s to spell out every problem in detail, but a general motivation seems usef= ul. My general notions are: - lack of flexibility (e.g., difficult to add fields without a very elabora= te and lengthy process typically spanning years) - lack of distribution (hard or impossible to have more than one administra= tor for each database) - complexity (we hear a fair amount about rural call completion problems wh= ich aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and p= orting mechanisms Henning ________________________________ From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] Sent: Monday, April 27, 2015 10:36 AM To: Henning Schulzrinne; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter David Holmes has made the point in the past that it is important to list ou= t what are the issues or problems to be solved that drive the work effort. To David's point, what are the flaws or inadequacies of the current adminis= tration and conservation of the E.164 telephone numbers that require or ben= efit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC= , and LERG that requires MODERN to fix it? My question is aimed specifically at the section in the charter which reads= : The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: April 25, 2015 7:37 AM To: Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter I'm not sure it matters if the identifier is numeric or not, but the unifyi= ng principle seems to be that there is a clear delegation chain, within a c= onfined geographic (mostly in the legal sense, i.e., a well-known set of na= tional laws apply) scope. In particular, this implies that the entities par= ticipating can generally be assumed to be cooperative, as there is an umpir= e to remove any uncooperative players from the field. I don't think it's a priority, but SMS shortcodes seem similar enough to fi= t into the same mechanism. To avoid needless ambiguity, simply saying E.164 numbers and leaving the do= or open to other identifiers that happen to fit might work. ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com] Sent: Friday, April 24, 2015 5:09 PM To: Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter On 24 Apr 2015, at 15:43, Richard Shockey wrote: > Out hopefully=A9that is a private proprietary namespace. Okay, so Skype IDs were a bad example--but my question was about whether th= e "other telephony related identifiers" were still assumed to be things tha= t look like TNs. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 nobody Wed Apr 29 14:49:44 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043121A01C6 for ; Wed, 29 Apr 2015 14:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bFmmzZStfyf for ; Wed, 29 Apr 2015 14:49:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966611A00E6 for ; Wed, 29 Apr 2015 14:49:38 -0700 (PDT) Received: from BN1BFFO11FD048.protection.gbl (10.58.144.31) by BN1BFFO11HUB006.protection.gbl (10.58.144.153) with Microsoft SMTP Server (TLS) id 15.1.160.8; Wed, 29 Apr 2015 21:49:37 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1BFFO11FD048.mail.protection.outlook.com (10.58.145.3) with Microsoft SMTP Server (TLS) id 15.1.154.14 via Frontend Transport; Wed, 29 Apr 2015 21:49:37 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3TKx4C4017435; Wed, 29 Apr 2015 16:49:36 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm3.corp.sprint.com with ESMTP id 1u08642b7u-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2015 16:49:36 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 29 Apr 2015 16:49:35 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 29 Apr 2015 16:49:35 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQfstU4kycWLjRaEypfCEYVmuNDp1c9NeAgAAHZYCAAQMSAIAC2bnAgANfGICAAAj84IAAoMEA//+s43A= Date: Wed, 29 Apr 2015 21:49:34 +0000 Message-ID: <251f98d054164109b102a203794ef0ce@PLSWE13M08.ad.sprint.com> References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.33] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(189002)(199003)(377454003)(108616004)(33646002)(2950100001)(2900100001)(15975445007)(102836002)(110136002)(5001960100002)(24736003)(47776003)(5250100002)(76176999)(106466001)(54356999)(85326001)(19580405001)(19580395003)(6806004)(86362001)(50986999)(87936001)(2656002)(92566002)(62966003)(77156002)(46102003)(106116001)(50466002)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB006; H:plsapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB006; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1BFFO11HUB006; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB006; X-Forefront-PRVS: 05610E64EE X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2015 21:49:37.1999 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB006 Archived-At: Cc: Modern List Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 21:49:43 -0000 I apologize Henning. I don't understand what you meant in your last respon= se. What is "the list discussion"? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: April 29, 2015 4:46 PM To: Gorman, Pierce A [CTO] Cc: Modern List Subject: RE: [Modern] Revised MODERN Charter I gather that some of those organizations responsible for managing numbers = are part of the list discussion... -----Original Message----- From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com] Sent: Wednesday, April 29, 2015 1:23 PM To: Henning Schulzrinne; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter Thank you Henning. Your list of general notions is what I was encouraging = Steve Donovan, et al, to do. I didn't volunteer any items even though I could think of some because I'm = not convinced the MODERN WG needs to include in its charter anything to do = with respect to "managing" E.164 telephone numbers. As you say, "nobody would design a new system to replicate what has evolved= over decades". I think your list of notions is useful input, but it would seem like it oug= ht to be directed at the existing organization(s) with authority and respon= sibility to manage E.164 telephone numbers. If they identify (or have identified already) a need for new protocols (rea= lly?) or request that the IETF develop a framework, then certainly MODERN c= ould be a good place to respond to that request. Has that happened? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: April 29, 2015 6:38 AM To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter Pierce, since you and your organization probably have first-hand experience with th= e existing system, particularly as you transition to all-IP, I'd be very in= terested in hearing what you see as deficiencies or problems. My general take is that just about anything can be made to work ("with enou= gh thrust, pigs can fly"), but that I suspect nobody would design a new sys= tem to replicate what has evolved over decades. I'm not sure the charter ha= s to spell out every problem in detail, but a general motivation seems usef= ul. My general notions are: - lack of flexibility (e.g., difficult to add fields without a very elabora= te and lengthy process typically spanning years) - lack of distribution (hard or impossible to have more than one administra= tor for each database) - complexity (we hear a fair amount about rural call completion problems wh= ich aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and p= orting mechanisms Henning ________________________________ From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] Sent: Monday, April 27, 2015 10:36 AM To: Henning Schulzrinne; Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: RE: [Modern] Revised MODERN Charter David Holmes has made the point in the past that it is important to list ou= t what are the issues or problems to be solved that drive the work effort. To David's point, what are the flaws or inadequacies of the current adminis= tration and conservation of the E.164 telephone numbers that require or ben= efit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC= , and LERG that requires MODERN to fix it? My question is aimed specifically at the section in the charter which reads= : The working group will define a framework for the roles and functions invol= ved in managing and resolving TNs in an IP environment. This includes a pro= tocol mechanism for acquiring TNs, which will provide an enrollment process= for the individuals and entities that use and manage TNs. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: April 25, 2015 7:37 AM To: Ben Campbell; Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter I'm not sure it matters if the identifier is numeric or not, but the unifyi= ng principle seems to be that there is a clear delegation chain, within a c= onfined geographic (mostly in the legal sense, i.e., a well-known set of na= tional laws apply) scope. In particular, this implies that the entities par= ticipating can generally be assumed to be cooperative, as there is an umpir= e to remove any uncooperative players from the field. I don't think it's a priority, but SMS shortcodes seem similar enough to fi= t into the same mechanism. To avoid needless ambiguity, simply saying E.164 numbers and leaving the do= or open to other identifiers that happen to fit might work. ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostr= um.com] Sent: Friday, April 24, 2015 5:09 PM To: Richard Shockey Cc: Modern List; McGarry, Tom Subject: Re: [Modern] Revised MODERN Charter On 24 Apr 2015, at 15:43, Richard Shockey wrote: > Out hopefully=A9that is a private proprietary namespace. Okay, so Skype IDs were a bad example--but my question was about whether th= e "other telephony related identifiers" were still assumed to be things tha= t look like TNs. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 nobody Thu Apr 30 05:16:48 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3DB1AD35D for ; Thu, 30 Apr 2015 05:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a41JKs1vspsT for ; Thu, 30 Apr 2015 05:16:45 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE3B1AD289 for ; Thu, 30 Apr 2015 05:16:45 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:52228 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnnOT-0004ST-RZ for modern@ietf.org; Thu, 30 Apr 2015 05:16:44 -0700 Message-ID: <55421D27.7020905@usdonovans.com> Date: Thu, 30 Apr 2015 07:16:39 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 12:16:47 -0000 Pierce, I don't understand the relevance of your question. The scope of work for the MODERN working group was discussed at the MODERN BOF during IETF 92. Consensus was reached that the IETF should do the work outlined in the charter. If I recall correctly the response to that question was unanimous but it is possible that I missed some isolated negative hums. This consensus clearly includes protocol work. Whether they are new protocols depends on what the working group produces. The primary open question that needed to be addressed in the charter was the set of identifiers that the working group would address. Thus the proposal to limit the scope of work to E.164 numbers. You can find the minutes from the meeting here: https://www.ietf.org/proceedings/92/minutes/minutes-92-modern Regards, Steve On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote: > Thank you Henning. Your list of general notions is what I was encouraging Steve Donovan, et al, to do. > > I didn't volunteer any items even though I could think of some because I'm not convinced the MODERN WG needs to include in its charter anything to do with respect to "managing" E.164 telephone numbers. > > As you say, "nobody would design a new system to replicate what has evolved over decades". > > I think your list of notions is useful input, but it would seem like it ought to be directed at the existing organization(s) with authority and responsibility to manage E.164 telephone numbers. > > If they identify (or have identified already) a need for new protocols (really?) or request that the IETF develop a framework, then certainly MODERN could be a good place to respond to that request. Has that happened? > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 M: 816-210-8623 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: April 29, 2015 6:38 AM > To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey > Cc: Modern List; McGarry, Tom > Subject: RE: [Modern] Revised MODERN Charter > > Pierce, > > since you and your organization probably have first-hand experience with the existing system, particularly as you transition to all-IP, I'd be very interested in hearing what you see as deficiencies or problems. > > My general take is that just about anything can be made to work ("with enough thrust, pigs can fly"), but that I suspect nobody would design a new system to replicate what has evolved over decades. I'm not sure the charter has to spell out every problem in detail, but a general motivation seems useful. > > My general notions are: > - lack of flexibility (e.g., difficult to add fields without a very elaborate and lengthy process typically spanning years) > - lack of distribution (hard or impossible to have more than one administrator for each database) > - complexity (we hear a fair amount about rural call completion problems which aren't helped by small providers struggling to keep numbers straight) > - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms > > Henning > > ________________________________ > From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] > Sent: Monday, April 27, 2015 10:36 AM > To: Henning Schulzrinne; Ben Campbell; Richard Shockey > Cc: Modern List; McGarry, Tom > Subject: RE: [Modern] Revised MODERN Charter > > > David Holmes has made the point in the past that it is important to list out what are the issues or problems to be solved that drive the work effort. > > > > To David's point, what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it? > > > > My question is aimed specifically at the section in the charter which reads: > > > > The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. > > > > Best regards, > > > > > > Pierce Gorman > > Core Network Planning > > O: 913-439-4368 > > pierce.gorman@sprint.com > > > > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzrinne > Sent: April 25, 2015 7:37 AM > To: Ben Campbell; Richard Shockey > Cc: Modern List; McGarry, Tom > Subject: Re: [Modern] Revised MODERN Charter > > > > I'm not sure it matters if the identifier is numeric or not, but the unifying principle seems to be that there is a clear delegation chain, within a confined geographic (mostly in the legal sense, i.e., a well-known set of national laws apply) scope. In particular, this implies that the entities participating can generally be assumed to be cooperative, as there is an umpire to remove any uncooperative players from the field. > > > > I don't think it's a priority, but SMS shortcodes seem similar enough to fit into the same mechanism. > > > > To avoid needless ambiguity, simply saying E.164 numbers and leaving the door open to other identifiers that happen to fit might work. > > > > ________________________________________ > > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com] > > Sent: Friday, April 24, 2015 5:09 PM > > To: Richard Shockey > > Cc: Modern List; McGarry, Tom > > Subject: Re: [Modern] Revised MODERN Charter > > > > On 24 Apr 2015, at 15:43, Richard Shockey wrote: > > > >> Out hopefully©that is a private proprietary namespace. > > > Okay, so Skype IDs were a bad example--but my question was about whether the "other telephony related identifiers" were still assumed to be things that look like TNs. > > > > > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > 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. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Thu Apr 30 07:09:25 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85F61B2AE5 for ; Thu, 30 Apr 2015 07:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0CaFrXFwWFJ for ; Thu, 30 Apr 2015 07:09:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213991B2AC9 for ; Thu, 30 Apr 2015 07:09:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id DAB5EB7346013; Thu, 30 Apr 2015 14:09:15 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UE9Itx021800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 16:09:18 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 16:09:18 +0200 From: "DRAGE, Keith (Keith)" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Revised MODERN Charter Thread-Index: AQHQgz+CavWLquyVY02Q/laaiIQEe51llTFA Date: Thu, 30 Apr 2015 14:09:17 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , <55421D27.7020905@usdonovans.com> In-Reply-To: <55421D27.7020905@usdonovans.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 14:09:23 -0000 Steve, not sure I understand your response.=20 1) All decisions in the meeting room need to be confirmed on list, and this= is essentially the thread that is doing that. So it is perfectly appropria= te to question anything discussed in the face-to-face meeting as part of th= at thread. 2) Your use of "unanimous" is incorrect (and indeed irrelevant to the discu= ssion) and I do not believe that word was used in the meeting room. IETF ne= eds "rough consensus". 3) If any work is performed, I do believe this should be limited to E.164, = with no scope for extension without rechartering. (And that is not saying I= believe this is needed as a product, merely that I have no objection to th= e work being done.) It may well be up to other SDOs to apply the principles= of any resultant RFC to other identifiers if they feel the need. Certainly= before IETF starts work on any SMS identifiers, as was suggested in a prio= r mail, there should be a communication with 3GPP and possibly GSMA as to w= hether there is a use case for such a mechanism in that respect, as all SMS= work apart from some IANA registrations lies in those organisations. Regards Keith > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > Steve Donovan > Sent: 30 April 2015 13:17 > To: modern@ietf.org > Subject: Re: [Modern] Revised MODERN Charter >=20 > Pierce, >=20 > I don't understand the relevance of your question. >=20 > The scope of work for the MODERN working group was discussed=20 > at the MODERN BOF during IETF 92. Consensus was reached that=20 > the IETF should do the work outlined in the charter. If I=20 > recall correctly the response to that question was unanimous=20 > but it is possible that I missed some isolated negative hums.=20 > This consensus clearly includes protocol work. =20 > Whether they are new protocols depends on what the working=20 > group produces. >=20 > The primary open question that needed to be addressed in the=20 > charter was the set of identifiers that the working group=20 > would address. Thus the proposal to limit the scope of work=20 > to E.164 numbers. >=20 > You can find the minutes from the meeting here: >=20 > https://www.ietf.org/proceedings/92/minutes/minutes-92-modern >=20 > Regards, >=20 > Steve >=20 > On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote: > > Thank you Henning. Your list of general notions is what I=20 > was encouraging Steve Donovan, et al, to do. > > > > I didn't volunteer any items even though I could think of=20 > some because I'm not convinced the MODERN WG needs to include=20 > in its charter anything to do with respect to "managing"=20 > E.164 telephone numbers. > > > > As you say, "nobody would design a new system to replicate=20 > what has evolved over decades". > > > > I think your list of notions is useful input, but it would=20 > seem like it ought to be directed at the existing=20 > organization(s) with authority and responsibility to manage=20 > E.164 telephone numbers. > > > > If they identify (or have identified already) a need for=20 > new protocols (really?) or request that the IETF develop a=20 > framework, then certainly MODERN could be a good place to=20 > respond to that request. Has that happened? > > > > Best regards, > > > > > > Pierce Gorman > > Core Network Planning > > O: 913-439-4368 M: 816-210-8623 > > pierce.gorman@sprint.com > > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > > Sent: April 29, 2015 6:38 AM > > To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey > > Cc: Modern List; McGarry, Tom > > Subject: RE: [Modern] Revised MODERN Charter > > > > Pierce, > > > > since you and your organization probably have first-hand=20 > experience with the existing system, particularly as you=20 > transition to all-IP, I'd be very interested in hearing what=20 > you see as deficiencies or problems. > > > > My general take is that just about anything can be made to=20 > work ("with enough thrust, pigs can fly"), but that I suspect=20 > nobody would design a new system to replicate what has=20 > evolved over decades. I'm not sure the charter has to spell=20 > out every problem in detail, but a general motivation seems useful. > > > > My general notions are: > > - lack of flexibility (e.g., difficult to add fields without a very=20 > > elaborate and lengthy process typically spanning years) > > - lack of distribution (hard or impossible to have more than one=20 > > administrator for each database) > > - complexity (we hear a fair amount about rural call completion=20 > > problems which aren't helped by small providers struggling to keep=20 > > numbers straight) > > - difficulty of adopting more modern allocation (e.g.,=20 > "blocks" of 1)=20 > > and porting mechanisms > > > > Henning > > > > ________________________________ > > From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] > > Sent: Monday, April 27, 2015 10:36 AM > > To: Henning Schulzrinne; Ben Campbell; Richard Shockey > > Cc: Modern List; McGarry, Tom > > Subject: RE: [Modern] Revised MODERN Charter > > > > > > David Holmes has made the point in the past that it is=20 > important to list out what are the issues or problems to be=20 > solved that drive the work effort. > > > > > > > > To David's point, what are the flaws or inadequacies of the=20 > current administration and conservation of the E.164=20 > telephone numbers that require or benefit from an IETF work=20 > group? i.e., what is wrong with INC/NANC/NANP, NPAC, and=20 > LERG that requires MODERN to fix it? > > > > > > > > My question is aimed specifically at the section in the=20 > charter which reads: > > > > > > > > The working group will define a framework for the roles and=20 > functions involved in managing and resolving TNs in an IP=20 > environment. This includes a protocol mechanism for acquiring=20 > TNs, which will provide an enrollment process for the=20 > individuals and entities that use and manage TNs. > > > > > > > > Best regards, > > > > > > > > > > > > Pierce Gorman > > > > Core Network Planning > > > > O: 913-439-4368 > > > > pierce.gorman@sprint.com > > > > > > > > > > > > -----Original Message----- > > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning=20 > > Schulzrinne > > Sent: April 25, 2015 7:37 AM > > To: Ben Campbell; Richard Shockey > > Cc: Modern List; McGarry, Tom > > Subject: Re: [Modern] Revised MODERN Charter > > > > > > > > I'm not sure it matters if the identifier is numeric or=20 > not, but the unifying principle seems to be that there is a=20 > clear delegation chain, within a confined geographic (mostly=20 > in the legal sense, i.e., a well-known set of national laws=20 > apply) scope. In particular, this implies that the entities=20 > participating can generally be assumed to be cooperative, as=20 > there is an umpire to remove any uncooperative players from the field. > > > > > > > > I don't think it's a priority, but SMS shortcodes seem=20 > similar enough to fit into the same mechanism. > > > > > > > > To avoid needless ambiguity, simply saying E.164 numbers=20 > and leaving the door open to other identifiers that happen to=20 > fit might work. > > > > > > > > ________________________________________ > > > > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell=20 > > [ben@nostrum.com] > > > > Sent: Friday, April 24, 2015 5:09 PM > > > > To: Richard Shockey > > > > Cc: Modern List; McGarry, Tom > > > > Subject: Re: [Modern] Revised MODERN Charter > > > > > > > > On 24 Apr 2015, at 15:43, Richard Shockey wrote: > > > > > > > >> Out hopefully=A9that is a private proprietary namespace. > > > > > > Okay, so Skype IDs were a bad example--but my question was=20 > about whether the "other telephony related identifiers" were=20 > still assumed to be things that look like TNs. > > > > > > > > > > > > _______________________________________________ > > > > Modern mailing list > > > > Modern@ietf.org > > > > https://www.ietf.org/mailman/listinfo/modern > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information=20 > intended for the sole use of the recipient(s). Any use by=20 > others is prohibited. If you are not the intended recipient,=20 > please contact the sender and delete all copies of the message. > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information=20 > intended for the sole use of the recipient(s). Any use by=20 > others is prohibited. If you are not the intended recipient,=20 > please contact the sender and delete all copies of the message. > > > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > https://www.ietf.org/mailman/listinfo/modern > > >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > = From nobody Thu Apr 30 07:30:01 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11BB1B2B91 for ; Thu, 30 Apr 2015 07:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARg7ZDCp3vIj for ; Thu, 30 Apr 2015 07:29:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1BA1B2B86 for ; Thu, 30 Apr 2015 07:29:42 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3UETU0R069889 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 09:29:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "DRAGE, Keith (Keith)" Date: Thu, 30 Apr 2015 09:29:29 -0500 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <55421D27.7020905@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Steve Donovan , "modern@ietf.org" Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 14:29:59 -0000 (As individual except where marked) On 30 Apr 2015, at 9:09, DRAGE, Keith (Keith) wrote: > Steve, not sure I understand your response. > > 1) All decisions in the meeting room need to be confirmed on list, and > this is essentially the thread that is doing that. So it is perfectly > appropriate to question anything discussed in the face-to-face meeting > as part of that thread. > > 2) Your use of "unanimous" is incorrect (and indeed irrelevant to the > discussion) and I do not believe that word was used in the meeting > room. IETF needs "rough consensus". I took Steve's meaning to be that we had a lot of people in the room who expressed a need for the work, in answer to Pierce's question that could be interpreted to ask whether the right people have expressed a need for the work. That being said, Keith's point is important. But from a process perspective, also remember there is no working group yet to confirm consensus with. The larger audience for this will be the IESG and the community during the review of the charter. > > 3) If any work is performed, I do believe this should be limited to > E.164, with no scope for extension without rechartering. (And that is > not saying I believe this is needed as a product, merely that I have > no objection to the work being done.) It may well be up to other SDOs > to apply the principles of any resultant RFC to other identifiers if > they feel the need. Certainly before IETF starts work on any SMS > identifiers, as was suggested in a prior mail, there should be a > communication with 3GPP and possibly GSMA as to whether there is a use > case for such a mechanism in that respect, as all SMS work apart from > some IANA registrations lies in those organisations. > Given the concerns about scope, I think this is a good approach. It's worth trying to be generic where it makes sense, but we don't want to get wrapped around proving we meet requirements for an ever expanding set of identifiers without good reason. > Regards > > Keith > >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >> Steve Donovan >> Sent: 30 April 2015 13:17 >> To: modern@ietf.org >> Subject: Re: [Modern] Revised MODERN Charter >> >> Pierce, >> >> I don't understand the relevance of your question. >> >> The scope of work for the MODERN working group was discussed >> at the MODERN BOF during IETF 92. Consensus was reached that >> the IETF should do the work outlined in the charter. If I >> recall correctly the response to that question was unanimous >> but it is possible that I missed some isolated negative hums. >> This consensus clearly includes protocol work. >> Whether they are new protocols depends on what the working >> group produces. >> >> The primary open question that needed to be addressed in the >> charter was the set of identifiers that the working group >> would address. Thus the proposal to limit the scope of work >> to E.164 numbers. >> >> You can find the minutes from the meeting here: >> >> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern >> >> Regards, >> >> Steve >> >> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote: >>> Thank you Henning. Your list of general notions is what I >> was encouraging Steve Donovan, et al, to do. >>> >>> I didn't volunteer any items even though I could think of >> some because I'm not convinced the MODERN WG needs to include >> in its charter anything to do with respect to "managing" >> E.164 telephone numbers. >>> >>> As you say, "nobody would design a new system to replicate >> what has evolved over decades". >>> >>> I think your list of notions is useful input, but it would >> seem like it ought to be directed at the existing >> organization(s) with authority and responsibility to manage >> E.164 telephone numbers. >>> >>> If they identify (or have identified already) a need for >> new protocols (really?) or request that the IETF develop a >> framework, then certainly MODERN could be a good place to >> respond to that request. Has that happened? >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 M: 816-210-8623 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >>> Sent: April 29, 2015 6:38 AM >>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: RE: [Modern] Revised MODERN Charter >>> >>> Pierce, >>> >>> since you and your organization probably have first-hand >> experience with the existing system, particularly as you >> transition to all-IP, I'd be very interested in hearing what >> you see as deficiencies or problems. >>> >>> My general take is that just about anything can be made to >> work ("with enough thrust, pigs can fly"), but that I suspect >> nobody would design a new system to replicate what has >> evolved over decades. I'm not sure the charter has to spell >> out every problem in detail, but a general motivation seems useful. >>> >>> My general notions are: >>> - lack of flexibility (e.g., difficult to add fields without a very >>> elaborate and lengthy process typically spanning years) >>> - lack of distribution (hard or impossible to have more than one >>> administrator for each database) >>> - complexity (we hear a fair amount about rural call completion >>> problems which aren't helped by small providers struggling to keep >>> numbers straight) >>> - difficulty of adopting more modern allocation (e.g., >> "blocks" of 1) >>> and porting mechanisms >>> >>> Henning >>> >>> ________________________________ >>> From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] >>> Sent: Monday, April 27, 2015 10:36 AM >>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: RE: [Modern] Revised MODERN Charter >>> >>> >>> David Holmes has made the point in the past that it is >> important to list out what are the issues or problems to be >> solved that drive the work effort. >>> >>> >>> >>> To David's point, what are the flaws or inadequacies of the >> current administration and conservation of the E.164 >> telephone numbers that require or benefit from an IETF work >> group? i.e., what is wrong with INC/NANC/NANP, NPAC, and >> LERG that requires MODERN to fix it? >>> >>> >>> >>> My question is aimed specifically at the section in the >> charter which reads: >>> >>> >>> >>> The working group will define a framework for the roles and >> functions involved in managing and resolving TNs in an IP >> environment. This includes a protocol mechanism for acquiring >> TNs, which will provide an enrollment process for the >> individuals and entities that use and manage TNs. >>> >>> >>> >>> Best regards, >>> >>> >>> >>> >>> >>> Pierce Gorman >>> >>> Core Network Planning >>> >>> O: 913-439-4368 >>> >>> pierce.gorman@sprint.com >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >>> Schulzrinne >>> Sent: April 25, 2015 7:37 AM >>> To: Ben Campbell; Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: Re: [Modern] Revised MODERN Charter >>> >>> >>> >>> I'm not sure it matters if the identifier is numeric or >> not, but the unifying principle seems to be that there is a >> clear delegation chain, within a confined geographic (mostly >> in the legal sense, i.e., a well-known set of national laws >> apply) scope. In particular, this implies that the entities >> participating can generally be assumed to be cooperative, as >> there is an umpire to remove any uncooperative players from the >> field. >>> >>> >>> >>> I don't think it's a priority, but SMS shortcodes seem >> similar enough to fit into the same mechanism. >>> >>> >>> >>> To avoid needless ambiguity, simply saying E.164 numbers >> and leaving the door open to other identifiers that happen to >> fit might work. >>> >>> >>> >>> ________________________________________ >>> >>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell >>> [ben@nostrum.com] >>> >>> Sent: Friday, April 24, 2015 5:09 PM >>> >>> To: Richard Shockey >>> >>> Cc: Modern List; McGarry, Tom >>> >>> Subject: Re: [Modern] Revised MODERN Charter >>> >>> >>> >>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>> >>> >>> >>>> Out hopefullyÅ that is a private proprietary namespace. >>> >>> >>> Okay, so Skype IDs were a bad example--but my question was >> about whether the "other telephony related identifiers" were >> still assumed to be things that look like TNs. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Modern mailing list >>> >>> Modern@ietf.org >>> >>> 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. >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information >> intended for the sole use of the recipient(s). Any use by >> others is prohibited. If you are not the intended recipient, >> please contact the sender and delete all copies of the message. >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Apr 30 08:00:59 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155E11B2CA4 for ; Thu, 30 Apr 2015 08:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brqkWvQEdwcp for ; Thu, 30 Apr 2015 08:00:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AED1B2CD2 for ; Thu, 30 Apr 2015 07:59:38 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:53304 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ynpw6-0002De-UV for modern@ietf.org; Thu, 30 Apr 2015 07:59:37 -0700 Message-ID: <55424356.2040204@usdonovans.com> Date: Thu, 30 Apr 2015 09:59:34 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <55421D27.7020905@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 15:00:58 -0000 On 4/30/15 9:29 AM, Ben Campbell wrote: > (As individual except where marked) > > On 30 Apr 2015, at 9:09, DRAGE, Keith (Keith) wrote: > >> Steve, not sure I understand your response. >> >> 1) All decisions in the meeting room need to be confirmed on list, >> and this is essentially the thread that is doing that. So it is >> perfectly appropriate to question anything discussed in the >> face-to-face meeting as part of that thread. SRD> Agreed. The question in Pierce's email that I was questioning the relevance of was whether or not the IETF has received a request for protocol development. This is not a prerequisite to the IETF starting work on new protocols. >> >> 2) Your use of "unanimous" is incorrect (and indeed irrelevant to >> the discussion) and I do not believe that word was used in the >> meeting room. IETF needs "rough consensus". > > I took Steve's meaning to be that we had a lot of people in the room > who expressed a need for the work, in answer to Pierce's question that > could be interpreted to ask whether the right people have expressed a > need for the work. SRD> Yes, I meant to point out that this had already been discussed during the BOF and that there was significant (in my view) support for the need for work. There were also many who indicated a willingness to actually do the work. > > > That being said, Keith's point is important. But from a process > perspective, also remember there is no working group yet to confirm > consensus with. The larger audience for this will be the IESG and the > community during the review of the charter. > SRD> Understood. > >> >> 3) If any work is performed, I do believe this should be limited >> to E.164, with no scope for extension without rechartering. (And that >> is not saying I believe this is needed as a product, merely that I >> have no objection to the work being done.) It may well be up to other >> SDOs to apply the principles of any resultant RFC to other >> identifiers if they feel the need. Certainly before IETF starts work >> on any SMS identifiers, as was suggested in a prior mail, there >> should be a communication with 3GPP and possibly GSMA as to whether >> there is a use case for such a mechanism in that respect, as all SMS >> work apart from some IANA registrations lies in those organisations. >> > > Given the concerns about scope, I think this is a good approach. It's > worth trying to be generic where it makes sense, but we don't want to > get wrapped around proving we meet requirements for an ever expanding > set of identifiers without good reason. SRD> I reviewed the minutes and it was discussed/agreed in the room that the scope should be limited to E.164 numbers. It feels like this discussion is leading in that same direction. As such, I propose removing the words "and other telephony related identifiers" from the paragraph before the list of deliverables. I'll send out a revised proposed charter shortly. > >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>> Steve Donovan >>> Sent: 30 April 2015 13:17 >>> To: modern@ietf.org >>> Subject: Re: [Modern] Revised MODERN Charter >>> >>> Pierce, >>> >>> I don't understand the relevance of your question. >>> >>> The scope of work for the MODERN working group was discussed >>> at the MODERN BOF during IETF 92. Consensus was reached that >>> the IETF should do the work outlined in the charter. If I >>> recall correctly the response to that question was unanimous >>> but it is possible that I missed some isolated negative hums. >>> This consensus clearly includes protocol work. >>> Whether they are new protocols depends on what the working >>> group produces. >>> >>> The primary open question that needed to be addressed in the >>> charter was the set of identifiers that the working group >>> would address. Thus the proposal to limit the scope of work >>> to E.164 numbers. >>> >>> You can find the minutes from the meeting here: >>> >>> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern >>> >>> Regards, >>> >>> Steve >>> >>> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote: >>>> Thank you Henning. Your list of general notions is what I >>> was encouraging Steve Donovan, et al, to do. >>>> >>>> I didn't volunteer any items even though I could think of >>> some because I'm not convinced the MODERN WG needs to include >>> in its charter anything to do with respect to "managing" >>> E.164 telephone numbers. >>>> >>>> As you say, "nobody would design a new system to replicate >>> what has evolved over decades". >>>> >>>> I think your list of notions is useful input, but it would >>> seem like it ought to be directed at the existing >>> organization(s) with authority and responsibility to manage >>> E.164 telephone numbers. >>>> >>>> If they identify (or have identified already) a need for >>> new protocols (really?) or request that the IETF develop a >>> framework, then certainly MODERN could be a good place to >>> respond to that request. Has that happened? >>>> >>>> Best regards, >>>> >>>> >>>> Pierce Gorman >>>> Core Network Planning >>>> O: 913-439-4368 M: 816-210-8623 >>>> pierce.gorman@sprint.com >>>> >>>> >>>> -----Original Message----- >>>> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >>>> Sent: April 29, 2015 6:38 AM >>>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey >>>> Cc: Modern List; McGarry, Tom >>>> Subject: RE: [Modern] Revised MODERN Charter >>>> >>>> Pierce, >>>> >>>> since you and your organization probably have first-hand >>> experience with the existing system, particularly as you >>> transition to all-IP, I'd be very interested in hearing what >>> you see as deficiencies or problems. >>>> >>>> My general take is that just about anything can be made to >>> work ("with enough thrust, pigs can fly"), but that I suspect >>> nobody would design a new system to replicate what has >>> evolved over decades. I'm not sure the charter has to spell >>> out every problem in detail, but a general motivation seems useful. >>>> >>>> My general notions are: >>>> - lack of flexibility (e.g., difficult to add fields without a very >>>> elaborate and lengthy process typically spanning years) >>>> - lack of distribution (hard or impossible to have more than one >>>> administrator for each database) >>>> - complexity (we hear a fair amount about rural call completion >>>> problems which aren't helped by small providers struggling to keep >>>> numbers straight) >>>> - difficulty of adopting more modern allocation (e.g., >>> "blocks" of 1) >>>> and porting mechanisms >>>> >>>> Henning >>>> >>>> ________________________________ >>>> From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] >>>> Sent: Monday, April 27, 2015 10:36 AM >>>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey >>>> Cc: Modern List; McGarry, Tom >>>> Subject: RE: [Modern] Revised MODERN Charter >>>> >>>> >>>> David Holmes has made the point in the past that it is >>> important to list out what are the issues or problems to be >>> solved that drive the work effort. >>>> >>>> >>>> >>>> To David's point, what are the flaws or inadequacies of the >>> current administration and conservation of the E.164 >>> telephone numbers that require or benefit from an IETF work >>> group? i.e., what is wrong with INC/NANC/NANP, NPAC, and >>> LERG that requires MODERN to fix it? >>>> >>>> >>>> >>>> My question is aimed specifically at the section in the >>> charter which reads: >>>> >>>> >>>> >>>> The working group will define a framework for the roles and >>> functions involved in managing and resolving TNs in an IP >>> environment. This includes a protocol mechanism for acquiring >>> TNs, which will provide an enrollment process for the >>> individuals and entities that use and manage TNs. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> >>>> >>>> >>>> Pierce Gorman >>>> >>>> Core Network Planning >>>> >>>> O: 913-439-4368 >>>> >>>> pierce.gorman@sprint.com >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >>>> Schulzrinne >>>> Sent: April 25, 2015 7:37 AM >>>> To: Ben Campbell; Richard Shockey >>>> Cc: Modern List; McGarry, Tom >>>> Subject: Re: [Modern] Revised MODERN Charter >>>> >>>> >>>> >>>> I'm not sure it matters if the identifier is numeric or >>> not, but the unifying principle seems to be that there is a >>> clear delegation chain, within a confined geographic (mostly >>> in the legal sense, i.e., a well-known set of national laws >>> apply) scope. In particular, this implies that the entities >>> participating can generally be assumed to be cooperative, as >>> there is an umpire to remove any uncooperative players from the field. >>>> >>>> >>>> >>>> I don't think it's a priority, but SMS shortcodes seem >>> similar enough to fit into the same mechanism. >>>> >>>> >>>> >>>> To avoid needless ambiguity, simply saying E.164 numbers >>> and leaving the door open to other identifiers that happen to >>> fit might work. >>>> >>>> >>>> >>>> ________________________________________ >>>> >>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell >>>> [ben@nostrum.com] >>>> >>>> Sent: Friday, April 24, 2015 5:09 PM >>>> >>>> To: Richard Shockey >>>> >>>> Cc: Modern List; McGarry, Tom >>>> >>>> Subject: Re: [Modern] Revised MODERN Charter >>>> >>>> >>>> >>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>>> >>>> >>>> >>>>> Out hopefullyÅ that is a private proprietary namespace. >>>> >>>> >>>> Okay, so Skype IDs were a bad example--but my question was >>> about whether the "other telephony related identifiers" were >>> still assumed to be things that look like TNs. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Modern mailing list >>>> >>>> Modern@ietf.org >>>> >>>> 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. >>>> >>>> ________________________________ >>>> >>>> This e-mail may contain Sprint proprietary information >>> intended for the sole use of the recipient(s). Any use by >>> others is prohibited. If you are not the intended recipient, >>> please contact the sender and delete all copies of the message. >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Apr 30 08:07:56 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E621A8935 for ; Thu, 30 Apr 2015 08:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY-Fxrp7zd1X for ; Thu, 30 Apr 2015 08:07:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C811B2C96 for ; Thu, 30 Apr 2015 08:06:34 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:53336 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ynq2p-000CiJ-2M for modern@ietf.org; Thu, 30 Apr 2015 08:06:34 -0700 Message-ID: <554244F7.7000209@usdonovans.com> Date: Thu, 30 Apr 2015 10:06:31 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> , , In-Reply-To: Content-Type: multipart/alternative; boundary="------------060304080106090706040101" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 15:07:55 -0000 This is a multi-part message in MIME format. --------------060304080106090706040101 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I propose adding the following to the first paragraph. This is a slightly wordsmithed version of Henning's list: A sample of problems with existing mechanisms include: - lack of flexibility (for example, it can be difficult to add fields without a very elaborate and lengthy process typically spanning years) - lack of distribution (for example, it is hard or impossible to have more than one administrator for each database) - complexity (leading, for example, to a fair amount of rural call completion problems which aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms Steve On 4/29/15 6:38 AM, Henning Schulzrinne wrote: > Pierce, > > since you and your organization probably have first-hand experience with the existing system, particularly as you transition to all-IP, I'd be very interested in hearing what you see as deficiencies or problems. > > My general take is that just about anything can be made to work ("with enough thrust, pigs can fly"), but that I suspect nobody would design a new system to replicate what has evolved over decades. I'm not sure the charter has to spell out every problem in detail, but a general motivation seems useful. > > My general notions are: > - lack of flexibility (e.g., difficult to add fields without a very elaborate and lengthy process typically spanning years) > - lack of distribution (hard or impossible to have more than one administrator for each database) > - complexity (we hear a fair amount about rural call completion problems which aren't helped by small providers struggling to keep numbers straight) > - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms > > Henning > > ________________________________ > From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] > Sent: Monday, April 27, 2015 10:36 AM > To: Henning Schulzrinne; Ben Campbell; Richard Shockey > Cc: Modern List; McGarry, Tom > Subject: RE: [Modern] Revised MODERN Charter > > > David Holmes has made the point in the past that it is important to list out what are the issues or problems to be solved that drive the work effort. > > > > To David’s point, what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it? > > > > My question is aimed specifically at the section in the charter which reads: > > > > The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. > > > > Best regards, > > > > > > Pierce Gorman > > Core Network Planning > > O: 913-439-4368 > > pierce.gorman@sprint.com > > > > > > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzrinne > Sent: April 25, 2015 7:37 AM > To: Ben Campbell; Richard Shockey > Cc: Modern List; McGarry, Tom > Subject: Re: [Modern] Revised MODERN Charter > > > > I'm not sure it matters if the identifier is numeric or not, but the unifying principle seems to be that there is a clear delegation chain, within a confined geographic (mostly in the legal sense, i.e., a well-known set of national laws apply) scope. In particular, this implies that the entities participating can generally be assumed to be cooperative, as there is an umpire to remove any uncooperative players from the field. > > > > I don't think it's a priority, but SMS shortcodes seem similar enough to fit into the same mechanism. > > > > To avoid needless ambiguity, simply saying E.164 numbers and leaving the door open to other identifiers that happen to fit might work. > > > > ________________________________________ > > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com] > > Sent: Friday, April 24, 2015 5:09 PM > > To: Richard Shockey > > Cc: Modern List; McGarry, Tom > > Subject: Re: [Modern] Revised MODERN Charter > > > > On 24 Apr 2015, at 15:43, Richard Shockey wrote: > > > >> Out hopefullyÅ that is a private proprietary namespace. > > > Okay, so Skype IDs were a bad example--but my question was about whether the "other telephony related identifiers" were still assumed to be things that look like TNs. > > > > > > _______________________________________________ > > Modern mailing list > > Modern@ietf.org > > 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. > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > --------------060304080106090706040101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I propose adding the following to the first paragraph.  This is a slightly wordsmithed version of Henning's list:

    A sample of problems with existing mechanisms include:

     

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

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

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

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


    Steve

    On 4/29/15 6:38 AM, Henning Schulzrinne wrote:
    Pierce,

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

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

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

Henning

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


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



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



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



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



Best regards,





Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com





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



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



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



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



________________________________________

From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com]

Sent: Friday, April 24, 2015 5:09 PM

To: Richard Shockey

Cc: Modern List; McGarry, Tom

Subject: Re: [Modern] Revised MODERN Charter



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




    Out hopefullyÅ that is a private proprietary namespace.

    

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





_______________________________________________

Modern mailing list

Modern@ietf.org<mailto:Modern@ietf.org>

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.

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    --------------060304080106090706040101-- From nobody Thu Apr 30 08:20:41 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACABB1A92DF for ; Thu, 30 Apr 2015 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZbkgcMnPee5 for ; Thu, 30 Apr 2015 08:20:39 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1269F1B2C83 for ; Thu, 30 Apr 2015 08:20:39 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:53377 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnqGT-0006az-52 for modern@ietf.org; Thu, 30 Apr 2015 08:20:38 -0700 Message-ID: <55424844.9040700@usdonovans.com> Date: Thu, 30 Apr 2015 10:20:36 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "modern@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [Modern] A revised revised MODERN charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 15:20:40 -0000 The following is the latest proposed version of the MODERN working group charter with updates discussed on the list discussion so far. Regards, Steve ---------- CHARTER TEXT: The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment. Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible. The traditional model of a TN having an association to a single service provider and a single application is breaking down. Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. A sample of problems with existing mechanisms include: - lack of flexibility (for example, it can be difficult to add fields without a very elaborate and lengthy process typically spanning years) - lack of distribution (for example, it is hard or impossible to have more than one administrator for each database) - complexity (leading, for example, to a fair amount of rural call completion problems which aren't helped by small providers struggling to keep numbers straight) - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. It will also define protocol mechanisms for acquiring and resolving TNs. The protocol mechanism for acquiring TNs will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. Privacy of the enrollment data and security of the resource will be primary considerations. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM). Maintaining reliability, real time application performance, security and privacy are primary considerations. The working group will take into consideration existing IETF work including ENUM, SPEERMINT, and DRINKS. The work of this group will focus on E.164 telephone numbers due to the changing telecom environment and interest expressed by telecommunications industry regulators to support more flexible regulatory models than exist today. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies. The work group will deliver the following: - An architecture overview, including high level requirements and security/privacy considerations - A description of the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information associated with enrollments - A description of mechanisms for resolving information related to TNs From nobody Thu Apr 30 09:24:42 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7841B2D96 for ; Thu, 30 Apr 2015 09:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlTYa91dGe7W for ; Thu, 30 Apr 2015 09:24:39 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BE61B2D95 for ; Thu, 30 Apr 2015 09:24:39 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t3UGMf5p007785; Thu, 30 Apr 2015 12:24:38 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1u37yn11u5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 12:24:38 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 30 Apr 2015 12:24:37 -0400 From: "Peterson, Jon" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] A revised revised MODERN charter Thread-Index: AQHQg1k6LJxbwBImI0KebvVxbpEE3p1li0uA Date: Thu, 30 Apr 2015 16:24:36 +0000 Message-ID: References: <55424844.9040700@usdonovans.com> In-Reply-To: <55424844.9040700@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.89] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C74EAD2881C8D48926922039847C57E@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-30_05:2015-04-29,2015-04-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504300198 Archived-At: Subject: Re: [Modern] A revised revised MODERN charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:24:41 -0000 While I understand the desire to scope identifiers in the charter per the recent thread, I think putting it this starkly is too restrictive: > Any such > extensions or reuse of MODERN mechanisms are out of scope for the MODERN > working group.=20 I mean, I thought we were going to define an extensible query-response protocol in this working group for managing data about telephone numbers. Something that would look at least vaguely like what is in draft-peterson-terq. From this reading, I could easily argue that TeRQ is outside the scope of MODERN precisely because it is extensible to other identifiers. >From the recent thread, I had thought people were arguing for some gating. Like "first, this working group is going to define a mechanism for telephone numbers. The group may later recharter to work on other things." I would be okay with some text along those lines, though frankly, I would prefer the second sentence read more like, "this group is also chartered to further investigate the use of other identifiers for the purpose of an eventual recharter," since I think the expertise to scope the work on identifiers resides on this mailing list and we should explicitly use it for that purpose. Also, in that same paragraph I'd prefer not to qualify "telephone numbers" with "E.164". This seems to come up again and again, but, there are a lot of telephone numbers we care about that do to fall under the E.164 plan. The earlier charter text doesn't say E.164, and I don't see why this part needs to either. Let's just keep it to "telephone numbers." Jon Peterson Neustar, Inc. On 4/30/15, 8:20 AM, "Steve Donovan" wrote: >The following is the latest proposed version of the MODERN working group >charter with updates discussed on the list discussion so far. > >Regards, > >Steve > >---------- > >CHARTER TEXT: > >The MODERN working group will define a set of Internet-based mechanisms >for the purposes of managing and resolving telephone numbers (TNs) in an >IP environment. Existing mechanisms for these purposes face >obsolescence as the voice communications infrastructure evolves to IP >technology and new applications for TNs become possible. The >traditional model of a TN having an association to a single service >provider and a single application is breaking down. Its use as a >network locator is going away, but its use as an identifier for an >individual or an organization will remain for some time. Devices, >applications, and network tools increasingly need to manage TNs, >including requesting and acquiring TN delegations from authorities. A >sample of problems with existing mechanisms include: > >- lack of flexibility (for example, it can be difficult to add fields >without a very elaborate and lengthy process typically spanning years) >- lack of distribution (for example, it is hard or impossible to have >more than one administrator for each database) >- complexity (leading, for example, to a fair amount of rural call >completion problems which aren't helped by small providers struggling to >keep numbers straight) >- difficulty of adopting more modern allocation (e.g., "blocks" of 1) >and porting mechanisms > >The working group will define a framework for the roles and functions >involved in managing and resolving TNs in an IP environment. It will >also define protocol mechanisms for acquiring and resolving TNs. The >protocol mechanism for acquiring TNs will provide an enrollment process >for the individuals and entities that use and manage TNs. TNs may either >be managed in a hierarchical tree, or in a distributed peer-to-peer >architecture. Privacy of the enrollment data and security of the >resource will be primary considerations. The protocol mechanism for >resolving TNs will allow entities such as service providers, devices, >and applications to access data related to TNs, possibly including >caller name data (CNAM). Maintaining reliability, real time application >performance, security and privacy are primary considerations. The >working group will take into consideration existing IETF work including >ENUM, SPEERMINT, and DRINKS. > >The work of this group will focus on E.164 telephone numbers due to the >changing telecom environment and interest expressed by >telecommunications industry regulators to support more flexible >regulatory models than exist today. There is an expectation that >aspects of the architecture and protocols defined by the working group >will be reusable for other user-focused identifiers. Any such >extensions or reuse of MODERN mechanisms are out of scope for the MODERN >working group. Solutions and mechanisms created by the working group >will be flexible enough to accommodate different policies, e.g., by >different regulatory agencies. > >The work group will deliver the following: > >- An architecture overview, including high level requirements and >security/privacy considerations > >- A description of the enrollment processes for existing and new >TNs including any modifications to metadata related to those TNs > >- A description of protocol mechanisms for accessing contact >information associated with enrollments > >- A description of mechanisms for resolving information related to >TNs > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Thu Apr 30 09:58:07 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF171A8748 for ; Thu, 30 Apr 2015 09:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3aEJLHTVDG2 for ; Thu, 30 Apr 2015 09:58:03 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734861B2E40 for ; Thu, 30 Apr 2015 09:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=/vppS0hyFcgxX1k7z+fD7KTeXw6xJ597Ro9UHNRXEQ8=; b=h1zkZ1664BJ6GCeiiuzn9xT4VlpDyGH+H2kV5WEn6JtkXQQjZrCnXgjrflabe7fJemg91+sFPMmnPziiIFRKCc4K/optSilLagzOWxhQtJ9ZwksQQEYTq3OpYbBqCN82i/r3U4gSUrLXgJyiLilA7YHExBSSN8J3VEh4lkDvWOg=; Received: from [141.161.20.228] (port=56700) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ynrmg-0000eB-2a for modern@ietf.org; Thu, 30 Apr 2015 09:58:02 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_EB8EAC5D-D59A-47AC-89CF-3C8E57F25094"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: <55421D27.7020905@usdonovans.com> Date: Thu, 30 Apr 2015 12:57:56 -0400 Message-Id: <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <55421D27.7020905@usdonovans.com> To: modern@ietf.org X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:58:06 -0000 --Apple-Mail=_EB8EAC5D-D59A-47AC-89CF-3C8E57F25094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let me reiterate. Read the minutes! There was nothing anywhere near strong consensus, no less unanimous = consensus, the IETF should do the work. The consensus we did come to was that the work in the charter as = presented at the BOF was NOT necessarily useful or well-scoped. I do not = think anyone disputed whether it was solvable. Likewise, it was one of = those 49-51, you had to be there, when it came to whether to form a work = group. What I am reading on the list is people are falling more on the side of = =E2=80=9Cnot useful.=E2=80=9D I will follow-up with what I think will be = useful in a separate email thread. > On Apr 30, 2015, at 8:16 AM, Steve Donovan = wrote: >=20 > Pierce, >=20 > I don't understand the relevance of your question. >=20 > The scope of work for the MODERN working group was discussed at the = MODERN BOF during IETF 92. Consensus was reached that the IETF should = do the work outlined in the charter. If I recall correctly the response = to that question was unanimous but it is possible that I missed some = isolated negative hums. This consensus clearly includes protocol work. = Whether they are new protocols depends on what the working group = produces. >=20 > The primary open question that needed to be addressed in the charter = was the set of identifiers that the working group would address. Thus = the proposal to limit the scope of work to E.164 numbers. >=20 > You can find the minutes from the meeting here: >=20 > https://www.ietf.org/proceedings/92/minutes/minutes-92-modern >=20 > Regards, >=20 > Steve >=20 > On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote: >> Thank you Henning. Your list of general notions is what I was = encouraging Steve Donovan, et al, to do. >>=20 >> I didn't volunteer any items even though I could think of some = because I'm not convinced the MODERN WG needs to include in its charter = anything to do with respect to "managing" E.164 telephone numbers. >>=20 >> As you say, "nobody would design a new system to replicate what has = evolved over decades". >>=20 >> I think your list of notions is useful input, but it would seem like = it ought to be directed at the existing organization(s) with authority = and responsibility to manage E.164 telephone numbers. >>=20 >> If they identify (or have identified already) a need for new = protocols (really?) or request that the IETF develop a framework, then = certainly MODERN could be a good place to respond to that request. Has = that happened? >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 M: 816-210-8623 >> pierce.gorman@sprint.com >>=20 >>=20 >> -----Original Message----- >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >> Sent: April 29, 2015 6:38 AM >> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey >> Cc: Modern List; McGarry, Tom >> Subject: RE: [Modern] Revised MODERN Charter >>=20 >> Pierce, >>=20 >> since you and your organization probably have first-hand experience = with the existing system, particularly as you transition to all-IP, I'd = be very interested in hearing what you see as deficiencies or problems. >>=20 >> My general take is that just about anything can be made to work = ("with enough thrust, pigs can fly"), but that I suspect nobody would = design a new system to replicate what has evolved over decades. I'm not = sure the charter has to spell out every problem in detail, but a general = motivation seems useful. >>=20 >> My general notions are: >> - lack of flexibility (e.g., difficult to add fields without a very = elaborate and lengthy process typically spanning years) >> - lack of distribution (hard or impossible to have more than one = administrator for each database) >> - complexity (we hear a fair amount about rural call completion = problems which aren't helped by small providers struggling to keep = numbers straight) >> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) = and porting mechanisms >>=20 >> Henning >>=20 >> ________________________________ >> From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] >> Sent: Monday, April 27, 2015 10:36 AM >> To: Henning Schulzrinne; Ben Campbell; Richard Shockey >> Cc: Modern List; McGarry, Tom >> Subject: RE: [Modern] Revised MODERN Charter >>=20 >>=20 >> David Holmes has made the point in the past that it is important to = list out what are the issues or problems to be solved that drive the = work effort. >>=20 >>=20 >>=20 >> To David's point, what are the flaws or inadequacies of the current = administration and conservation of the E.164 telephone numbers that = require or benefit from an IETF work group? i.e., what is wrong with = INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it? >>=20 >>=20 >>=20 >> My question is aimed specifically at the section in the charter which = reads: >>=20 >>=20 >>=20 >> The working group will define a framework for the roles and functions = involved in managing and resolving TNs in an IP environment. This = includes a protocol mechanism for acquiring TNs, which will provide an = enrollment process for the individuals and entities that use and manage = TNs. >>=20 >>=20 >>=20 >> Best regards, >>=20 >>=20 >>=20 >>=20 >>=20 >> Pierce Gorman >>=20 >> Core Network Planning >>=20 >> O: 913-439-4368 >>=20 >> pierce.gorman@sprint.com >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning = Schulzrinne >> Sent: April 25, 2015 7:37 AM >> To: Ben Campbell; Richard Shockey >> Cc: Modern List; McGarry, Tom >> Subject: Re: [Modern] Revised MODERN Charter >>=20 >>=20 >>=20 >> I'm not sure it matters if the identifier is numeric or not, but the = unifying principle seems to be that there is a clear delegation chain, = within a confined geographic (mostly in the legal sense, i.e., a = well-known set of national laws apply) scope. In particular, this = implies that the entities participating can generally be assumed to be = cooperative, as there is an umpire to remove any uncooperative players = from the field. >>=20 >>=20 >>=20 >> I don't think it's a priority, but SMS shortcodes seem similar enough = to fit into the same mechanism. >>=20 >>=20 >>=20 >> To avoid needless ambiguity, simply saying E.164 numbers and leaving = the door open to other identifiers that happen to fit might work. >>=20 >>=20 >>=20 >> ________________________________________ >>=20 >> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell = [ben@nostrum.com] >>=20 >> Sent: Friday, April 24, 2015 5:09 PM >>=20 >> To: Richard Shockey >>=20 >> Cc: Modern List; McGarry, Tom >>=20 >> Subject: Re: [Modern] Revised MODERN Charter >>=20 >>=20 >>=20 >> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>=20 >>=20 >>=20 >>> Out hopefully=C5=A0that is a private proprietary namespace. >>=20 >>=20 >> Okay, so Skype IDs were a bad example--but my question was about = whether the "other telephony related identifiers" were still assumed to = be things that look like TNs. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> Modern mailing list >>=20 >> Modern@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/modern >>=20 >> ________________________________ >>=20 >> 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. >>=20 >> ________________________________ >>=20 >> 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. >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_EB8EAC5D-D59A-47AC-89CF-3C8E57F25094 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQl8VAAoJEDY/T2tCIPW3MK8P/R1hTAW69yPeJ4dml/cVnFDu zaSClRTkZPsBJ3v9/BjPUacbxxnXdsNTN1+z1bZwTcsq52xdVDMEileeoImavSIN eH1Bk6oFwqC2dS9c6FFGvLls9dKGcH6u9AtcAY0jMqefPiaH4rXaz3fBjuUAGwKV DidLlzrNtL5XxIg6/z/0uZPnOUfH8CjK93Ph9FJwdeEYd5uubgmue9SHnyzcLlwW PBzjpyjDbVpXsFTckHH4u57hDOzbltf7kEPcQQKm27VT8i9ZVFpt5/3r+oGZ0tQD zy92dtAoUarLBOOJPU2CphLieDvYM5IMa5jCKJlles6jaY0FldxFUYPDM8b3C8rZ hJP9GYvQKBXCLrpDKOGUAdHDI9VXu2Y+ypHsFRKIQtzNZF7m5aNyRBb3jrmE1YT7 401dr4i4qVX6pTXdDRQusGoF9/3uuJ/Rr/gJS5TiM0zew14DRVaeEMmFwXtQS8BI +AhhZrNLQTpXycoSDdEGZGXCo0OsUOmXsIVJEPpMVgbM8O1uaTiFBMYYmfJAIV/w 9cV+45CxgmtCC7OEF/c8MYOl+EZepOKvyjlIncRWZMPIqF6nJ9vu6ZbTqeENMvsr mMV3U0bPSWruE0Cp5I/x3kQjvN21Qf2H7mSMa81fP07OWSi2ACfeHMZXTOCuo+7Y y798bl48M3S+v2Ql+aug =unKU -----END PGP SIGNATURE----- --Apple-Mail=_EB8EAC5D-D59A-47AC-89CF-3C8E57F25094-- From nobody Thu Apr 30 10:10:22 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199511B2D98 for ; Thu, 30 Apr 2015 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_Ihu4YS_vK5 for ; Thu, 30 Apr 2015 10:10:17 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753B21B2DA2 for ; Thu, 30 Apr 2015 10:10:17 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:53938 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnryY-000184-BG for modern@ietf.org; Thu, 30 Apr 2015 10:10:16 -0700 Message-ID: <554261F5.3090404@usdonovans.com> Date: Thu, 30 Apr 2015 12:10:13 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <55424844.9040700@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] A revised revised MODERN charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:10:19 -0000 Jon, In my mind a well defined and discrete charter is better than an open ended one. I don't think the group will benefit from spending a lot of time arguing about what constitutes a telephone number. It would be better to have a list of telephone number identifiers that we consider in scope. I'm open to having that list contain more than one item, I just don't think it shouldn't be open ended. The existing wording doesn't say that any defined mechanisms can't be extensible. It says that the current iteration of the MODERN working group will not be responsible for defining those extensions. If we need to add something to the charter saying that any architectures/frameworks/protocols/data models created by the working group should be extensible then we should, by all means, add that wording. More inline. Steve On 4/30/15 11:24 AM, Peterson, Jon wrote: > While I understand the desire to scope identifiers in the charter per the > recent thread, I think putting it this starkly is too restrictive: > >> Any such >> extensions or reuse of MODERN mechanisms are out of scope for the MODERN >> working group. > I mean, I thought we were going to define an extensible query-response > protocol in this working group for managing data about telephone numbers. > Something that would look at least vaguely like what is in > draft-peterson-terq. From this reading, I could easily argue that TeRQ is > outside the scope of MODERN precisely because it is extensible to other > identifiers. SRD> See my comment above. > > >From the recent thread, I had thought people were arguing for some gating. > Like "first, this working group is going to define a mechanism for > telephone numbers. The group may later recharter to work on other things." > I would be okay with some text along those lines, though frankly, I would > prefer the second sentence read more like, "this group is also chartered > to further investigate the use of other identifiers for the purpose of an > eventual recharter," since I think the expertise to scope the work on > identifiers resides on this mailing list and we should explicitly use it > for that purpose. SRD> I'm ok with adding a work item along the lines that you articulate above. It should come after the primary work items are finished. > > > Also, in that same paragraph I'd prefer not to qualify "telephone numbers" > with "E.164". This seems to come up again and again, but, there are a lot > of telephone numbers we care about that do to fall under the E.164 plan. > The earlier charter text doesn't say E.164, and I don't see why this part > needs to either. Let's just keep it to "telephone numbers." SRD> I assume you mean "do not fall under...". Let's list the ones that we care about in the charter. If we miss any that are architecturally significant then we can recharter and pull them in. > > Jon Peterson > Neustar, Inc. > > On 4/30/15, 8:20 AM, "Steve Donovan" wrote: > >> The following is the latest proposed version of the MODERN working group >> charter with updates discussed on the list discussion so far. >> >> Regards, >> >> Steve >> >> ---------- >> >> CHARTER TEXT: >> >> The MODERN working group will define a set of Internet-based mechanisms >> for the purposes of managing and resolving telephone numbers (TNs) in an >> IP environment. Existing mechanisms for these purposes face >> obsolescence as the voice communications infrastructure evolves to IP >> technology and new applications for TNs become possible. The >> traditional model of a TN having an association to a single service >> provider and a single application is breaking down. Its use as a >> network locator is going away, but its use as an identifier for an >> individual or an organization will remain for some time. Devices, >> applications, and network tools increasingly need to manage TNs, >> including requesting and acquiring TN delegations from authorities. A >> sample of problems with existing mechanisms include: >> >> - lack of flexibility (for example, it can be difficult to add fields >> without a very elaborate and lengthy process typically spanning years) >> - lack of distribution (for example, it is hard or impossible to have >> more than one administrator for each database) >> - complexity (leading, for example, to a fair amount of rural call >> completion problems which aren't helped by small providers struggling to >> keep numbers straight) >> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) >> and porting mechanisms >> >> The working group will define a framework for the roles and functions >> involved in managing and resolving TNs in an IP environment. It will >> also define protocol mechanisms for acquiring and resolving TNs. The >> protocol mechanism for acquiring TNs will provide an enrollment process >> for the individuals and entities that use and manage TNs. TNs may either >> be managed in a hierarchical tree, or in a distributed peer-to-peer >> architecture. Privacy of the enrollment data and security of the >> resource will be primary considerations. The protocol mechanism for >> resolving TNs will allow entities such as service providers, devices, >> and applications to access data related to TNs, possibly including >> caller name data (CNAM). Maintaining reliability, real time application >> performance, security and privacy are primary considerations. The >> working group will take into consideration existing IETF work including >> ENUM, SPEERMINT, and DRINKS. >> >> The work of this group will focus on E.164 telephone numbers due to the >> changing telecom environment and interest expressed by >> telecommunications industry regulators to support more flexible >> regulatory models than exist today. There is an expectation that >> aspects of the architecture and protocols defined by the working group >> will be reusable for other user-focused identifiers. Any such >> extensions or reuse of MODERN mechanisms are out of scope for the MODERN >> working group. Solutions and mechanisms created by the working group >> will be flexible enough to accommodate different policies, e.g., by >> different regulatory agencies. >> >> The work group will deliver the following: >> >> - An architecture overview, including high level requirements and >> security/privacy considerations >> >> - A description of the enrollment processes for existing and new >> TNs including any modifications to metadata related to those TNs >> >> - A description of protocol mechanisms for accessing contact >> information associated with enrollments >> >> - A description of mechanisms for resolving information related to >> TNs >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern > From nobody Thu Apr 30 10:17:53 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6571B2E5A for ; Thu, 30 Apr 2015 10:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hug8Pxkoy-Pk for ; Thu, 30 Apr 2015 10:17:49 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABB11A889C for ; Thu, 30 Apr 2015 10:17:49 -0700 (PDT) Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:54003 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yns5p-000ANj-Kq for modern@ietf.org; Thu, 30 Apr 2015 10:17:48 -0700 Message-ID: <554263B9.6000804@usdonovans.com> Date: Thu, 30 Apr 2015 12:17:45 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: modern@ietf.org References: <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> <55421D27.7020905@usdonovans.com> <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> In-Reply-To: <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> Content-Type: multipart/alternative; boundary="------------050204040101010805000705" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Revised MODERN Charter X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:17:52 -0000 This is a multi-part message in MIME format. --------------050204040101010805000705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Eric, My assertion of significant support (I'll not use the word unanimous as Kieth has pointed out it isn't correctly used in this context) was in the answer to question 5. From the minutes: Q5: Does the community think that, given the charter discussion, a WG should be formed? Consensus: Yes, but charter needs work. Earlier questions had less clear consensus. My recollection of this question was that I did not hear any hums in the negative. Steve On 4/30/15 11:57 AM, Eric Burger wrote: > Let me reiterate. Read the minutes! > > There was nothing anywhere near strong consensus, no less unanimous consensus, the IETF should do the work. > > The consensus we did come to was that the work in the charter as presented at the BOF was NOT necessarily useful or well-scoped. I do not think anyone disputed whether it was solvable. Likewise, it was one of those 49-51, you had to be there, when it came to whether to form a work group. > > What I am reading on the list is people are falling more on the side of “not useful.” I will follow-up with what I think will be useful in a separate email thread. > > >> On Apr 30, 2015, at 8:16 AM, Steve Donovan wrote: >> >> Pierce, >> >> I don't understand the relevance of your question. >> >> The scope of work for the MODERN working group was discussed at the MODERN BOF during IETF 92. Consensus was reached that the IETF should do the work outlined in the charter. If I recall correctly the response to that question was unanimous but it is possible that I missed some isolated negative hums. This consensus clearly includes protocol work. Whether they are new protocols depends on what the working group produces. >> >> The primary open question that needed to be addressed in the charter was the set of identifiers that the working group would address. Thus the proposal to limit the scope of work to E.164 numbers. >> >> You can find the minutes from the meeting here: >> >> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern >> >> Regards, >> >> Steve >> >> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote: >>> Thank you Henning. Your list of general notions is what I was encouraging Steve Donovan, et al, to do. >>> >>> I didn't volunteer any items even though I could think of some because I'm not convinced the MODERN WG needs to include in its charter anything to do with respect to "managing" E.164 telephone numbers. >>> >>> As you say, "nobody would design a new system to replicate what has evolved over decades". >>> >>> I think your list of notions is useful input, but it would seem like it ought to be directed at the existing organization(s) with authority and responsibility to manage E.164 telephone numbers. >>> >>> If they identify (or have identified already) a need for new protocols (really?) or request that the IETF develop a framework, then certainly MODERN could be a good place to respond to that request. Has that happened? >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 M: 816-210-8623 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >>> Sent: April 29, 2015 6:38 AM >>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: RE: [Modern] Revised MODERN Charter >>> >>> Pierce, >>> >>> since you and your organization probably have first-hand experience with the existing system, particularly as you transition to all-IP, I'd be very interested in hearing what you see as deficiencies or problems. >>> >>> My general take is that just about anything can be made to work ("with enough thrust, pigs can fly"), but that I suspect nobody would design a new system to replicate what has evolved over decades. I'm not sure the charter has to spell out every problem in detail, but a general motivation seems useful. >>> >>> My general notions are: >>> - lack of flexibility (e.g., difficult to add fields without a very elaborate and lengthy process typically spanning years) >>> - lack of distribution (hard or impossible to have more than one administrator for each database) >>> - complexity (we hear a fair amount about rural call completion problems which aren't helped by small providers struggling to keep numbers straight) >>> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms >>> >>> Henning >>> >>> ________________________________ >>> From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com] >>> Sent: Monday, April 27, 2015 10:36 AM >>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: RE: [Modern] Revised MODERN Charter >>> >>> >>> David Holmes has made the point in the past that it is important to list out what are the issues or problems to be solved that drive the work effort. >>> >>> >>> >>> To David's point, what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group? i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it? >>> >>> >>> >>> My question is aimed specifically at the section in the charter which reads: >>> >>> >>> >>> The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. >>> >>> >>> >>> Best regards, >>> >>> >>> >>> >>> >>> Pierce Gorman >>> >>> Core Network Planning >>> >>> O: 913-439-4368 >>> >>> pierce.gorman@sprint.com >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzrinne >>> Sent: April 25, 2015 7:37 AM >>> To: Ben Campbell; Richard Shockey >>> Cc: Modern List; McGarry, Tom >>> Subject: Re: [Modern] Revised MODERN Charter >>> >>> >>> >>> I'm not sure it matters if the identifier is numeric or not, but the unifying principle seems to be that there is a clear delegation chain, within a confined geographic (mostly in the legal sense, i.e., a well-known set of national laws apply) scope. In particular, this implies that the entities participating can generally be assumed to be cooperative, as there is an umpire to remove any uncooperative players from the field. >>> >>> >>> >>> I don't think it's a priority, but SMS shortcodes seem similar enough to fit into the same mechanism. >>> >>> >>> >>> To avoid needless ambiguity, simply saying E.164 numbers and leaving the door open to other identifiers that happen to fit might work. >>> >>> >>> >>> ________________________________________ >>> >>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com] >>> >>> Sent: Friday, April 24, 2015 5:09 PM >>> >>> To: Richard Shockey >>> >>> Cc: Modern List; McGarry, Tom >>> >>> Subject: Re: [Modern] Revised MODERN Charter >>> >>> >>> >>> On 24 Apr 2015, at 15:43, Richard Shockey wrote: >>> >>> >>> >>>> Out hopefullyŠthat is a private proprietary namespace. >>> >>> Okay, so Skype IDs were a bad example--but my question was about whether the "other telephony related identifiers" were still assumed to be things that look like TNs. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Modern mailing list >>> >>> Modern@ietf.org >>> >>> 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. >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --------------050204040101010805000705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Eric,

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

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

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

    Steve

    On 4/30/15 11:57 AM, Eric Burger wrote:
    Let me reiterate. Read the minutes!

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

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

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



    On Apr 30, 2015, at 8:16 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Pierce,

I don't understand the relevance of your question.

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

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

You can find the minutes from the meeting here:

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

Regards,

Steve

On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:

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

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

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

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

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

Best regards,


Pierce Gorman
Core Network Planning
O: 913-439-4368  M: 816-210-8623
pierce.gorman@sprint.com


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

Pierce,

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

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

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

Henning

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


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



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



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



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



Best regards,





Pierce Gorman

Core Network Planning

O: 913-439-4368

pierce.gorman@sprint.com





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



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



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



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



________________________________________

From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com]

Sent: Friday, April 24, 2015 5:09 PM

To: Richard Shockey

Cc: Modern List; McGarry, Tom

Subject: Re: [Modern] Revised MODERN Charter



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




    Out hopefullyŠthat is a private proprietary namespace.

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





_______________________________________________

Modern mailing list

Modern@ietf.org<mailto:Modern@ietf.org>

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.

________________________________

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

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern


    _______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    
      
    
      
    
      
    
      
    _______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    
    
    
    
    
  


--------------050204040101010805000705--


From nobody Thu Apr 30 10:19:29 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E01B2E60 for ; Thu, 30 Apr 2015 10:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wmb88PrewcA for ; Thu, 30 Apr 2015 10:19:27 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E30F1B2E5A for ; Thu, 30 Apr 2015 10:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=lwBDBiHctdxM6kYyTLloA7PQAZGYVCguIR1uFj1m/70=;  b=XGicW5HAx4KV1xqyq7oc9jF3p0WFaQbVZucAJ7dH6bO+QRnI24yJwY9siPhLbbWWZ43Ai2UnmlGeJdD+TU5gJpv8yskx80uWRXJPhRdkV/dXWuA4XqSkAl1K8+z9l/X8yC8RkXOq8XDvvf+amll6PQ2Cm8dDRrAExDqnG1L+oTo=;
Received: from [141.161.20.228] (port=57105) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Yns7R-0001g5-7u for modern@ietf.org; Thu, 30 Apr 2015 10:19:26 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_7D2DA56A-3BF4-40C0-B7E7-47939338F7D0"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Date: Thu, 30 Apr 2015 13:19:22 -0400
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com>       <55421D27.7020905@usdonovans.com> <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> <554263B9.6000804@usdonovans.com>
To: modern@ietf.org
In-Reply-To: <554263B9.6000804@usdonovans.com>
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 17:19:29 -0000

--Apple-Mail=_7D2DA56A-3BF4-40C0-B7E7-47939338F7D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Without consensus on Q1-4, is Q5 relevant?

> On Apr 30, 2015, at 1:17 PM, Steve Donovan  =
wrote:
>=20
> Eric,
>=20
> My assertion of significant support (I'll not use the word unanimous =
as Kieth has pointed out it isn't correctly used in this context) was in =
the answer to question 5.  =46rom the minutes:
>=20
> Q5: Does the community think that, given the charter discussion, a WG=20=

> should be formed?
> Consensus:=20
> Yes, but charter needs work.
>=20
> Earlier questions had less clear consensus.  My recollection of this =
question was that I did not hear any hums in the negative.
>=20
> Steve
>=20
> On 4/30/15 11:57 AM, Eric Burger wrote:
>> Let me reiterate. Read the minutes!
>>=20
>> There was nothing anywhere near strong consensus, no less unanimous =
consensus, the IETF should do the work.
>>=20
>> The consensus we did come to was that the work in the charter as =
presented at the BOF was NOT necessarily useful or well-scoped. I do not =
think anyone disputed whether it was solvable. Likewise, it was one of =
those 49-51, you had to be there, when it came to whether to form a work =
group.
>>=20
>> What I am reading on the list is people are falling more on the side =
of =93not useful.=94 I will follow-up with what I think will be useful =
in a separate email thread.
>>=20
>>=20
>>=20
>>> On Apr 30, 2015, at 8:16 AM, Steve Donovan =

>>>  wrote:
>>>=20
>>> Pierce,
>>>=20
>>> I don't understand the relevance of your question.
>>>=20
>>> The scope of work for the MODERN working group was discussed at the =
MODERN BOF during IETF 92.  Consensus was reached that the IETF should =
do the work outlined in the charter.  If I recall correctly the response =
to that question was unanimous but it is possible that I missed some =
isolated negative hums.  This consensus clearly includes protocol work.  =
Whether they are new protocols depends on what the working group =
produces.
>>>=20
>>> The primary open question that needed to be addressed in the charter =
was the set of identifiers that the working group would address. Thus =
the proposal to limit the scope of work to E.164 numbers.
>>>=20
>>> You can find the minutes from the meeting here:
>>>=20
>>>=20
>>> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern
>>>=20
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:
>>>=20
>>>> Thank you Henning.  Your list of general notions is what I was =
encouraging Steve Donovan, et al, to do.
>>>>=20
>>>> I didn't volunteer any items even though I could think of some =
because I'm not convinced the MODERN WG needs to include in its charter =
anything to do with respect to "managing" E.164 telephone numbers.
>>>>=20
>>>> As you say, "nobody would design a new system to replicate what has =
evolved over decades".
>>>>=20
>>>> I think your list of notions is useful input, but it would seem =
like it ought to be directed at the existing organization(s) with =
authority and responsibility to manage E.164 telephone numbers.
>>>>=20
>>>> If they identify (or have identified already) a need for new =
protocols (really?) or request that the IETF develop a framework, then =
certainly MODERN could be a good place to respond to that request.  Has =
that happened?
>>>>=20
>>>> Best regards,
>>>>=20
>>>>=20
>>>> Pierce Gorman
>>>> Core Network Planning
>>>> O: 913-439-4368  M: 816-210-8623
>>>>=20
>>>> pierce.gorman@sprint.com
>>>>=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Henning Schulzrinne [
>>>> mailto:Henning.Schulzrinne@fcc.gov
>>>> ]
>>>> Sent: April 29, 2015 6:38 AM
>>>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
>>>> Cc: Modern List; McGarry, Tom
>>>> Subject: RE: [Modern] Revised MODERN Charter
>>>>=20
>>>> Pierce,
>>>>=20
>>>> since you and your organization probably have first-hand experience =
with the existing system, particularly as you transition to all-IP, I'd =
be very interested in hearing what you see as deficiencies or problems.
>>>>=20
>>>> My general take is that just about anything can be made to work =
("with enough thrust, pigs can fly"), but that I suspect nobody would =
design a new system to replicate what has evolved over decades. I'm not =
sure the charter has to spell out every problem in detail, but a general =
motivation seems useful.
>>>>=20
>>>> My general notions are:
>>>> - lack of flexibility (e.g., difficult to add fields without a very =
elaborate and lengthy process typically spanning years)
>>>> - lack of distribution (hard or impossible to have more than one =
administrator for each database)
>>>> - complexity (we hear a fair amount about rural call completion =
problems which aren't helped by small providers struggling to keep =
numbers straight)
>>>> - difficulty of adopting more modern allocation (e.g., "blocks" of =
1) and porting mechanisms
>>>>=20
>>>> Henning
>>>>=20
>>>> ________________________________
>>>> From: Gorman, Pierce A [CTO] [
>>>> Pierce.Gorman@sprint.com
>>>> ]
>>>> Sent: Monday, April 27, 2015 10:36 AM
>>>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey
>>>> Cc: Modern List; McGarry, Tom
>>>> Subject: RE: [Modern] Revised MODERN Charter
>>>>=20
>>>>=20
>>>> David Holmes has made the point in the past that it is important to =
list out what are the issues or problems to be solved that drive the =
work effort.
>>>>=20
>>>>=20
>>>>=20
>>>> To David's point, what are the flaws or inadequacies of the current =
administration and conservation of the E.164 telephone numbers that =
require or benefit from an IETF work group?  i.e., what is wrong with =
INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
>>>>=20
>>>>=20
>>>>=20
>>>> My question is aimed specifically at the section in the charter =
which reads:
>>>>=20
>>>>=20
>>>>=20
>>>> The working group will define a framework for the roles and =
functions involved in managing and resolving TNs in an IP environment. =
This includes a protocol mechanism for acquiring TNs, which will provide =
an enrollment process for the individuals and entities that use and =
manage TNs.
>>>>=20
>>>>=20
>>>>=20
>>>> Best regards,
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Pierce Gorman
>>>>=20
>>>> Core Network Planning
>>>>=20
>>>> O: 913-439-4368
>>>>=20
>>>>=20
>>>> pierce.gorman@sprint.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Modern [
>>>> mailto:modern-bounces@ietf.org
>>>> ] On Behalf Of Henning Schulzrinne
>>>> Sent: April 25, 2015 7:37 AM
>>>> To: Ben Campbell; Richard Shockey
>>>> Cc: Modern List; McGarry, Tom
>>>> Subject: Re: [Modern] Revised MODERN Charter
>>>>=20
>>>>=20
>>>>=20
>>>> I'm not sure it matters if the identifier is numeric or not, but =
the unifying principle seems to be that there is a clear delegation =
chain, within a confined geographic (mostly in the legal sense, i.e., a =
well-known set of national laws apply) scope. In particular, this =
implies that the entities participating can generally be assumed to be =
cooperative, as there is an umpire to remove any uncooperative players =
from the field.
>>>>=20
>>>>=20
>>>>=20
>>>> I don't think it's a priority, but SMS shortcodes seem similar =
enough to fit into the same mechanism.
>>>>=20
>>>>=20
>>>>=20
>>>> To avoid needless ambiguity, simply saying E.164 numbers and =
leaving the door open to other identifiers that happen to fit might =
work.
>>>>=20
>>>>=20
>>>>=20
>>>> ________________________________________
>>>>=20
>>>> From: Modern [
>>>> modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com
>>>> ]
>>>>=20
>>>> Sent: Friday, April 24, 2015 5:09 PM
>>>>=20
>>>> To: Richard Shockey
>>>>=20
>>>> Cc: Modern List; McGarry, Tom
>>>>=20
>>>> Subject: Re: [Modern] Revised MODERN Charter
>>>>=20
>>>>=20
>>>>=20
>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> Out hopefully=8Athat is a private proprietary namespace.
>>>>>=20
>>>>=20
>>>> Okay, so Skype IDs were a bad example--but my question was about =
whether the "other telephony related identifiers" were still assumed to =
be things that look like TNs.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>>=20
>>>> Modern mailing list
>>>>=20
>>>>=20
>>>> Modern@ietf.org
>>>>=20
>>>>=20
>>>>=20
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>=20
>>>>=20
>>>> ________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> ________________________________
>>>>=20
>>>> 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.
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>>=20
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>=20
>>>>=20
>>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>>=20
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>>=20
>> _______________________________________________
>> Modern mailing list
>>=20
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--Apple-Mail=_7D2DA56A-3BF4-40C0-B7E7-47939338F7D0
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw
ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla
MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY
jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6
iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw
F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1
4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB
8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+
kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD
VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF
BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt
GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do
Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT
ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln
m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX
cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB
QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy
dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW
sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K
+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr
LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn
vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD
CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0
uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB
7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq
R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK
tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0
MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE
jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG
BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0
RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j
c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y
dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY
fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH
DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1
a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm
7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI
5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R
KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4
yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6
Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j
BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA
MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM
BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j
cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP
omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y
78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl
pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa
SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3
1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h
z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5
PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU
mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8
YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ
BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x
NTA0MzAxNzE5MjRaMCMGCSqGSIb3DQEJBDEWBBS/Ukcp9bT6iLyyKBcKTBhBnTCh4jCBvgYJKwYB
BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43
HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA
BG6PKNbqHeNTr6VOTH/hSHxDVMzZwV+ICZ1sa48Z+m4pt8GWZ6fLsl3rDA9M6jfK0SnsXJeK4TFG
8Gnjb5+n9XX9EYGhw0Fyh6iAqJdVGs0zJoXoqCjubH9Sdd+OQeyOQpLyk/eD0AUtk0mEZgfgdga+
iXmjPQlL2hVDV1WqP2pXvaYNFCSSORddHGc/Cbl341aF4gm4xbiciJ/vAe87jKGe2kUmDSD5CZVo
Auo+mEekdiKrWdbFZ/eev6VXzPKfr/5dIvInoMCmusshx4d8XjSymq3bds0OHhbubfB5lbgNdLcJ
nM0om6gZmWtOSAoOuoRgonnDQk45lDyvAVMZVQAAAAAAAA==
--Apple-Mail=_7D2DA56A-3BF4-40C0-B7E7-47939338F7D0--


From nobody Thu Apr 30 10:28:10 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63311A1A15 for ; Thu, 30 Apr 2015 10:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ercBVhbAuT3H for ; Thu, 30 Apr 2015 10:28:05 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2B21A8729 for ; Thu, 30 Apr 2015 10:28:05 -0700 (PDT)
Received: from cpe-76-183-208-111.tx.res.rr.com ([76.183.208.111]:54063 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnsFm-000AN2-Aq for modern@ietf.org; Thu, 30 Apr 2015 10:28:05 -0700
Message-ID: <55426621.3030304@usdonovans.com>
Date: Thu, 30 Apr 2015 12:28:01 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: modern@ietf.org
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com>       <55421D27.7020905@usdonovans.com> <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> <554263B9.6000804@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020407010300040108090804"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 17:28:09 -0000

This is a multi-part message in MIME format.
--------------020407010300040108090804
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Questions 1 and 2 were about the charter.

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

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

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

Steve

On 4/30/15 12:19 PM, Eric Burger wrote:
> Without consensus on Q1-4, is Q5 relevant?
>
>> On Apr 30, 2015, at 1:17 PM, Steve Donovan  wrote:
>>
>> Eric,
>>
>> My assertion of significant support (I'll not use the word unanimous as Kieth has pointed out it isn't correctly used in this context) was in the answer to question 5.  From the minutes:
>>
>> Q5: Does the community think that, given the charter discussion, a WG
>> should be formed?
>> Consensus:
>> Yes, but charter needs work.
>>
>> Earlier questions had less clear consensus.  My recollection of this question was that I did not hear any hums in the negative.
>>
>> Steve
>>
>> On 4/30/15 11:57 AM, Eric Burger wrote:
>>> Let me reiterate. Read the minutes!
>>>
>>> There was nothing anywhere near strong consensus, no less unanimous consensus, the IETF should do the work.
>>>
>>> The consensus we did come to was that the work in the charter as presented at the BOF was NOT necessarily useful or well-scoped. I do not think anyone disputed whether it was solvable. Likewise, it was one of those 49-51, you had to be there, when it came to whether to form a work group.
>>>
>>> What I am reading on the list is people are falling more on the side of “not useful.” I will follow-up with what I think will be useful in a separate email thread.
>>>
>>>
>>>
>>>> On Apr 30, 2015, at 8:16 AM, Steve Donovan 
>>>>   wrote:
>>>>
>>>> Pierce,
>>>>
>>>> I don't understand the relevance of your question.
>>>>
>>>> The scope of work for the MODERN working group was discussed at the MODERN BOF during IETF 92.  Consensus was reached that the IETF should do the work outlined in the charter.  If I recall correctly the response to that question was unanimous but it is possible that I missed some isolated negative hums.  This consensus clearly includes protocol work.  Whether they are new protocols depends on what the working group produces.
>>>>
>>>> The primary open question that needed to be addressed in the charter was the set of identifiers that the working group would address. Thus the proposal to limit the scope of work to E.164 numbers.
>>>>
>>>> You can find the minutes from the meeting here:
>>>>
>>>>
>>>> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:
>>>>
>>>>> Thank you Henning.  Your list of general notions is what I was encouraging Steve Donovan, et al, to do.
>>>>>
>>>>> I didn't volunteer any items even though I could think of some because I'm not convinced the MODERN WG needs to include in its charter anything to do with respect to "managing" E.164 telephone numbers.
>>>>>
>>>>> As you say, "nobody would design a new system to replicate what has evolved over decades".
>>>>>
>>>>> I think your list of notions is useful input, but it would seem like it ought to be directed at the existing organization(s) with authority and responsibility to manage E.164 telephone numbers.
>>>>>
>>>>> If they identify (or have identified already) a need for new protocols (really?) or request that the IETF develop a framework, then certainly MODERN could be a good place to respond to that request.  Has that happened?
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Pierce Gorman
>>>>> Core Network Planning
>>>>> O: 913-439-4368  M: 816-210-8623
>>>>>
>>>>> pierce.gorman@sprint.com
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Henning Schulzrinne [
>>>>> mailto:Henning.Schulzrinne@fcc.gov
>>>>> ]
>>>>> Sent: April 29, 2015 6:38 AM
>>>>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
>>>>> Cc: Modern List; McGarry, Tom
>>>>> Subject: RE: [Modern] Revised MODERN Charter
>>>>>
>>>>> Pierce,
>>>>>
>>>>> since you and your organization probably have first-hand experience with the existing system, particularly as you transition to all-IP, I'd be very interested in hearing what you see as deficiencies or problems.
>>>>>
>>>>> My general take is that just about anything can be made to work ("with enough thrust, pigs can fly"), but that I suspect nobody would design a new system to replicate what has evolved over decades. I'm not sure the charter has to spell out every problem in detail, but a general motivation seems useful.
>>>>>
>>>>> My general notions are:
>>>>> - lack of flexibility (e.g., difficult to add fields without a very elaborate and lengthy process typically spanning years)
>>>>> - lack of distribution (hard or impossible to have more than one administrator for each database)
>>>>> - complexity (we hear a fair amount about rural call completion problems which aren't helped by small providers struggling to keep numbers straight)
>>>>> - difficulty of adopting more modern allocation (e.g., "blocks" of 1) and porting mechanisms
>>>>>
>>>>> Henning
>>>>>
>>>>> ________________________________
>>>>> From: Gorman, Pierce A [CTO] [
>>>>> Pierce.Gorman@sprint.com
>>>>> ]
>>>>> Sent: Monday, April 27, 2015 10:36 AM
>>>>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey
>>>>> Cc: Modern List; McGarry, Tom
>>>>> Subject: RE: [Modern] Revised MODERN Charter
>>>>>
>>>>>
>>>>> David Holmes has made the point in the past that it is important to list out what are the issues or problems to be solved that drive the work effort.
>>>>>
>>>>>
>>>>>
>>>>> To David's point, what are the flaws or inadequacies of the current administration and conservation of the E.164 telephone numbers that require or benefit from an IETF work group?  i.e., what is wrong with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
>>>>>
>>>>>
>>>>>
>>>>> My question is aimed specifically at the section in the charter which reads:
>>>>>
>>>>>
>>>>>
>>>>> The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs.
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Pierce Gorman
>>>>>
>>>>> Core Network Planning
>>>>>
>>>>> O: 913-439-4368
>>>>>
>>>>>
>>>>> pierce.gorman@sprint.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Modern [
>>>>> mailto:modern-bounces@ietf.org
>>>>> ] On Behalf Of Henning Schulzrinne
>>>>> Sent: April 25, 2015 7:37 AM
>>>>> To: Ben Campbell; Richard Shockey
>>>>> Cc: Modern List; McGarry, Tom
>>>>> Subject: Re: [Modern] Revised MODERN Charter
>>>>>
>>>>>
>>>>>
>>>>> I'm not sure it matters if the identifier is numeric or not, but the unifying principle seems to be that there is a clear delegation chain, within a confined geographic (mostly in the legal sense, i.e., a well-known set of national laws apply) scope. In particular, this implies that the entities participating can generally be assumed to be cooperative, as there is an umpire to remove any uncooperative players from the field.
>>>>>
>>>>>
>>>>>
>>>>> I don't think it's a priority, but SMS shortcodes seem similar enough to fit into the same mechanism.
>>>>>
>>>>>
>>>>>
>>>>> To avoid needless ambiguity, simply saying E.164 numbers and leaving the door open to other identifiers that happen to fit might work.
>>>>>
>>>>>
>>>>>
>>>>> ________________________________________
>>>>>
>>>>> From: Modern [
>>>>> modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com
>>>>> ]
>>>>>
>>>>> Sent: Friday, April 24, 2015 5:09 PM
>>>>>
>>>>> To: Richard Shockey
>>>>>
>>>>> Cc: Modern List; McGarry, Tom
>>>>>
>>>>> Subject: Re: [Modern] Revised MODERN Charter
>>>>>
>>>>>
>>>>>
>>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Out hopefullyŠthat is a private proprietary namespace.
>>>>>>
>>>>> Okay, so Skype IDs were a bad example--but my question was about whether the "other telephony related identifiers" were still assumed to be things that look like TNs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Modern mailing list
>>>>>
>>>>>
>>>>> Modern@ietf.org
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> ________________________________
>>>>>
>>>>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>>>>>
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>>
>>>>> Modern@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Modern mailing list
>>>>
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>
>>> _______________________________________________
>>> Modern mailing list
>>>
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


--------------020407010300040108090804
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Questions 1 and 2 were about the charter.
    
    
    
    Questions 3 and 4 were not consensus questions, they were asking if
    people were willing to do the work.  
    
    
    
    Question 5 was about the need to form a working group.
    
    
    
    Personally, I consider the combined answers to questions 3-5 to be
    relevant.  This is, of course, contingent upon fixing the charter.
    
    
    
    Steve
    
    
    
    
    On 4/30/15 12:19 PM, Eric Burger wrote:
    
    
    
    
    
      
    Without consensus on Q1-4, is Q5 relevant?


    
      
    
        
    On Apr 30, 2015, at 1:17 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Eric,

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

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

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

Steve

On 4/30/15 11:57 AM, Eric Burger wrote:

    
        
    
          
    Let me reiterate. Read the minutes!

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

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

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




    
          
    
            
    On Apr 30, 2015, at 8:16 AM, Steve Donovan <srdonovan@usdonovans.com>
 wrote:

Pierce,

I don't understand the relevance of your question.

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

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

You can find the minutes from the meeting here:


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


Regards,

Steve

On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:


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

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

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

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

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

Best regards,


Pierce Gorman
Core Network Planning
O: 913-439-4368  M: 816-210-8623

pierce.gorman@sprint.com



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

Pierce,

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

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

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

Henning

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


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



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



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



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



Best regards,





Pierce Gorman

Core Network Planning

O: 913-439-4368


pierce.gorman@sprint.com






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



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



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



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



________________________________________

From: Modern [
modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com
]

Sent: Friday, April 24, 2015 5:09 PM

To: Richard Shockey

Cc: Modern List; McGarry, Tom

Subject: Re: [Modern] Revised MODERN Charter



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





    
              
    
                
    Out hopefullyŠthat is a private proprietary namespace.


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





_______________________________________________

Modern mailing list


Modern@ietf.org<mailto:Modern@ietf.org>



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.

________________________________

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

_______________________________________________
Modern mailing list

Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern




    
            
    
            
    _______________________________________________
Modern mailing list

Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    
          
    
          
    
_______________________________________________
Modern mailing list

Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    
        
    
        
    _______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    
      
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

    
    
    
    
    
  


--------------020407010300040108090804--


From nobody Thu Apr 30 10:28:42 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CD71A8902 for ; Thu, 30 Apr 2015 10:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level: 
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DSJdCglEN6R for ; Thu, 30 Apr 2015 10:28:35 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9818B1A8969 for ; Thu, 30 Apr 2015 10:28:35 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t3UHP15d009669; Thu, 30 Apr 2015 13:28:35 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1u3a4r115y-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 13:28:35 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Thu, 30 Apr 2015 13:28:32 -0400
From: "Peterson, Jon" 
To: Eric Burger , "modern@ietf.org" 
Thread-Topic: [Modern] Revised MODERN Charter
Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOLPICAAq06o4AApb6AgAE80YCAAE6XAIAABYqAgAAAcwD//401AA==
Date: Thu, 30 Apr 2015 17:28:32 +0000
Message-ID: 
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com>       <55421D27.7020905@usdonovans.com> <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> <554263B9.6000804@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.129.89]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <89A9CA52F69D234FB755E183AC5BCF46@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-04-30_05:2015-04-29,2015-04-30,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=2.86215495748365e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504300207
Archived-At: 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 17:28:41 -0000

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

Jon Peterson
Neustar, Inc.

On 4/30/15, 10:19 AM, "Eric Burger"  wrote:

>Without consensus on Q1-4, is Q5 relevant?
>
>> On Apr 30, 2015, at 1:17 PM, Steve Donovan 
>>wrote:
>>=20
>> Eric,
>>=20
>> My assertion of significant support (I'll not use the word unanimous as
>>Kieth has pointed out it isn't correctly used in this context) was in
>>the answer to question 5.  From the minutes:
>>=20
>> Q5: Does the community think that, given the charter discussion, a WG
>> should be formed?
>> Consensus:=20
>> Yes, but charter needs work.
>>=20
>> Earlier questions had less clear consensus.  My recollection of this
>>question was that I did not hear any hums in the negative.
>>=20
>> Steve
>>=20
>> On 4/30/15 11:57 AM, Eric Burger wrote:
>>> Let me reiterate. Read the minutes!
>>>=20
>>> There was nothing anywhere near strong consensus, no less unanimous
>>>consensus, the IETF should do the work.
>>>=20
>>> The consensus we did come to was that the work in the charter as
>>>presented at the BOF was NOT necessarily useful or well-scoped. I do
>>>not think anyone disputed whether it was solvable. Likewise, it was one
>>>of those 49-51, you had to be there, when it came to whether to form a
>>>work group.
>>>=20
>>> What I am reading on the list is people are falling more on the side
>>>of "not useful." I will follow-up with what I think will be useful in a
>>>separate email thread.
>>>=20
>>>=20
>>>=20
>>>> On Apr 30, 2015, at 8:16 AM, Steve Donovan 
>>>>  wrote:
>>>>=20
>>>> Pierce,
>>>>=20
>>>> I don't understand the relevance of your question.
>>>>=20
>>>> The scope of work for the MODERN working group was discussed at the
>>>>MODERN BOF during IETF 92.  Consensus was reached that the IETF should
>>>>do the work outlined in the charter.  If I recall correctly the
>>>>response to that question was unanimous but it is possible that I
>>>>missed some isolated negative hums.  This consensus clearly includes
>>>>protocol work.  Whether they are new protocols depends on what the
>>>>working group produces.
>>>>=20
>>>> The primary open question that needed to be addressed in the charter
>>>>was the set of identifiers that the working group would address. Thus
>>>>the proposal to limit the scope of work to E.164 numbers.
>>>>=20
>>>> You can find the minutes from the meeting here:
>>>>=20
>>>>=20
>>>> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern
>>>>=20
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:
>>>>=20
>>>>> Thank you Henning.  Your list of general notions is what I was
>>>>>encouraging Steve Donovan, et al, to do.
>>>>>=20
>>>>> I didn't volunteer any items even though I could think of some
>>>>>because I'm not convinced the MODERN WG needs to include in its
>>>>>charter anything to do with respect to "managing" E.164 telephone
>>>>>numbers.
>>>>>=20
>>>>> As you say, "nobody would design a new system to replicate what has
>>>>>evolved over decades".
>>>>>=20
>>>>> I think your list of notions is useful input, but it would seem like
>>>>>it ought to be directed at the existing organization(s) with
>>>>>authority and responsibility to manage E.164 telephone numbers.
>>>>>=20
>>>>> If they identify (or have identified already) a need for new
>>>>>protocols (really?) or request that the IETF develop a framework,
>>>>>then certainly MODERN could be a good place to respond to that
>>>>>request.  Has that happened?
>>>>>=20
>>>>> Best regards,
>>>>>=20
>>>>>=20
>>>>> Pierce Gorman
>>>>> Core Network Planning
>>>>> O: 913-439-4368  M: 816-210-8623
>>>>>=20
>>>>> pierce.gorman@sprint.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Henning Schulzrinne [
>>>>> mailto:Henning.Schulzrinne@fcc.gov
>>>>> ]
>>>>> Sent: April 29, 2015 6:38 AM
>>>>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
>>>>> Cc: Modern List; McGarry, Tom
>>>>> Subject: RE: [Modern] Revised MODERN Charter
>>>>>=20
>>>>> Pierce,
>>>>>=20
>>>>> since you and your organization probably have first-hand experience
>>>>>with the existing system, particularly as you transition to all-IP,
>>>>>I'd be very interested in hearing what you see as deficiencies or
>>>>>problems.
>>>>>=20
>>>>> My general take is that just about anything can be made to work
>>>>>("with enough thrust, pigs can fly"), but that I suspect nobody would
>>>>>design a new system to replicate what has evolved over decades. I'm
>>>>>not sure the charter has to spell out every problem in detail, but a
>>>>>general motivation seems useful.
>>>>>=20
>>>>> My general notions are:
>>>>> - lack of flexibility (e.g., difficult to add fields without a very
>>>>>elaborate and lengthy process typically spanning years)
>>>>> - lack of distribution (hard or impossible to have more than one
>>>>>administrator for each database)
>>>>> - complexity (we hear a fair amount about rural call completion
>>>>>problems which aren't helped by small providers struggling to keep
>>>>>numbers straight)
>>>>> - difficulty of adopting more modern allocation (e.g., "blocks" of
>>>>>1) and porting mechanisms
>>>>>=20
>>>>> Henning
>>>>>=20
>>>>> ________________________________
>>>>> From: Gorman, Pierce A [CTO] [
>>>>> Pierce.Gorman@sprint.com
>>>>> ]
>>>>> Sent: Monday, April 27, 2015 10:36 AM
>>>>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey
>>>>> Cc: Modern List; McGarry, Tom
>>>>> Subject: RE: [Modern] Revised MODERN Charter
>>>>>=20
>>>>>=20
>>>>> David Holmes has made the point in the past that it is important to
>>>>>list out what are the issues or problems to be solved that drive the
>>>>>work effort.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> To David's point, what are the flaws or inadequacies of the current
>>>>>administration and conservation of the E.164 telephone numbers that
>>>>>require or benefit from an IETF work group?  i.e., what is wrong with
>>>>>INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> My question is aimed specifically at the section in the charter
>>>>>which reads:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> The working group will define a framework for the roles and
>>>>>functions involved in managing and resolving TNs in an IP
>>>>>environment. This includes a protocol mechanism for acquiring TNs,
>>>>>which will provide an enrollment process for the individuals and
>>>>>entities that use and manage TNs.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Best regards,
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Pierce Gorman
>>>>>=20
>>>>> Core Network Planning
>>>>>=20
>>>>> O: 913-439-4368
>>>>>=20
>>>>>=20
>>>>> pierce.gorman@sprint.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Modern [
>>>>> mailto:modern-bounces@ietf.org
>>>>> ] On Behalf Of Henning Schulzrinne
>>>>> Sent: April 25, 2015 7:37 AM
>>>>> To: Ben Campbell; Richard Shockey
>>>>> Cc: Modern List; McGarry, Tom
>>>>> Subject: Re: [Modern] Revised MODERN Charter
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I'm not sure it matters if the identifier is numeric or not, but the
>>>>>unifying principle seems to be that there is a clear delegation
>>>>>chain, within a confined geographic (mostly in the legal sense, i.e.,
>>>>>a well-known set of national laws apply) scope. In particular, this
>>>>>implies that the entities participating can generally be assumed to
>>>>>be cooperative, as there is an umpire to remove any uncooperative
>>>>>players from the field.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I don't think it's a priority, but SMS shortcodes seem similar
>>>>>enough to fit into the same mechanism.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> To avoid needless ambiguity, simply saying E.164 numbers and leaving
>>>>>the door open to other identifiers that happen to fit might work.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> ________________________________________
>>>>>=20
>>>>> From: Modern [
>>>>> modern-bounces@ietf.org] on behalf of Ben Campbell [ben@nostrum.com
>>>>> ]
>>>>>=20
>>>>> Sent: Friday, April 24, 2015 5:09 PM
>>>>>=20
>>>>> To: Richard Shockey
>>>>>=20
>>>>> Cc: Modern List; McGarry, Tom
>>>>>=20
>>>>> Subject: Re: [Modern] Revised MODERN Charter
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Out hopefully=A9that is a private proprietary namespace.
>>>>>>=20
>>>>>=20
>>>>> Okay, so Skype IDs were a bad example--but my question was about
>>>>>whether the "other telephony related identifiers" were still assumed
>>>>>to be things that look like TNs.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>>=20
>>>>> Modern mailing list
>>>>>=20
>>>>>=20
>>>>> Modern@ietf.org
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>=20
>>>>>=20
>>>>> ________________________________
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> ________________________________
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>>=20
>>>>> Modern@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>>>=20
>>>>>=20
>>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>>=20
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>=20
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>>=20
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>


From nobody Thu Apr 30 10:39:58 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483CF1A87A8 for ; Thu, 30 Apr 2015 10:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbbfQ_zcGX-P for ; Thu, 30 Apr 2015 10:39:53 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB671A1A11 for ; Thu, 30 Apr 2015 10:39:53 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3UHdfbW093377 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 12:39:52 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Steve Donovan" 
Date: Thu, 30 Apr 2015 12:39:41 -0500
Message-ID: <553D7900-80D8-4B8D-9260-06A195D02858@nostrum.com>
In-Reply-To: <554261F5.3090404@usdonovans.com>
References: <55424844.9040700@usdonovans.com>  <554261F5.3090404@usdonovans.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: modern@ietf.org
Subject: Re: [Modern] A revised revised MODERN charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 17:39:56 -0000

On 30 Apr 2015, at 12:10, Steve Donovan wrote:

> Jon,
>
> In my mind a well defined and discrete charter is better than an open 
> ended one.  I don't think the group will benefit from spending a lot 
> of time arguing about what constitutes a telephone number.  It would 
> be better to have a list of telephone number identifiers that we 
> consider in scope.  I'm open to having that list contain more than one 
> item, I just don't think it shouldn't be open ended.
>
> The existing wording doesn't say that any defined mechanisms can't be 
> extensible.  It says that the current iteration of the MODERN working 
> group will not be responsible for defining those extensions.  If we 
> need to add something to the charter saying that any 
> architectures/frameworks/protocols/data models created by the working 
> group should be extensible then we should, by all means, add that 
> wording.

I also read it that _extensions_ were out of scope, not necessarily 
_extensibility_.

Should we explicitly ask for extensibility?

>
> More inline.
>
> Steve
>
> On 4/30/15 11:24 AM, Peterson, Jon wrote:
>> While I understand the desire to scope identifiers in the charter per 
>> the
>> recent thread, I think putting it this starkly is too restrictive:
>>
>>> Any such
>>> extensions or reuse of MODERN mechanisms are out of scope for the 
>>> MODERN
>>> working group.
>> I mean, I thought we were going to define an extensible 
>> query-response
>> protocol in this working group for managing data about telephone 
>> numbers.
>> Something that would look at least vaguely like what is in
>> draft-peterson-terq. From this reading, I could easily argue that 
>> TeRQ is
>> outside the scope of MODERN precisely because it is extensible to 
>> other
>> identifiers.
> SRD> See my comment above.
>>
>> >From the recent thread, I had thought people were arguing for some 
>> gating.
>> Like "first, this working group is going to define a mechanism for
>> telephone numbers. The group may later recharter to work on other 
>> things."
>> I would be okay with some text along those lines, though frankly, I 
>> would
>> prefer the second sentence read more like, "this group is also 
>> chartered
>> to further investigate the use of other identifiers for the purpose 
>> of an
>> eventual recharter," since I think the expertise to scope the work on
>> identifiers resides on this mailing list and we should explicitly use 
>> it
>> for that purpose.
> SRD> I'm ok with adding a work item along the lines that you 
> articulate above.  It should come after the primary work items are 
> finished.
>>
>>
>> Also, in that same paragraph I'd prefer not to qualify "telephone 
>> numbers"
>> with "E.164". This seems to come up again and again, but, there are a 
>> lot
>> of telephone numbers we care about that do to fall under the E.164 
>> plan.
>> The earlier charter text doesn't say E.164, and I don't see why this 
>> part
>> needs to either. Let's just keep it to "telephone numbers."
> SRD> I assume you mean "do not fall under...".  Let's list the ones 
> that we care about in the charter.  If we miss any that are 
> architecturally significant then we can recharter and pull them in.
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>> On 4/30/15, 8:20 AM, "Steve Donovan"  
>> wrote:
>>
>>> The following is the latest proposed version of the MODERN working 
>>> group
>>> charter with updates discussed on the list discussion so far.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> ----------
>>>
>>> CHARTER TEXT:
>>>
>>> The MODERN working group will define a set of Internet-based 
>>> mechanisms
>>> for the purposes of managing and resolving telephone numbers (TNs) 
>>> in an
>>> IP environment.  Existing mechanisms for these purposes face
>>> obsolescence as the voice communications infrastructure evolves to 
>>> IP
>>> technology and new applications for TNs become possible.  The
>>> traditional model of a TN having an association to a single service
>>> provider and a single application is breaking down.  Its use as a
>>> network locator is going away, but its use as an identifier for an
>>> individual or an organization will remain for some time. Devices,
>>> applications, and network tools increasingly need to manage TNs,
>>> including requesting and acquiring TN delegations from authorities.  
>>> A
>>> sample of problems with existing mechanisms include:
>>>
>>> - lack of flexibility (for example, it can be difficult to add 
>>> fields
>>> without a very elaborate and lengthy process typically spanning 
>>> years)
>>> - lack of distribution (for example, it is hard or impossible to 
>>> have
>>> more than one administrator for each database)
>>> - complexity (leading, for example, to a fair amount of rural call
>>> completion problems which aren't helped by small providers 
>>> struggling to
>>> keep numbers straight)
>>> - difficulty of adopting more modern allocation (e.g., "blocks" of 
>>> 1)
>>> and porting mechanisms
>>>
>>> The working group will define a framework for the roles and 
>>> functions
>>> involved in managing and resolving TNs in an IP environment.  It 
>>> will
>>> also define protocol mechanisms for acquiring and resolving TNs.  
>>> The
>>> protocol mechanism for acquiring TNs will provide an enrollment 
>>> process
>>> for the individuals and entities that use and manage TNs. TNs may 
>>> either
>>> be managed in a hierarchical tree, or in a distributed peer-to-peer
>>> architecture.  Privacy of the enrollment data and security of the
>>> resource will be primary considerations.  The protocol mechanism for
>>> resolving TNs will allow entities such as service providers, 
>>> devices,
>>> and applications to access data related to TNs, possibly including
>>> caller name data (CNAM).  Maintaining reliability, real time 
>>> application
>>> performance, security and privacy are primary considerations.  The
>>> working group will take into consideration existing IETF work 
>>> including
>>> ENUM, SPEERMINT, and DRINKS.
>>>
>>> The work of this group will focus on E.164 telephone numbers due to 
>>> the
>>> changing telecom environment and interest expressed by
>>> telecommunications industry regulators to support more flexible
>>> regulatory models than exist today.  There is an expectation that
>>> aspects of the architecture and protocols defined by the working 
>>> group
>>> will be reusable for other user-focused identifiers.  Any such
>>> extensions or reuse of MODERN mechanisms are out of scope for the 
>>> MODERN
>>> working group.  Solutions and mechanisms created by the working 
>>> group
>>> will be flexible enough to accommodate different policies, e.g., by
>>> different regulatory agencies.
>>>
>>> The work group will deliver the following:
>>>
>>> -       An architecture overview, including high level requirements 
>>> and
>>> security/privacy considerations
>>>
>>> -       A description of the enrollment processes for existing and 
>>> new
>>> TNs including any modifications to metadata related to those TNs
>>>
>>> -       A description of protocol mechanisms for accessing contact
>>> information associated with enrollments
>>>
>>> -       A description of mechanisms for resolving information 
>>> related to
>>> TNs
>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>>
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Apr 30 10:43:08 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155741A87A8 for ; Thu, 30 Apr 2015 10:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnww72ZpVPZM for ; Thu, 30 Apr 2015 10:43:06 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275081A1A11 for ; Thu, 30 Apr 2015 10:43:06 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3UHgrTe093648 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 12:43:05 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Eric Burger" 
Date: Thu, 30 Apr 2015 12:42:53 -0500
Message-ID: <7240D9E9-F1F6-4F8B-BD52-4E303890654B@nostrum.com>
In-Reply-To: 
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com>       <55421D27.7020905@usdonovans.com> <50D31189-8F1A-45A6-8485-809117A72B12@standardstrack.com> <554263B9.6000804@usdonovans.com> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: modern@ietf.org
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 17:43:07 -0000

On 30 Apr 2015, at 12:19, Eric Burger wrote:

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

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


>> On Apr 30, 2015, at 1:17 PM, Steve Donovan  
>> wrote:
>>
>> Eric,
>>
>> My assertion of significant support (I'll not use the word unanimous 
>> as Kieth has pointed out it isn't correctly used in this context) was 
>> in the answer to question 5.  From the minutes:
>>
>> Q5: Does the community think that, given the charter discussion, a WG
>> should be formed?
>> Consensus:
>> Yes, but charter needs work.
>>
>> Earlier questions had less clear consensus.  My recollection of this 
>> question was that I did not hear any hums in the negative.


From nobody Thu Apr 30 11:13:06 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E71B2E8B for ; Thu, 30 Apr 2015 11:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7FVXysvb1YH for ; Thu, 30 Apr 2015 11:13:01 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5171ACD6A for ; Thu, 30 Apr 2015 11:13:01 -0700 (PDT)
Received: from BN1AFFO11HUB014.protection.gbl (10.58.52.124) by BN1AFFO11HUB050.protection.gbl (10.58.52.180) with Microsoft SMTP Server (TLS) id 15.1.154.14; Thu, 30 Apr 2015 18:12:59 +0000
Received: from BN1AFFO11FD055.protection.gbl (10.58.52.32) by BN1AFFO11HUB014.protection.gbl (10.58.52.124) with Microsoft SMTP Server (TLS) id 15.1.160.8; Thu, 30 Apr 2015 18:12:37 +0000
Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;
Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism)
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1AFFO11FD055.mail.protection.outlook.com (10.58.53.70) with Microsoft SMTP Server (TLS) id 15.1.154.14 via Frontend Transport; Thu, 30 Apr 2015 18:12:36 +0000
Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t3UHravG030741;  Thu, 30 Apr 2015 13:12:36 -0500
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 1u08q05cb4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 13:12:36 -0500
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 30 Apr 2015 13:12:35 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Thu, 30 Apr 2015 13:12:34 -0500
From: "Gorman, Pierce A [CTO]" 
To: "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Revised MODERN Charter
Thread-Index: AQHQfstU4kycWLjRaEypfCEYVmuNDp1c9NeAgAAHZYCAAQMSAIAC2bnAgANfGICAAAj84IABlCWAgAAfeID//+6XgA==
Date: Thu, 30 Apr 2015 18:12:34 +0000
Message-ID: <6ff23f316bec4bca9761aabc7ee2fe53@PLSWE13M08.ad.sprint.com>
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> ,  ,    <55421D27.7020905@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.33]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(377454003)(13464003)(24454002)(189002)(51704005)(199003)(479174004)(50986999)(86362001)(19580405001)(19580395003)(77156002)(5001770100001)(62966003)(2656002)(54356999)(6806004)(93886004)(106116001)(5001960100002)(46102003)(50466002)(87936001)(92566002)(2900100001)(15975445007)(24736003)(2950100001)(5001920100001)(108616004)(33646002)(561944003)(5250100002)(2501003)(102836002)(106466001)(47776003)(553524004)(107886002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB014; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB014; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB050; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB014; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB014; 
X-Forefront-PRVS: 056297E276
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2015 18:12:36.8972 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38];  Helo=[plsapdm2.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB014
X-OriginatorOrg: sprint.com
Archived-At: 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 18:13:05 -0000

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

Steve,

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

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

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

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

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

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

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

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

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

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

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

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

I'm reminded of jokes regarding light bulb installation.

Best regards,


Pierce Gorman
Core Network Planning
O: 913-439-4368
pierce.gorman@sprint.com


-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke=
ith)
Sent: April 30, 2015 9:09 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Revised MODERN Charter

Steve, not sure I understand your response.

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

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

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

Regards

Keith

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve
> Donovan
> Sent: 30 April 2015 13:17
> To: modern@ietf.org
> Subject: Re: [Modern] Revised MODERN Charter
>
> Pierce,
>
> I don't understand the relevance of your question.
>
> The scope of work for the MODERN working group was discussed at the
> MODERN BOF during IETF 92.  Consensus was reached that the IETF should
> do the work outlined in the charter.  If I recall correctly the
> response to that question was unanimous but it is possible that I
> missed some isolated negative hums.
>  This consensus clearly includes protocol work.
> Whether they are new protocols depends on what the working group
> produces.
>
> The primary open question that needed to be addressed in the charter
> was the set of identifiers that the working group would address. Thus
> the proposal to limit the scope of work to E.164 numbers.
>
> You can find the minutes from the meeting here:
>
> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern
>
> Regards,
>
> Steve
>
> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:
> > Thank you Henning.  Your list of general notions is what I
> was encouraging Steve Donovan, et al, to do.
> >
> > I didn't volunteer any items even though I could think of
> some because I'm not convinced the MODERN WG needs to include in its
> charter anything to do with respect to "managing"
> E.164 telephone numbers.
> >
> > As you say, "nobody would design a new system to replicate
> what has evolved over decades".
> >
> > I think your list of notions is useful input, but it would
> seem like it ought to be directed at the existing
> organization(s) with authority and responsibility to manage
> E.164 telephone numbers.
> >
> > If they identify (or have identified already) a need for
> new protocols (really?) or request that the IETF develop a framework,
> then certainly MODERN could be a good place to respond to that
> request.  Has that happened?
> >
> > Best regards,
> >
> >
> > Pierce Gorman
> > Core Network Planning
> > O: 913-439-4368  M: 816-210-8623
> > pierce.gorman@sprint.com
> >
> >
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
> > Sent: April 29, 2015 6:38 AM
> > To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
> > Cc: Modern List; McGarry, Tom
> > Subject: RE: [Modern] Revised MODERN Charter
> >
> > Pierce,
> >
> > since you and your organization probably have first-hand
> experience with the existing system, particularly as you transition to
> all-IP, I'd be very interested in hearing what you see as deficiencies
> or problems.
> >
> > My general take is that just about anything can be made to
> work ("with enough thrust, pigs can fly"), but that I suspect nobody
> would design a new system to replicate what has evolved over decades.
> I'm not sure the charter has to spell out every problem in detail, but
> a general motivation seems useful.
> >
> > My general notions are:
> > - lack of flexibility (e.g., difficult to add fields without a very
> > elaborate and lengthy process typically spanning years)
> > - lack of distribution (hard or impossible to have more than one
> > administrator for each database)
> > - complexity (we hear a fair amount about rural call completion
> > problems which aren't helped by small providers struggling to keep
> > numbers straight)
> > - difficulty of adopting more modern allocation (e.g.,
> "blocks" of 1)
> > and porting mechanisms
> >
> > Henning
> >
> > ________________________________
> > From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com]
> > Sent: Monday, April 27, 2015 10:36 AM
> > To: Henning Schulzrinne; Ben Campbell; Richard Shockey
> > Cc: Modern List; McGarry, Tom
> > Subject: RE: [Modern] Revised MODERN Charter
> >
> >
> > David Holmes has made the point in the past that it is
> important to list out what are the issues or problems to be solved
> that drive the work effort.
> >
> >
> >
> > To David's point, what are the flaws or inadequacies of the
> current administration and conservation of the E.164 telephone numbers
> that require or benefit from an IETF work group?  i.e., what is wrong
> with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
> >
> >
> >
> > My question is aimed specifically at the section in the
> charter which reads:
> >
> >
> >
> > The working group will define a framework for the roles and
> functions involved in managing and resolving TNs in an IP environment.
> This includes a protocol mechanism for acquiring TNs, which will
> provide an enrollment process for the individuals and entities that
> use and manage TNs.
> >
> >
> >
> > Best regards,
> >
> >
> >
> >
> >
> > Pierce Gorman
> >
> > Core Network Planning
> >
> > O: 913-439-4368
> >
> > pierce.gorman@sprint.com
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning
> > Schulzrinne
> > Sent: April 25, 2015 7:37 AM
> > To: Ben Campbell; Richard Shockey
> > Cc: Modern List; McGarry, Tom
> > Subject: Re: [Modern] Revised MODERN Charter
> >
> >
> >
> > I'm not sure it matters if the identifier is numeric or
> not, but the unifying principle seems to be that there is a clear
> delegation chain, within a confined geographic (mostly in the legal
> sense, i.e., a well-known set of national laws
> apply) scope. In particular, this implies that the entities
> participating can generally be assumed to be cooperative, as there is
> an umpire to remove any uncooperative players from the field.
> >
> >
> >
> > I don't think it's a priority, but SMS shortcodes seem
> similar enough to fit into the same mechanism.
> >
> >
> >
> > To avoid needless ambiguity, simply saying E.164 numbers
> and leaving the door open to other identifiers that happen to fit
> might work.
> >
> >
> >
> > ________________________________________
> >
> > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell
> > [ben@nostrum.com]
> >
> > Sent: Friday, April 24, 2015 5:09 PM
> >
> > To: Richard Shockey
> >
> > Cc: Modern List; McGarry, Tom
> >
> > Subject: Re: [Modern] Revised MODERN Charter
> >
> >
> >
> > On 24 Apr 2015, at 15:43, Richard Shockey wrote:
> >
> >
> >
> >> Out hopefully=A9that is a private proprietary namespace.
> >
> >
> > Okay, so Skype IDs were a bad example--but my question was
> about whether the "other telephony related identifiers" were still
> assumed to be things that look like TNs.
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > Modern mailing list
> >
> > Modern@ietf.org
> >
> > 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.
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information
> intended for the sole use of the recipient(s). Any use by others is
> prohibited. If you are not the intended recipient, please contact the
> sender and delete all copies of the message.
> >
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org
> > https://www.ietf.org/mailman/listinfo/modern
> >
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
>
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

________________________________

This e-mail may contain Sprint proprietary information intended for the sol=
e 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 nobody Thu Apr 30 11:29:04 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C761B2EC4 for ; Thu, 30 Apr 2015 11:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpkIKhKgKcv5 for ; Thu, 30 Apr 2015 11:29:00 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A34D1B2EC3 for ; Thu, 30 Apr 2015 11:28:59 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 29B9F6D3F5079; Thu, 30 Apr 2015 18:28:54 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UISviR009273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 20:28:57 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 20:28:57 +0200
From: "DRAGE, Keith (Keith)" 
To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] A revised revised MODERN charter
Thread-Index: AQHQg1lOihCD8v7+G0ejkSdsD1Xpg51lnBIAgAA5R/A=
Date: Thu, 30 Apr 2015 18:28:56 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <55424844.9040700@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] A revised revised MODERN charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 18:29:03 -0000

I'd argue against putting extension statements in charters unless there is =
at least a perception of a clear need to do additional work.

At the end of the day, any working group can be rechartered, whether such a=
 statement exists or not. Conversely, the AD has a big orange button to kil=
l a working group, whether the charter has completed or not.

Regarding using the term "telephone number" rather than "E.164 number", the=
n I am afraid that:

-	I find no standard definition of the term that is useful
-	use within normal English / American covers a very wide range of differen=
t perceptions, so in the US, I believe some people would quite happily refe=
r to sequences incorporating alphabetic characters as telephone numbers. Th=
ey would not in the UK.

I prefer to use terms that are defined, especially in this case. I would su=
ggest the way forward is to identify what you want to cover explicitly in a=
ddition to E.164 numbers. Then the list can cast judgement. You may find th=
at annex A of Recommendation E.164 gives you some appropriate terminology.

Regards

Keith=20

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20
> Peterson, Jon
> Sent: 30 April 2015 17:25
> To: Steve Donovan; modern@ietf.org
> Subject: Re: [Modern] A revised revised MODERN charter
>=20
>=20
> While I understand the desire to scope identifiers in the=20
> charter per the recent thread, I think putting it this=20
> starkly is too restrictive:
>=20
> > Any such
> > extensions or reuse of MODERN mechanisms are out of scope for the=20
> > MODERN working group.
>=20
> I mean, I thought we were going to define an extensible=20
> query-response protocol in this working group for managing=20
> data about telephone numbers.
> Something that would look at least vaguely like what is in=20
> draft-peterson-terq. From this reading, I could easily argue=20
> that TeRQ is outside the scope of MODERN precisely because it=20
> is extensible to other identifiers.
>=20
> >From the recent thread, I had thought people were arguing=20
> for some gating.
> Like "first, this working group is going to define a=20
> mechanism for telephone numbers. The group may later=20
> recharter to work on other things."
> I would be okay with some text along those lines, though=20
> frankly, I would prefer the second sentence read more like,=20
> "this group is also chartered to further investigate the use=20
> of other identifiers for the purpose of an eventual=20
> recharter," since I think the expertise to scope the work on=20
> identifiers resides on this mailing list and we should=20
> explicitly use it for that purpose.
>=20
>=20
> Also, in that same paragraph I'd prefer not to qualify=20
> "telephone numbers"
> with "E.164". This seems to come up again and again, but,=20
> there are a lot of telephone numbers we care about that do to=20
> fall under the E.164 plan.
> The earlier charter text doesn't say E.164, and I don't see=20
> why this part needs to either. Let's just keep it to=20
> "telephone numbers."
>=20
> Jon Peterson
> Neustar, Inc.
>=20
> On 4/30/15, 8:20 AM, "Steve Donovan"  wrote:
>=20
> >The following is the latest proposed version of the MODERN working=20
> >group charter with updates discussed on the list discussion so far.
> >
> >Regards,
> >
> >Steve
> >
> >----------
> >
> >CHARTER TEXT:
> >
> >The MODERN working group will define a set of Internet-based=20
> mechanisms=20
> >for the purposes of managing and resolving telephone numbers=20
> (TNs) in=20
> >an IP environment.  Existing mechanisms for these purposes face=20
> >obsolescence as the voice communications infrastructure=20
> evolves to IP=20
> >technology and new applications for TNs become possible.  The=20
> >traditional model of a TN having an association to a single service=20
> >provider and a single application is breaking down.  Its use as a=20
> >network locator is going away, but its use as an identifier for an=20
> >individual or an organization will remain for some time. Devices,=20
> >applications, and network tools increasingly need to manage TNs,=20
> >including requesting and acquiring TN delegations from=20
> authorities.  A=20
> >sample of problems with existing mechanisms include:
> >
> >- lack of flexibility (for example, it can be difficult to=20
> add fields=20
> >without a very elaborate and lengthy process typically=20
> spanning years)
> >- lack of distribution (for example, it is hard or=20
> impossible to have=20
> >more than one administrator for each database)
> >- complexity (leading, for example, to a fair amount of rural call=20
> >completion problems which aren't helped by small providers=20
> struggling=20
> >to keep numbers straight)
> >- difficulty of adopting more modern allocation (e.g.,=20
> "blocks" of 1)=20
> >and porting mechanisms
> >
> >The working group will define a framework for the roles and=20
> functions=20
> >involved in managing and resolving TNs in an IP environment.=20
>  It will=20
> >also define protocol mechanisms for acquiring and resolving=20
> TNs.  The=20
> >protocol mechanism for acquiring TNs will provide an=20
> enrollment process=20
> >for the individuals and entities that use and manage TNs. TNs may=20
> >either be managed in a hierarchical tree, or in a distributed=20
> >peer-to-peer architecture.  Privacy of the enrollment data=20
> and security=20
> >of the resource will be primary considerations.  The=20
> protocol mechanism=20
> >for resolving TNs will allow entities such as service providers,=20
> >devices, and applications to access data related to TNs, possibly=20
> >including caller name data (CNAM).  Maintaining reliability,=20
> real time=20
> >application performance, security and privacy are primary=20
> >considerations.  The working group will take into consideration=20
> >existing IETF work including ENUM, SPEERMINT, and DRINKS.
> >
> >The work of this group will focus on E.164 telephone numbers=20
> due to the=20
> >changing telecom environment and interest expressed by=20
> >telecommunications industry regulators to support more flexible=20
> >regulatory models than exist today.  There is an expectation that=20
> >aspects of the architecture and protocols defined by the=20
> working group=20
> >will be reusable for other user-focused identifiers.  Any such=20
> >extensions or reuse of MODERN mechanisms are out of scope for the=20
> >MODERN working group.  Solutions and mechanisms created by=20
> the working=20
> >group will be flexible enough to accommodate different=20
> policies, e.g.,=20
> >by different regulatory agencies.
> >
> >The work group will deliver the following:
> >
> >-       An architecture overview, including high level=20
> requirements and
> >security/privacy considerations
> >
> >-       A description of the enrollment processes for=20
> 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=20
> information related to
> >TNs
> >
> >_______________________________________________
> >Modern mailing list
> >Modern@ietf.org
> >https://www.ietf.org/mailman/listinfo/modern
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
> =


From nobody Thu Apr 30 11:33:32 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AB21AD17F for ; Thu, 30 Apr 2015 11:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.888
X-Spam-Level: 
X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPc_fLps7Q0b for ; Thu, 30 Apr 2015 11:33:29 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BDB1ACDCB for ; Thu, 30 Apr 2015 11:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=Content-Type:MIME-Version:To:From:Message-ID:Subject:Date; bh=Q4kGlVv/cOTk5ebocSxBoSmXkgpwtVEPfDDZXhYVEpI=;  b=Voa/c8UzcnoQ6zuzzyJawPNX8Sc7+xF56/W3PuoWdyLTDx2aQJ7EO195XdpBX7RhOKWYKqIvEpXRMQDn5t+WmGZx2mHewHIy/4oNNapq2fS3nt1hqVyg6wVpbFJtbzxqwax0pa8mJeCNty480sFQ16j0QC84SbEte3QK/RBNBGI=;
Received: from 236.sub-70-208-133.myvzw.com ([70.208.133.236]:11891 helo=[100.94.16.21]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.82) (envelope-from ) id 1YntH3-0002Bj-8q for modern@ietf.org; Thu, 30 Apr 2015 11:33:28 -0700
Date: Thu, 30 Apr 2015 14:33:21 -0400
Message-ID: 
Importance: normal
From: Eric Burger 
To: modern@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_2008380321037260"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: [Modern] Why a work group?
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 18:33:30 -0000

----_com.android.email_2008380321037260
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SSBhbSBpbiB0aGUgbWlkc3Qgb2Ygd3JpdGluZyB1cCB3aGF0IEkgd291bGQgbGlrZSB0byBzZWUg
dGhlIHdvcmsgZ3JvdXAgd29yayBvbiBhbmQgd2h5LiBIb3dldmVyLCBpbiB0aGUgbWVhbiB0aW1l
LCB0aGlzIGV4Y2hhbmdlIG1ha2VzIGl0IGNsZWFyIHRvIG1lIHdlIGFsbCBuZWVkIHRvIHVuZGVy
c3RhbmQgdGhlIHVzZWZ1bG5lc3Mgb2YgdGhlIHdvcmsgYW5kIHdoeS7CoAoKSSB0aGluayB3ZSBo
YXZlIGJlZW4gdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIgaGVyZS4gV2hlbiBwZW9wbGUgYXQgdGhl
IEJPRiBzYWlkIHRoZXkgd2FudGVkIGEgd29yayBncm91cCwgcmVjYWxsIHRoZSBtaW51dGVzIG1h
ZGUgY2xlYXIgdGhlIGNoYXJ0ZXIgd2FzIG5vdCBjbGVhciBhdCBhbGwuIElNSE8gdGhhdCBieSBk
ZWZpbml0aW9uIGRheXMgd2UgZGlkbid0IGtub3cgd2hhdCB3ZSB3ZXJlIGFza2luZyBmb3IgYW5k
IGFzIHN1Y2ggc2F5aW5nIHRoZXJlIHdhcyBjb25zZW5zdXMgdG8gZm9ybSBhIHdvcmsgZ3JvdXAg
dG8gZG8gc29tZXRoaW5nLCBidXQgd2UgZG9uJ3Qga25vdyB3aGF0LCBpcyBub3QgYSBjb25zZW5z
dXMgb24gYW55dGhpbmcuwqAKCklmIHdlIGNhbiBnZXQsIG9uIHRoZSBsaXN0LCB3aGF0IHRoZSBw
cm9ibGVtIGlzIGFuZCB3aHkgcGVvcGxlIHdvdWxkIHVzZSB0aGUgc29sdXRpb24gdG8gdGhlIHBy
b2JsZW0sIHRoZSBjaGFydGVyaW5nIHdpbGwgYmUgZWFzeS4gVGhpcyBpcyBhIGNhc2Ugd2hlcmUg
dGhlIElFVEYgcHJvY2VzcyBvZiByZXF1aXJpbmcgYWxsIGRlY2lzaW9ucyB0byBiZSBvbiB0aGUg
bGlzdCB3aWxsIGhlbHAgdXMgZmlndXJlIG91dCB3aGF0IHdlIG5lZWQgdG8gZG8uwqAKClRoZSB2
aWV3IGZyb20gbXkgdmFudGFnZSBwb2ludCBpcyBhbiBhY2FkZW1pYyBhbmQgYSBmZXcgcmVzZWFy
Y2hlcnMgdGhpbmsgdGhlIHNwYWNlIGlzIGludGVyZXN0aW5nLiBXZSBhbHNvIGtub3cgdGhhdCB3
aGF0IGlzIG91dCB0aGVyZSBpcyBsZXNzIHRoYW4gaWRlYWwuIFdoYXQgSSB3YW50IHRvIGF2b2lk
IGlzIGEgcmVwZWF0IG9mIEtQTUwsIHdoZXJlIGFmdGVyIGFsbCB0aGUgd29yaywgYW5kIGEgbG90
IG9mIHdvcmsgdG8gcHJvdmluZyBpdCB0byBiZSB0aGUgbW9zdCBlZmZpY2llbnQgYW5kIGFyY2hp
dGVjdHVyYWxseSBwdXJlIGFwcHJvYWNoLCBpcyBpZ25vcmVkIGJlY2F1c2Ugd2hhdCBpcyBvdXQg
dGhlcmUgd29ya3Mgd2VsbCBlbm91Z2guIElmIHdlIGNhbiBnZXQsIGluIHdyaXRpbmcsIHdoYXQg
c3BlY2lmaWMgcHJvYmxlbSB3ZSBhcmUgc29sdmluZyBhbmQgd2hvIHdpbGwgdXNlIHRoZSBzb2x1
dGlvbiwgd2Ugd2lsbCBub3QgYmUgc3BlbmRpbmcgb3VyIGN5Y2xlcyB3aXNlbHkuwqAKClNvLCBo
ZXJlIGFyZSBteSB0d28gcXVlc3Rpb25zIHRvIHRoZSBsaXN0LiBJIGhvcGUgbW9yZSB0aGFuIFBp
ZXJjZSBhbmQgSGVubmluZyB3aWxsIHJlcGx5LsKgCgpRdWVzdGlvbiAxOiB3aGF0IGlzIHRoZSBw
cm9ibGVtIHlvdSBuZWVkIHNvbHZlZD/CoAoKUXVlc3Rpb24gMjogd2h5IGlzIGl0IGltcG9ydGFu
dCB0byB5b3UgYW5kIHdvdWxkIHlvdSB1c2UgYSBzb2x1dGlvbiB0aGF0IGlzIGRpZmZlcmVudCBm
cm9tIHdoYXQgeW91IGhhdmUgdG9kYXk/wqAKCgoKClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNl
LiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2ll
dGYvbGVtb25hZGUKCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2
PjxkaXY+RnJvbTogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+IDwvZGl2PjxkaXY+RGF0
ZTowNC8zMC8yMDE1ICAxOjQyIFBNICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBFcmljIEJ1
cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+IDwvZGl2PjxkaXY+Q2M6IG1vZGVybkBp
ZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbTW9kZXJuXSBSZXZpc2VkIE1PREVSTiBD
aGFydGVyIDwvZGl2PjxkaXY+CjwvZGl2Pk9uIDMwIEFwciAyMDE1LCBhdCAxMjoxOSwgRXJpYyBC
dXJnZXIgd3JvdGU6Cgo+IFdpdGhvdXQgY29uc2Vuc3VzIG9uIFExLTQsIGlzIFE1IHJlbGV2YW50
Pwo+CgpJIHRoaW5rIGl0IGlzLiBJZiB0aGUgYW5zd2VyIHRvIFE1IHdhcyB0aGF0IG5vIG9uZSBj
YXJlZCBhYm91dCB0aGUgd29yaywgCndlIHdvdWxkIG5vdCBiZSBzcGVuZGluZyBjeWNsZXMgd29y
a2luZyB0byByZWZpbmUgdGhlIGNoYXJ0ZXIuIE9UT0gsIApjb21pbmcgdXAgd2l0aCBhbiBhY2Nl
cHRhYmxlIGNoYXJ0ZXIgaXMgc3RpbGwgYSBwcmVyZXF1aXNpdGUgZm9yIApzdGFydGluZyBhIHdv
cmtpbmcgZ3JvdXAuIFRoZXJlJ3Mgbm8gZ3VhcmFudHkgb2Ygc3VjY2Vzcy4KCgo+PiBPbiBBcHIg
MzAsIDIwMTUsIGF0IDE6MTcgUE0sIFN0ZXZlIERvbm92YW4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5z
LmNvbT4gCj4+IHdyb3RlOgo+Pgo+PiBFcmljLAo+Pgo+PiBNeSBhc3NlcnRpb24gb2Ygc2lnbmlm
aWNhbnQgc3VwcG9ydCAoSSdsbCBub3QgdXNlIHRoZSB3b3JkIHVuYW5pbW91cyAKPj4gYXMgS2ll
dGggaGFzIHBvaW50ZWQgb3V0IGl0IGlzbid0IGNvcnJlY3RseSB1c2VkIGluIHRoaXMgY29udGV4
dCkgd2FzIAo+PiBpbiB0aGUgYW5zd2VyIHRvIHF1ZXN0aW9uIDUuICBGcm9tIHRoZSBtaW51dGVz
Ogo+Pgo+PiBRNTogRG9lcyB0aGUgY29tbXVuaXR5IHRoaW5rIHRoYXQsIGdpdmVuIHRoZSBjaGFy
dGVyIGRpc2N1c3Npb24sIGEgV0cKPj4gc2hvdWxkIGJlIGZvcm1lZD8KPj4gQ29uc2Vuc3VzOgo+
PiBZZXMsIGJ1dCBjaGFydGVyIG5lZWRzIHdvcmsuCj4+Cj4+IEVhcmxpZXIgcXVlc3Rpb25zIGhh
ZCBsZXNzIGNsZWFyIGNvbnNlbnN1cy4gIE15IHJlY29sbGVjdGlvbiBvZiB0aGlzIAo+PiBxdWVz
dGlvbiB3YXMgdGhhdCBJIGRpZCBub3QgaGVhciBhbnkgaHVtcyBpbiB0aGUgbmVnYXRpdmUuCg==

----_com.android.email_2008380321037260
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5JIGFtIGluIHRoZSBtaWRz
dCBvZiB3cml0aW5nIHVwIHdoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgd29yayBncm91cCB3
b3JrIG9uIGFuZCB3aHkuIEhvd2V2ZXIsIGluIHRoZSBtZWFuIHRpbWUsIHRoaXMgZXhjaGFuZ2Ug
bWFrZXMgaXQgY2xlYXIgdG8gbWUgd2UgYWxsIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgdXNlZnVs
bmVzcyBvZiB0aGUgd29yayBhbmQgd2h5LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
PGRpdj5JIHRoaW5rIHdlIGhhdmUgYmVlbiB0YWxraW5nIHBhc3QgZWFjaCBvdGhlciBoZXJlLiBX
aGVuIHBlb3BsZSBhdCB0aGUgQk9GIHNhaWQgdGhleSB3YW50ZWQgYSB3b3JrIGdyb3VwLCByZWNh
bGwgdGhlIG1pbnV0ZXMgbWFkZSBjbGVhciB0aGUgY2hhcnRlciB3YXMgbm90IGNsZWFyIGF0IGFs
bC4gSU1ITyB0aGF0IGJ5IGRlZmluaXRpb24gZGF5cyB3ZSBkaWRuJ3Qga25vdyB3aGF0IHdlIHdl
cmUgYXNraW5nIGZvciBhbmQgYXMgc3VjaCBzYXlpbmcgdGhlcmUgd2FzIGNvbnNlbnN1cyB0byBm
b3JtIGEgd29yayBncm91cCB0byBkbyBzb21ldGhpbmcsIGJ1dCB3ZSBkb24ndCBrbm93IHdoYXQs
IGlzIG5vdCBhIGNvbnNlbnN1cyBvbiBhbnl0aGluZy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2PklmIHdlIGNhbiBnZXQsIG9uIHRoZSBsaXN0LCB3aGF0IHRoZSBwcm9ibGVtIGlzIGFu
ZCB3aHkgcGVvcGxlIHdvdWxkIHVzZSB0aGUgc29sdXRpb24gdG8gdGhlIHByb2JsZW0sIHRoZSBj
aGFydGVyaW5nIHdpbGwgYmUgZWFzeS4gVGhpcyBpcyBhIGNhc2Ugd2hlcmUgdGhlIElFVEYgcHJv
Y2VzcyBvZiByZXF1aXJpbmcgYWxsIGRlY2lzaW9ucyB0byBiZSBvbiB0aGUgbGlzdCB3aWxsIGhl
bHAgdXMgZmlndXJlIG91dCB3aGF0IHdlIG5lZWQgdG8gZG8uJm5ic3A7PC9kaXY+PGRpdj48YnI+
PC9kaXY+PGRpdj5UaGUgdmlldyBmcm9tIG15IHZhbnRhZ2UgcG9pbnQgaXMgYW4gYWNhZGVtaWMg
YW5kIGEgZmV3IHJlc2VhcmNoZXJzIHRoaW5rIHRoZSBzcGFjZSBpcyBpbnRlcmVzdGluZy4gV2Ug
YWxzbyBrbm93IHRoYXQgd2hhdCBpcyBvdXQgdGhlcmUgaXMgbGVzcyB0aGFuIGlkZWFsLiBXaGF0
IEkgd2FudCB0byBhdm9pZCBpcyBhIHJlcGVhdCBvZiBLUE1MLCB3aGVyZSBhZnRlciBhbGwgdGhl
IHdvcmssIGFuZCBhIGxvdCBvZiB3b3JrIHRvIHByb3ZpbmcgaXQgdG8gYmUgdGhlIG1vc3QgZWZm
aWNpZW50IGFuZCBhcmNoaXRlY3R1cmFsbHkgcHVyZSBhcHByb2FjaCwgaXMgaWdub3JlZCBiZWNh
dXNlIHdoYXQgaXMgb3V0IHRoZXJlIHdvcmtzIHdlbGwgZW5vdWdoLiBJZiB3ZSBjYW4gZ2V0LCBp
biB3cml0aW5nLCB3aGF0IHNwZWNpZmljIHByb2JsZW0gd2UgYXJlIHNvbHZpbmcgYW5kIHdobyB3
aWxsIHVzZSB0aGUgc29sdXRpb24sIHdlIHdpbGwgbm90IGJlIHNwZW5kaW5nIG91ciBjeWNsZXMg
d2lzZWx5LiZuYnNwOzwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U28sIGhlcmUgYXJl
IG15IHR3byBxdWVzdGlvbnMgdG8gdGhlIGxpc3QuIEkgaG9wZSBtb3JlIHRoYW4gUGllcmNlIGFu
ZCBIZW5uaW5nIHdpbGwgcmVwbHkuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5RdWVz
dGlvbiAxOiB3aGF0IGlzIHRoZSBwcm9ibGVtIHlvdSBuZWVkIHNvbHZlZD8mbmJzcDs8L2Rpdj48
ZGl2Pjxicj48L2Rpdj48ZGl2PlF1ZXN0aW9uIDI6IHdoeSBpcyBpdCBpbXBvcnRhbnQgdG8geW91
IGFuZCB3b3VsZCB5b3UgdXNlIGEgc29sdXRpb24gdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB3aGF0
IHlvdSBoYXZlIHRvZGF5PyZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2
PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PlNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNl
LiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2ll
dGYvbGVtb25hZGU8YnI+PGJyPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t
LTwvZGl2PjxkaXY+RnJvbTogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+IDwvZGl2Pjxk
aXY+RGF0ZTowNC8zMC8yMDE1ICAxOjQyIFBNICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBF
cmljIEJ1cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+IDwvZGl2PjxkaXY+Q2M6IG1v
ZGVybkBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbTW9kZXJuXSBSZXZpc2VkIE1P
REVSTiBDaGFydGVyIDwvZGl2PjxkaXY+PGJyPjwvZGl2Pk9uIDMwIEFwciAyMDE1LCBhdCAxMjox
OSwgRXJpYyBCdXJnZXIgd3JvdGU6PGJyPjxicj4mZ3Q7IFdpdGhvdXQgY29uc2Vuc3VzIG9uIFEx
LTQsIGlzIFE1IHJlbGV2YW50Pzxicj4mZ3Q7PGJyPjxicj5JIHRoaW5rIGl0IGlzLiBJZiB0aGUg
YW5zd2VyIHRvIFE1IHdhcyB0aGF0IG5vIG9uZSBjYXJlZCBhYm91dCB0aGUgd29yaywgPGJyPndl
IHdvdWxkIG5vdCBiZSBzcGVuZGluZyBjeWNsZXMgd29ya2luZyB0byByZWZpbmUgdGhlIGNoYXJ0
ZXIuIE9UT0gsIDxicj5jb21pbmcgdXAgd2l0aCBhbiBhY2NlcHRhYmxlIGNoYXJ0ZXIgaXMgc3Rp
bGwgYSBwcmVyZXF1aXNpdGUgZm9yIDxicj5zdGFydGluZyBhIHdvcmtpbmcgZ3JvdXAuIFRoZXJl
J3Mgbm8gZ3VhcmFudHkgb2Ygc3VjY2Vzcy48YnI+PGJyPjxicj4mZ3Q7Jmd0OyBPbiBBcHIgMzAs
IDIwMTUsIGF0IDE6MTcgUE0sIFN0ZXZlIERvbm92YW4gJmx0O3NyZG9ub3ZhbkB1c2Rvbm92YW5z
LmNvbSZndDsgPGJyPiZndDsmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBFcmlj
LDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBNeSBhc3NlcnRpb24gb2Ygc2lnbmlmaWNhbnQgc3Vw
cG9ydCAoSSdsbCBub3QgdXNlIHRoZSB3b3JkIHVuYW5pbW91cyA8YnI+Jmd0OyZndDsgYXMgS2ll
dGggaGFzIHBvaW50ZWQgb3V0IGl0IGlzbid0IGNvcnJlY3RseSB1c2VkIGluIHRoaXMgY29udGV4
dCkgd2FzIDxicj4mZ3Q7Jmd0OyBpbiB0aGUgYW5zd2VyIHRvIHF1ZXN0aW9uIDUuJm5ic3A7IEZy
b20gdGhlIG1pbnV0ZXM6PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFE1OiBEb2VzIHRoZSBjb21t
dW5pdHkgdGhpbmsgdGhhdCwgZ2l2ZW4gdGhlIGNoYXJ0ZXIgZGlzY3Vzc2lvbiwgYSBXRzxicj4m
Z3Q7Jmd0OyBzaG91bGQgYmUgZm9ybWVkPzxicj4mZ3Q7Jmd0OyBDb25zZW5zdXM6PGJyPiZndDsm
Z3Q7IFllcywgYnV0IGNoYXJ0ZXIgbmVlZHMgd29yay48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsg
RWFybGllciBxdWVzdGlvbnMgaGFkIGxlc3MgY2xlYXIgY29uc2Vuc3VzLiZuYnNwOyBNeSByZWNv
bGxlY3Rpb24gb2YgdGhpcyA8YnI+Jmd0OyZndDsgcXVlc3Rpb24gd2FzIHRoYXQgSSBkaWQgbm90
IGhlYXIgYW55IGh1bXMgaW4gdGhlIG5lZ2F0aXZlLjxicj48L2JvZHk+

----_com.android.email_2008380321037260--



From nobody Thu Apr 30 12:20:23 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1971A904C for ; Thu, 30 Apr 2015 12:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.266
X-Spam-Level: 
X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHooOK_1L4k2 for ; Thu, 30 Apr 2015 12:20:19 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AE61A8B84 for ; Thu, 30 Apr 2015 12:20:19 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t3UJFSMQ014107; Thu, 30 Apr 2015 15:20:16 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1u3s3b04p5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 15:20:16 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 30 Apr 2015 15:20:14 -0400
From: "Peterson, Jon" 
To: "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] A revised revised MODERN charter
Thread-Index: AQHQg1k6LJxbwBImI0KebvVxbpEE3p1li0uAgACYGQD//5j4AA==
Date: Thu, 30 Apr 2015 19:20:13 +0000
Message-ID: 
References: <55424844.9040700@usdonovans.com>  <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.129.89]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-04-30_05:2015-04-30,2015-04-30,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.90218976523238e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504300227
Archived-At: 
Subject: Re: [Modern] A revised revised MODERN charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 19:20:22 -0000

The list of identifiers I personally thought were interesting, and a
description of the nature of telephone numbers, are both in
draft-peterson-terq. Basically, when used for an ENUM-like query, TeRQ
proposed operating on either telephone numbers or SPIDs, and being able to
return a variety of identifiers including Internet identifiers like URIs
or PSTN identifiers like trunk groups. It did include the notion of
querying for a telephone number range - I think if we lose that property,
we will lose a bunch of use cases that we want to keep. SPIDs, well, I'd
be okay relegating them to a later extension or iteration.

But ranges are one reason why I'm reluctant to say "E.164" in the charter.
My understanding is that a lot of things don't fall under E.164, including
service codes, short codes, US freephone numbers, and various other
dialable numbers I think we care about. I would be comfortable defining
"telephone number" by its ABNF rather than by its policy or practice, and
going from there - in fact, I think doing so is essential to the whole
MODERN concept of reimagining number administration. That's roughly what
TeRQ does. In the early TeRQ discussions, there was some debate about
whether we need a new ABNF for telephone numbers, and if so, fine - but
that should be in the MODERN charter.

Jon Peterson
Neustar, Inc.

On 4/30/15, 11:28 AM, "DRAGE, Keith (Keith)"
 wrote:

>I'd argue against putting extension statements in charters unless there
>is at least a perception of a clear need to do additional work.
>
>At the end of the day, any working group can be rechartered, whether such
>a statement exists or not. Conversely, the AD has a big orange button to
>kill a working group, whether the charter has completed or not.
>
>Regarding using the term "telephone number" rather than "E.164 number",
>then I am afraid that:
>
>-	I find no standard definition of the term that is useful
>-	use within normal English / American covers a very wide range of
>different perceptions, so in the US, I believe some people would quite
>happily refer to sequences incorporating alphabetic characters as
>telephone numbers. They would not in the UK.
>
>I prefer to use terms that are defined, especially in this case. I would
>suggest the way forward is to identify what you want to cover explicitly
>in addition to E.164 numbers. Then the list can cast judgement. You may
>find that annex A of Recommendation E.164 gives you some appropriate
>terminology.
>
>Regards
>
>Keith=20
>
>> -----Original Message-----
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of
>> Peterson, Jon
>> Sent: 30 April 2015 17:25
>> To: Steve Donovan; modern@ietf.org
>> Subject: Re: [Modern] A revised revised MODERN charter
>>=20
>>=20
>> While I understand the desire to scope identifiers in the
>> charter per the recent thread, I think putting it this
>> starkly is too restrictive:
>>=20
>> > Any such
>> > extensions or reuse of MODERN mechanisms are out of scope for the
>> > MODERN working group.
>>=20
>> I mean, I thought we were going to define an extensible
>> query-response protocol in this working group for managing
>> data about telephone numbers.
>> Something that would look at least vaguely like what is in
>> draft-peterson-terq. From this reading, I could easily argue
>> that TeRQ is outside the scope of MODERN precisely because it
>> is extensible to other identifiers.
>>=20
>> >From the recent thread, I had thought people were arguing
>> for some gating.
>> Like "first, this working group is going to define a
>> mechanism for telephone numbers. The group may later
>> recharter to work on other things."
>> I would be okay with some text along those lines, though
>> frankly, I would prefer the second sentence read more like,
>> "this group is also chartered to further investigate the use
>> of other identifiers for the purpose of an eventual
>> recharter," since I think the expertise to scope the work on
>> identifiers resides on this mailing list and we should
>> explicitly use it for that purpose.
>>=20
>>=20
>> Also, in that same paragraph I'd prefer not to qualify
>> "telephone numbers"
>> with "E.164". This seems to come up again and again, but,
>> there are a lot of telephone numbers we care about that do to
>> fall under the E.164 plan.
>> The earlier charter text doesn't say E.164, and I don't see
>> why this part needs to either. Let's just keep it to
>> "telephone numbers."
>>=20
>> Jon Peterson
>> Neustar, Inc.
>>=20
>> On 4/30/15, 8:20 AM, "Steve Donovan"  wrote:
>>=20
>> >The following is the latest proposed version of the MODERN working
>> >group charter with updates discussed on the list discussion so far.
>> >
>> >Regards,
>> >
>> >Steve
>> >
>> >----------
>> >
>> >CHARTER TEXT:
>> >
>> >The MODERN working group will define a set of Internet-based
>> mechanisms=20
>> >for the purposes of managing and resolving telephone numbers
>> (TNs) in=20
>> >an IP environment.  Existing mechanisms for these purposes face
>> >obsolescence as the voice communications infrastructure
>> evolves to IP=20
>> >technology and new applications for TNs become possible.  The
>> >traditional model of a TN having an association to a single service
>> >provider and a single application is breaking down.  Its use as a
>> >network locator is going away, but its use as an identifier for an
>> >individual or an organization will remain for some time. Devices,
>> >applications, and network tools increasingly need to manage TNs,
>> >including requesting and acquiring TN delegations from
>> authorities.  A=20
>> >sample of problems with existing mechanisms include:
>> >
>> >- lack of flexibility (for example, it can be difficult to
>> add fields=20
>> >without a very elaborate and lengthy process typically
>> spanning years)
>> >- lack of distribution (for example, it is hard or
>> impossible to have
>> >more than one administrator for each database)
>> >- complexity (leading, for example, to a fair amount of rural call
>> >completion problems which aren't helped by small providers
>> struggling=20
>> >to keep numbers straight)
>> >- difficulty of adopting more modern allocation (e.g.,
>> "blocks" of 1)=20
>> >and porting mechanisms
>> >
>> >The working group will define a framework for the roles and
>> functions=20
>> >involved in managing and resolving TNs in an IP environment.
>>  It will=20
>> >also define protocol mechanisms for acquiring and resolving
>> TNs.  The=20
>> >protocol mechanism for acquiring TNs will provide an
>> enrollment process
>> >for the individuals and entities that use and manage TNs. TNs may
>> >either be managed in a hierarchical tree, or in a distributed
>> >peer-to-peer architecture.  Privacy of the enrollment data
>> and security=20
>> >of the resource will be primary considerations.  The
>> protocol mechanism
>> >for resolving TNs will allow entities such as service providers,
>> >devices, and applications to access data related to TNs, possibly
>> >including caller name data (CNAM).  Maintaining reliability,
>> real time=20
>> >application performance, security and privacy are primary
>> >considerations.  The working group will take into consideration
>> >existing IETF work including ENUM, SPEERMINT, and DRINKS.
>> >
>> >The work of this group will focus on E.164 telephone numbers
>> due to the=20
>> >changing telecom environment and interest expressed by
>> >telecommunications industry regulators to support more flexible
>> >regulatory models than exist today.  There is an expectation that
>> >aspects of the architecture and protocols defined by the
>> working group=20
>> >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=20
>> >group will be flexible enough to accommodate different
>> policies, e.g.,=20
>> >by different regulatory agencies.
>> >
>> >The work group will deliver the following:
>> >
>> >-       An architecture overview, including high level
>> requirements and
>> >security/privacy considerations
>> >
>> >-       A description of the enrollment processes for
>> existing and new
>> >TNs including any modifications to metadata related to those TNs
>> >
>> >-       A description of protocol mechanisms for accessing contact
>> >information associated with enrollments
>> >
>> >-       A description of mechanisms for resolving
>> information related to
>> >TNs
>> >
>> >_______________________________________________
>> >Modern mailing list
>> >Modern@ietf.org
>> >https://www.ietf.org/mailman/listinfo/modern
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>>=20


From nobody Thu Apr 30 12:39:24 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A341A87CB for ; Thu, 30 Apr 2015 12:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level: 
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HABDZXswujnW for ; Thu, 30 Apr 2015 12:39:19 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353451A700A for ; Thu, 30 Apr 2015 12:39:19 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t3UJcEBo019346; Thu, 30 Apr 2015 15:39:16 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1u3gse0ud3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 15:39:16 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.61]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 30 Apr 2015 15:39:15 -0400
From: "Peterson, Jon" 
To: "Gorman, Pierce A [CTO]" , "DRAGE, Keith (Keith)" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Revised MODERN Charter
Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOLPICAAq06o4AApb6AgAE80YCAAB95gIAAQ/gA//+i3AA=
Date: Thu, 30 Apr 2015 19:39:14 +0000
Message-ID: 
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com>       <55421D27.7020905@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <6ff23f316bec4bca9761aabc7ee2fe53@PLSWE13M08.ad.sprint.com>
In-Reply-To: <6ff23f316bec4bca9761aabc7ee2fe53@PLSWE13M08.ad.sprint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.129.89]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-04-30_05:2015-04-30,2015-04-30,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.90218976523238e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.993311949948012 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.993311949948012 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504300228
Archived-At: 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 19:39:23 -0000

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

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

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

Jon Peterson
Neustar, Inc.

On 4/30/15, 11:12 AM, "Gorman, Pierce A [CTO]" 
wrote:

>Thank you Keith.  I'm a newbie when it comes to standards discussions and
>I appreciate your assistance.
>
>Steve,
>
>One of the main concerns I have with the proposed MODERN charter is the
>confusion being generated between the IETF MODERN WG and existing NANP
>SDOs.
>
>I've talked with our internal numbering folks who represent Sprint in the
>INC/NANC organizations and they definitely do not understand why IETF is
>is chartering a WG that "...will define a framework for the roles and
>functions involved in managing and resolving TNs..." which "will provide
>an enrollment process for the individuals and entities that use and
>manage TNs."
>
>I would have a similar concern if INC decided to convene a group to
>determine how to better manage IP addresses because INC was dissatisfied
>with:
>
>     * management of IP addressing by multiple independent RIRs
>     * challenges associated with resolving TNs to IPs across slowly
>evolving multiple versions of IP addresses
>     * private versus public addressing
>     * increased costs dealing with IP network address and port
>translation across operational boundaries of varying complexity and
>security requirements
>
>I would feel that it was incumbent upon INC to liason with IETF and ARIN
>to address concerns, and not create a new INC WG proposing to usurp ARIN
>and manage what ARIN is responsible for.
>
>I use ARIN in my hypothetical example because I'm specifically concerned
>about management of numbers in the NANP.   CC=3D1 is the only E.164
>namespace we're a participant in managing.  I assume non-NA numbering
>management organizations (e.g., ITU) can comfortably ignore MODERN but
>that NANC cannot (and vice-versa).
>
>For discussion's sake, let's say I hadn't questioned this part of the
>MODERN charter, and work proceeded quickly generating a quality framework
>that had "rough consensus".  How will MODERN go about implementing this
>framework?  Will MODERN WG not then be in the position of reaching out to
>INC/NANC for discussions?
>
>I'll offer additional concerns I think are of a more practical nature.
>
>There is a Joint Task Force WG under the auspices of the SIP Forum and
>ATIS PTSC which covered much of this same ground MODERN is proposing in
>its charter.  The JTF produced two technical reports; a routing TR, and
>an inter-carrier all-IP NNI TR.  The routing TR largely conisists of
>multiple proposals on how to manage, provision, and resolve telephone
>numbers and IP addresses.
>
>Also, the FCC and NANC authorized transition of number portability
>management from Neustar to iconective.
>
>NPAC transition planning is an example where MODERN might offer benefit
>to NANC regarding development of enrollment, metadata, and provisioning
>protocol mechanisms.  But this assumes the SDOs are working together and
>not independently of one another.
>
>As it is, I assume NANC (NAPM LLC) will work independently of MODERN to
>manage the transition.  And I assume there is some (small?) risk of
>potentially changing the underlying number management problem set MODERN
>is proposing to address while MODERN is in-flight addressing it.  (As a
>nit, I'll also mention I think the proposed MODERN charter implies number
>management is a single database problem ignoring LERG and LNP.)
>
>I'm reminded of jokes regarding light bulb installation.
>
>Best regards,
>
>
>Pierce Gorman
>Core Network Planning
>O: 913-439-4368
>pierce.gorman@sprint.com
>
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DRAGE, Keith
>(Keith)
>Sent: April 30, 2015 9:09 AM
>To: Steve Donovan; modern@ietf.org
>Subject: Re: [Modern] Revised MODERN Charter
>
>Steve, not sure I understand your response.
>
>1)All decisions in the meeting room need to be confirmed on list, and
>this is essentially the thread that is doing that. So it is perfectly
>appropriate to question anything discussed in the face-to-face meeting as
>part of that thread.
>
>2)Your use of "unanimous" is incorrect (and indeed irrelevant to the
>discussion) and I do not believe that word was used in the meeting room.
>IETF needs "rough consensus".
>
>3)If any work is performed, I do believe this should be limited to E.164,
>with no scope for extension without rechartering. (And that is not saying
>I believe this is needed as a product, merely that I have no objection to
>the work being done.) It may well be up to other SDOs to apply the
>principles of any resultant RFC to other identifiers if they feel the
>need. Certainly before IETF starts work on any SMS identifiers, as was
>suggested in a prior mail, there should be a communication with 3GPP and
>possibly GSMA as to whether there is a use case for such a mechanism in
>that respect, as all SMS work apart from some IANA registrations lies in
>those organisations.
>
>Regards
>
>Keith
>
>> -----Original Message-----
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve
>> Donovan
>> Sent: 30 April 2015 13:17
>> To: modern@ietf.org
>> Subject: Re: [Modern] Revised MODERN Charter
>>
>> Pierce,
>>
>> I don't understand the relevance of your question.
>>
>> The scope of work for the MODERN working group was discussed at the
>> MODERN BOF during IETF 92.  Consensus was reached that the IETF should
>> do the work outlined in the charter.  If I recall correctly the
>> response to that question was unanimous but it is possible that I
>> missed some isolated negative hums.
>>  This consensus clearly includes protocol work.
>> Whether they are new protocols depends on what the working group
>> produces.
>>
>> The primary open question that needed to be addressed in the charter
>> was the set of identifiers that the working group would address. Thus
>> the proposal to limit the scope of work to E.164 numbers.
>>
>> You can find the minutes from the meeting here:
>>
>> https://www.ietf.org/proceedings/92/minutes/minutes-92-modern
>>
>> Regards,
>>
>> Steve
>>
>> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:
>> > Thank you Henning.  Your list of general notions is what I
>> was encouraging Steve Donovan, et al, to do.
>> >
>> > I didn't volunteer any items even though I could think of
>> some because I'm not convinced the MODERN WG needs to include in its
>> charter anything to do with respect to "managing"
>> E.164 telephone numbers.
>> >
>> > As you say, "nobody would design a new system to replicate
>> what has evolved over decades".
>> >
>> > I think your list of notions is useful input, but it would
>> seem like it ought to be directed at the existing
>> organization(s) with authority and responsibility to manage
>> E.164 telephone numbers.
>> >
>> > If they identify (or have identified already) a need for
>> new protocols (really?) or request that the IETF develop a framework,
>> then certainly MODERN could be a good place to respond to that
>> request.  Has that happened?
>> >
>> > Best regards,
>> >
>> >
>> > Pierce Gorman
>> > Core Network Planning
>> > O: 913-439-4368  M: 816-210-8623
>> > pierce.gorman@sprint.com
>> >
>> >
>> > -----Original Message-----
>> > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
>> > Sent: April 29, 2015 6:38 AM
>> > To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
>> > Cc: Modern List; McGarry, Tom
>> > Subject: RE: [Modern] Revised MODERN Charter
>> >
>> > Pierce,
>> >
>> > since you and your organization probably have first-hand
>> experience with the existing system, particularly as you transition to
>> all-IP, I'd be very interested in hearing what you see as deficiencies
>> or problems.
>> >
>> > My general take is that just about anything can be made to
>> work ("with enough thrust, pigs can fly"), but that I suspect nobody
>> would design a new system to replicate what has evolved over decades.
>> I'm not sure the charter has to spell out every problem in detail, but
>> a general motivation seems useful.
>> >
>> > My general notions are:
>> > - lack of flexibility (e.g., difficult to add fields without a very
>> > elaborate and lengthy process typically spanning years)
>> > - lack of distribution (hard or impossible to have more than one
>> > administrator for each database)
>> > - complexity (we hear a fair amount about rural call completion
>> > problems which aren't helped by small providers struggling to keep
>> > numbers straight)
>> > - difficulty of adopting more modern allocation (e.g.,
>> "blocks" of 1)
>> > and porting mechanisms
>> >
>> > Henning
>> >
>> > ________________________________
>> > From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com]
>> > Sent: Monday, April 27, 2015 10:36 AM
>> > To: Henning Schulzrinne; Ben Campbell; Richard Shockey
>> > Cc: Modern List; McGarry, Tom
>> > Subject: RE: [Modern] Revised MODERN Charter
>> >
>> >
>> > David Holmes has made the point in the past that it is
>> important to list out what are the issues or problems to be solved
>> that drive the work effort.
>> >
>> >
>> >
>> > To David's point, what are the flaws or inadequacies of the
>> current administration and conservation of the E.164 telephone numbers
>> that require or benefit from an IETF work group?  i.e., what is wrong
>> with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
>> >
>> >
>> >
>> > My question is aimed specifically at the section in the
>> charter which reads:
>> >
>> >
>> >
>> > The working group will define a framework for the roles and
>> functions involved in managing and resolving TNs in an IP environment.
>> This includes a protocol mechanism for acquiring TNs, which will
>> provide an enrollment process for the individuals and entities that
>> use and manage TNs.
>> >
>> >
>> >
>> > Best regards,
>> >
>> >
>> >
>> >
>> >
>> > Pierce Gorman
>> >
>> > Core Network Planning
>> >
>> > O: 913-439-4368
>> >
>> > pierce.gorman@sprint.com
>> >
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning
>> > Schulzrinne
>> > Sent: April 25, 2015 7:37 AM
>> > To: Ben Campbell; Richard Shockey
>> > Cc: Modern List; McGarry, Tom
>> > Subject: Re: [Modern] Revised MODERN Charter
>> >
>> >
>> >
>> > I'm not sure it matters if the identifier is numeric or
>> not, but the unifying principle seems to be that there is a clear
>> delegation chain, within a confined geographic (mostly in the legal
>> sense, i.e., a well-known set of national laws
>> apply) scope. In particular, this implies that the entities
>> participating can generally be assumed to be cooperative, as there is
>> an umpire to remove any uncooperative players from the field.
>> >
>> >
>> >
>> > I don't think it's a priority, but SMS shortcodes seem
>> similar enough to fit into the same mechanism.
>> >
>> >
>> >
>> > To avoid needless ambiguity, simply saying E.164 numbers
>> and leaving the door open to other identifiers that happen to fit
>> might work.
>> >
>> >
>> >
>> > ________________________________________
>> >
>> > From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell
>> > [ben@nostrum.com]
>> >
>> > Sent: Friday, April 24, 2015 5:09 PM
>> >
>> > To: Richard Shockey
>> >
>> > Cc: Modern List; McGarry, Tom
>> >
>> > Subject: Re: [Modern] Revised MODERN Charter
>> >
>> >
>> >
>> > On 24 Apr 2015, at 15:43, Richard Shockey wrote:
>> >
>> >
>> >
>> >> Out hopefully=A9that is a private proprietary namespace.
>> >
>> >
>> > Okay, so Skype IDs were a bad example--but my question was
>> about whether the "other telephony related identifiers" were still
>> assumed to be things that look like TNs.
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> >
>> > Modern mailing list
>> >
>> > Modern@ietf.org
>> >
>> > 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.
>> >
>> > ________________________________
>> >
>> > This e-mail may contain Sprint proprietary information
>> intended for the sole use of the recipient(s). Any use by others is
>> prohibited. If you are not the intended recipient, please contact the
>> sender and delete all copies of the message.
>> >
>> > _______________________________________________
>> > Modern mailing list
>> > Modern@ietf.org
>> > https://www.ietf.org/mailman/listinfo/modern
>> >
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>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.
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Apr 30 13:11:44 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C1A1A0181 for ; Thu, 30 Apr 2015 13:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHUOZPNlwCy4 for ; Thu, 30 Apr 2015 13:11:39 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51D21A017D for ; Thu, 30 Apr 2015 13:11:39 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t3UK2o9a021291; Thu, 30 Apr 2015 16:11:38 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1u3pk38e7a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 16:11:38 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Thu, 30 Apr 2015 16:11:36 -0400
From: "McGarry, Tom" 
To: "Gorman, Pierce A [CTO]" 
Thread-Topic: [Modern] Revised MODERN Charter
Thread-Index: AQHQe3iuavWLquyVY02Q/laaiIQEe51c4sYAgAAH84CAAAdlgIAAvf5RgAOLPICAAq06o4AApb6AgAE80YCAAB95gIAAQ/gA///eNb8=
Date: Thu, 30 Apr 2015 20:11:36 +0000
Message-ID: <0BAA4724-EBEB-4252-87BE-999D470DDE25@neustar.biz>
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com> ,  ,    <55421D27.7020905@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <6ff23f316bec4bca9761aabc7ee2fe53@PLSWE13M08.ad.sprint.com>
In-Reply-To: <6ff23f316bec4bca9761aabc7ee2fe53@PLSWE13M08.ad.sprint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-04-30_05:2015-04-30,2015-04-30,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.44849987560036e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.992957022353465 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.992957022353465 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.992957022353465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504300233
Archived-At: 
Cc: Steve Donovan , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 20:11:43 -0000

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

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

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

Sent from my iPhone

> On Apr 30, 2015, at 2:13 PM, Gorman, Pierce A [CTO]  wrote:
>=20
> Thank you Keith.  I'm a newbie when it comes to standards discussions and=
 I appreciate your assistance.
>=20
> Steve,
>=20
> One of the main concerns I have with the proposed MODERN charter is the c=
onfusion being generated between the IETF MODERN WG and existing NANP SDOs.
>=20
> I've talked with our internal numbering folks who represent Sprint in the=
 INC/NANC organizations and they definitely do not understand why IETF is i=
s chartering a WG that "...will define a framework for the roles and functi=
ons involved in managing and resolving TNs..." which "will provide an enrol=
lment process for the individuals and entities that use and manage TNs."
>=20
> I would have a similar concern if INC decided to convene a group to deter=
mine how to better manage IP addresses because INC was dissatisfied with:
>=20
>     * management of IP addressing by multiple independent RIRs
>     * challenges associated with resolving TNs to IPs across slowly evolv=
ing multiple versions of IP addresses
>     * private versus public addressing
>     * increased costs dealing with IP network address and port translatio=
n across operational boundaries of varying complexity and security requirem=
ents
>=20
> I would feel that it was incumbent upon INC to liason with IETF and ARIN =
to address concerns, and not create a new INC WG proposing to usurp ARIN an=
d manage what ARIN is responsible for.
>=20
> I use ARIN in my hypothetical example because I'm specifically concerned =
about management of numbers in the NANP.   CC=3D1 is the only E.164 namespa=
ce we're a participant in managing.  I assume non-NA numbering management o=
rganizations (e.g., ITU) can comfortably ignore MODERN but that NANC cannot=
 (and vice-versa).
>=20
> For discussion's sake, let's say I hadn't questioned this part of the MOD=
ERN charter, and work proceeded quickly generating a quality framework that=
 had "rough consensus".  How will MODERN go about implementing this framewo=
rk?  Will MODERN WG not then be in the position of reaching out to INC/NANC=
 for discussions?
>=20
> I'll offer additional concerns I think are of a more practical nature.
>=20
> There is a Joint Task Force WG under the auspices of the SIP Forum and AT=
IS PTSC which covered much of this same ground MODERN is proposing in its c=
harter.  The JTF produced two technical reports; a routing TR, and an inter=
-carrier all-IP NNI TR.  The routing TR largely conisists of multiple propo=
sals on how to manage, provision, and resolve telephone numbers and IP addr=
esses.
>=20
> Also, the FCC and NANC authorized transition of number portability manage=
ment from Neustar to iconective.
>=20
> NPAC transition planning is an example where MODERN might offer benefit t=
o NANC regarding development of enrollment, metadata, and provisioning prot=
ocol mechanisms.  But this assumes the SDOs are working together and not in=
dependently of one another.
>=20
> As it is, I assume NANC (NAPM LLC) will work independently of MODERN to m=
anage the transition.  And I assume there is some (small?) risk of potentia=
lly changing the underlying number management problem set MODERN is proposi=
ng to address while MODERN is in-flight addressing it.  (As a nit, I'll als=
o mention I think the proposed MODERN charter implies number management is =
a single database problem ignoring LERG and LNP.)
>=20
> I'm reminded of jokes regarding light bulb installation.
>=20
> Best regards,
>=20
>=20
> Pierce Gorman
> Core Network Planning
> O: 913-439-4368
> pierce.gorman@sprint.com
>=20
>=20
> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DRAGE, Keith (=
Keith)
> Sent: April 30, 2015 9:09 AM
> To: Steve Donovan; modern@ietf.org
> Subject: Re: [Modern] Revised MODERN Charter
>=20
> Steve, not sure I understand your response.
>=20
> 1)All decisions in the meeting room need to be confirmed on list, and thi=
s is essentially the thread that is doing that. So it is perfectly appropri=
ate to question anything discussed in the face-to-face meeting as part of t=
hat thread.
>=20
> 2)Your use of "unanimous" is incorrect (and indeed irrelevant to the disc=
ussion) and I do not believe that word was used in the meeting room. IETF n=
eeds "rough consensus".
>=20
> 3)If any work is performed, I do believe this should be limited to E.164,=
 with no scope for extension without rechartering. (And that is not saying =
I believe this is needed as a product, merely that I have no objection to t=
he work being done.) It may well be up to other SDOs to apply the principle=
s of any resultant RFC to other identifiers if they feel the need. Certainl=
y before IETF starts work on any SMS identifiers, as was suggested in a pri=
or mail, there should be a communication with 3GPP and possibly GSMA as to =
whether there is a use case for such a mechanism in that respect, as all SM=
S work apart from some IANA registrations lies in those organisations.
>=20
> Regards
>=20
> Keith
>=20
>> -----Original Message-----
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve
>> Donovan
>> Sent: 30 April 2015 13:17
>> To: modern@ietf.org
>> Subject: Re: [Modern] Revised MODERN Charter
>>=20
>> Pierce,
>>=20
>> I don't understand the relevance of your question.
>>=20
>> The scope of work for the MODERN working group was discussed at the
>> MODERN BOF during IETF 92.  Consensus was reached that the IETF should
>> do the work outlined in the charter.  If I recall correctly the
>> response to that question was unanimous but it is possible that I
>> missed some isolated negative hums.
>> This consensus clearly includes protocol work.
>> Whether they are new protocols depends on what the working group
>> produces.
>>=20
>> The primary open question that needed to be addressed in the charter
>> was the set of identifiers that the working group would address. Thus
>> the proposal to limit the scope of work to E.164 numbers.
>>=20
>> You can find the minutes from the meeting here:
>>=20
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_proc=
eedings_92_minutes_minutes-2D92-2Dmodern&d=3DAwIFBA&c=3DMOptNlVtIETeDALC_lU=
Lrw&r=3D4Klm32iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DtKiH7d2V4QFGuXkmnVz=
Y030gfNCDwvjfL5lzOrX6qQs&s=3Dxopj1tqPN5PGIHrrSzra_u7RKrg6MYYqy2MU_HtXnNs&e=
=3D=20
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>>> On 4/29/15 12:22 PM, Gorman, Pierce A [CTO] wrote:
>>> Thank you Henning.  Your list of general notions is what I
>> was encouraging Steve Donovan, et al, to do.
>>>=20
>>> I didn't volunteer any items even though I could think of
>> some because I'm not convinced the MODERN WG needs to include in its
>> charter anything to do with respect to "managing"
>> E.164 telephone numbers.
>>>=20
>>> As you say, "nobody would design a new system to replicate
>> what has evolved over decades".
>>>=20
>>> I think your list of notions is useful input, but it would
>> seem like it ought to be directed at the existing
>> organization(s) with authority and responsibility to manage
>> E.164 telephone numbers.
>>>=20
>>> If they identify (or have identified already) a need for
>> new protocols (really?) or request that the IETF develop a framework,
>> then certainly MODERN could be a good place to respond to that
>> request.  Has that happened?
>>>=20
>>> Best regards,
>>>=20
>>>=20
>>> Pierce Gorman
>>> Core Network Planning
>>> O: 913-439-4368  M: 816-210-8623
>>> pierce.gorman@sprint.com
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
>>> Sent: April 29, 2015 6:38 AM
>>> To: Gorman, Pierce A [CTO]; Ben Campbell; Richard Shockey
>>> Cc: Modern List; McGarry, Tom
>>> Subject: RE: [Modern] Revised MODERN Charter
>>>=20
>>> Pierce,
>>>=20
>>> since you and your organization probably have first-hand
>> experience with the existing system, particularly as you transition to
>> all-IP, I'd be very interested in hearing what you see as deficiencies
>> or problems.
>>>=20
>>> My general take is that just about anything can be made to
>> work ("with enough thrust, pigs can fly"), but that I suspect nobody
>> would design a new system to replicate what has evolved over decades.
>> I'm not sure the charter has to spell out every problem in detail, but
>> a general motivation seems useful.
>>>=20
>>> My general notions are:
>>> - lack of flexibility (e.g., difficult to add fields without a very
>>> elaborate and lengthy process typically spanning years)
>>> - lack of distribution (hard or impossible to have more than one
>>> administrator for each database)
>>> - complexity (we hear a fair amount about rural call completion
>>> problems which aren't helped by small providers struggling to keep
>>> numbers straight)
>>> - difficulty of adopting more modern allocation (e.g.,
>> "blocks" of 1)
>>> and porting mechanisms
>>>=20
>>> Henning
>>>=20
>>> ________________________________
>>> From: Gorman, Pierce A [CTO] [Pierce.Gorman@sprint.com]
>>> Sent: Monday, April 27, 2015 10:36 AM
>>> To: Henning Schulzrinne; Ben Campbell; Richard Shockey
>>> Cc: Modern List; McGarry, Tom
>>> Subject: RE: [Modern] Revised MODERN Charter
>>>=20
>>>=20
>>> David Holmes has made the point in the past that it is
>> important to list out what are the issues or problems to be solved
>> that drive the work effort.
>>>=20
>>>=20
>>>=20
>>> To David's point, what are the flaws or inadequacies of the
>> current administration and conservation of the E.164 telephone numbers
>> that require or benefit from an IETF work group?  i.e., what is wrong
>> with INC/NANC/NANP, NPAC, and LERG that requires MODERN to fix it?
>>>=20
>>>=20
>>>=20
>>> My question is aimed specifically at the section in the
>> charter which reads:
>>>=20
>>>=20
>>>=20
>>> The working group will define a framework for the roles and
>> functions involved in managing and resolving TNs in an IP environment.
>> This includes a protocol mechanism for acquiring TNs, which will
>> provide an enrollment process for the individuals and entities that
>> use and manage TNs.
>>>=20
>>>=20
>>>=20
>>> Best regards,
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> Pierce Gorman
>>>=20
>>> Core Network Planning
>>>=20
>>> O: 913-439-4368
>>>=20
>>> pierce.gorman@sprint.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning
>>> Schulzrinne
>>> Sent: April 25, 2015 7:37 AM
>>> To: Ben Campbell; Richard Shockey
>>> Cc: Modern List; McGarry, Tom
>>> Subject: Re: [Modern] Revised MODERN Charter
>>>=20
>>>=20
>>>=20
>>> I'm not sure it matters if the identifier is numeric or
>> not, but the unifying principle seems to be that there is a clear
>> delegation chain, within a confined geographic (mostly in the legal
>> sense, i.e., a well-known set of national laws
>> apply) scope. In particular, this implies that the entities
>> participating can generally be assumed to be cooperative, as there is
>> an umpire to remove any uncooperative players from the field.
>>>=20
>>>=20
>>>=20
>>> I don't think it's a priority, but SMS shortcodes seem
>> similar enough to fit into the same mechanism.
>>>=20
>>>=20
>>>=20
>>> To avoid needless ambiguity, simply saying E.164 numbers
>> and leaving the door open to other identifiers that happen to fit
>> might work.
>>>=20
>>>=20
>>>=20
>>> ________________________________________
>>>=20
>>> From: Modern [modern-bounces@ietf.org] on behalf of Ben Campbell
>>> [ben@nostrum.com]
>>>=20
>>> Sent: Friday, April 24, 2015 5:09 PM
>>>=20
>>> To: Richard Shockey
>>>=20
>>> Cc: Modern List; McGarry, Tom
>>>=20
>>> Subject: Re: [Modern] Revised MODERN Charter
>>>=20
>>>=20
>>>=20
>>> On 24 Apr 2015, at 15:43, Richard Shockey wrote:
>>>=20
>>>=20
>>>=20
>>>> Out hopefully=8Athat is a private proprietary namespace.
>>>=20
>>>=20
>>> Okay, so Skype IDs were a bad example--but my question was
>> about whether the "other telephony related identifiers" were still
>> assumed to be things that look like TNs.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>>=20
>>> Modern mailing list
>>>=20
>>> Modern@ietf.org
>>>=20
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai=
lman_listinfo_modern&d=3DAwIFBA&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Huf=
veeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DtKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX=
6qQs&s=3DNMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=3D=20
>>>=20
>>> ________________________________
>>>=20
>>> 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.
>>>=20
>>> ________________________________
>>>=20
>>> 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.
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai=
lman_listinfo_modern&d=3DAwIFBA&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Huf=
veeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DtKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX=
6qQs&s=3DNMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=3D
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail=
man_listinfo_modern&d=3DAwIFBA&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufv=
eeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DtKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6=
qQs&s=3DNMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=3D
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_modern&d=3DAwIFBA&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DtKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6q=
Qs&s=3DNMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=3D=20
>=20
> ________________________________
>=20
> This e-mail may contain Sprint proprietary information intended for the s=
ole use of the recipient(s). Any use by others is prohibited. If you are no=
t the intended recipient, please contact the sender and delete all copies o=
f the message.
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_modern&d=3DAwIFBA&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DtKiH7d2V4QFGuXkmnVzY030gfNCDwvjfL5lzOrX6q=
Qs&s=3DNMi8qhrKu2rsWkTvlsm5yCL0k0I_Nz7nEmLfxAmd_1E&e=3D=20


From nobody Thu Apr 30 13:37:54 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5A1A0077 for ; Thu, 30 Apr 2015 13:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18latxx3ibwy for ; Thu, 30 Apr 2015 13:37:51 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DA61A0033 for ; Thu, 30 Apr 2015 13:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=cwm+2EAGDyjGkh9sZ0jvnXxATuLYOdTDt5FOvFhsrN4=;  b=agIck+LgO81yH0tsoRcFLsKogKBg5kYpiHLpfpijuMVYO1l7K0+vUO7V0wG0XIGY+HDO17fNiwdDdon1OqX4PQoofC76cN1yyJA9/Ksd4xOUHSqcAT549aY7/5nst88B/zjNOqo/XNW02k59zJb2cEjI5UPqNyvoVXgwDVWY2Fc=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:59658 helo=[192.168.15.122]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnvDO-0002JD-1A for modern@ietf.org; Thu, 30 Apr 2015 13:37:50 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_F049A37C-4D62-43FF-90A5-3061C9C35516"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Burger 
In-Reply-To: <55424844.9040700@usdonovans.com>
Date: Thu, 30 Apr 2015 16:37:44 -0400
Message-Id: <1D5B0A8A-A41B-41C2-8BB2-A5102506E947@standardstrack.com>
References: <55424844.9040700@usdonovans.com>
To: "modern@ietf.org" 
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: [Modern] Use cases that people may care about
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 20:37:53 -0000

--Apple-Mail=_F049A37C-4D62-43FF-90A5-3061C9C35516
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Are we boiling the ocean?

> On Apr 30, 2015, at 11:20 AM, Steve Donovan  =
wrote:
>=20
> The working group will define a framework for the roles and functions =
involved in managing and resolving TNs in an IP environment.

Does this mean we are replacing not only the NPAC, LERG, NANPA, et al., =
but ENUM, DNS, et al. too?

Let us put aside whether it is worth working on replacing something that =
works in order for the incumbents to spend a lot of money to get the =
features and functionality they get today. I.e., they have strong =
negative incentives to not use any results we develop in the IETF. =
Putting it bluntly, I did not see a lot of people saying the problems =
discussed by =
https://tools.ietf.org/html/draft-peterson-modern-problems-00 were =
problems that needed to be solved, or solved any time soon.

So, let=E2=80=99s put aside the Charter discussion for a few minutes, =
and see if we can come up with some problems that *do* need to be =
solved, and if we can rally behind a charter to solve them. If it =
happens that the solution to these problems can address the issues =
raised by Jon=E2=80=99s draft, then I think in the long term *everyone* =
can be happy.


OVERARCHING PROBLEM: E.164 numbers are being used for more than =
terminating phone calls by service providers.
[Why is this the overarching problem? Because if the problem is simply =
that the PSTN is transitioning to an all-IP telecommunications network, =
then until the industry really needs it, the industry will use the NPAC, =
LERG, etc. as is. The code to run the databases is already written, the =
code to interface with the databases is already written, and the =
policies, governance, procedures and regulations are already known and =
debugged.]

So, who would benefit from access to E.164 allocations that cannot get =
them right now?

I see two use cases; I would love it if people could pour in more.

USE CASE #1: Enterprise DID assignment
Cullen gave the compelling example of a multi-campus enterprise. Why do =
they need to buy their DIDs from a registered carrier, and then pay =
carriers for the privilege of moving them to other carriers for =
termination to their own campus?

USE CASE #2: DID-based applications
Another use case would be for enhanced services, such as a single number =
service. Today an enhanced services company needs to be a service bureau =
and buy their DIDs from a registered carrier, who will provide them with =
termination services. I.e., technically the service bureau is buying =
termination service and getting DIDs as a part of that termination =
service. Again, if the service bureau wants to change termination =
service providers, they have to pay for the privilege.



Let me examine Use Case #2. I would offer this is a compelling =
opportunity. Why? Because there are extant IP-based protocols for =
entities to get numbers from carriers today. Moreover, that are a bunch =
of incompatible IP-based protocols for entities to get numbers from =
carriers. I.e., we have existence proof of a solution, we have existence =
proof of market need, and we have an opportunity to create standards to =
expand markets and solve problems (like Cullen=E2=80=99s). For example =
(and thanks to Cullen for finding the URL=E2=80=99s so I do not need to =
go hunting), see:

> AT&T is doing this - see =
https://developer.att.com/apis/enhanced-webrtc/docs
>=20
> Tropo is doing this - see phone number pricing at =
https://www.tropo.com/pricing/
>=20
> Twillio is doing this - their pricing at =
https://www.twilio.com/voice/pricing#volume-pricing - and it is used by =
Uber, AIrBNB, PayPal, Opentable, Home Depot and so on
Twillio is also the back end for BT and others.

Note that where there are APIs, they are all different. That is an =
opportunity, I would think.

Now there is a subtlety going on here. All of these services are bundled =
with termination services. In the AT&T case mentioned above, it has a =
nice integration with their wireless offering and enterprise offering. =
For virtual numbers (DIDs), calls get handled by AT&T for termination to =
their customer, the app developer. For Tropo and Twillio, they ofter =
termination services at their platform, presumably through contracts =
with various global carriers, who have access to the pool of regional =
E.164 numbers.

Are we interested in making it easy for carriers to rent their inventory =
of DIDs? Are we interested in making it easy for application developers =
to have access to an inventory of DIDs? I know I am. Are you?

Note that solving this problem does not require the clean-sheet =
reinvention of the all-IP telecommunications network. I.e., not only how =
numbers are managed (which we have near zero consensus there is a need) =
but also how they are resolved (also near zero consensus there is a =
need).

Building on Use Case #1, if we can do retail rental of DIDs, any reason =
not to do bulk assignment of DIDs? This begins to come on to Cullen=E2=80=99=
s use case he brought up at the BOF. Namely, I am an enterprise and I =
somehow get a bucket full of DIDs. I want to assign them as I wish to my =
various campuses. That means that in addition to needing to be able to =
grab an allocation of DIDs (Use Case #2), I will need to tell my service =
provider how to terminate calls to a particular DID. That is a somewhat =
more challenging problem. However, I would offer it would have a big =
payout. The big payout is my expectation is a protocol that lets an =
enterprise grab a DID *and* lets an enterprise specify how to route that =
DID would look almost the same as a protocol that enables a carrier to =
manage E.164 allocation and use.

So, you might ask, =E2=80=9CHas Eric lost his mind? Eric has been saying =
no one wants to build a protocol to enable a carrier to manage E.164 =
numbers, and yet in the paragraph above he says we can enable carriers =
to manage E.164 numbers!=E2=80=9D Well, here is the answer: approaching =
the problem from the national numbering authority perspective is doomed. =
It is rather clear that no one wants to tackle it, and even if we did, =
as Pierce rather eloquently stated, we are walking right into other =
folks=E2=80=99 SDO patch. I would offer his ARIN analogy is 100% spot =
on.

Let us not look at this problem as =E2=80=9CHow do we do work to remove =
the last reason for carriers to exist?=E2=80=9D That is, if carriers do =
not vouch for subscriber identity and manager their numbers, what is =
left for them to do? Instead, let us look at a parallel and really valid =
problem: how can we automate and standardize the interaction between =
_some_entity_with_numbers_ (carriers in the base case) and =
_some_entity_that_uses_numbers_ (app service bureaux and enterprises). =
If it happens the solution to that could be used for the cases mentioned =
in Jon=E2=80=99s draft, that is gravy.

--Apple-Mail=_F049A37C-4D62-43FF-90A5-3061C9C35516
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQpKYAAoJEDY/T2tCIPW3tdgP/iU4xZnFi3YlXMFvyhOo5OPU
Z5STXVyprqJLGF6Fuz7VE8M5q/fPSCZfFR+4tLA0OUrkG6BXhdmh9bLLd6HnSalv
xJnGoViLR5bodvdMWS2rOsBVkR/9lSS5zluC7e4Vk+fKiMSDNbNJepp5iF8njR4e
JehfbZpGlf8smeFqlBBejWygN2dvEQh+FG70AAo9fbUDIhkcDm+E/iDjrj/dEGqI
MGhRQ/aYfumfNqLG/RWTkRYugNfhe3YQoU1uYPV5MXDhDpES1w1cWGnoFUtiUf1O
QE6KfifRSMK4mn0CnJishIUI20rcMvXGg/FP0BUFET9rnF2Hj0GCTLUHCT9H46b2
KBkzBtTt+yHNmTNOcRfAhmNa5C82OlXttJgJ0d2pCd+dER/IqDbL4TlaG2tpw92d
19QDUj7G58VWG/uqPb3BQ9FmVKHQZm8+Nr7FvI6UmNW34BipburU/sSuM5wRAbG/
QLeFkJ1ZzAZKaEvpmpJM6W2mskA5flagIH4xpY9zi5WnZE8bVpxwuoPrY6tBR6vB
lRcjJjEn7gTNGMWVUFlMwEfYeq8Q9kTHueSAln8CWNgD0r9zmtlRVqrMLZ9tAvOt
EZ31Y9cAoUTwpiRFIaubP4EKe6+BuKAsvuneH8GvwmgvRGIWVaY40QLOPDwWvsck
GzJCHu3UPj9B4wosqWuI
=KUG8
-----END PGP SIGNATURE-----

--Apple-Mail=_F049A37C-4D62-43FF-90A5-3061C9C35516--


From nobody Thu Apr 30 13:40:38 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256381A00BF for ; Thu, 30 Apr 2015 13:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hg__DvwB_-j for ; Thu, 30 Apr 2015 13:40:34 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A381A00CD for ; Thu, 30 Apr 2015 13:40:33 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 5D0DF37269101; Thu, 30 Apr 2015 20:40:27 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UKeUh5008561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 22:40:31 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 22:40:30 +0200
From: "DRAGE, Keith (Keith)" 
To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] A revised revised MODERN charter
Thread-Index: AQHQg1lOihCD8v7+G0ejkSdsD1Xpg51lnBIAgAA5R/D///fKgIAANSEg
Date: Thu, 30 Apr 2015 20:40:30 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970D457@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <55424844.9040700@usdonovans.com>  <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] A revised revised MODERN charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 20:40:37 -0000

Well here is where it would help if people actually read E.164, and why I r=
eferred to annex A, especially when you say the terminology defined there d=
oes not suit your purpose.

To the best of my knowledge US freephone numbers are international E.164 nu=
mbers. They can be used across national boundaries; all that happens is tha=
t the resultant call is not free of charge.

If they are not used across national boundaries, I suspect they fall into t=
he class identified in E.164 annex A.8.3.2 as international special purpose=
 numbers used nationally.

What you mean by service codes are, I suspect, identified in E.164 annex A.=
8.3.1 as Local Special Purpose Numbers.

"telephone number range" is just a means of specifying multiple numbers in =
one go. It does not remove the necessity of saying what those numbers are.

As regards the latter part of your mail, IETF has zero responsibility for r=
edefining the numbering plan for the telephony world, or its administration=
. If you want to do that, I suggest you get your tickets to ITU-T SG2.=20

Keith

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20
> Sent: 30 April 2015 20:20
> To: DRAGE, Keith (Keith); Steve Donovan; modern@ietf.org
> Subject: Re: [Modern] A revised revised MODERN charter
>=20
>=20
> The list of identifiers I personally thought were=20
> interesting, and a description of the nature of telephone=20
> numbers, are both in draft-peterson-terq. Basically, when=20
> used for an ENUM-like query, TeRQ proposed operating on=20
> either telephone numbers or SPIDs, and being able to return a=20
> variety of identifiers including Internet identifiers like=20
> URIs or PSTN identifiers like trunk groups. It did include=20
> the notion of querying for a telephone number range - I think=20
> if we lose that property, we will lose a bunch of use cases=20
> that we want to keep. SPIDs, well, I'd be okay relegating=20
> them to a later extension or iteration.
>=20
> But ranges are one reason why I'm reluctant to say "E.164" in=20
> the charter.
> My understanding is that a lot of things don't fall under=20
> E.164, including service codes, short codes, US freephone=20
> numbers, and various other dialable numbers I think we care=20
> about. I would be comfortable defining "telephone number" by=20
> its ABNF rather than by its policy or practice, and going=20
> from there - in fact, I think doing so is essential to the=20
> whole MODERN concept of reimagining number administration.=20
> That's roughly what TeRQ does. In the early TeRQ discussions,=20
> there was some debate about whether we need a new ABNF for=20
> telephone numbers, and if so, fine - but that should be in=20
> the MODERN charter.
>=20
> Jon Peterson
> Neustar, Inc.
>=20
> On 4/30/15, 11:28 AM, "DRAGE, Keith (Keith)"
>  wrote:
>=20
> >I'd argue against putting extension statements in charters=20
> unless there=20
> >is at least a perception of a clear need to do additional work.
> >
> >At the end of the day, any working group can be rechartered, whether=20
> >such a statement exists or not. Conversely, the AD has a big orange=20
> >button to kill a working group, whether the charter has=20
> completed or not.
> >
> >Regarding using the term "telephone number" rather than=20
> "E.164 number",=20
> >then I am afraid that:
> >
> >-	I find no standard definition of the term that is useful
> >-	use within normal English / American covers a very wide range of
> >different perceptions, so in the US, I believe some people=20
> would quite=20
> >happily refer to sequences incorporating alphabetic characters as=20
> >telephone numbers. They would not in the UK.
> >
> >I prefer to use terms that are defined, especially in this case. I=20
> >would suggest the way forward is to identify what you want to cover=20
> >explicitly in addition to E.164 numbers. Then the list can cast=20
> >judgement. You may find that annex A of Recommendation E.164=20
> gives you=20
> >some appropriate terminology.
> >
> >Regards
> >
> >Keith
> >
> >> -----Original Message-----
> >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20
> Peterson,=20
> >> Jon
> >> Sent: 30 April 2015 17:25
> >> To: Steve Donovan; modern@ietf.org
> >> Subject: Re: [Modern] A revised revised MODERN charter
> >>=20
> >>=20
> >> While I understand the desire to scope identifiers in the=20
> charter per=20
> >> the recent thread, I think putting it this starkly is too=20
> >> restrictive:
> >>=20
> >> > Any such
> >> > extensions or reuse of MODERN mechanisms are out of=20
> scope for the=20
> >> > MODERN working group.
> >>=20
> >> I mean, I thought we were going to define an extensible=20
> >> query-response protocol in this working group for managing=20
> data about=20
> >> telephone numbers.
> >> Something that would look at least vaguely like what is in=20
> >> draft-peterson-terq. From this reading, I could easily argue that=20
> >> TeRQ is outside the scope of MODERN precisely because it is=20
> >> extensible to other identifiers.
> >>=20
> >> >From the recent thread, I had thought people were arguing
> >> for some gating.
> >> Like "first, this working group is going to define a mechanism for=20
> >> telephone numbers. The group may later recharter to work on other=20
> >> things."
> >> I would be okay with some text along those lines, though=20
> frankly, I=20
> >> would prefer the second sentence read more like, "this=20
> group is also=20
> >> chartered to further investigate the use of other=20
> identifiers for the=20
> >> purpose of an eventual recharter," since I think the expertise to=20
> >> scope the work on identifiers resides on this mailing list and we=20
> >> should explicitly use it for that purpose.
> >>=20
> >>=20
> >> Also, in that same paragraph I'd prefer not to qualify "telephone=20
> >> numbers"
> >> with "E.164". This seems to come up again and again, but,=20
> there are a=20
> >> lot of telephone numbers we care about that do to fall under the=20
> >> E.164 plan.
> >> The earlier charter text doesn't say E.164, and I don't=20
> see why this=20
> >> part needs to either. Let's just keep it to "telephone numbers."
> >>=20
> >> Jon Peterson
> >> Neustar, Inc.
> >>=20
> >> On 4/30/15, 8:20 AM, "Steve Donovan"=20
>  wrote:
> >>=20
> >> >The following is the latest proposed version of the=20
> MODERN working=20
> >> >group charter with updates discussed on the list=20
> discussion so far.
> >> >
> >> >Regards,
> >> >
> >> >Steve
> >> >
> >> >----------
> >> >
> >> >CHARTER TEXT:
> >> >
> >> >The MODERN working group will define a set of Internet-based
> >> mechanisms
> >> >for the purposes of managing and resolving telephone numbers
> >> (TNs) in
> >> >an IP environment.  Existing mechanisms for these purposes face=20
> >> >obsolescence as the voice communications infrastructure
> >> evolves to IP
> >> >technology and new applications for TNs become possible.  The=20
> >> >traditional model of a TN having an association to a=20
> single service=20
> >> >provider and a single application is breaking down.  Its use as a=20
> >> >network locator is going away, but its use as an=20
> identifier for an=20
> >> >individual or an organization will remain for some time. Devices,=20
> >> >applications, and network tools increasingly need to manage TNs,=20
> >> >including requesting and acquiring TN delegations from
> >> authorities.  A
> >> >sample of problems with existing mechanisms include:
> >> >
> >> >- lack of flexibility (for example, it can be difficult to
> >> add fields
> >> >without a very elaborate and lengthy process typically
> >> spanning years)
> >> >- lack of distribution (for example, it is hard or
> >> impossible to have
> >> >more than one administrator for each database)
> >> >- complexity (leading, for example, to a fair amount of=20
> rural call=20
> >> >completion problems which aren't helped by small providers
> >> struggling
> >> >to keep numbers straight)
> >> >- difficulty of adopting more modern allocation (e.g.,
> >> "blocks" of 1)
> >> >and porting mechanisms
> >> >
> >> >The working group will define a framework for the roles and
> >> functions
> >> >involved in managing and resolving TNs in an IP environment.
> >>  It will
> >> >also define protocol mechanisms for acquiring and resolving
> >> TNs.  The
> >> >protocol mechanism for acquiring TNs will provide an
> >> enrollment process
> >> >for the individuals and entities that use and manage TNs. TNs may=20
> >> >either be managed in a hierarchical tree, or in a distributed=20
> >> >peer-to-peer architecture.  Privacy of the enrollment data
> >> and security
> >> >of the resource will be primary considerations.  The
> >> protocol mechanism
> >> >for resolving TNs will allow entities such as service providers,=20
> >> >devices, and applications to access data related to TNs, possibly=20
> >> >including caller name data (CNAM).  Maintaining reliability,
> >> real time
> >> >application performance, security and privacy are primary=20
> >> >considerations.  The working group will take into consideration=20
> >> >existing IETF work including ENUM, SPEERMINT, and DRINKS.
> >> >
> >> >The work of this group will focus on E.164 telephone numbers
> >> due to the
> >> >changing telecom environment and interest expressed by=20
> >> >telecommunications industry regulators to support more flexible=20
> >> >regulatory models than exist today.  There is an expectation that=20
> >> >aspects of the architecture and protocols defined by the
> >> working group
> >> >will be reusable for other user-focused identifiers.  Any such=20
> >> >extensions or reuse of MODERN mechanisms are out of scope for the=20
> >> >MODERN working group.  Solutions and mechanisms created by
> >> the working
> >> >group will be flexible enough to accommodate different
> >> policies, e.g.,
> >> >by different regulatory agencies.
> >> >
> >> >The work group will deliver the following:
> >> >
> >> >-       An architecture overview, including high level
> >> requirements and
> >> >security/privacy considerations
> >> >
> >> >-       A description of the enrollment processes for
> >> existing and new
> >> >TNs including any modifications to metadata related to those TNs
> >> >
> >> >-       A description of protocol mechanisms for accessing contact
> >> >information associated with enrollments
> >> >
> >> >-       A description of mechanisms for resolving
> >> information related to
> >> >TNs
> >> >
> >> >_______________________________________________
> >> >Modern mailing list
> >> >Modern@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/modern
> >>=20
> >> _______________________________________________
> >> Modern mailing list
> >> Modern@ietf.org
> >> https://www.ietf.org/mailman/listinfo/modern
> >>=20
>=20
> =


From nobody Thu Apr 30 13:52:18 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330451A009E for ; Thu, 30 Apr 2015 13:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR-QB9ntwZLh for ; Thu, 30 Apr 2015 13:52:16 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BDD1A0060 for ; Thu, 30 Apr 2015 13:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=3hulxjszs5BhR2bFmJm+NXbyuEaGs/Z/Rg3Fy9jFlAM=;  b=QLBICV/5wrgE92W0VEILd5OehPuRm50oMogsw8z+dUGDNm0eQgO0ASvxmacSdxBnfbwv22te2PTwSSdfrtgNeqQiq7x4s7/S+WEwO7bbKgmuFXARdp93r6lbGB/sHX8/cM+ghkS0Zi1gI6ee4YT56IxKhu+LAkhFIu9DVP037Ck=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:59911 helo=[192.168.15.122]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnvRN-0003hy-FT for modern@ietf.org; Thu, 30 Apr 2015 13:52:14 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_08CAB1DE-599F-4A1A-903B-1890C8C70525"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Burger 
In-Reply-To: <0BAA4724-EBEB-4252-87BE-999D470DDE25@neustar.biz>
Date: Thu, 30 Apr 2015 16:52:12 -0400
Message-Id: <35BE3377-C0DD-4670-87C4-895DB94DDC19@standardstrack.com>
References:  <44E20DC0-AE48-4B62-9BBC-2B0F16060A7F@nostrum.com>       <55421D27.7020905@usdonovans.com> <949EF20990823C4C85C18D59AA11AD8B6970CE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <6ff23f316bec4bca9761aabc7ee2fe53@PLSWE13M08.ad.sprint.com> <0BAA4724-EBEB-4252-87BE-999D470DDE25@neustar.biz>
To: "modern@ietf.org" 
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] Revised MODERN Charter
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 20:52:17 -0000

--Apple-Mail=_08CAB1DE-599F-4A1A-903B-1890C8C70525
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On Apr 30, 2015, at 4:11 PM, McGarry, Tom  =
wrote:
>=20
> WRT questions about the problem space:
> The first paragraph says:
> -  existing mechanisms are facing obsolescence, ie., IP replacing PSTN

True, but not relevant.

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

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

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

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

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

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

Examples?

> There were two presentations that went into more detail on the problem =
space.
> There were non-telcos in the room that expressed strong support for a =
need to improve processes and capabilities wrt TN management.
>=20
> WRT what's wrong with NANPA/PA/LERG/NPAC:
> For all intents and purposes these are spreadsheet-based solutions. My =
company has to screen scrape some of these websites to collect number =
administration information. We'd very much like to improve these =
processes.
> The one that isn't spreadsheet based, NPAC, is special purpose built =
for PSTN systems which have to be jury-rigged to work for IP networks.
> While the question was US-specific we work with number administration =
all over the world and they all need improvement, I'm sure others would =
agree.

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

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

What does =91supportive=92 mean?

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

Agreed.



--Apple-Mail=_08CAB1DE-599F-4A1A-903B-1890C8C70525
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQpX8AAoJEDY/T2tCIPW3V1wP/2S5HAVbGvPeyLCUp2qeTKuD
yQIJNEaxfRavGMxgHmvt5jli5NxZCqN/+iSpdcEyFgw/1/FBVyrweswItuNZZ3Kb
2Sqr/GXNuHVpUJo6RCX0T/xr7z674fg6h//NNf4ExBfbE8/nuP37aO8XNLyKPOOo
bYeNUumvf6cemWYR6UvI5JUybOHaK7RQbKi+wixY2R8w5kw71O+vl/hL0+DGrjPf
f0pJjvDCEz9BNYxp/y2Kks2YR7t1FNymcacAf0HXAyHA5tR1dtO+8q0pFO5iDWkM
ivwjOXi9Bh9QCJh/O02CLIkZG2yy34F7AlE4BiqZXN7Vqo00wiXb2rmynfiBKKEX
AueSm9+dLNY2DxOdiylhY0cHeFOy62MmIvNs2nWufe6YbmCIFVV6gU7x6ro/9Qzt
zJQC23jbprRc5AW4N/zEH3iGkuriCkazyME6Brl1QlZ8ciX0yUxPYopjKTsKu2eq
KrvA6B+FCw45rP9viUqoLtG8Of04nbOA4duH/XURm00xrUGkOlu2JTdpXPnh4yi3
ymp3aSsYFIZY7Qzn2+D7NsFVhpd4Xg+a4HnFli2gUpMRE+ikDa8HfN+AHRNB6Zcn
LF1U4pk4nMZypXTkh5b1wThBALwm9eLI5v1r8nAmX0SsWa+C+pKVcNyZd5j9sl+6
D3n39T89V/700g581wMZ
=JcCN
-----END PGP SIGNATURE-----

--Apple-Mail=_08CAB1DE-599F-4A1A-903B-1890C8C70525--


From nobody Thu Apr 30 14:02:02 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDF51A00F7 for ; Thu, 30 Apr 2015 14:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paO6pfTMXuq5 for ; Thu, 30 Apr 2015 14:01:59 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471271A00D4 for ; Thu, 30 Apr 2015 14:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=UqnSIU9Hz303oKhJETAJgCBKiBAUspxM57oyLh2wBLI=;  b=tKnkLeFIuFCGDeSn6I7Of4ZN79sUkJoXevOzkGwonoudWi4xd/+S4UtZjGiHckHHWRXebNAJm7hW94gdsKc+q5ieqAe/IWKrb1EpA5KmTAGW8X01ZSdDLR6VeA49H0OmOQicQOMmkTGZ0Su+nN5uzuYyIp0fzb7Y1Cff2ZKGGUQ=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:60082 helo=[192.168.15.122]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Ynvam-0008WJ-Ed for modern@ietf.org; Thu, 30 Apr 2015 14:01:58 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_637BDE3A-7DF1-4979-A64A-65631C1E73B7"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Date: Thu, 30 Apr 2015 17:01:55 -0400
References: <55424844.9040700@usdonovans.com>  <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com>  
To: modern@ietf.org
In-Reply-To: 
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] All-IP telecommunications network or TN identifiers
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 21:02:01 -0000

--Apple-Mail=_637BDE3A-7DF1-4979-A64A-65631C1E73B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Here is a big question for the community that Keith has been touching =
on: what *is* a telephone number? As Keith points out, the only thing =
that makes sense for us to talk about is an E.164 number. Otherwise, we =
are talking about strings of digits that are up to 15 digits long. We =
can do that right now - heck, not much different than an ASN.

So, if we are talking about E.164 numbers, can we hand them out =
willy-nilly? The answer from Henning=E2=80=99s presentation: No, an =
E.164 number is literally that, something the ITU-T allocates at the =
international (country code) level [ITU Operational Bulletin No. 835]. =
Moreover, the answer for delegated numbers is also No: Henning=E2=80=99s =
expectation is different nation states will handle number allocation as =
they see fit.

What I am offering here, and the first point of question for the work =
group, is whether it makes sense for the IETF to be heading directly =
into policy space? I.e., carriers or users getting numbers directly from =
a numbering authority (to use Jon=E2=80=99s terms)?

My vote is a strong No. We do not have a need to reinvent number =
allocation. =46rom a business perspective, carriers already get numbers =
from numbering authorities. The code is written, debugged, and works. In =
fact, it mostly works over IP, if you want to get into the particulars =
and feel that because something runs over IP it is =E2=80=98better.' =
Until it is time for the carriers to replace their provisioning systems, =
there is little need for a =E2=80=98new=E2=80=99 method to get what they =
get today.



> On Apr 30, 2015, at 3:20 PM, Peterson, Jon  =
wrote:
>=20
>=20
> The list of identifiers I personally thought were interesting, and a
> description of the nature of telephone numbers, are both in
> draft-peterson-terq. Basically, when used for an ENUM-like query, TeRQ
> proposed operating on either telephone numbers or SPIDs, and being =
able to
> return a variety of identifiers including Internet identifiers like =
URIs
> or PSTN identifiers like trunk groups. It did include the notion of
> querying for a telephone number range - I think if we lose that =
property,
> we will lose a bunch of use cases that we want to keep. SPIDs, well, =
I'd
> be okay relegating them to a later extension or iteration.
>=20
> But ranges are one reason why I'm reluctant to say "E.164" in the =
charter.
> My understanding is that a lot of things don't fall under E.164, =
including
> service codes, short codes, US freephone numbers, and various other
> dialable numbers I think we care about. I would be comfortable =
defining
> "telephone number" by its ABNF rather than by its policy or practice, =
and
> going from there - in fact, I think doing so is essential to the whole
> MODERN concept of reimagining number administration. That's roughly =
what
> TeRQ does. In the early TeRQ discussions, there was some debate about
> whether we need a new ABNF for telephone numbers, and if so, fine - =
but
> that should be in the MODERN charter.
>=20
> Jon Peterson
> Neustar, Inc.
>=20
> On 4/30/15, 11:28 AM, "DRAGE, Keith (Keith)"
>  wrote:
>=20
>> I'd argue against putting extension statements in charters unless =
there
>> is at least a perception of a clear need to do additional work.
>>=20
>> At the end of the day, any working group can be rechartered, whether =
such
>> a statement exists or not. Conversely, the AD has a big orange button =
to
>> kill a working group, whether the charter has completed or not.
>>=20
>> Regarding using the term "telephone number" rather than "E.164 =
number",
>> then I am afraid that:
>>=20
>> -	I find no standard definition of the term that is useful
>> -	use within normal English / American covers a very wide range of
>> different perceptions, so in the US, I believe some people would =
quite
>> happily refer to sequences incorporating alphabetic characters as
>> telephone numbers. They would not in the UK.
>>=20
>> I prefer to use terms that are defined, especially in this case. I =
would
>> suggest the way forward is to identify what you want to cover =
explicitly
>> in addition to E.164 numbers. Then the list can cast judgement. You =
may
>> find that annex A of Recommendation E.164 gives you some appropriate
>> terminology.
>>=20
>> Regards
>>=20
>> Keith=20
>>=20
>>> -----Original Message-----
>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of
>>> Peterson, Jon
>>> Sent: 30 April 2015 17:25
>>> To: Steve Donovan; modern@ietf.org
>>> Subject: Re: [Modern] A revised revised MODERN charter
>>>=20
>>>=20
>>> While I understand the desire to scope identifiers in the
>>> charter per the recent thread, I think putting it this
>>> starkly is too restrictive:
>>>=20
>>>> Any such
>>>> extensions or reuse of MODERN mechanisms are out of scope for the
>>>> MODERN working group.
>>>=20
>>> I mean, I thought we were going to define an extensible
>>> query-response protocol in this working group for managing
>>> data about telephone numbers.
>>> Something that would look at least vaguely like what is in
>>> draft-peterson-terq. =46rom this reading, I could easily argue
>>> that TeRQ is outside the scope of MODERN precisely because it
>>> is extensible to other identifiers.
>>>=20
>>>> =46rom the recent thread, I had thought people were arguing
>>> for some gating.
>>> Like "first, this working group is going to define a
>>> mechanism for telephone numbers. The group may later
>>> recharter to work on other things."
>>> I would be okay with some text along those lines, though
>>> frankly, I would prefer the second sentence read more like,
>>> "this group is also chartered to further investigate the use
>>> of other identifiers for the purpose of an eventual
>>> recharter," since I think the expertise to scope the work on
>>> identifiers resides on this mailing list and we should
>>> explicitly use it for that purpose.
>>>=20
>>>=20
>>> Also, in that same paragraph I'd prefer not to qualify
>>> "telephone numbers"
>>> with "E.164". This seems to come up again and again, but,
>>> there are a lot of telephone numbers we care about that do to
>>> fall under the E.164 plan.
>>> The earlier charter text doesn't say E.164, and I don't see
>>> why this part needs to either. Let's just keep it to
>>> "telephone numbers."
>>>=20
>>> Jon Peterson
>>> Neustar, Inc.
>>>=20
>>> On 4/30/15, 8:20 AM, "Steve Donovan"  =
wrote:
>>>=20
>>>> The following is the latest proposed version of the MODERN working
>>>> group charter with updates discussed on the list discussion so far.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>> ----------
>>>>=20
>>>> CHARTER TEXT:
>>>>=20
>>>> The MODERN working group will define a set of Internet-based
>>> mechanisms=20
>>>> for the purposes of managing and resolving telephone numbers
>>> (TNs) in=20
>>>> an IP environment.  Existing mechanisms for these purposes face
>>>> obsolescence as the voice communications infrastructure
>>> evolves to IP=20
>>>> technology and new applications for TNs become possible.  The
>>>> traditional model of a TN having an association to a single service
>>>> provider and a single application is breaking down.  Its use as a
>>>> network locator is going away, but its use as an identifier for an
>>>> individual or an organization will remain for some time. Devices,
>>>> applications, and network tools increasingly need to manage TNs,
>>>> including requesting and acquiring TN delegations from
>>> authorities.  A=20
>>>> sample of problems with existing mechanisms include:
>>>>=20
>>>> - lack of flexibility (for example, it can be difficult to
>>> add fields=20
>>>> without a very elaborate and lengthy process typically
>>> spanning years)
>>>> - lack of distribution (for example, it is hard or
>>> impossible to have
>>>> more than one administrator for each database)
>>>> - complexity (leading, for example, to a fair amount of rural call
>>>> completion problems which aren't helped by small providers
>>> struggling=20
>>>> to keep numbers straight)
>>>> - difficulty of adopting more modern allocation (e.g.,
>>> "blocks" of 1)=20
>>>> and porting mechanisms
>>>>=20
>>>> The working group will define a framework for the roles and
>>> functions=20
>>>> involved in managing and resolving TNs in an IP environment.
>>> It will=20
>>>> also define protocol mechanisms for acquiring and resolving
>>> TNs.  The=20
>>>> protocol mechanism for acquiring TNs will provide an
>>> enrollment process
>>>> for the individuals and entities that use and manage TNs. TNs may
>>>> either be managed in a hierarchical tree, or in a distributed
>>>> peer-to-peer architecture.  Privacy of the enrollment data
>>> and security=20
>>>> of the resource will be primary considerations.  The
>>> protocol mechanism
>>>> for resolving TNs will allow entities such as service providers,
>>>> devices, and applications to access data related to TNs, possibly
>>>> including caller name data (CNAM).  Maintaining reliability,
>>> real time=20
>>>> application performance, security and privacy are primary
>>>> considerations.  The working group will take into consideration
>>>> existing IETF work including ENUM, SPEERMINT, and DRINKS.
>>>>=20
>>>> The work of this group will focus on E.164 telephone numbers
>>> due to the=20
>>>> changing telecom environment and interest expressed by
>>>> telecommunications industry regulators to support more flexible
>>>> regulatory models than exist today.  There is an expectation that
>>>> aspects of the architecture and protocols defined by the
>>> working group=20
>>>> 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=20
>>>> group will be flexible enough to accommodate different
>>> policies, e.g.,=20
>>>> by different regulatory agencies.
>>>>=20
>>>> The work group will deliver the following:
>>>>=20
>>>> -       An architecture overview, including high level
>>> requirements and
>>>> security/privacy considerations
>>>>=20
>>>> -       A description of the enrollment processes for
>>> existing and new
>>>> TNs including any modifications to metadata related to those TNs
>>>>=20
>>>> -       A description of protocol mechanisms for accessing contact
>>>> information associated with enrollments
>>>>=20
>>>> -       A description of mechanisms for resolving
>>> information related to
>>>> TNs
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>>=20
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern



--Apple-Mail=_637BDE3A-7DF1-4979-A64A-65631C1E73B7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw
ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla
MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY
jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6
iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw
F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1
4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB
8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+
kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD
VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF
BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt
GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do
Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT
ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln
m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX
cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB
QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy
dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW
sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K
+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr
LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn
vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD
CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0
uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB
7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq
R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK
tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0
MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE
jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG
BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0
RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j
c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y
dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY
fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH
DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1
a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm
7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI
5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R
KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4
yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6
Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j
BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA
MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM
BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j
cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP
omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y
78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl
pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa
SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3
1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h
z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5
PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU
mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8
YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ
BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x
NTA0MzAyMTAxNTVaMCMGCSqGSIb3DQEJBDEWBBRFAh265KP7ishu6ufGeFGe/QCBQzCBvgYJKwYB
BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43
HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA
ACinjU5g3ZFNzPX72BUKWzROaN8PsTW9iwueehWUEU5KQDwSEitwsvQ3gq/sb/RqQqPQppKPTXlP
Mh9THRrB4HMsxMOsLlFdf2/kGixEX/7m75fv+y5AO7mjx0MWksixAUI6oz2xgX5/Gg0f0ynCEsqa
UTLnq3BlN1H+mif+zwrsyiSD+67zhVPefarm+lVQ81JDk3S5FLL9kczSrZVIYRyMmca2ROzWQbpK
k6z8fmcm50RP64R5wA5gdAPHUqIYkxsPPFczn7qcQ6Zmm9jTMv/PGYvOiTWdOid9Uj2rtqlt0Vla
bFtDBWICrSgRYNqs4RSJqbLwhyNb6C9PoXop4wAAAAAAAA==
--Apple-Mail=_637BDE3A-7DF1-4979-A64A-65631C1E73B7--


From nobody Thu Apr 30 14:42:05 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253601A1BAC for ; Thu, 30 Apr 2015 14:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLiSzcVi9Hx6 for ; Thu, 30 Apr 2015 14:42:02 -0700 (PDT)
Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5AC1A1A7C for ; Thu, 30 Apr 2015 14:42:01 -0700 (PDT)
Received: from office.denic.de (mailout-6.osl.denic.de [10.122.34.32]) by office.denic.de (Postfix) with ESMTP id AE6131FB40; Thu, 30 Apr 2015 23:41:55 +0200 (CEST)
Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)  id 1YnwDT-0006uT-C0; Thu, 30 Apr 2015 23:41:55 +0200
Received: from localhost by x27.adm.denic.de with local  id 1YnwDQ-0007A6-2K; Thu, 30 Apr 2015 23:41:52 +0200
Date: Thu, 30 Apr 2015 23:41:52 +0200
From: Peter Koch 
To: Eric Burger 
Message-ID: <20150430214152.GG20261@x28.adm.denic.de>
References: <55424844.9040700@usdonovans.com>  <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com>   <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com>
User-Agent: Mutt/1.4.2.3i
Sender: Peter Koch 
Archived-At: 
Cc: modern@ietf.org
Subject: Re: [Modern] All-IP telecommunications network or TN identifiers
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 21:42:04 -0000

On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote:

> My vote is a strong No. We do not have a need to reinvent number allocation. From a business perspective, carriers already get numbers from numbering authorities. The code is written, debugged, and works. In fact, it mostly works over IP, if you want to get into the particulars and feel that because something runs over IP it is ???better.' Until it is time for the carriers to replace their provisioning systems, there is little need for a ???new??? method to get what they get today.

my understanding is - and please take this as an attempt to rephrase the question
rather than an explanation, that - in IP address parlance - "allocation"
would be superseded by "assignment", getting rid of number blocks and the
necessity for porting, as well as, at the risk of crossing the policy
boundary, support for a thick registry (of TN holders) rather than a thin
registry (of block custodians).  I'm likely wrong, but I'd like to know where.

-Peter


From nobody Thu Apr 30 14:53:27 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584AE1A1BE3 for ; Thu, 30 Apr 2015 14:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.887
X-Spam-Level: 
X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKGBfUv-nHkl for ; Thu, 30 Apr 2015 14:53:25 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2651A1BA7 for ; Thu, 30 Apr 2015 14:53:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zCOhtFSoRWKocFsU785SEa5qo4SA857aTcCIF2oNlM4=;  b=GxwegSDS/dOe1DTcMhODc8BIbbpO93CNhry5Z3HoxGKj/dnJZtSjmSxdup0Nb3+MSfr7Fs4YFxLoZtvs3WNCQ5jM3zEu+YQbF0geq9spcafEc7k1cs3xsOZssNdnW8wbDYbiEj15iJASXOR5BjxgnoOkTMDb9avrMLp+X6iqvkg=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:61289 helo=[192.168.15.122]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YnwOZ-0006a7-FU for modern@ietf.org; Thu, 30 Apr 2015 14:53:24 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_CFB83B15-20EA-4DC4-B65B-BC96E75755CE"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Burger 
In-Reply-To: <20150430214152.GG20261@x28.adm.denic.de>
Date: Thu, 30 Apr 2015 17:53:22 -0400
Message-Id: 
References: <55424844.9040700@usdonovans.com>  <949EF20990823C4C85C18D59AA11AD8B6970D285@FR712WXCHMBA11.zeu.alcatel-lucent.com>   <333A6B15-15AE-4DB6-98CF-DDB2E122D51C@standardstrack.com> <20150430214152.GG20261@x28.adm.denic.de>
To: modern@ietf.org
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] All-IP telecommunications network or TN identifiers
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Apr 2015 21:53:26 -0000

--Apple-Mail=_CFB83B15-20EA-4DC4-B65B-BC96E75755CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 30, 2015, at 5:41 PM, Peter Koch  wrote:
>=20
> On Thu, Apr 30, 2015 at 05:01:55PM -0400, Eric Burger wrote:
>=20
>> My vote is a strong No. We do not have a need to reinvent number =
allocation. =46rom a business perspective, carriers already get numbers =
from numbering authorities. The code is written, debugged, and works. In =
fact, it mostly works over IP, if you want to get into the particulars =
and feel that because something runs over IP it is ???better.' Until it =
is time for the carriers to replace their provisioning systems, there is =
little need for a ???new??? method to get what they get today.
>=20
> my understanding is - and please take this as an attempt to rephrase =
the question
> rather than an explanation, that - in IP address parlance - =
"allocation"
> would be superseded by "assignment", getting rid of number blocks and =
the
> necessity for porting, as well as, at the risk of crossing the policy
> boundary, support for a thick registry (of TN holders) rather than a =
thin
> registry (of block custodians).  I'm likely wrong, but I'd like to =
know where.
>=20
> -Peter

I do not know that you are wrong, but where is the requirement?

Is the requirement to eliminate service providers managing TNs?
Is the requirement to eliminate the two-tier model we have today, where =
national numbering authorities allocate TNs to service providers who =
allocate them to users? And related, where =E2=80=98users=E2=80=99 are =
sometimes enterprises or service bureaux who then allocate their numbers =
to users?
Is the requirement to eliminate the distributed model we have today in =
most of the world where the national numbering authority allocates TNs =
in blocks to service providers and replace it with a centralized model =
where all TNs live in a single data base?
Is the requirement to eliminate the quasi-distributed model we have =
today in countries such as the U.S., Canada, Argentina, India, etc. =
where the national numbering authority allocates TNs in blocks to =
services providers with a centralized data base for ported numbers?
Is there another requirement?

And, if we are going to dictate the numbering allocation model to the =
world, will the world accept it?


--Apple-Mail=_CFB83B15-20EA-4DC4-B65B-BC96E75755CE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQqRSAAoJEDY/T2tCIPW3cwgP/2Zzw6tiaSgQ85IShptl9lwX
tn3BVDZ+BSRF3soVzNFMD/CjfpDwwFFkV6Jx/HVyX+Qehjf4NsfwydrcxE8AlnBA
UbEEg88dSb9Ty6/7Ij3gT5U/FCnTsHpXBQ/nMnZfIlDwhzWXpt9T/fTCkvZkCuvs
SgD+zjMkkoSiFV89pAT3zL7LyQcjApRwbjuTLmPwOjLQuK43gQFZfY79hnzb5r8j
19LnYSRimen2zArFPhndC7GgieJmWNbdHUZCOn/qQEHBVAu8NmXxmSpLBsHTvUEu
k7o4C1c3kMwcn8LCIAMojPfT0tY8MyvG2aHdUe73GkCZREpXYhDwxwx1TrcPaNvB
VjcmvjMyiYKF0ydTT370peJVxvF17PJ7oQW5VN38UcrNpbd+p6FaqJkqBc//PSqm
AibwnBe0FkPc82GWOpbug8X5T4DvJcgbYVbedpsjgW8/Cju8oy7FLy/cWy8HzGLU
5CO+yMowXN4kS4ioLnG9vLG/aj2uhyDOhn9AbqP6wzklGYP/W9wixSv5+VqBvfA4
yxGaNC42kKekrZaVzViqi+g1mhmkoCEZPWWeqomEbtBYOSLpYjYHCUwBSHgcef7W
mnY8ZVJ5e3o0hrQ5OsaBAZdY1hpUVsXYMkHDOWnpEbgPO06WzG+OhqNLpqb/kmdv
fVXWayYfGtzlHummerUg
=dejU
-----END PGP SIGNATURE-----

--Apple-Mail=_CFB83B15-20EA-4DC4-B65B-BC96E75755CE--