From nobody Wed Feb 11 09:19: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 1382D1A894C for ; Wed, 11 Feb 2015 09:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.566 X-Spam-Level: X-Spam-Status: No, score=-99.566 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 tFwwqFNgx53n for ; Wed, 11 Feb 2015 09:18:39 -0800 (PST) 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 C0AF61A894E for ; Wed, 11 Feb 2015 09:18:39 -0800 (PST) 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 t1BHDUGr016673 for ; Wed, 11 Feb 2015 12:18:39 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1sg3cv8ngr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 11 Feb 2015 12:18:38 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.67]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 11 Feb 2015 12:18:37 -0500 From: "Peterson, Jon" To: "modern@ietf.org" Thread-Topic: draft charter Thread-Index: AQHQRh7FZCWKLIxx2EOzvUKYZFZGpg== Date: Wed, 11 Feb 2015 17:18:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.128.80] Content-Type: multipart/alternative; boundary="_000_D100CEF21492B8jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7708 signatures=670625 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502110170 Archived-At: Subject: [Modern] draft 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, 11 Feb 2015 17:18:51 -0000 --_000_D100CEF21492B8jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern 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, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. Solutions and mechanisms created by the wo= rking 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 document that includes high level requirem= ents and security/privacy considerations - A document describing the enrollment processes for existing and new= TNs including any modifications to metadata related to those TNs - A document describing protocol mechanisms for accessing contact inf= ormation associated with enrollments - A document describing mechanisms for resolving information related = to TNs --_000_D100CEF21492B8jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <74835DF884D05C4693EB1AE6E56C6AC5@neustar.biz> Content-Transfer-Encoding: quoted-printable

At the Dallas IETF meeting in March, we'd like to get together and tal= k about what a working group for MODERN might look like. As an initial inpu= t to the discussion, a few of us have put together a proposed charter. Whil= e the TeRQ work was positively evaluated in the DISPATCH process, we feel this is broader enough in scope to warran= t its own BoF.

Comments are welcome, this is just a starting point.

------

Modern 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, STIR, and DRINKS= .

 

The work of this group is limited to specifying a so= lution for TNs and covers any service that can be addressed using a TN.&nbs= p; Expanding the work to other identifiers is out of scope.  Solutions= and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by differ= ent regulatory agencies.

 

The work group will deliver the following:

 

-       An architecture overview document that includes high l= evel requirements and security/privacy considerations

-       A document describing the enrollment processes for exi= sting and new TNs including any modifications to metadata related to those = TNs

-       A document describing protocol mechanisms for accessin= g contact information associated with enrollments

-       A document describing mechanisms for resolving informa= tion related to TNs

--_000_D100CEF21492B8jonpetersonneustarbiz_-- From nobody Wed Feb 11 10:04:47 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 452271A1A59 for ; Wed, 11 Feb 2015 10:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 q8IIl39U3Vu2 for ; Wed, 11 Feb 2015 10:04:39 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 104FB1A1A13 for ; Wed, 11 Feb 2015 10:04:36 -0800 (PST) Received: (qmail 16734 invoked by uid 0); 11 Feb 2015 18:04:36 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 11 Feb 2015 18:04:36 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id r63F1p0031MNPNq0163JYJ; Wed, 11 Feb 2015 11:03:18 -0700 X-Authority-Analysis: v=2.1 cv=J8Y5smXS c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Fm5PWBbyStgA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=P1BN0RY3_L70yMIVEhsA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=XzwoKrf5MuV6Hdm6bdEA:9 a=ig-wg7xawUpxcIPo:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=mxld8gWZ9toPfYPnKlBMNBdmfDUSsyLKWp91mBALxPA=; b=YAc03C3EU8uhuRUgUpUucULtp+z+3tW61IpnegWgjB+tRuTmBIGAgvXFFvFkPfj41SNGN6XNikDYJsTRGws7qvyc81lC6Kfmlflh/myGdPopXJE3e0lqXurwkp/teuf1; Received: from [108.56.131.201] (port=52781 helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YLbd5-0006BF-Jr; Wed, 11 Feb 2015 11:03:15 -0700 User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Wed, 11 Feb 2015 13:03:10 -0500 From: Richard Shockey To: "Peterson, Jon" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] draft charter Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3506504595_491416" 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: dispatch Subject: Re: [Modern] draft 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, 11 Feb 2015 18:04:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3506504595_491416 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 its time. In addition its time to take a look at the CNAM CNIT proposition as well. My reluctance to draft a charter has been due to understanding what, if anything 3GPP, is doing in this space. Comments in line. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Peterson, Jon" Date: Wednesday, February 11, 2015 at 12:18 PM To: "modern@ietf.org" Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk about what a working group for MODERN might look like. As an initial input to the discussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DISPATCH process, we feel thi= s is broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern charter text: =20 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 [specific] communications infrastructure evolves to IP technology and new applications for TNs become possible. [The limitations of the existing ENUM RFC 6116 mechanisms are well understood] 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 wil= l remain for some time [probably after we are all dead] . Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. =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. 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. =20 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, STIR, and DRINKS. =20 The work of this group is limited to specifying a solution for TNs and covers any service that can be addressed using a TN. Expanding the work to other identifiers is out of scope. [what about the STIR certs?] Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies.=20 =20 The work group will deliver the following: =20 - An architecture overview document that includes high level requirements and security/privacy considerations - A document describing the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs - A document describing protocol mechanisms for accessing contact information associated with enrollments - A document describing mechanisms for resolving information related t= o TNs _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3506504595_491416 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

+1 &= nbsp;its time.

In addition its time to take a look = at the CNAM CNIT proposition as well.  My reluctance to draft a charter= has been due to understanding what, if anything 3GPP, is doing in this spac= e.

Comments in line.

= — 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
ww= w.sipforum.org
richard<at>shockey.us
Skype-Linkedi= n-Facebook rshockey101
PSTN +1 703-593-2683


From: "Pe= terson, Jon" <jon.peterson@neus= tar.biz>
Date: Wednesday, F= ebruary 11, 2015 at 12:18 PM
To: "= modern@ietf.org" <modern@ietf.org>
Sub= ject: [Modern] draft charter


At the Dallas IETF mee= ting in March, we'd like to get together and talk about what a working group= for MODERN might look like. As an initial input to the discussion, a few of= us have put together a proposed charter. While the TeRQ work was positively= evaluated in the DISPATCH process, we feel this is broader enough in scope to warran= t its own BoF.

Comments are welcome, this is just a= starting point.

------

Modern charter text:

<= o:p> 

The MODERN working group will defin= e a set of Internet-based mechanisms for the purposes of managing and resolv= ing telephone numbers (TNs) in an IP environment.  Existing mechanisms = for these purposes face obsolescence as the voice [specific] communications infrastructure evolves to IP technology and new applications for TNs becom= e possible.  [The limitations of the existing ENUM RFC 6116 mechanisms = are well understood]   The traditional model of a TN having an associat= ion to a single service provider and a single application is breaking down.&= nbsp; Its 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 [probably after we are all dead] . 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 hiera= rchical tree, or in a distributed peer-to-peer architecture.  Privacy o= f the enrollment data and security of the resource will be primary considera= tions.

 

Additionally, the working group will deliver a protocol mechanism for res= olving 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 p= rivacy are primary considerations.  The working group will take into co= nsideration existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS.<= /p>


<= div>

 

The work of this group is limited to specifying a solution for TNs and co= vers any service that can be addressed using a TN.  Expanding the work = to other identifiers is out of scope. 


[what about the STIR certs?]

So= lutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by differ= ent regulatory agencies.

 

The work group will deliver the following:

 

-    &n= bsp;  An architecture overview document that includes high l= evel requirements and security/privacy considerations

-       A document describing the enrollment processes for exi= sting and new TNs including any modifications to metadata related to those T= Ns

-     &nbs= p; A document describing protocol mechanisms for accessin= g contact information associated with enrollments

<= !--[if !supportLists]-->-       A document describing mechanisms for resolving informa= tion related to TNs

_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3506504595_491416-- From nobody Wed Feb 11 10:32: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 4083C1A893B for ; Wed, 11 Feb 2015 10:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=unavailable 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 PXjAJe8CT_Ci for ; Wed, 11 Feb 2015 10:32:34 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD341A88AE for ; Wed, 11 Feb 2015 10:32:34 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id w8so3767949qac.1 for ; Wed, 11 Feb 2015 10:32:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=o/2oHWeENdZ45qE0z/USDkh8Lb8um8JntTbAmI9Ii48=; b=HwZIixEAh7XpDcHJDAXgNtEAMpXTMXy5SWBS81fJ6pDrjCUUJDH1iD/LJaWYN2skSQ NXFd//U4jpSnURByJDy2FcEDt8nMeCL7jwBUdqv5k77c47ZTFza9jAKv2MjGOnbD9YYp G4AXG7FP8bL+R6Y3s0fp6W65Qlqlv7g7h5c9Us4V2X2DJ+qoeZB7Nnfjeqa6oVGseIMw Fmqi3wWb9LVbk/m7TfijSMrNvpmZdsIYYxueVCayXmcB/oqW4lKSjHeTslx0HkQnySRq sZdIi4vFXIuqEMJ3vyfZhMUCfN2wOF+ehM15jKNQCtCHtJ3+Md1WdzZpXK3/KWpREUUC Jo+g== X-Gm-Message-State: ALoCoQll1yjcfFOWfL4RMDnIx5GYBrCf0dxYP/SQEICNW+mEXOLYToBbjil5nkPYbtMtC1lR1tNJ X-Received: by 10.224.123.193 with SMTP id q1mr16878869qar.64.1423679553486; Wed, 11 Feb 2015 10:32:33 -0800 (PST) Received: from gjoyner1-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id a6sm1583360qgf.13.2015.02.11.10.32.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Feb 2015 10:32:32 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_02B9F227-EB43-404F-A13C-43D2ABE7DD26" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Rosen In-Reply-To: Date: Wed, 11 Feb 2015 13:32:28 -0500 Message-Id: References: To: Richard Shockey X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dispatch , "modern@ietf.org" , Jon Peterson Subject: Re: [Modern] draft 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, 11 Feb 2015 18:32:38 -0000 --Apple-Mail=_02B9F227-EB43-404F-A13C-43D2ABE7DD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92ll work with you on that if you want. I am sure we can work through = the 3GPP issues. Brian > On Feb 11, 2015, at 1:03 PM, Richard Shockey = wrote: >=20 >=20 > +1 its time. >=20 > In addition its time to take a look at the CNAM CNIT proposition as = well. My reluctance to draft a charter has been due to understanding = what, if anything 3GPP, is doing in this space. >=20 > Comments in line. >=20 > =97=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "Peterson, Jon" > > Date: Wednesday, February 11, 2015 at 12:18 PM > To: "modern@ietf.org " > > Subject: [Modern] draft charter >=20 >=20 > At the Dallas IETF meeting in March, we'd like to get together and = talk about what a working group for MODERN might look like. As an = initial input to the discussion, a few of us have put together a = proposed charter. While the TeRQ work was positively evaluated in the = DISPATCH process, we feel this is broader enough in scope to warrant its = own BoF. >=20 > Comments are welcome, this is just a starting point. >=20 > ------ >=20 > Modern charter text: > =20 > 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 [specific] communications infrastructure = evolves to IP technology and new applications for TNs become possible. = [The limitations of the existing ENUM RFC 6116 mechanisms are well = understood] 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 [probably = after we are all dead] . Devices, applications, and network tools = increasingly need to manage TNs, including requesting and acquiring TN = delegations from authorities. > =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. 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. > =20 > 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, STIR, and DRINKS. >=20 > =20 > The work of this group is limited to specifying a solution for TNs and = covers any service that can be addressed using a TN. Expanding the work = to other identifiers is out of scope.=20 >=20 > [what about the STIR certs?] >=20 > Solutions and mechanisms created by the working group will be flexible = enough to accommodate different policies, e.g., by different regulatory = agencies. > =20 > The work group will deliver the following: > =20 > - An architecture overview document that includes high level = requirements and security/privacy considerations > - A document describing the enrollment processes for existing = and new TNs including any modifications to metadata related to those TNs > - A document describing protocol mechanisms for accessing = contact information associated with enrollments > - A document describing 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 = --Apple-Mail=_02B9F227-EB43-404F-A13C-43D2ABE7DD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92ll work with you on that if you want.  I am sure we = can work through the 3GPP issues.


Brian

On Feb 11, 2015, at 1:03 PM, Richard Shockey <richard@shockey.us> = wrote:


+1 =  its time.

In addition its time to take a look at the CNAM CNIT = proposition as well.  My reluctance to draft a charter has been due = to understanding what, if anything 3GPP, is doing in this = space.

Comments = in line.

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


From: "Peterson, Jon" = <jon.peterson@neustar.biz>
Date: Wednesday, February = 11, 2015 at 12:18 PM
To: "modern@ietf.org" <modern@ietf.org>
Subject: [Modern] draft = charter


At the Dallas IETF meeting in March, = we'd like to get together and talk about what a working group for MODERN = might look like. As an initial input to the discussion, a few of us have = put together a proposed charter. While the TeRQ work was positively = evaluated in the DISPATCH process, we feel this is broader enough in = scope to warrant its own BoF.

Comments are welcome, this is just a = starting point.

------

Modern 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 [specific] communications infrastructure = evolves to IP technology and new applications for TNs become possible. =  [The limitations of the existing ENUM RFC 6116 mechanisms are well = understood]   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 [probably after we are all dead] . 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, STIR, and DRINKS.

 
The work of this = group is limited to specifying a solution for TNs and covers any service = that can be addressed using a TN.  Expanding the work to other = identifiers is out of scope. 

[what about the STIR certs?]

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 document that includes high level requirements and = security/privacy considerations
-       A document = describing the enrollment processes for existing and new TNs including = any modifications to metadata related to those TNs
-       A document = describing protocol mechanisms for accessing contact information = associated with enrollments
-       A document = describing 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

= --Apple-Mail=_02B9F227-EB43-404F-A13C-43D2ABE7DD26-- From nobody Wed Feb 11 11:07: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 5C7FF1A8A81 for ; Wed, 11 Feb 2015 11:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 fVxj8sskFLBE for ; Wed, 11 Feb 2015 11:06:42 -0800 (PST) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 8E1CF1A1B46 for ; Wed, 11 Feb 2015 11:06:39 -0800 (PST) Received: (qmail 31227 invoked by uid 0); 11 Feb 2015 19:06:35 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 11 Feb 2015 19:06:35 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id r6iC1p00F1MNPNq016iFpP; Wed, 11 Feb 2015 11:42:19 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Fm5PWBbyStgA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ajNGGDAxAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=HLLxP2VMAAAA:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=HUe9btjZYD2HB1kEX9UA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=2seW82Q7BYkA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=emTtFift818A:10 a=NWVoK91CQyQA:10 a=Bj9vM_EGxUE3Rnwo1_IA:9 a=HSMcUNSODLlHoY-I:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=hvTR6VRPidZ0Sx+nMFPju/zxv/ltxP+xoOyOew8G55I=; b=XG91KYqLqiiOqrbdYGJMkJ3WeJdhgfg/cUqJ5YVstvyOLzX+p9H96z5+Gau8RCcJR7Ovepyz2axGxCeH4kXyK+Cs8aYBh9omCDfNA43dmgfg+SzPGdPZvENDKQdgP1fe; Received: from [108.56.131.201] (port=53411 helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YLcEl-0005Ph-VB; Wed, 11 Feb 2015 11:42:12 -0700 User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Wed, 11 Feb 2015 13:42:07 -0500 From: Richard Shockey To: Brian Rosen Message-ID: Thread-Topic: [Modern] draft charter References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3506506931_651302" 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: dispatch , "modern@ietf.org" , Jon Peterson Subject: Re: [Modern] draft 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, 11 Feb 2015 19:06:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3506506931_651302 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable OK Its my understanding that it was SA-1 that was looking into this but the document is essentially blank. http://www.3gpp.org/DynaReport/TSG-WG--s1--wis.htm =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen Date: Wednesday, February 11, 2015 at 1:32 PM To: Richard Shockey Cc: Jon Peterson , "modern@ietf.org" , dispatch Subject: Re: [Modern] draft charter I=B9ll work with you on that if you want. I am sure we can work through the 3GPP issues. Brian > On Feb 11, 2015, at 1:03 PM, Richard Shockey wrote: >=20 >=20 > +1 its time. >=20 > In addition its time to take a look at the CNAM CNIT proposition as well.= My > reluctance to draft a charter has been due to understanding what, if anyt= hing > 3GPP, is doing in this space. >=20 > Comments in line. >=20 > =8B=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "Peterson, Jon" > Date: Wednesday, February 11, 2015 at 12:18 PM > To: "modern@ietf.org" > Subject: [Modern] draft charter >=20 >=20 > At the Dallas IETF meeting in March, we'd like to get together and talk a= bout > what a working group for MODERN might look like. As an initial input to t= he > discussion, a few of us have put together a proposed charter. While the T= eRQ > work was positively evaluated in the DISPATCH process, we feel this is br= oader > enough in scope to warrant its own BoF. >=20 > Comments are welcome, this is just a starting point. >=20 > ------ >=20 > Modern charter text: > =20 > The MODERN working group will define a set of Internet-based mechanisms f= or > the purposes of managing and resolving telephone numbers (TNs) in an IP > environment. Existing mechanisms for these purposes face obsolescence as= the > voice [specific] communications infrastructure evolves to IP technology a= nd > new applications for TNs become possible. [The limitations of the existi= ng > ENUM RFC 6116 mechanisms are well understood] The traditional model of = a TN > having an association to a single service provider and a single applicati= on is > breaking down. Its use as a network locator is going away, but its use a= s an > identifier for an individual or an organization will remain for some time > [probably after we are all dead] . Devices, applications, and network too= ls > increasingly need to manage TNs, including requesting and acquiring TN > delegations from authorities. > =20 > The working group will define a framework for the roles and functions inv= olved > in managing and resolving TNs in an IP environment. This includes a proto= col > mechanism for acquiring TNs, which will provide an enrollment process for= the > individuals and entities that use and manage TNs. TNs may either be manag= ed in > a hierarchical tree, or in a distributed peer-to-peer architecture. Priv= acy > of the enrollment data and security of the resource will be primary > considerations. > =20 > Additionally, the working group will deliver a protocol mechanism for > resolving TNs which will allow entities such as service providers, device= s, > 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, STIR, an= d > DRINKS. >=20 > =20 > The work of this group is limited to specifying a solution for TNs and co= vers > any service that can be addressed using a TN. Expanding the work to othe= r > identifiers is out of scope. >=20 > [what about the STIR certs?] >=20 > Solutions and mechanisms created by the working group will be flexible en= ough > to accommodate different policies, e.g., by different regulatory agencies= . > =20 > The work group will deliver the following: > =20 > - An architecture overview document that includes high level > requirements and security/privacy considerations > - A document describing the enrollment processes for existing and n= ew > TNs including any modifications to metadata related to those TNs > - A document describing protocol mechanisms for accessing contact > information associated with enrollments > - A document describing mechanisms for resolving information relate= d 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 --B_3506506931_651302 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

OK

Its my understanding that it was SA-1 that was looki= ng into this but the document is essentially blank.



=


— 
Richard Shoc= key
Shockey Consulting LLC
Chairman of the Board SIP For= um
www.shockey.us
www.sipforum.org
richard<= at>shockey.us
Skype-Linkedin-Facebook rshockey101
PST= N +1 703-593-2683


From: Brian Rosen <br@brianrosen.net>
Date= : Wednesday, February 11, 2015 at 1:32 PM
To: Richard Shockey <= richard@shockey.us>
Cc: Jon= Peterson <jon.peterson@neustar= .biz>, "modern@ietf.org" <modern@ietf.org>, dispatch <dispatch-bounces@ietf.org>
Subject: Re: [Modern] draft charter

I’ll work with = you on that if you want.  I am sure we can work through the 3GPP issues= .


Brian

On Feb 11, 2015, at 1:03 PM, Richard Shockey <richard@shockey.us> wrote:
=

+1  its time.

In= addition its time to take a look at the CNAM CNIT proposition as well. &nbs= p;My reluctance to draft a charter has been due to understanding what, if an= ything 3GPP, is doing in this space.

<= div class=3D"">Comments in line.

— 
Richard Shockey
<= div class=3D"">Shockey Consulting LLC
Chairman of the Board= SIP Forum
www.= shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebo= ok rshockey101
PSTN +1 703-593-2683

From: "Peterson, Jon" <= jon.peterson@neustar.biz>
Date: Wedn= esday, February 11, 2015 at 12:18 PM
To: "<= a href=3D"mailto:modern@ietf.org" class=3D"">modern@ietf.org" <modern@ietf.org>
Subject: [Modern] draft charter


=
At the Dallas IETF meeting in March, we'd like to get together= and talk about what a working group for MODERN might look like. As an initi= al input to the discussion, a few of us have put together a proposed charter= . While the TeRQ work was positively evaluated in the DISPATCH process, we f= eel this is broader enough in scope to warrant its own BoF.

Comments are welcome, this is just a sta= rting point.

------

Mod= ern charter text:
 
The MODERN working group will define a set of Internet-based mechanis= ms for the purposes of managing and resolving telephone numbers (TNs) in an = IP environment.  Existing mechanisms for these purposes face obsolescen= ce as the voice [specific] communications infrastructure evolves to IP techn= ology and new applications for TNs become possible.  [The limitations o= f the existing ENUM RFC 6116 mechanisms are well understood]   The trad= itional 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 i= s going away, but its use as an identifier for an individual or an organizat= ion will remain for some time [probably after we are all dead] . Devices, ap= plications, and network tools increasingly need to manage TNs, including req= uesting 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 hierarc= hical tree, or in a distributed peer-to-peer architecture.  Privacy of = the enrollment data and security of the resource will be primary considerati= ons.
 
Additionally, the working group will deliver a protocol mechanism fo= r 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 perfo= rmance, security and privacy are primary considerations.  The working g= roup will take into consideration existing IETF work including ENUM, SPEERMI= NT, STIR, and DRINKS.

 
The = work of this group is limited to specifying a solution for TNs and covers an= y service that can be addressed using a TN.  Expanding the work to othe= r identifiers is out of scope. 

[what about the STIR certs?]

Solutions and mech= anisms created by the working group will be flexible enough to accommodate d= ifferent policies, e.g., by different regulatory agencies.
 
The work group= will deliver the following:
 
-   &n= bsp;   An a= rchitecture overview document that includes high level requirements and secu= rity/privacy considerations
-       A document describing the enrollment processes f= or existing and new TNs including any modifications to metadata related to t= hose TNs
- &= nbsp;     A document describing protocol mechanisms for accessing contact inf= ormation associated with enrollments
-       A document describing mechanisms for re= solving information related to TNs
_______________________________________________ Modern mailing list Modern@ietf.org = https://www.= ietf.org/mailman/listinfo/modern&nbs= p;_______________________________________________Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
--B_3506506931_651302-- From nobody Wed Feb 11 11:12: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 777BF1A8AA3; Wed, 11 Feb 2015 11:12:32 -0800 (PST) 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 E5Z8xF_U8sGZ; Wed, 11 Feb 2015 11:12:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C7A1A8A98; Wed, 11 Feb 2015 11:12:21 -0800 (PST) Received: from BL2FFO11FD005.protection.gbl (10.173.160.34) by BL2FFO11HUB031.protection.gbl (10.173.161.55) with Microsoft SMTP Server (TLS) id 15.1.87.10; Wed, 11 Feb 2015 19:12:01 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Wed, 11 Feb 2015 19:12:01 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t1BJBw7q021953 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 13:11:59 -0600 Received: from PREWE13M08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t1BJBvx9000542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Feb 2015 13:11:59 -0600 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.995.29; Wed, 11 Feb 2015 14:11:58 -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.0995.028; Wed, 11 Feb 2015 13:11:57 -0600 From: "Gorman, Pierce A [NTK]" To: Richard Shockey , Brian Rosen Thread-Topic: [Modern] draft charter Thread-Index: AQHQRiVs8zTP8ZQrtUaA31Zu7bAZPJzsKncAgAACsoD//6PAKw== Date: Wed, 11 Feb 2015 19:11:56 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_vfcq0nam7h54gh81g0iss9lw1423681913778emailandroidcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Pierce.Gorman@sprint.com; X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(479174004)(24454002)(92566002)(33646002)(16236675004)(19580395003)(15975445007)(15395725005)(2950100001)(2900100001)(19580405001)(84326002)(6806004)(77156002)(106116001)(106466001)(102836002)(15974865002)(76176999)(54356999)(19617315012)(512944002)(63666004)(95246002)(50986999)(86362001)(46102003)(4546004)(87936001)(2656002)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB031; H:pdaasdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB031; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BL2FFO11HUB031; X-Forefront-PRVS: 0484063412 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB031; X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 19:12:01.1122 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.229.32.57] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB031 Archived-At: Cc: dispatch , "modern@ietf.org" , Jon Peterson Subject: Re: [Modern] draft 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, 11 Feb 2015 19:12:34 -0000 X-List-Received-Date: Wed, 11 Feb 2015 19:12:34 -0000 --_000_vfcq0nam7h54gh81g0iss9lw1423681913778emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think you're right it is SA-1 regardless. Sent on a Sprint Samsung Galaxy S=AE III -------- Original message -------- From: Richard Shockey Date:02/11/2015 1:07 PM (GMT-06:00) To: Brian Rosen Cc: dispatch , modern@ietf.org, Jon Peterson Subject: Re: [Modern] draft charter OK Its my understanding that it was SA-1 that was looking into this but the do= cument is essentially blank. http://www.3gpp.org/DynaReport/TSG-WG--s1--wis.htm =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Brian Rosen > Date: Wednesday, February 11, 2015 at 1:32 PM To: Richard Shockey > Cc: Jon Peterson = >, "modern@ietf.org" >, dispatch > Subject: Re: [Modern] draft charter I=92ll work with you on that if you want. I am sure we can work through th= e 3GPP issues. Brian On Feb 11, 2015, at 1:03 PM, Richard Shockey > wrote: +1 its time. In addition its time to take a look at the CNAM CNIT proposition as well. = My reluctance to draft a charter has been due to understanding what, if any= thing 3GPP, is doing in this space. Comments in line. =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Peterson, Jon" > Date: Wednesday, February 11, 2015 at 12:18 PM To: "modern@ietf.org" > Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern 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 [specific] communications infrastructure evolves to IP technology an= d new applications for TNs become possible. [The limitations of the existi= ng ENUM RFC 6116 mechanisms are well understood] The traditional model of= a TN having an association to a single service provider and a single appli= cation is breaking down. Its use as a network locator is going away, but i= ts use as an identifier for an individual or an organization will remain fo= r some time [probably after we are all dead] . Devices, applications, and n= etwork tools increasingly need to manage TNs, including requesting and acqu= iring 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, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. [what about the STIR certs?] Solutions and mechanisms created by the working group will be flexible enou= gh to accommodate different policies, e.g., by different regulatory agencie= s. The work group will deliver the following: - An architecture overview document that includes high level requirem= ents and security/privacy considerations - A document describing the enrollment processes for existing and new= TNs including any modifications to metadata related to those TNs - A document describing protocol mechanisms for accessing contact inf= ormation associated with enrollments - A document describing mechanisms for resolving information related = to TNs _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/mode= rn _______________________________________________ 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_vfcq0nam7h54gh81g0iss9lw1423681913778emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I think you're right it is  SA-1 regardless. 


Sent on a Sprint Samsung Galaxy= S=AE III


-------- Original message --------
From: Richard Shockey
Date:02/11/2015 1:07 PM (GMT-06:00)
To: Brian Rosen
Cc: dispatch , modern@ietf.org, Jon Peterson
Subject: Re: [Modern] draft charter


OK

Its my understanding that it was SA-1 that was looking into this but t= he document is essentially blank.





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


From: Brian Rosen <br@brianrosen.net>
Date: Wednesday, February 11, 2015 = at 1:32 PM
To: Richard Shockey <richard@shockey.us>
Cc: Jon Peterson <jon.peterson@neustar.biz>, "modern@ietf.org" <modern@ietf.org>, dispatch <dispatch-bounces@ietf.org>
Subject: Re: [Modern] draft charter=

I=92ll work with you on that= if you want.  I am sure we can work through the 3GPP issues.


Brian

On Feb 11, 2015, at 1:03 PM, Richard Shockey <richard@shockey.us> wrote:

+1  its time.

In addition its time to take a look at the CNAM CNIT propos= ition as well.  My reluctance to draft a charter has been due to under= standing what, if anything 3GPP, is doing in this space.

Comments in line.

=97 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.u= s
www.sipforu= m.org
richard<at>= shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From: "Peterson, Jon" <jon.peterson@neustar.biz><= br class=3D""> Date: Wednesday, February 11, 2015 at 12:18 PM To: "modern@ietf.org" <modern@ietf.org>
Subject: [Modern] draft charter


At the Dallas IETF meeting in March, we'd like to get toget= her and talk about what a working group for MODERN might look like. As an i= nitial input to the discussion, a few of us have put together a proposed ch= arter. While the TeRQ work was positively evaluated in the DISPATCH process, we feel this is broader enough in scope= to warrant its own BoF.

Comments are welcome, this is just a starting point.

------

Modern 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 a= s the voice [specific] communications infrastructure evolves to IP technology and new applications for TNs becom= e possible.  [The limitations of the existing ENUM RFC 6116 mechanisms= are well understood]   The traditional model of a TN having an associ= ation 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 wil= l remain for some time [probably after we are all dead] . Devices, applicat= ions, 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 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 be managed in a hierarchical tree,= or in a distributed peer-to-peer architecture.  Privacy of the enroll= ment 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, security and privacy are primary consid= erations.  The working group will take into consideration existing IET= F work including ENUM, SPEERMINT, STIR, and DRINKS.

 
The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN.  Expanding the work t= o other identifiers is out of scope. 

[what about the STIR certs?]

Solutions and mechanisms created by the working group will be flexible enou= gh to accommodate different policies, e.g., by different regulatory agencie= s.
 
The work group will deliver the following:
 
-&n= bsp;     &nb= sp;An architecture overview document that includes high level= requirements and security/privacy considerations
-&n= bsp;     &nb= sp;A document describing the enrollment processes for existin= g and new TNs including any modifications to metadata related to those TNs<= /div>
-&n= bsp;     &nb= sp;A document describing protocol mechanisms for accessing co= ntact information associated with enrollments
-&n= bsp;     &nb= sp;A document describing mechanisms for resolving information= related to TNs
_______________________________________________ Modern mailing list Modern@ietf.org&nbs= p;https://www.ietf.org/mailman/listinfo/modern ______= _________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mai= lman/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_vfcq0nam7h54gh81g0iss9lw1423681913778emailandroidcom_-- From nobody Tue Feb 24 14:06: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 B9E381A903D for ; Tue, 24 Feb 2015 14:06:33 -0800 (PST) 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, 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 71DS7wmINu8y for ; Tue, 24 Feb 2015 14:06:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE901A9038 for ; Tue, 24 Feb 2015 14:06:30 -0800 (PST) Received: from BN1BFFO11FD027.protection.gbl (10.58.144.34) by BN1BFFO11HUB033.protection.gbl (10.58.144.180) with Microsoft SMTP Server (TLS) id 15.1.99.6; Tue, 24 Feb 2015 22:06:06 +0000 Received: from plsasdm2.corp.sprint.com (144.230.168.26) by BN1BFFO11FD027.mail.protection.outlook.com (10.58.144.90) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Tue, 24 Feb 2015 22:06:05 +0000 Received: from pdaasen1.corp.sprint.com (mailhost.it.sprintspectrum.com [144.226.111.128]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t1OM64jP012129 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2015 16:06:04 -0600 Received: from PREWE13M01.ad.sprint.com (prewe13m01.corp.sprint.com [144.226.128.20]) by pdaasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t1OM633f010950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Feb 2015 16:06:04 -0600 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M01.ad.sprint.com (2002:90e2:8014::90e2:8014) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 24 Feb 2015 17:06:02 -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.0995.028; Tue, 24 Feb 2015 16:06:02 -0600 From: "Holmes, David W [CTO]" To: "Peterson, Jon" , "modern@ietf.org" Thread-Topic: draft charter Thread-Index: AQHQRh7FZCWKLIxx2EOzvUKYZFZGpp0Aa+rA Date: Tue, 24 Feb 2015 22:06:01 +0000 Message-ID: <4143963f1b334314a917ab582bfc738d@PLSWE13M01.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.91.92] Content-Type: multipart/alternative; boundary="_000_4143963f1b334314a917ab582bfc738dPLSWE13M01adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.26 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.26; helo=plsasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.26) smtp.mailfrom=David.Holmes@sprint.com; neustar.biz; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:144.230.168.26; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(438002)(377454003)(199003)(53824002)(189002)(54356999)(108616004)(76176999)(50986999)(84326002)(30436002)(46102003)(64706001)(86362001)(221733001)(16236675004)(5250100002)(19625215002)(2656002)(26826002)(87936001)(19300405004)(4546004)(33646002)(512954002)(62966003)(19580405001)(6806004)(19580395003)(97736003)(92566002)(107886001)(77156002)(102836002)(106116001)(106466001)(15975445007)(2900100001)(2950100001)(68736005)(92726002)(2501003)(111123002)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB033; H:plsasdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB033; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1BFFO11HUB033; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB033; X-Forefront-PRVS: 04976078F0 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2015 22:06:05.8597 (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.168.26] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB033 Archived-At: Subject: Re: [Modern] draft 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, 24 Feb 2015 22:06:33 -0000 --_000_4143963f1b334314a917ab582bfc738dPLSWE13M01adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jon, Thank you for the work in assembling this draft of the charter for MODERN. We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility = to support the needs of different regulatory regimes, & thus to ensure that= if quoted alone they are not taken out of context; i.e. the group product = will be the protocols to support the allocation etc. activities, & it would= not attempt to define the allocation processes. We also would like the ch= arter to note the relevant work that has already been performed by both IET= F & the ATIS/SIP Forum JTF, & incorporate that into the output from the MOD= ERN WG as appropriate. These changes/additions are have been added to your= text inline below. We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to ot= her commitments that week. Regards, David/Sprint ___________________________________________________________________________= ___ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern 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, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. Solutions and mechanisms created by the wo= rking 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 document that includes high level requi= rements and security/privacy considerations built on the work of IETF & the= ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment proces= ses for existing and new TNs including any modifications to metadata relate= d to those TNs - A document describing protocol mechanisms for accessing contact = information associated with enrollments - A document describing protocol mechanisms for resolving informat= ion related to TNs - ________________________________ 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_4143963f1b334314a917ab582bfc738dPLSWE13M01adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jon, =

=  

Thank= you for the work in assembling this draft of the charter for MODERN.

=  

We wo= uld like to suggest some minor clarifications to the bullets describing the= deliverables, to align them with the statement regarding flexibility to su= pport the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the all= ocation etc. activities, & it would not attempt to define the allocatio= n processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the = MODERN WG as appropriate.  These changes/additions are have been added= to your text inline below.

=  

We ar= e hoping that the MODERN session at IETF#92 will have remote access, to all= ow participation by those of us that cannot attend in person due to other c= ommitments that week.  

=  

Regar= ds,

=  

David= /Sprint

_____= _________________________________________________________________________

=  

From: Modern [= mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

&n= bsp;

At the = Dallas IETF meeting in March, we'd like to get together and talk about what= a working group for MODERN might look like. As an initial input to the dis= cussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own = BoF.

&n= bsp;

Comment= s are welcome, this is just a starting point.

&n= bsp;

------<= o:p>

&n= bsp;

Modern charter text:

 =

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

 =

The working group will d= efine a framework for the roles and functions involved in managing and reso= lving TNs in an IP environment. This includes a protocol mechanism for acqu= iring 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 reso= urce will be primary considerations.

 =

Additionally, the workin= g group will deliver a protocol mechanism for resolving TNs which will allo= w entities such as service providers, devices, and applications to access d= ata related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The= working group will take into consideration existing IETF work including EN= UM, SPEERMINT, STIR, and DRINKS.

 =

The work of this group i= s limited to specifying a solution for TNs and covers any service that can = be addressed using a TN.  Expanding the work to other identifiers is o= ut of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The work group will deli= ver the following:

 =

-       &n= bsp;  An architecture overview document that i= ncludes high level requirements and security/privacy considerations<= span style=3D"color:#1F497D"> built on the work of IETF & the ATIS/SIP Forum JTF, that included: <= /u>

o<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif";color:#1F497D">   Call routing architecture

o<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif";color:#1F497D">   Inter-carrier NNI=

o<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif";color:#1F497D">   Cryptographically-enabled Anti-spoo= fing (STIR)

o<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif";color:#1F497D">   Enhanced Calling Name (CNIT/CNAM)

-       &= nbsp;  A document describing the protocols to support enrollment processes for existing an= d new TNs including any modifications to metadata related to those TNs=

-       &= nbsp;  A document describing protocol mechanism= s for accessing contact information associated with enrollments<= /span>

-       &nb= sp;  A document describing protocol mechanisms for resolving information= related to TNs

=  

-     =       



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_4143963f1b334314a917ab582bfc738dPLSWE13M01adsprintcom_-- From nobody Tue Feb 24 15:36: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 EF76D1A0404 for ; Tue, 24 Feb 2015 15:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 R_3lHkbBQowk for ; Tue, 24 Feb 2015 15:35:54 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 2AA651A03A8 for ; Tue, 24 Feb 2015 15:35:54 -0800 (PST) Received: (qmail 7153 invoked by uid 0); 24 Feb 2015 23:35:50 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 24 Feb 2015 23:35:50 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id wPbh1p00V1MNPNq01Pbkbh; Tue, 24 Feb 2015 16:35:50 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=yzGsJ_kaSJTH4ywiPr4A:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=T6OtXD6WGDFFu2m34D8A:9 a=UPUXymDLgta0xV5k:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=B8y54U98aW/byf2x55oxzVU6d3gQQg5AEVFmqj95r9I=; b=Am3IDQlcvUKFZ/hUz5cIYOoXUYrICLIrlyuuIq3nxPscHkIPhNA162/G3QCFs/q+lOf1vtf6nariQcjyly1TXLEb6tYDsvfrFgWGGXiEdG0wsfgrTl3Z7X/OWTfKbSb/; Received: from [108.56.131.201] (port=59696 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQP0u-0001N7-Od; Tue, 24 Feb 2015 16:35:41 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 24 Feb 2015 18:35:36 -0500 From: Richard Shockey To: "Holmes, David W [CTO]" , "Peterson, Jon" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] draft charter Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507647740_1709012" 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: dispatch@ietf.org Subject: Re: [Modern] draft 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, 24 Feb 2015 23:35:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507647740_1709012 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Excellent points David. My concern here is charter overreach. I really want to keep CNAM+/CNIT out of this. IMHO that is a very separate and highly focused effort to define both the modification of the SIP headers necessary to support some enhanced calling party identification and a very limited effort to define the object and or the STIR validation data. I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. If registries can be used fine but I certainly want to see how this can be accomplished in bi lateral agreements between consenting service providers and work with CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP. Certainly the relevance of CNAM+/CNIT in enterprise and residential access markets is important but we all know =B3Money is the answer what is the question ..=B2 I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and report o= n the JTF on NNI. As you well know we have made considerable progress. Last week I gave a talk on this to a panel that included many of our friend= s among the national regulators. http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Holmes, David W [CTO]" Date: Tuesday, February 24, 2015 at 5:06 PM To: "Peterson, Jon" , "modern@ietf.org" Subject: Re: [Modern] draft charter Jon,=20 =20 Thank you for the work in assembling this draft of the charter for MODERN. =20 We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out of context; i.e. the group product will be the protocols to support the allocation etc. activities, & it would not attempt to define the allocation processes. We also would like the charter to note the relevant work that has already been performed by both IETF & th= e ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG a= s appropriate. These changes/additions are have been added to your text inline below.=20 =20 We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to othe= r commitments that week. =20 Regards,=20 =20 David/Sprint=20 ___________________________________________________________________________= _ __ =20 From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter =20 =20 At the Dallas IETF meeting in March, we'd like to get together and talk about what a working group for MODERN might look like. As an initial input to the discussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DISPATCH process, we feel thi= s is broader enough in scope to warrant its own BoF. =20 Comments are welcome, this is just a starting point. =20 ------ =20 Modern charter text: =20 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. =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. 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. =20 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, STIR, and DRINKS. =20 The work of this group is limited to specifying a solution for TNs and covers any service that can be addressed using a TN. Expanding the work to other identifiers is 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. =20 The work group will deliver the following: =20 - An architecture overview document that includes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment processes for existing and new TNs including any modifications to metadata related to those TNs - A document describing protocol mechanisms for accessing contact information associated with enrollments - A document describing protocol mechanisms for resolving information related to TNs =20 - =20 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 th= e 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 --B_3507647740_1709012 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Excellent= points David.  

My concern here is charter ov= erreach. I really want to keep CNAM+/CNIT out of this.  IMHO that is a = very separate and highly focused effort to define both the modification of t= he SIP headers necessary to support some enhanced calling party identificati= on and a very limited effort to define the object and or the STIR validation= data.  

I’m violently opposed to “= ;end world hunger” WG’s. 

If regis= tries can be used fine but I certainly want to see how this can be accomplis= hed in bi lateral agreements between consenting service providers and work w= ith CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft i= n the context of a formal liaison with 3GPP.  Certainly the relevance o= f CNAM+/CNIT in enterprise and residential access markets is important but w= e all know “Money is the answer what is the  question ..” &= nbsp;

I’ve asked for time in Dispatch to look= at the CNAM/CNIT issue and report on the JTF on NNI. As you well know we ha= ve made considerable progress.

Last week I gave a t= alk on this to a panel that included many of our friends among the national = regulators.  




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


From: "Holmes, Da= vid W [CTO]" <David.Holmes@sprin= t.com>
Date: Tuesday, Febru= ary 24, 2015 at 5:06 PM
To: "Peter= son, Jon" <jon.peterson@neustar= .biz>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft charter

Jon,

 

Thank you for the wor= k in assembling this draft of the charter for MODERN.

 

We would like to suggest some minor clarifica= tions to the bullets describing the deliverables, to align them with the sta= tement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the allo= cation etc. activities, & it would not attempt to define the allocation = processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the M= ODERN WG as appropriate.  These changes/additions are have been added t= o your text inline below.

 

We are hoping that the MODERN session at IETF= #92 will have remote access, to allow participation by those of us that cann= ot attend in person due to other commitments that week.  

 

Regards,

 

David/Sprint

________________________________________________________________________= ______

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2= 015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

 

At the Dallas IETF meeting in March, we'= d like to get together and talk about what a working group for MODERN might = look like. As an initial input to the discussion, a few of us have put toget= her a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own B= oF.

 

Comments are welcome, this is just a starting p= oint.

 

------

 

<= p class=3D"MsoNormal">Modern charter text:

 =

The MODERN working= group will define a set of Internet-based mechanisms for the purposes of ma= naging and resolving telephone numbers (TNs) in an IP environment.  Exi= sting mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w 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 a= n organization will remain for some time. Devices, applications, and network= tools increasingly need to manage TNs, including requesting and acquiring T= N delegations from authorities.

 

The working group will define a framework for the roles and f= unctions involved in managing and resolving TNs in an IP environment. This i= ncludes a protocol mechanism for acquiring TNs, which will provide an enroll= ment 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 a= rchitecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 =

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

 =

The wor= k of this group is limited to specifying a solution for TNs and covers any s= ervice that can be addressed using a TN.  Expanding the work to other i= dentifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The wor= k group will deliver the following:

 

-      =     An architecture overview document that inc= ludes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Foru= m JTF, that included:

o   Call routing architecture =

o   Inter-carrier NNI

o   Cryptographically-enabled Anti-spoofi= ng (STIR)

oEnhanced Calling Name (CNIT/CNAM)

-=           A document describing the protocols to support enrollment processes for existing and = new TNs including any modifications to metadata related to those TNs

-&= nbsp;         A document describing protocol mechanisms = for accessing contact information associated with enrollments

- &nbs= p;        A document describing protocol mechanisms for resolving information r= elated to TNs

 

-       = ;    


<= br> 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 t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3507647740_1709012-- From nobody Tue Feb 24 18:03: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 3DD031A9077; Tue, 24 Feb 2015 18:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 xpmkT1eW7FnI; Tue, 24 Feb 2015 18:03:09 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E8D1A9073; Tue, 24 Feb 2015 18:03:08 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id a5d2de45.0.5269730.00-1965.14830243.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Feb 2015 02:03:09 +0000 (UTC) X-MXL-Hash: 54ed2d5d68c1b717-ccb1b3168eba8ca4cce064b800c926e7d063979c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1P235pM017826; Tue, 24 Feb 2015 21:03:06 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1P22tYM017752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Feb 2015 21:02:58 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 25 Feb 2015 02:02:41 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.167]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 21:02:41 -0500 From: "DOLLY, MARTIN C" To: Richard Shockey Thread-Topic: [dispatch] [Modern] draft charter Thread-Index: AQHQUJ8jttaE08TRjkylaRACfmlD9Q== Date: Wed, 25 Feb 2015 02:02:41 +0000 Message-ID: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4DA2FD252B324812A9FEE8649BED9989attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EtBlW1gA c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=doUQ] X-AnalysisOut: [ZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=izV7ms69AAA] X-AnalysisOut: [A:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=iy2iwTbxphpkVQNCo6] X-AnalysisOut: [MA:9 a=pILNOxqGKmIA:10 a=JpNyA6z_r-EA:10 a=ivbTfD_dPm4A:10] X-AnalysisOut: [ a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=QuLkP43yR8ib2NjKHewA:9 a=UiCQ7L4-1S4A:10 a=] X-AnalysisOut: [hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "modern@ietf.org" , "Peterson, Jon" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 02:03:13 -0000 --_000_4DA2FD252B324812A9FEE8649BED9989attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support Richard on this Martin Dolly Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey > wrote: Excellent points David. My concern here is charter overreach. I really want to keep CNAM+/CNIT out = of this. IMHO that is a very separate and highly focused effort to define = both the modification of the SIP headers necessary to support some enhanced= calling party identification and a very limited effort to define the objec= t and or the STIR validation data. I=92m violently opposed to =93end world hunger=94 WG=92s. If registries can be used fine but I certainly want to see how this can be = accomplished in bi lateral agreements between consenting service providers = and work with CUA vendors on how the data is displayed aka Apple, Samsung, = Microsoft in the context of a formal liaison with 3GPP. Certainly the rele= vance of CNAM+/CNIT in enterprise and residential access markets is importa= nt but we all know =93Money is the answer what is the question ..=94 I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on the JTF on NNI. As you well know we have made considerable progress. Last week I gave a talk on this to a panel that included many of our friend= s among the national regulators. http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM To: "Peterson, Jon" >, "modern@ietf.org" > Subject: Re: [Modern] draft charter Jon, Thank you for the work in assembling this draft of the charter for MODERN. We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility = to support the needs of different regulatory regimes, & thus to ensure that= if quoted alone they are not taken out of context; i.e. the group product = will be the protocols to support the allocation etc. activities, & it would= not attempt to define the allocation processes. We also would like the ch= arter to note the relevant work that has already been performed by both IET= F & the ATIS/SIP Forum JTF, & incorporate that into the output from the MOD= ERN WG as appropriate. These changes/additions are have been added to your= text inline below. We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to ot= her commitments that week. Regards, David/Sprint ___________________________________________________________________________= ___ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern 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, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. Solutions and mechanisms created by the wo= rking 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 document that includes high level requi= rements and security/privacy considerationsbuilt on the work of IETF & the = ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment proces= ses for existing and new TNs including any modifications to metadata relate= d to those TNs - A document describing protocol mechanisms for accessing contact = information associated with enrollments - A document describing protocol mechanisms for resolving informat= ion related to TNs - ________________________________ 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. _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/mode= rn _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_4DA2FD252B324812A9FEE8649BED9989attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I support Richard on this 

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and 
Industry Alliances
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  

My concern here is charter overreach. I really want to keep CNAM+/= CNIT out of this.  IMHO that is a very separate and highly focused eff= ort to define both the modification of the SIP headers necessary to support= some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I=92m violently opposed to =93end world hunger=94 WG=92s. 

If registries can be used fine but I certainly want to see how this ca= n be accomplished in bi lateral agreements between consenting service provi= ders and work with CUA vendors on how the data is displayed aka Apple, Sams= ung, Microsoft in the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNI= T in enterprise and residential access markets is important but we all know= =93Money is the answer what is the  question ..=94  

I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and r= eport on the JTF on NNI. As you well know we have made considerable progres= s.

Last week I gave a talk on this to a panel that included many of our f= riends among the national regulators.  




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


From: "Holmes, David W [CTO]&q= uot; <David.Holmes@sprint.com= >
Date: Tuesday, February 24, 2015 at= 5:06 PM
To: "Peterson, Jon" <<= a href=3D"mailto:jon.peterson@neustar.biz">jon.peterson@neustar.biz>= , "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft charter=

Jon, =

=  

Thank= you for the work in assembling this draft of the charter for MODERN.

=  

We wo= uld like to suggest some minor clarifications to the bullets describing the= deliverables, to align them with the statement regarding flexibility to su= pport the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the all= ocation etc. activities, & it would not attempt to define the allocatio= n processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the = MODERN WG as appropriate.  These changes/additions are have been added= to your text inline below.

=  

We ar= e hoping that the MODERN session at IETF#92 will have remote access, to all= ow participation by those of us that cannot attend in person due to other c= ommitments that week.  

=  

Regar= ds,

=  

David= /Sprint

_____= _________________________________________________________________________

=  

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

&n= bsp;

At the = Dallas IETF meeting in March, we'd like to get together and talk about what= a working group for MODERN might look like. As an initial input to the dis= cussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own = BoF.

&n= bsp;

Comment= s are welcome, this is just a starting point.

&n= bsp;

------<= o:p>

&n= bsp;

Modern charter text:

 =

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

 =

The working group will d= efine a framework for the roles and functions involved in managing and reso= lving TNs in an IP environment. This includes a protocol mechanism for acqu= iring 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 reso= urce will be primary considerations.

 =

Additionally, the workin= g group will deliver a protocol mechanism for resolving TNs which will allo= w entities such as service providers, devices, and applications to access d= ata related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The= working group will take into consideration existing IETF work including EN= UM, SPEERMINT, STIR, and DRINKS.

 =

The work of this group i= s limited to specifying a solution for TNs and covers any service that can = be addressed using a TN.  Expanding the work to other identifiers is o= ut of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The work group will deli= ver the following:

 =

- = ;         An architecture overview document that i= ncludes high level requirements and security/privacy considerations<= span style=3D"color:#1F497D">built on the work of IETF & the ATIS/SI= P Forum JTF, that included:

o   Call routing architecture

o   Inter-carrier NNI=

o   Cryptographically-enabled Anti-spoo= fing (STIR)

o   Enhanced Calling Name (CNIT/CNAM)

-&nbs= p;         A document describing the protocols to support enrollment processes for existing an= d new TNs including any modifications to metadata related to those TNs=

-&nbs= p;         A document describing protocol mechanism= s for accessing contact information associated with enrollments<= /span>

- =          A document describing protocol mechanisms for resolving information= related to TNs

=  

- &n= bsp;         <= /o:p>



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.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_4DA2FD252B324812A9FEE8649BED9989attcom_-- From nobody Wed Feb 25 09:06:50 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 EC4041A90C5 for ; Wed, 25 Feb 2015 09:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 C3daHAVSzZ9M for ; Wed, 25 Feb 2015 09:06:41 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id D6AE01A903F for ; Wed, 25 Feb 2015 09:06:40 -0800 (PST) Received: (qmail 5483 invoked by uid 0); 25 Feb 2015 17:06:38 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 25 Feb 2015 17:06:38 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id wo5C1p00h1MNPNq01o5Fc6; Wed, 25 Feb 2015 17:05:24 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=0Or7jusycULVaPx2pgEA:9 a=rpj6ZxKFMDNLe-dQ:21 a=_AFRu06Vt3MRSuX4:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=hzi90bUycbL9tOCHrCUA:9 a=KhwY1BwdpY_w7US2:21 a=9qgP4eEyyhwikyru:21 a=mK_KfrpBNI_agG4o:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=XeIq556CbkeiZBxs1O5oyTHEdymKPuVHBEQk5lUDaJA=; b=XFb5vOovja5RB8KdLLfv01y8YqBFSL61Qxbzh//xR8xOnuQLxP4sf9SwfR/vGgBToDDCrOuY6KNNJKELY6/TUke8k3ySKua+2BGvrK0aP36ySq8y4Ny+YIJfUtGHogU5; Received: from [108.56.131.201] (port=55216 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQfOb-0003nB-PV; Wed, 25 Feb 2015 10:05:14 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 12:05:08 -0500 From: Richard Shockey To: "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [dispatch] draft charter Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507710713_441257" 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: "Holmes, David W \[CTO\]" , cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" , "Peterson, Jon" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 17:06:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507710713_441257 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks Martin .. This is my very raw first cut at a charter. Its hopefully simple and straight forward. Send me any edits etc. ***** CNIT Charter [Calling Name Identity Trust] WG Chairs TBD: Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters of information associated with a specific E.164 calling party number in the Public Switched Telephone Network [PSTN]. In the PSTN this data is sent by the originating network only at the specific request of the terminating network via a SS7 Transaction Application Part [TCAP] response message. In the Session Initiation Protocol [SIP] this information can be inserted into the FROM: part of the originating INVITE message or by other means. As with the originating source telephone number, this data can be altered i= n transit creating a variety of malicious abuses similar to the ones identified by the IETF STIR working group. The purpose of the CNIT working group will be to define a data structure, a new SIP header or repurpose an existing SIP header to carry an advanced for= m of CNAM as well as information from a STIR Validation Authority. The purpose of this work is to present to the SIP called party trusted information from the calling party in order that the called party make a more reasoned and informed judgment on whether to accept the INVITE or not. The working group will not invalidate any existing SIP mechanism for anonymous calling.=20 The working group will, to the best of its ability, reuse existing IETF protocols. Full Internationalization of the Calling Name Identity Trust data object(s) is a requirement. The working group will closely work with the IETF STIR working group The working group will immediately liaison with 3GPP SA-1 in order to coordinate efforts. The working group will coordinate with National Numbering Authorities and National Regulatory Authorities as needed. The working group will deliver the flowing. =80 A problem statement and requirements detailing the current deployment environment and situations that motivate work on Calling Name Identity Trust. =80 Define either a new SIP header or document a repurpose of an SIP existing header for Calling Name Identify Trust data =80 Define a data model for the Calling Name Identity Trust object (s) which may include various forms of multimedia data =80 Deliver an analysis of privacy implications of the proposed Calling Name Identity Trust mechanism. Milestones: =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "DOLLY, MARTIN C" Date: Tuesday, February 24, 2015 at 9:02 PM To: Richard Shockey Cc: "Holmes, David W [CTO]" , "dispatch@ietf.org" , "modern@ietf.org" , "Peterson, Jon" Subject: Re: [Modern] [dispatch] draft charter I support Richard on this Martin Dolly=20 Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and=20 Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey wrote: >=20 > Excellent points David. >=20 > My concern here is charter overreach. I really want to keep CNAM+/CNIT ou= t of > this. IMHO that is a very separate and highly focused effort to define b= oth > the modification of the SIP headers necessary to support some enhanced ca= lling > party identification and a very limited effort to define the object and o= r the > STIR validation data. >=20 > I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. >=20 > If registries can be used fine but I certainly want to see how this can b= e > accomplished in bi lateral agreements between consenting service provider= s and > work with CUA vendors on how the data is displayed aka Apple, Samsung, > Microsoft in the context of a formal liaison with 3GPP. Certainly the > relevance of CNAM+/CNIT in enterprise and residential access markets is > important but we all know =B3Money is the answer what is the question ..=B2 >=20 > I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on > the JTF on NNI. As you well know we have made considerable progress. >=20 > Last week I gave a talk on this to a panel that included many of our frie= nds > among the national regulators. >=20 > http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >=20 >=20 >=20 > From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM > To: "Peterson, Jon" , "modern@ietf.org" > > Subject: Re: [Modern] draft charter >=20 > Jon,=20 > =20 > Thank you for the work in assembling this draft of the charter for MODERN= . > =20 > We would like to suggest some minor clarifications to the bullets describ= ing > the deliverables, to align them with the statement regarding flexibility = to > support the needs of different regulatory regimes, & thus to ensure that = if > quoted alone they are not taken out of context; i.e. the group product wi= ll be > the protocols to support the allocation etc. activities, & it would not > attempt to define the allocation processes. We also would like the chart= er to > note the relevant work that has already been performed by both IETF & the > ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG= as > appropriate. These changes/additions are have been added to your text in= line > below.=20 > =20 > We are hoping that the MODERN session at IETF#92 will have remote access,= to > allow participation by those of us that cannot attend in person due to ot= her > commitments that week. > =20 > Regards,=20 > =20 > David/Sprint=20 > _________________________________________________________________________= _____ > =20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, February 11, 2015 9:19 AM > To: modern@ietf.org > Subject: [Modern] draft charter > =20 > =20 > At the Dallas IETF meeting in March, we'd like to get together and talk a= bout > what a working group for MODERN might look like. As an initial input to t= he > discussion, a few of us have put together a proposed charter. While the T= eRQ > work was positively evaluated in the DISPATCH process, we feel this is br= oader > enough in scope to warrant its own BoF. > =20 > Comments are welcome, this is just a starting point. > =20 > ------ > =20 > Modern charter text: > =20 > The MODERN working group will define a set of Internet-based mechanisms f= or > 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 havi= ng an > association to a single service provider and a single application is brea= king > 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. > =20 > The working group will define a framework for the roles and functions inv= olved > in managing and resolving TNs in an IP environment. This includes a proto= col > mechanism for acquiring TNs, which will provide an enrollment process for= the > individuals and entities that use and manage TNs. TNs may either be manag= ed in > a hierarchical tree, or in a distributed peer-to-peer architecture. Priv= acy > of the enrollment data and security of the resource will be primary > considerations.=20 > =20 > Additionally, the working group will deliver a protocol mechanism for > resolving TNs which will allow entities such as service providers, device= s, > 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, STIR, an= d > DRINKS.=20 > =20 > The work of this group is limited to specifying a solution for TNs and co= vers > any service that can be addressed using a TN. Expanding the work to othe= r > identifiers is out of scope. Solutions and mechanisms created by the wor= king > group will be flexible enough to accommodate different policies, e.g., by > different regulatory agencies. > =20 > The work group will deliver the following: > =20 > - An architecture overview document that includes high level > requirements and security/privacy considerationsbuilt on the work of IETF= & > the ATIS/SIP Forum JTF, that included: >=20 > o Call routing architecture >=20 > o Inter-carrier NNI >=20 > o Cryptographically-enabled Anti-spoofing (STIR) >=20 > o Enhanced Calling Name (CNIT/CNAM) >=20 > - A document describing the protocols to support enrollment proce= sses > for existing and new TNs including any modifications to metadata related = to > those TNs >=20 > - A document describing protocol mechanisms for accessing contact > information associated with enrollments >=20 > - A document describing protocol mechanisms for resolving informa= tion > related to TNs >=20 > =20 >=20 > - =20 >=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 not = the > intended recipient, please contact the sender and delete all copies of th= e > message. > _______________________________________________ Modern mailing list > Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3507710713_441257 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

<= div style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size:= 14px;">Thanks Martin .. This is my very raw first cut at a charter. Its hop= efully simple and straight forward.

Send me= any edits etc.

*****

CNIT Charter [Calling Name Iden= tity Trust]

WG Chairs TBD:

Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters o= f information associated with a specific E.164 calling party number in the P= ublic Switched Telephone Network [PSTN].  In the PSTN this data is sent= by the originating network only at the specific request of the terminating = network via a SS7 Transaction Application Part [TCAP] response message. &nbs= p;In the Session Initiation Protocol [SIP] this information can be inserted = into the FROM: part of the originating INVITE message or by other means.

As with the originating source telephone number, thi= s data can be altered in transit creating a variety of malicious abuses simi= lar to the ones identified by the IETF STIR working group.
=
The purpose of the CNIT working group will be to define a data str= ucture, a new SIP header or repurpose an existing SIP header to carry an adv= anced form of CNAM as well as information from a STIR Validation Authority. =  The purpose of this work is to present to the SIP called party trusted= information from the calling party in order that the called party make a mo= re reasoned and informed judgment on whether to accept the INVITE or not.

The working group will not invalidate any existing = SIP mechanism for anonymous calling.  

The w= orking group will, to the best of its ability, reuse existing IETF protocols= .

Full Internationalization of the Calling Name I= dentity Trust data object(s) is a requirement.

Th= e working group will closely work with the IETF STIR working group

The working group will immediately liaison with 3GPP SA-1 = in order to coordinate efforts.

The working group= will coordinate with National Numbering Authorities and National Regulatory= Authorities as needed.
The working group will de= liver the flowing.

• A problem statement and requirements d= etailing the current deployment environment and situations that motivate wor= k on Calling Name Identity Trust.
• D= efine either a new SIP header or document a repurpose of an SIP existing hea= der for Calling Name Identify Trust data
• <= /span>Define a data model for the Calling Name Identity Trust object (s) whi= ch may include various forms of multimedia data
• Deliver an analysis of privacy implications of the proposed Cal= ling Name Identity Trust mechanism.


Milestones:


— 
Richa= rd Shockey
Shockey Consulting LLC
Chairman of the Board = SIP Forum
www.shockey.us
www.sipforum.org
rich= ard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
<= div>PSTN +1 703-593-2683


=
From: "DOLLY, MARTIN C" <md3135@att.com>
Date: Tuesday, February 24, 2015 at 9:02 PM
To: Richard Shockey <richard@shockey.us>
Cc= : "Holmes, David W [CTO]" <David.Holmes@sprint.com>, "disp= atch@ietf.org" <dispatch@ietf.org<= /a>>, "modern@ietf.org" <modern@ietf.org>, "Peterson, Jon" <jon.peterson@neustar.biz>
Subject: Re: [Modern] [dispatch] draft c= harter

I support Richard on = this 

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory S= tandards
AT&T Standards and 
Industry Alliances=
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  
=
My concern here is charter overreach. I really want to keep C= NAM+/CNIT out of this.  IMHO that is a very separate and highly focused= effort to define both the modification of the SIP headers necessary to supp= ort some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I’m violently opposed to “= end world hunger” WG’s. 

If regist= ries can be used fine but I certainly want to see how this can be accomplish= ed in bi lateral agreements between consenting service providers and work wi= th CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in= the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNIT in= enterprise and residential access markets is important but we all know R= 20;Money is the answer what is the  question ..”  

I’ve asked for time in Dispatch to look at the CNAM/CN= IT issue and report on the JTF on NNI. As you well know we have made conside= rable progress.

Last week I gave a talk on this to = a panel that included many of our friends among the national regulators. &nb= sp;


From: "Holmes, David W [CTO]" <David.Holmes@sprint.com>
Date: Tuesday, February 24, 2015 at 5:06 PM
To: "Peterson, Jon" <jon.peterson@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft = charter

Jon,

 

Thank you for the wor= k in assembling this draft of the charter for MODERN.

 

We would like to suggest some minor clarifica= tions to the bullets describing the deliverables, to align them with the sta= tement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the allo= cation etc. activities, & it would not attempt to define the allocation = processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the M= ODERN WG as appropriate.  These changes/additions are have been added t= o your text inline below.

 

We are hoping that the MODERN session at IETF= #92 will have remote access, to allow participation by those of us that cann= ot attend in person due to other commitments that week.  

 

Regards,

 

David/Sprint

________________________________________________________________________= ______

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2= 015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

 

At the Dallas IETF meeting in March, we'= d like to get together and talk about what a working group for MODERN might = look like. As an initial input to the discussion, a few of us have put toget= her a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own B= oF.

 

Comments are welcome, this is just a starting p= oint.

 

------

 

<= p class=3D"MsoNormal">Modern charter text:

 =

The MODERN working= group will define a set of Internet-based mechanisms for the purposes of ma= naging and resolving telephone numbers (TNs) in an IP environment.  Exi= sting mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w 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 a= n organization will remain for some time. Devices, applications, and network= tools increasingly need to manage TNs, including requesting and acquiring T= N delegations from authorities.

 

The working group will define a framework for the roles and f= unctions involved in managing and resolving TNs in an IP environment. This i= ncludes a protocol mechanism for acquiring TNs, which will provide an enroll= ment 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 a= rchitecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 =

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

 =

The wor= k of this group is limited to specifying a solution for TNs and covers any s= ervice that can be addressed using a TN.  Expanding the work to other i= dentifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The wor= k group will deliver the following:

 

-      =     An architecture overview document that inc= ludes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Foru= m JTF, that included:

o   Call routing architecture =

o   Inter-carrier NNI

o   Cryptographically-enabled Anti-spoofi= ng (STIR)

oEnhanced Calling Name (CNIT/CNAM)

-=           A document describing the protocols to support enrollment processes for existing and = new TNs including any modifications to metadata related to those TNs

-&= nbsp;         A document describing protocol mechanisms = for accessing contact information associated with enrollments

- &nbs= p;        A document describing protocol mechanisms for resolving information r= elated to TNs

 

-       = ;    


<= br> 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 t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org = https://www.ietf.org/mailman/listinfo/modern
___________________________________________= ____
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/d= ispatch
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3507710713_441257-- From nobody Wed Feb 25 09:55:51 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 A26691A1A13; Wed, 25 Feb 2015 09:32:05 -0800 (PST) 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 jMxEu1YnHgPR; Wed, 25 Feb 2015 09:32:02 -0800 (PST) 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 23A611A1A0F; Wed, 25 Feb 2015 09:32:01 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 3C0276726DC7E; Wed, 25 Feb 2015 17:31:56 +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 t1PHVwtQ012327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 18:31:58 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 18:31:58 +0100 From: "DRAGE, Keith (Keith)" To: Richard Shockey , "DOLLY, MARTIN C" Thread-Topic: [dispatch] [Modern] draft charter Thread-Index: AQHQUR12wXN/MqmpnkuTg3mwcQ/taZ0BmYJA Date: Wed, 25 Feb 2015 17:31:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A10928E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: 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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 09:55:50 -0800 Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 17:32:05 -0000 ITU-T Recommendation I.251.9 specifies: calling name: Information associated with a specific calling party number. = The maximum length is at least 15 characters and may be up to 50 characters= . The exact length, format and character set (e.g. T.51, T.52) of the calli= ng name to be delivered is a service provider option Therefore 15 would appear to be a deployment specific limitation. I believe QSIG defines 50 characters. The definition above also raises the question of character set. QSIG defines a number of different character sets. Regards Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Richard Shockey > Sent: 25 February 2015 17:05 > To: DOLLY, MARTIN C > Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=20 > modern@ietf.org > Subject: Re: [dispatch] [Modern] draft charter >=20 >=20 > Thanks Martin .. This is my very raw first cut at a charter.=20 > Its hopefully simple and straight forward. >=20 > Send me any edits etc. >=20 > ***** >=20 > CNIT Charter [Calling Name Identity Trust] >=20 >=20 > WG Chairs TBD: >=20 >=20 > Calling Name Delivery [CNAM] is a string of up to 15 ASCII=20 > Characters of information associated with a specific E.164=20 > calling party number in the Public Switched Telephone Network=20 > [PSTN]. In the PSTN this data is sent by the originating=20 > network only at the specific request of the terminating=20 > network via a SS7 Transaction Application Part [TCAP]=20 > response message. In the Session Initiation Protocol [SIP]=20 > this information can be inserted into the FROM: part of the=20 > originating INVITE message or by other means. >=20 >=20 > As with the originating source telephone number, this data=20 > can be altered in transit creating a variety of malicious=20 > abuses similar to the ones identified by the IETF STIR working group. >=20 >=20 > The purpose of the CNIT working group will be to define a=20 > data structure, a new SIP header or repurpose an existing SIP=20 > header to carry an advanced form of CNAM as well as=20 > information from a STIR Validation Authority. The purpose of=20 > this work is to present to the SIP called party trusted=20 > information from the calling party in order that the called=20 > party make a more reasoned and informed judgment on whether=20 > to accept the INVITE or not. >=20 >=20 > The working group will not invalidate any existing SIP=20 > mechanism for anonymous calling. =20 >=20 >=20 > The working group will, to the best of its ability, reuse=20 > existing IETF protocols. >=20 >=20 > Full Internationalization of the Calling Name Identity Trust=20 > data object(s) is a requirement. >=20 >=20 > The working group will closely work with the IETF STIR working group >=20 >=20 > The working group will immediately liaison with 3GPP SA-1 in=20 > order to coordinate efforts. >=20 >=20 > The working group will coordinate with National Numbering=20 > Authorities and National Regulatory Authorities as needed. >=20 >=20 > The working group will deliver the flowing. >=20 >=20 > * A problem statement and requirements detailing the current=20 > deployment environment and situations that motivate work on=20 > Calling Name Identity Trust. > * Define either a new SIP header or document a repurpose of=20 > an SIP existing header for Calling Name Identify Trust data *=20 > Define a data model for the Calling Name Identity Trust=20 > object (s) which may include various forms of multimedia data=20 > * Deliver an analysis of privacy implications of the proposed=20 > Calling Name Identity Trust mechanism. >=20 >=20 >=20 >=20 > Milestones: >=20 >=20 > - > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "DOLLY, MARTIN C" > Date: Tuesday, February 24, 2015 at 9:02 PM > To: Richard Shockey > Cc: "Holmes, David W [CTO]" ,=20 > "dispatch@ietf.org" , "modern@ietf.org"=20 > , "Peterson, Jon" > Subject: Re: [Modern] [dispatch] draft charter >=20 >=20 > I support Richard on this=20 >=20 > Martin Dolly=20 > Lead Member of Technical Staff > Core & Gov't/Regulatory Standards > AT&T Standards and=20 > Industry Alliances > +1-609-903-3390 >=20 > Sent from my iPhone >=20 > On Feb 24, 2015, at 6:36 PM, Richard Shockey=20 > wrote: >=20 >=20 >=20 >=20 > Excellent points David. =20 >=20 > My concern here is charter overreach. I really want to=20 > keep CNAM+/CNIT out of this. IMHO that is a very separate=20 > and highly focused effort to define both the modification of=20 > the SIP headers necessary to support some enhanced calling=20 > party identification and a very limited effort to define the=20 > object and or the STIR validation data. =20 >=20 > I'm violently opposed to "end world hunger" WG's.=20 >=20 > If registries can be used fine but I certainly want to=20 > see how this can be accomplished in bi lateral agreements=20 > between consenting service providers and work with CUA=20 > vendors on how the data is displayed aka Apple, Samsung,=20 > Microsoft in the context of a formal liaison with 3GPP. =20 > Certainly the relevance of CNAM+/CNIT in enterprise and=20 > residential access markets is important but we all know=20 > "Money is the answer what is the question .." =20 >=20 > I've asked for time in Dispatch to look at the=20 > CNAM/CNIT issue and report on the JTF on NNI. As you well=20 > know we have made considerable progress. >=20 > Last week I gave a talk on this to a panel that=20 > included many of our friends among the national regulators. =20 >=20 > http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >=20 >=20 >=20 > =09 > From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM > To: "Peterson, Jon" ,=20 > "modern@ietf.org" > Subject: Re: [Modern] draft charter > =09 >=20 >=20 > Jon,=20 >=20 > =20 >=20 > Thank you for the work in assembling this draft of the=20 > charter for MODERN.=20 >=20 > =20 >=20 > We would like to suggest some minor clarifications to=20 > the bullets describing the deliverables, to align them with=20 > the statement regarding flexibility to support the needs of=20 > different regulatory regimes, & thus to ensure that if quoted=20 > alone they are not taken out of context; i.e. the group=20 > product will be the protocols to support the allocation etc.=20 > activities, & it would not attempt to define the allocation=20 > processes. We also would like the charter to note the=20 > relevant work that has already been performed by both IETF &=20 > the ATIS/SIP Forum JTF, & incorporate that into the output=20 > from the MODERN WG as appropriate. These changes/additions=20 > are have been added to your text inline below.=20 >=20 > =20 >=20 > We are hoping that the MODERN session at IETF#92 will=20 > have remote access, to allow participation by those of us=20 > that cannot attend in person due to other commitments that week. =20 >=20 > =20 >=20 > Regards,=20 >=20 > =20 >=20 > David/Sprint=20 >=20 > =09 > ______________________________________________________________ > ________________ >=20 > =20 >=20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf=20 > Of Peterson, Jon > Sent: Wednesday, February 11, 2015 9:19 AM > To: modern@ietf.org > Subject: [Modern] draft charter >=20 > =20 >=20 > =20 >=20 > At the Dallas IETF meeting in March, we'd like to get=20 > together and talk about what a working group for MODERN might=20 > look like. As an initial input to the discussion, a few of us=20 > have put together a proposed charter. While the TeRQ work was=20 > positively evaluated in the DISPATCH process, we feel this is=20 > broader enough in scope to warrant its own BoF. >=20 > =20 >=20 > Comments are welcome, this is just a starting point. >=20 > =20 >=20 > ------ >=20 > =20 >=20 > Modern charter text: >=20 > =20 >=20 > The MODERN working group will define a set of=20 > Internet-based mechanisms for the purposes of managing and=20 > resolving telephone numbers (TNs) in an IP environment. =20 > Existing mechanisms for these purposes face obsolescence as=20 > the voice communications infrastructure 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=20 > service provider and a single application is breaking down. =20 > Its use as a network locator is going away, but its use as an=20 > identifier for an individual or an organization will remain=20 > for some time. Devices, applications, and network tools=20 > increasingly need to manage TNs, including requesting and=20 > acquiring TN delegations from authorities. >=20 > =20 >=20 > The working group will define a framework for the roles=20 > and 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. 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 of the resource will be primary considerations.=20 >=20 > =20 >=20 > Additionally, the working group will deliver a protocol=20 > mechanism for resolving TNs which will allow entities such as=20 > service providers, devices, and applications to access data=20 > related to TNs, possibly including caller name data (CNAM). =20 > Maintaining reliability, real time application performance,=20 > security and privacy are primary considerations. The working=20 > group will take into consideration existing IETF work=20 > including ENUM, SPEERMINT, STIR, and DRINKS.=20 >=20 > =20 >=20 > The work of this group is limited to specifying a=20 > solution for TNs and covers any service that can be addressed=20 > using a TN. Expanding the work to other identifiers is out=20 > of scope. Solutions and mechanisms created by the working=20 > group will be flexible enough to accommodate different=20 > policies, e.g., by different regulatory agencies.=20 >=20 > =20 >=20 > The work group will deliver the following: >=20 > =20 >=20 > - An architecture overview document that=20 > includes high level requirements and security/privacy=20 > considerationsbuilt on the work of IETF & the ATIS/SIP Forum=20 > JTF, that included:=20 >=20 > o Call routing architecture=20 >=20 > o Inter-carrier NNI >=20 > o Cryptographically-enabled Anti-spoofing (STIR) >=20 > o Enhanced Calling Name (CNIT/CNAM) >=20 > - A document describing the protocols to=20 > support enrollment processes for existing and new TNs=20 > including any modifications to metadata related to those TNs >=20 > - A document describing protocol mechanisms=20 > for accessing contact information associated with enrollments >=20 > - A document describing protocol mechanisms=20 > for resolving information related to TNs >=20 > =20 >=20 > - =20 >=20 >=20 > ________________________________ >=20 > =09 > 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. > =09 > _______________________________________________ Modern=20 > mailing list Modern@ietf.org =20 > https://www.ietf.org/mailman/listinfo/modern >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =09 >=20 > _______________________________________________ Modern=20 > mailing list Modern@ietf.org=20 > https://www.ietf.org/mailman/listinfo/modern=20 > = From nobody Wed Feb 25 10:14: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 D672C1A00D0; Wed, 25 Feb 2015 10:14:40 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 FAvV16KRN3h2; Wed, 25 Feb 2015 10:14:37 -0800 (PST) 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 1FC251A0016; Wed, 25 Feb 2015 10:14:37 -0800 (PST) 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 t1PIDrvW003550; Wed, 25 Feb 2015 13:14:27 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1sskb580kg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2015 13:14:26 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.67]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 13:14:25 -0500 From: "Peterson, Jon" To: "DOLLY, MARTIN C" , Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUJ876Ub0AVjuokK2O8uJqxpi6J0BejeA Date: Wed, 25 Feb 2015 18:14:25 +0000 Message-ID: References: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> In-Reply-To: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.189] Content-Type: multipart/alternative; boundary="_000_D1134C4014B0A7jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7723 signatures=670627 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=7.7937656328686e-14 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-1502250189 Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 18:14:41 -0000 --_000_D1134C4014B0A7jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think the potential for a CNAM-like function enters into MODERN from the = WHOIS/WEIRDS sorts of requirements we imagine are associated with moving th= e number registration process to the Internet. As you enroll in the system = to get numbers, obviously some information about assignees is going to chan= ge hands, and somewhere there will have to be control and accountability fo= r who owns what numbers, and a secure (privacy-protecting) way to query for= that data. But more broadly, since MODERN follows on TeRQ, any TeRQ-like p= rotocol is going to be able to ask about arbitrary data associated with num= bers including names - but crucially, TeRQ queries can and will be launched= at a time no call from that number is in progress. So I'm not sure MODERN would conflict or even overlap, necessarily, with ef= forts to define a header or other place to carry that naming information in= SIP as in the proposed CNIT charter. MODERN isn't going to define a SIP he= ader to carry CNAM data, and CNIT isn't going to define a way to query for = CNAM-like data outside of a SIP session in progress, from my reading of the= draft charter. If that sounds reasonable, we could build language into bot= h proposed charters that makes the distinction clear. Jon Peterson Neustar, Inc. From: , MARTIN C > Date: Tuesday, February 24, 2015 at 6:02 PM To: Richard Shockey > Cc: "Holmes, David W [CTO]" >, "dispatch@ietf.org" >, "modern@ietf.org" >, Jon Peterson > Subject: Re: [Modern] [dispatch] draft charter I support Richard on this Martin Dolly Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey > wrote: Excellent points David. My concern here is charter overreach. I really want to keep CNAM+/CNIT out = of this. IMHO that is a very separate and highly focused effort to define = both the modification of the SIP headers necessary to support some enhanced= calling party identification and a very limited effort to define the objec= t and or the STIR validation data. I=92m violently opposed to =93end world hunger=94 WG=92s. If registries can be used fine but I certainly want to see how this can be = accomplished in bi lateral agreements between consenting service providers = and work with CUA vendors on how the data is displayed aka Apple, Samsung, = Microsoft in the context of a formal liaison with 3GPP. Certainly the rele= vance of CNAM+/CNIT in enterprise and residential access markets is importa= nt but we all know =93Money is the answer what is the question ..=94 I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on the JTF on NNI. As you well know we have made considerable progress. Last week I gave a talk on this to a panel that included many of our friend= s among the national regulators. http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM To: "Peterson, Jon" >, "modern@ietf.org" > Subject: Re: [Modern] draft charter Jon, Thank you for the work in assembling this draft of the charter for MODERN. We would like to suggest some minor clarifications to the bullets describin= g the deliverables, to align them with the statement regarding flexibility = to support the needs of different regulatory regimes, & thus to ensure that= if quoted alone they are not taken out of context; i.e. the group product = will be the protocols to support the allocation etc. activities, & it would= not attempt to define the allocation processes. We also would like the ch= arter to note the relevant work that has already been performed by both IET= F & the ATIS/SIP Forum JTF, & incorporate that into the output from the MOD= ERN WG as appropriate. These changes/additions are have been added to your= text inline below. We are hoping that the MODERN session at IETF#92 will have remote access, t= o allow participation by those of us that cannot attend in person due to ot= her commitments that week. Regards, David/Sprint ___________________________________________________________________________= ___ From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, February 11, 2015 9:19 AM To: modern@ietf.org Subject: [Modern] draft charter At the Dallas IETF meeting in March, we'd like to get together and talk abo= ut what a working group for MODERN might look like. As an initial input to = the discussion, a few of us have put together a proposed charter. While the= TeRQ work was positively evaluated in the DISPATCH process, we feel this i= s broader enough in scope to warrant its own BoF. Comments are welcome, this is just a starting point. ------ Modern 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, STIR, an= d DRINKS. The work of this group is limited to specifying a solution for TNs and cove= rs any service that can be addressed using a TN. Expanding the work to oth= er identifiers is out of scope. Solutions and mechanisms created by the wo= rking 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 document that includes high level requi= rements and security/privacy considerationsbuilt on the work of IETF & the = ATIS/SIP Forum JTF, that included: o Call routing architecture o Inter-carrier NNI o Cryptographically-enabled Anti-spoofing (STIR) o Enhanced Calling Name (CNIT/CNAM) - A document describing the protocols to support enrollment proces= ses for existing and new TNs including any modifications to metadata relate= d to those TNs - A document describing protocol mechanisms for accessing contact = information associated with enrollments - A document describing protocol mechanisms for resolving informat= ion related to TNs - ________________________________ 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. _______________________________________________ Modern mailing list Modern@= ietf.org https://www.ietf.org/mailman/listinfo/mode= rn _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_D1134C4014B0A7jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I think the potential for a CNAM-like function enters into MODERN from= the WHOIS/WEIRDS sorts of requirements we imagine are associated with movi= ng the number registration process to the Internet. As you enroll in the sy= stem to get numbers, obviously some information about assignees is going to change hands, and somewhere there = will have to be control and accountability for who owns what numbers, and a= secure (privacy-protecting) way to query for that data. But more broadly, = since MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associa= ted with numbers including names - but crucially, TeRQ queries can and will= be launched at a time no call from that number is in progress.

So I'm not sure MODERN would conflict or even overlap, necessarily, wi= th efforts to define a header or other place to carry that naming informati= on in SIP as in the proposed CNIT charter. MODERN isn't going to define a S= IP header to carry CNAM data, and CNIT isn't going to define a way to query for CNAM-like data outside of a = SIP session in progress, from my reading of the draft charter. If that soun= ds reasonable, we could build language into both proposed charters that mak= es the distinction clear.

Jon Peterson
Neustar, Inc.

From: <DOLLY>, MARTIN C <<= a href=3D"mailto:md3135@att.com">md3135@att.com>
Date: Tuesday, February 24, 2015 at= 6:02 PM
To: Richard Shockey <richard@shockey.us>
Cc: "Holmes, David W [CTO]&quo= t; <David.Holmes@sprint.com>, "dispatch@ietf.org&qu= ot; <dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>, Jon Peterson <<= a href=3D"mailto:jon.peterson@neustar.biz">jon.peterson@neustar.biz>=
Subject: Re: [Modern] [dispatch] dr= aft charter

I support Richard on this 

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and 
Industry Alliances
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  

My concern here is charter overreach. I really want to keep CNAM+/= CNIT out of this.  IMHO that is a very separate and highly focused eff= ort to define both the modification of the SIP headers necessary to support= some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I=92m violently opposed to =93end world hunger=94 WG=92s. 

If registries can be used fine but I certainly want to see how this ca= n be accomplished in bi lateral agreements between consenting service provi= ders and work with CUA vendors on how the data is displayed aka Apple, Sams= ung, Microsoft in the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNI= T in enterprise and residential access markets is important but we all know= =93Money is the answer what is the  question ..=94  

I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and r= eport on the JTF on NNI. As you well know we have made considerable progres= s.

Last week I gave a talk on this to a panel that included many of our f= riends among the national regulators.  




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


From: "Holmes, David W [CTO]&q= uot; <David.Holmes@sprint.com= >
Date: Tuesday, February 24, 2015 at= 5:06 PM
To: "Peterson, Jon" <<= a href=3D"mailto:jon.peterson@neustar.biz">jon.peterson@neustar.biz>= , "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] draft charter=

Jon, =

=  

Thank= you for the work in assembling this draft of the charter for MODERN.

=  

We wo= uld like to suggest some minor clarifications to the bullets describing the= deliverables, to align them with the statement regarding flexibility to su= pport the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the all= ocation etc. activities, & it would not attempt to define the allocatio= n processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the = MODERN WG as appropriate.  These changes/additions are have been added= to your text inline below.

=  

We ar= e hoping that the MODERN session at IETF#92 will have remote access, to all= ow participation by those of us that cannot attend in person due to other c= ommitments that week.  

=  

Regar= ds,

=  

David= /Sprint

_____= _________________________________________________________________________

=  

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

&n= bsp;

At the = Dallas IETF meeting in March, we'd like to get together and talk about what= a working group for MODERN might look like. As an initial input to the dis= cussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own = BoF.

&n= bsp;

Comment= s are welcome, this is just a starting point.

&n= bsp;

------<= o:p>

&n= bsp;

Modern charter text:

 =

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

 =

The working group will d= efine a framework for the roles and functions involved in managing and reso= lving TNs in an IP environment. This includes a protocol mechanism for acqu= iring 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 reso= urce will be primary considerations.

 =

Additionally, the workin= g group will deliver a protocol mechanism for resolving TNs which will allo= w entities such as service providers, devices, and applications to access d= ata related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time applicat= ion performance, security and privacy are primary considerations.  The= working group will take into consideration existing IETF work including EN= UM, SPEERMINT, STIR, and DRINKS.

 =

The work of this group i= s limited to specifying a solution for TNs and covers any service that can = be addressed using a TN.  Expanding the work to other identifiers is o= ut of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The work group will deli= ver the following:

 =

- = ;         An architecture overview document that i= ncludes high level requirements and security/privacy considerations<= span style=3D"color:#1F497D">built on the work of IETF & the ATIS/SI= P Forum JTF, that included:

o   Call routing architecture

o   Inter-carrier NNI=

o   Cryptographically-enabled Anti-spoo= fing (STIR)

o   Enhanced Calling Name (CNIT/CNAM)

-&nbs= p;         A document describing the protocols to support enrollment processes for existing an= d new TNs including any modifications to metadata related to those TNs=

-&nbs= p;         A document describing protocol mechanism= s for accessing contact information associated with enrollments<= /span>

- =          A document describing protocol mechanisms for resolving information= related to TNs

=  

- &n= bsp;         <= /o:p>



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.
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
 --_000_D1134C4014B0A7jonpetersonneustarbiz_-- From nobody Wed Feb 25 10:55: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 9307D1A1B7D for ; Wed, 25 Feb 2015 10:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 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, 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 Nht1nF7E5ecc for ; Wed, 25 Feb 2015 10:55:20 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id DCEA71A1B11 for ; Wed, 25 Feb 2015 10:55:19 -0800 (PST) Received: (qmail 6200 invoked by uid 0); 25 Feb 2015 18:55:16 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 25 Feb 2015 18:55:16 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id wiuL1p00t1MNPNq01iuPo4; Wed, 25 Feb 2015 11:54:23 -0700 X-Authority-Analysis: v=2.1 cv=bJKFfpOZ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=gxZvrgisAAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=sjzYArKkxSwgTGd0bBcA:9 a=Yb7oC6_DpRCdxxZ3:21 a=tp1Sofds9zBsTQDX:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA: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:CC:To:From:Subject:Date; bh=Nu0VJE94YPTvWADy+NS92iUXwwW1pQ9uxtL6ZOtbA4c=; b=nFm+nVoyQ0Vpm9aZezLmwDVz91hxPO2XCFBD92vBX6PPJPfEknpMCrCCLbnNu5eVOEdUTitNPEOD1+58hOfhoBX9UFFA4pNlgGPaZo+BUjfuj2/pgBPeiYJH2EFhtx9o; Received: from [108.56.131.201] (port=57241 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQh6D-0003TY-0s; Wed, 25 Feb 2015 11:54:21 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 13:54:14 -0500 From: Richard Shockey To: "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [dispatch] draft charter 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: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 18:55:23 -0000 Humm.. Thanks. I=B9m not sure anyone has actually deployed a 50 character service. Does anyone know? =20 On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" wrote: >ITU-T Recommendation I.251.9 specifies: > >calling name: Information associated with a specific calling party >number. The maximum length is at least 15 characters and may be up to 50 >characters. The exact length, format and character set (e.g. T.51, T.52) >of the calling name to be delivered is a service provider option > >Therefore 15 would appear to be a deployment specific limitation. > >I believe QSIG defines 50 characters. > >The definition above also raises the question of character set. > >QSIG defines a number of different character sets. > > > >Regards > >Keith=20 > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Richard Shockey >> Sent: 25 February 2015 17:05 >> To: DOLLY, MARTIN C >> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org; >> modern@ietf.org >> Subject: Re: [dispatch] [Modern] draft charter >>=20 >>=20 >> Thanks Martin .. This is my very raw first cut at a charter. >> Its hopefully simple and straight forward. >>=20 >> Send me any edits etc. >>=20 >> ***** >>=20 >> CNIT Charter [Calling Name Identity Trust] >>=20 >>=20 >> WG Chairs TBD: >>=20 >>=20 >> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >> Characters of information associated with a specific E.164 >> calling party number in the Public Switched Telephone Network >> [PSTN]. In the PSTN this data is sent by the originating >> network only at the specific request of the terminating >> network via a SS7 Transaction Application Part [TCAP] >> response message. In the Session Initiation Protocol [SIP] >> this information can be inserted into the FROM: part of the >> originating INVITE message or by other means. >>=20 >>=20 >> As with the originating source telephone number, this data >> can be altered in transit creating a variety of malicious >> abuses similar to the ones identified by the IETF STIR working group. >>=20 >>=20 >> The purpose of the CNIT working group will be to define a >> data structure, a new SIP header or repurpose an existing SIP >> header to carry an advanced form of CNAM as well as >> information from a STIR Validation Authority. The purpose of >> this work is to present to the SIP called party trusted >> information from the calling party in order that the called >> party make a more reasoned and informed judgment on whether >> to accept the INVITE or not. >>=20 >>=20 >> The working group will not invalidate any existing SIP >> mechanism for anonymous calling. >>=20 >>=20 >> The working group will, to the best of its ability, reuse >> existing IETF protocols. >>=20 >>=20 >> Full Internationalization of the Calling Name Identity Trust >> data object(s) is a requirement. >>=20 >>=20 >> The working group will closely work with the IETF STIR working group >>=20 >>=20 >> The working group will immediately liaison with 3GPP SA-1 in >> order to coordinate efforts. >>=20 >>=20 >> The working group will coordinate with National Numbering >> Authorities and National Regulatory Authorities as needed. >>=20 >>=20 >> The working group will deliver the flowing. >>=20 >>=20 >> * A problem statement and requirements detailing the current >> deployment environment and situations that motivate work on >> Calling Name Identity Trust. >> * Define either a new SIP header or document a repurpose of >> an SIP existing header for Calling Name Identify Trust data * >> Define a data model for the Calling Name Identity Trust >> object (s) which may include various forms of multimedia data >> * Deliver an analysis of privacy implications of the proposed >> Calling Name Identity Trust mechanism. >>=20 >>=20 >>=20 >>=20 >> Milestones: >>=20 >>=20 >> - >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >> From: "DOLLY, MARTIN C" >> Date: Tuesday, February 24, 2015 at 9:02 PM >> To: Richard Shockey >> Cc: "Holmes, David W [CTO]" , >> "dispatch@ietf.org" , "modern@ietf.org" >> , "Peterson, Jon" >> Subject: Re: [Modern] [dispatch] draft charter >>=20 >>=20 >> I support Richard on this >>=20 >> Martin Dolly=20 >> Lead Member of Technical Staff >> Core & Gov't/Regulatory Standards >> AT&T Standards and >> Industry Alliances >> +1-609-903-3390 >>=20 >> Sent from my iPhone >>=20 >> On Feb 24, 2015, at 6:36 PM, Richard Shockey >> wrote: >>=20 >>=20 >>=20 >>=20 >> Excellent points David. >>=20 >> My concern here is charter overreach. I really want to >> keep CNAM+/CNIT out of this. IMHO that is a very separate >> and highly focused effort to define both the modification of >> the SIP headers necessary to support some enhanced calling >> party identification and a very limited effort to define the >> object and or the STIR validation data. >>=20 >> I'm violently opposed to "end world hunger" WG's. >>=20 >> If registries can be used fine but I certainly want to >> see how this can be accomplished in bi lateral agreements >> between consenting service providers and work with CUA >> vendors on how the data is displayed aka Apple, Samsung, >> Microsoft in the context of a formal liaison with 3GPP. >> Certainly the relevance of CNAM+/CNIT in enterprise and >> residential access markets is important but we all know >> "Money is the answer what is the question .." >>=20 >> I've asked for time in Dispatch to look at the >> CNAM/CNIT issue and report on the JTF on NNI. As you well >> know we have made considerable progress. >>=20 >> Last week I gave a talk on this to a panel that >> included many of our friends among the national regulators. >>=20 >> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>=20 >>=20 >>=20 >> >> From: "Holmes, David W [CTO]" >> Date: Tuesday, February 24, 2015 at 5:06 PM >> To: "Peterson, Jon" , >> "modern@ietf.org" >> Subject: Re: [Modern] draft charter >> >>=20 >>=20 >> Jon,=20 >>=20 >> =20 >>=20 >> Thank you for the work in assembling this draft of the >> charter for MODERN. >>=20 >> =20 >>=20 >> We would like to suggest some minor clarifications to >> the bullets describing the deliverables, to align them with >> the statement regarding flexibility to support the needs of >> different regulatory regimes, & thus to ensure that if quoted >> alone they are not taken out of context; i.e. the group >> product will be the protocols to support the allocation etc. >> activities, & it would not attempt to define the allocation >> processes. We also would like the charter to note the >> relevant work that has already been performed by both IETF & >> the ATIS/SIP Forum JTF, & incorporate that into the output >> from the MODERN WG as appropriate. These changes/additions >> are have been added to your text inline below. >>=20 >> =20 >>=20 >> We are hoping that the MODERN session at IETF#92 will >> have remote access, to allow participation by those of us >> that cannot attend in person due to other commitments that week. >>=20 >> =20 >>=20 >> Regards,=20 >>=20 >> =20 >>=20 >> David/Sprint=20 >>=20 >> >> ______________________________________________________________ >> ________________ >>=20 >> =20 >>=20 >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >> Of Peterson, Jon >> Sent: Wednesday, February 11, 2015 9:19 AM >> To: modern@ietf.org >> Subject: [Modern] draft charter >>=20 >> =20 >>=20 >> =20 >>=20 >> At the Dallas IETF meeting in March, we'd like to get >> together and talk about what a working group for MODERN might >> look like. As an initial input to the discussion, a few of us >> have put together a proposed charter. While the TeRQ work was >> positively evaluated in the DISPATCH process, we feel this is >> broader enough in scope to warrant its own BoF. >>=20 >> =20 >>=20 >> Comments are welcome, this is just a starting point. >>=20 >> =20 >>=20 >> ------ >>=20 >> =20 >>=20 >> Modern charter text: >>=20 >> =20 >>=20 >> 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. >>=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. 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. >>=20 >> =20 >>=20 >> 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, STIR, and DRINKS. >>=20 >> =20 >>=20 >> The work of this group is limited to specifying a >> solution for TNs and covers any service that can be addressed >> using a TN. Expanding the work to other identifiers is 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. >>=20 >> =20 >>=20 >> The work group will deliver the following: >>=20 >> =20 >>=20 >> - An architecture overview document that >> includes high level requirements and security/privacy >> considerationsbuilt on the work of IETF & the ATIS/SIP Forum >> JTF, that included: >>=20 >> o Call routing architecture >>=20 >> o Inter-carrier NNI >>=20 >> o Cryptographically-enabled Anti-spoofing (STIR) >>=20 >> o Enhanced Calling Name (CNIT/CNAM) >>=20 >> - A document describing the protocols to >> support enrollment processes for existing and new TNs >> including any modifications to metadata related to those TNs >>=20 >> - A document describing protocol mechanisms >> for accessing contact information associated with enrollments >>=20 >> - A document describing protocol mechanisms >> for resolving information related to TNs >>=20 >> =20 >>=20 >> - =20 >>=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. >> >> _______________________________________________ Modern >> mailing list Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >>=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 From nobody Wed Feb 25 11:16:52 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 E7D2C1A8758 for ; Wed, 25 Feb 2015 11:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, 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 FAZ-R0gUu08F for ; Wed, 25 Feb 2015 11:16:37 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 585851A7023 for ; Wed, 25 Feb 2015 11:16:22 -0800 (PST) Received: (qmail 24578 invoked by uid 0); 25 Feb 2015 19:16:22 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 25 Feb 2015 19:16:22 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id wps71p00N1MNPNq01psARL; Wed, 25 Feb 2015 18:52:21 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=hGBaWAWWAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=doUQZJtgAAAA:8 a=0Or7jusycULVaPx2pgEA:9 a=BhnP0eqWb-lopdWh:21 a=0NtdEuhFNy3hOqwa:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=6c8eWjDizDoA:10 a=NWVoK91CQyQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=hzi90bUycbL9tOCHrCUA:9 a=q_Qj5BrfrNCEuXYA:21 a=vm2NJDszbNg87r3L:21 a=ZamLWs1pq4GIX3x8:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=Byx/u0bs8RpuJQ+Wac5EmqwaQWgq9aSJFLuT9dqsixU=; b=i2YVBoug5cnhQ67/d6PqtpwiVQKt6Qq2mO8JCTfJnCiZcL1OeaMIh4WWkv4lvKms77Z1AHkm+aieDWij0+f18FEIjqPiLD9jY674HQr0gMlAmkzb3hUM3hzjdX7Nlr0g; Received: from [108.56.131.201] (port=57240 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQh44-0001fY-Ll; Wed, 25 Feb 2015 11:52:09 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 13:52:02 -0500 From: Richard Shockey To: "Peterson, Jon" , "DOLLY, MARTIN C" Message-ID: Thread-Topic: [Modern] [dispatch] draft charter References: <4DA2FD25-2B32-4812-A9FE-E8649BED9989@att.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507717128_833412" 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: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 19:16:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507717128_833412 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Excellent points. I agree. I don=B9t see a conflict here in the various Goals and Requirements between MODERN and CNIT. My concern was to make sure we could make some immediate progress by properly separating the work into digestible functions. I=B9m not concerned at this point on how CNIT / STIR validation data is acquired, much less authenticated during session establishment or by which SIP/IMS functional element, only what is the structure of that data and where in the SIP headers it resides. There is ample evidence this is getting attention in other SDO=B9s so the first order of business is making sure RAI defines what goes where properly= . =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: "Peterson, Jon" Date: Wednesday, February 25, 2015 at 1:14 PM To: "DOLLY, MARTIN C" , Richard Shockey Cc: "Holmes, David W [CTO]" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [Modern] [dispatch] draft charter I think the potential for a CNAM-like function enters into MODERN from the WHOIS/WEIRDS sorts of requirements we imagine are associated with moving th= e number registration process to the Internet. As you enroll in the system to get numbers, obviously some information about assignees is going to change hands, and somewhere there will have to be control and accountability for who owns what numbers, and a secure (privacy-protecting) way to query for that data. But more broadly, since MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associated with numbers including names - but crucially, TeRQ queries can and will be launched at a time no call from that number is in progress. So I'm not sure MODERN would conflict or even overlap, necessarily, with efforts to define a header or other place to carry that naming information in SIP as in the proposed CNIT charter. MODERN isn't going to define a SIP header to carry CNAM data, and CNIT isn't going to define a way to query fo= r CNAM-like data outside of a SIP session in progress, from my reading of the draft charter. If that sounds reasonable, we could build language into both proposed charters that makes the distinction clear. Jon Peterson Neustar, Inc. From: , MARTIN C Date: Tuesday, February 24, 2015 at 6:02 PM To: Richard Shockey Cc: "Holmes, David W [CTO]" , "dispatch@ietf.org" , "modern@ietf.org" , Jon Peterson Subject: Re: [Modern] [dispatch] draft charter I support Richard on this Martin Dolly=20 Lead Member of Technical Staff Core & Gov't/Regulatory Standards AT&T Standards and=20 Industry Alliances +1-609-903-3390 Sent from my iPhone On Feb 24, 2015, at 6:36 PM, Richard Shockey wrote: >=20 > Excellent points David. >=20 > My concern here is charter overreach. I really want to keep CNAM+/CNIT ou= t of > this. IMHO that is a very separate and highly focused effort to define b= oth > the modification of the SIP headers necessary to support some enhanced ca= lling > party identification and a very limited effort to define the object and o= r the > STIR validation data. >=20 > I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. >=20 > If registries can be used fine but I certainly want to see how this can b= e > accomplished in bi lateral agreements between consenting service provider= s and > work with CUA vendors on how the data is displayed aka Apple, Samsung, > Microsoft in the context of a formal liaison with 3GPP. Certainly the > relevance of CNAM+/CNIT in enterprise and residential access markets is > important but we all know =B3Money is the answer what is the question ..=B2 >=20 > I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and report= on > the JTF on NNI. As you well know we have made considerable progress. >=20 > Last week I gave a talk on this to a panel that included many of our frie= nds > among the national regulators. >=20 > http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >=20 >=20 >=20 > =8B=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "Holmes, David W [CTO]" > Date: Tuesday, February 24, 2015 at 5:06 PM > To: "Peterson, Jon" , "modern@ietf.org" > > Subject: Re: [Modern] draft charter >=20 > Jon,=20 > =20 > Thank you for the work in assembling this draft of the charter for MODERN= . > =20 > We would like to suggest some minor clarifications to the bullets describ= ing > the deliverables, to align them with the statement regarding flexibility = to > support the needs of different regulatory regimes, & thus to ensure that = if > quoted alone they are not taken out of context; i.e. the group product wi= ll be > the protocols to support the allocation etc. activities, & it would not > attempt to define the allocation processes. We also would like the chart= er to > note the relevant work that has already been performed by both IETF & the > ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG= as > appropriate. These changes/additions are have been added to your text in= line > below.=20 > =20 > We are hoping that the MODERN session at IETF#92 will have remote access,= to > allow participation by those of us that cannot attend in person due to ot= her > commitments that week. > =20 > Regards,=20 > =20 > David/Sprint=20 > _________________________________________________________________________= _____ > =20 > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, February 11, 2015 9:19 AM > To: modern@ietf.org > Subject: [Modern] draft charter > =20 > =20 > At the Dallas IETF meeting in March, we'd like to get together and talk a= bout > what a working group for MODERN might look like. As an initial input to t= he > discussion, a few of us have put together a proposed charter. While the T= eRQ > work was positively evaluated in the DISPATCH process, we feel this is br= oader > enough in scope to warrant its own BoF. > =20 > Comments are welcome, this is just a starting point. > =20 > ------ > =20 > Modern charter text: > =20 > The MODERN working group will define a set of Internet-based mechanisms f= or > 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 havi= ng an > association to a single service provider and a single application is brea= king > 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. > =20 > The working group will define a framework for the roles and functions inv= olved > in managing and resolving TNs in an IP environment. This includes a proto= col > mechanism for acquiring TNs, which will provide an enrollment process for= the > individuals and entities that use and manage TNs. TNs may either be manag= ed in > a hierarchical tree, or in a distributed peer-to-peer architecture. Priv= acy > of the enrollment data and security of the resource will be primary > considerations.=20 > =20 > Additionally, the working group will deliver a protocol mechanism for > resolving TNs which will allow entities such as service providers, device= s, > 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, STIR, an= d > DRINKS.=20 > =20 > The work of this group is limited to specifying a solution for TNs and co= vers > any service that can be addressed using a TN. Expanding the work to othe= r > identifiers is out of scope. Solutions and mechanisms created by the wor= king > group will be flexible enough to accommodate different policies, e.g., by > different regulatory agencies. > =20 > The work group will deliver the following: > =20 > - An architecture overview document that includes high level > requirements and security/privacy considerationsbuilt on the work of IETF= & > the ATIS/SIP Forum JTF, that included: >=20 > o Call routing architecture >=20 > o Inter-carrier NNI >=20 > o Cryptographically-enabled Anti-spoofing (STIR) >=20 > o Enhanced Calling Name (CNIT/CNAM) >=20 > - A document describing the protocols to support enrollment proce= sses > for existing and new TNs including any modifications to metadata related = to > those TNs >=20 > - A document describing protocol mechanisms for accessing contact > information associated with enrollments >=20 > - A document describing protocol mechanisms for resolving informa= tion > related to TNs >=20 > =20 >=20 > - =20 >=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 not = the > intended recipient, please contact the sender and delete all copies of th= e > message. > _______________________________________________ Modern mailing list > Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern --B_3507717128_833412 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Excellent= points.  I agree.

I don’t see a conflic= t here in the various Goals and Requirements between MODERN and CNIT.
<= div>
My concern was to make sure we could make some immediate = progress by properly separating the work into digestible functions.  I&= #8217;m not concerned at this point on how CNIT / STIR validation data is ac= quired, much less authenticated during session establishment or by which SIP= /IMS functional element, only what is the structure of that data and where i= n the SIP headers it resides. 

There is ample = evidence this is getting attention in other SDO’s so the first order o= f business is making sure RAI defines what goes where properly.
— 
Richard Shockey
Shockey = Consulting LLC
Chairman of the Board SIP Forum
www.shock= ey.us
www.sipforum.org
richard<at>shockey.us
=
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


<= div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:black= ; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in;= PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDE= R-RIGHT: medium none; PADDING-TOP: 3pt">From:= "Peterson, Jon" <jon.p= eterson@neustar.biz>
Date: = Wednesday, February 25, 2015 at 1:14 PM
To= : "DOLLY, MARTIN C" <md3135@att.c= om>, Richard Shockey <richard@= shockey.us>
Cc: "Holmes, Da= vid W [CTO]" <David.Holmes@sprin= t.com>, "dispatch@ietf.org" &l= t;dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [Modern] [dispatch] draft charter


I think the potential for a CNAM-like func= tion enters into MODERN from the WHOIS/WEIRDS sorts of requirements we imagi= ne are associated with moving the number registration process to the Interne= t. As you enroll in the system to get numbers, obviously some information about assignees is going to change hands, and somewhere there = will have to be control and accountability for who owns what numbers, and a = secure (privacy-protecting) way to query for that data. But more broadly, si= nce MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associa= ted with numbers including names - but crucially, TeRQ queries can and will = be launched at a time no call from that number is in progress.
So I'm not sure MODERN would conflict or even overlap, necessari= ly, with efforts to define a header or other place to carry that naming info= rmation in SIP as in the proposed CNIT charter. MODERN isn't going to define= a SIP header to carry CNAM data, and CNIT isn't going to define a way to query for CNAM-like data outside of a = SIP session in progress, from my reading of the draft charter. If that sound= s reasonable, we could build language into both proposed charters that makes= the distinction clear.

Jon Peterson
Neus= tar, Inc.

From: <D= OLLY>, MARTIN C <md3135@att.com>= ;
Date: Tuesday, February 24, 2015 = at 6:02 PM
To: Richard Shockey <= richard@shockey.us>
Cc: "Holmes, David W [CTO]" <David.Holmes@sprint.com>, "dispatch@ietf.org" <dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>
Subject: Re: [Modern] [dispatch] draft charter

I support Richard on this =

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory S= tandards
AT&T Standards and 
Industry Alliances=
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> wrote:


Excellent points David.  
=
My concern here is charter overreach. I really want to keep C= NAM+/CNIT out of this.  IMHO that is a very separate and highly focused= effort to define both the modification of the SIP headers necessary to supp= ort some enhanced calling party identification and a very limited effort to define the object and or the STIR validation = data.  

I’m violently opposed to “= end world hunger” WG’s. 

If regist= ries can be used fine but I certainly want to see how this can be accomplish= ed in bi lateral agreements between consenting service providers and work wi= th CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in= the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNIT in= enterprise and residential access markets is important but we all know R= 20;Money is the answer what is the  question ..”  

I’ve asked for time in Dispatch to look at the CNAM/CN= IT issue and report on the JTF on NNI. As you well know we have made conside= rable progress.

Last week I gave a talk on this to = a panel that included many of our friends among the national regulators. &nb= sp;

http://apps.fcc.gov/ecfs/document/view?id=3D60001033217



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


From: "Holmes, David W [CTO]" <Davi= d.Holmes@sprint.com>
Date: T= uesday, February 24, 2015 at 5:06 PM
To: <= /span>"Peterson, Jon" <jon.pete= rson@neustar.biz>, "modern@ietf.org<= /a>" <modern@ietf.org>
Subject: Re: [Modern] draft charter
=

Jon,

 

Thank you for the wor= k in assembling this draft of the charter for MODERN.

 

We would like to suggest some minor clarifica= tions to the bullets describing the deliverables, to align them with the sta= tement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out = of context; i.e. the group product will be the protocols to support the allo= cation etc. activities, & it would not attempt to define the allocation = processes.  We also would like the charter to note the relevant work that has already been performed by both IETF &am= p; the ATIS/SIP Forum JTF, & incorporate that into the output from the M= ODERN WG as appropriate.  These changes/additions are have been added t= o your text inline below.

 

We are hoping that the MODERN session at IETF= #92 will have remote access, to allow participation by those of us that cann= ot attend in person due to other commitments that week.  

 

Regards,

 

David/Sprint

________________________________________________________________________= ______

 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2= 015 9:19 AM
To: modern@ietf.org
Subject: [Modern] draft charter

 

 

At the Dallas IETF meeting in March, we'= d like to get together and talk about what a working group for MODERN might = look like. As an initial input to the discussion, a few of us have put toget= her a proposed charter. While the TeRQ work was positively evaluated in the DI= SPATCH process, we feel this is broader enough in scope to warrant its own B= oF.

 

Comments are welcome, this is just a starting p= oint.

 

------

 

<= p class=3D"MsoNormal">Modern charter text:

 =

The MODERN working= group will define a set of Internet-based mechanisms for the purposes of ma= naging and resolving telephone numbers (TNs) in an IP environment.  Exi= sting mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and ne= w 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 a= n organization will remain for some time. Devices, applications, and network= tools increasingly need to manage TNs, including requesting and acquiring T= N delegations from authorities.

 

The working group will define a framework for the roles and f= unctions involved in managing and resolving TNs in an IP environment. This i= ncludes a protocol mechanism for acquiring TNs, which will provide an enroll= ment 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 a= rchitecture.  Privacy of the enrollment data and security of the resour= ce will be primary considerations.

 =

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

 =

The wor= k of this group is limited to specifying a solution for TNs and covers any s= ervice that can be addressed using a TN.  Expanding the work to other i= dentifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different poli= cies, e.g., by different regulatory agencies.

 =

The wor= k group will deliver the following:

 

-      =     An architecture overview document that inc= ludes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Foru= m JTF, that included:

o   Call routing architecture =

o   Inter-carrier NNI

o   Cryptographically-enabled Anti-spoofi= ng (STIR)

oEnhanced Calling Name (CNIT/CNAM)

-=           A document describing the protocols to support enrollment processes for existing and = new TNs including any modifications to metadata related to those TNs

-&= nbsp;         A document describing protocol mechanisms = for accessing contact information associated with enrollments

- &nbs= p;        A document describing protocol mechanisms for resolving information r= elated to TNs

 

-       = ;    


<= br> 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 t= he intended recipient, please contact the sender and delete all copies of th= e message.
_______________________________________________ Modern mailing list Modern@ietf.org = https://www.ietf.org/mailman/listinfo/modern
___________________________________________= ____
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/d= ispatch
_______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org= /mailman/listinfo/modern --B_3507717128_833412-- From nobody Wed Feb 25 11:18: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 7F5081A701A; Wed, 25 Feb 2015 11:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PR_5EfPd7Ht8; Wed, 25 Feb 2015 11:17:57 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642BF1A700E; Wed, 25 Feb 2015 11:17:26 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-7e-54edcb6b2d46 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.8F.03307.B6BCDE45; Wed, 25 Feb 2015 14:17:31 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 25 Feb 2015 14:17:25 -0500 From: Hala Mowafy To: Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUSxyUNMhknct5ESAEGnIVCPAoZ0BvQVY Date: Wed, 25 Feb 2015 19:17:24 +0000 Message-ID: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPiG726bchBh8uy1pcnb2P0eL7hwVM FksnLWC1eNp4ltHi0IOn7BaX9jNZzPhh4MDu0fpsL6vHy/45jB5Llvxk8pj48QyzR9ul3cwB rFFcNimpOZllqUX6dglcGb2fZ7EVnMireHb3IGsD44uILkZODgkBE4mu87sYIWwxiQv31rN1 MXJxCAkcYZTo330FylnOKHH84zF2kCo2AR2JOX8/MoPYIgIaEi37ulhAipgF2pkkzk9ewgKS EBYwlHja/5kJoshIYuOkB8ww9ultS8FqWARUJfqnzmcFsXkF7CVOPZwGVM8BtE1f4uoDARCT U8BAYvNbsOMYgY77fmoN2ERmAXGJW0/mM0EcLSCxZM95ZghbVOLl43+sEDV6EjemTmGDsLUl li18zQyxSVDi5MwnLBMYRWchGTULScssJC2zkLQsYGRZxchRWpxalptuZLCJERhZxyTYdHcw 7nlpeYhRgINRiYfX4OXrECHWxLLiytxDjNIcLErivIseHAwREkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwNii+unRGc0uvfexT9Z8K9J7+v+lkVX28nJnlXk7V8i2GKatuNvoXbZXNNWTLWbx scxff0UK5q/vOVV3KW5DcULXyapN3FMrlotq8THVFpQuuD9VoSNQqPGQXUDw3F1r5efu4vLK 2j934au98w9Lzw9nPbPihaAZEz9/cHhCsl781mC55tlJfkosxRmJhlrMRcWJAIb53P6NAgAA Archived-At: Cc: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "cnit@ietf.org" , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 19:18:00 -0000 Not to my knowledge in North America.=20 Keith, I believe you are referencing an ISDN PBX standard so it may have be= en just within a business group - not inter-network?? Correct me if I'm wro= ng.=20 In our discussions at ATIS last year for CNAM in SIP headers someone brough= t up limitations on network elements handling more than 35 characters and t= hat is what we are planning to support with an objective of 60 ch in the fu= ture.=20 I think 35 is more than enough even for some of the longest, hyphenated nam= es.=20 Hala Mowafy ERICSSON=20 > On Feb 25, 2015, at 1:55 PM, Richard Shockey wrote: >=20 >=20 > Humm.. Thanks. >=20 > I=B9m not sure anyone has actually deployed a 50 character service. Does > anyone know? =20 >=20 >=20 >=20 > On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" > wrote: >=20 >> ITU-T Recommendation I.251.9 specifies: >>=20 >> calling name: Information associated with a specific calling party >> number. The maximum length is at least 15 characters and may be up to 50 >> characters. The exact length, format and character set (e.g. T.51, T.52) >> of the calling name to be delivered is a service provider option >>=20 >> Therefore 15 would appear to be a deployment specific limitation. >>=20 >> I believe QSIG defines 50 characters. >>=20 >> The definition above also raises the question of character set. >>=20 >> QSIG defines a number of different character sets. >>=20 >>=20 >>=20 >> Regards >>=20 >> Keith=20 >>=20 >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >>> Of Richard Shockey >>> Sent: 25 February 2015 17:05 >>> To: DOLLY, MARTIN C >>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org; >>> modern@ietf.org >>> Subject: Re: [dispatch] [Modern] draft charter >>>=20 >>>=20 >>> Thanks Martin .. This is my very raw first cut at a charter. >>> Its hopefully simple and straight forward. >>>=20 >>> Send me any edits etc. >>>=20 >>> ***** >>>=20 >>> CNIT Charter [Calling Name Identity Trust] >>>=20 >>>=20 >>> WG Chairs TBD: >>>=20 >>>=20 >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >>> Characters of information associated with a specific E.164 >>> calling party number in the Public Switched Telephone Network >>> [PSTN]. In the PSTN this data is sent by the originating >>> network only at the specific request of the terminating >>> network via a SS7 Transaction Application Part [TCAP] >>> response message. In the Session Initiation Protocol [SIP] >>> this information can be inserted into the FROM: part of the >>> originating INVITE message or by other means. >>>=20 >>>=20 >>> As with the originating source telephone number, this data >>> can be altered in transit creating a variety of malicious >>> abuses similar to the ones identified by the IETF STIR working group. >>>=20 >>>=20 >>> The purpose of the CNIT working group will be to define a >>> data structure, a new SIP header or repurpose an existing SIP >>> header to carry an advanced form of CNAM as well as >>> information from a STIR Validation Authority. The purpose of >>> this work is to present to the SIP called party trusted >>> information from the calling party in order that the called >>> party make a more reasoned and informed judgment on whether >>> to accept the INVITE or not. >>>=20 >>>=20 >>> The working group will not invalidate any existing SIP >>> mechanism for anonymous calling. >>>=20 >>>=20 >>> The working group will, to the best of its ability, reuse >>> existing IETF protocols. >>>=20 >>>=20 >>> Full Internationalization of the Calling Name Identity Trust >>> data object(s) is a requirement. >>>=20 >>>=20 >>> The working group will closely work with the IETF STIR working group >>>=20 >>>=20 >>> The working group will immediately liaison with 3GPP SA-1 in >>> order to coordinate efforts. >>>=20 >>>=20 >>> The working group will coordinate with National Numbering >>> Authorities and National Regulatory Authorities as needed. >>>=20 >>>=20 >>> The working group will deliver the flowing. >>>=20 >>>=20 >>> * A problem statement and requirements detailing the current >>> deployment environment and situations that motivate work on >>> Calling Name Identity Trust. >>> * Define either a new SIP header or document a repurpose of >>> an SIP existing header for Calling Name Identify Trust data * >>> Define a data model for the Calling Name Identity Trust >>> object (s) which may include various forms of multimedia data >>> * Deliver an analysis of privacy implications of the proposed >>> Calling Name Identity Trust mechanism. >>>=20 >>>=20 >>>=20 >>>=20 >>> Milestones: >>>=20 >>>=20 >>> - >>> Richard Shockey >>> Shockey Consulting LLC >>> Chairman of the Board SIP Forum >>> www.shockey.us >>> www.sipforum.org >>> richardshockey.us >>> Skype-Linkedin-Facebook rshockey101 >>> PSTN +1 703-593-2683 >>>=20 >>>=20 >>> From: "DOLLY, MARTIN C" >>> Date: Tuesday, February 24, 2015 at 9:02 PM >>> To: Richard Shockey >>> Cc: "Holmes, David W [CTO]" , >>> "dispatch@ietf.org" , "modern@ietf.org" >>> , "Peterson, Jon" >>> Subject: Re: [Modern] [dispatch] draft charter >>>=20 >>>=20 >>> I support Richard on this >>>=20 >>> Martin Dolly=20 >>> Lead Member of Technical Staff >>> Core & Gov't/Regulatory Standards >>> AT&T Standards and >>> Industry Alliances >>> +1-609-903-3390 >>>=20 >>> Sent from my iPhone >>>=20 >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>> wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> Excellent points David. >>>=20 >>> My concern here is charter overreach. I really want to >>> keep CNAM+/CNIT out of this. IMHO that is a very separate >>> and highly focused effort to define both the modification of >>> the SIP headers necessary to support some enhanced calling >>> party identification and a very limited effort to define the >>> object and or the STIR validation data. >>>=20 >>> I'm violently opposed to "end world hunger" WG's. >>>=20 >>> If registries can be used fine but I certainly want to >>> see how this can be accomplished in bi lateral agreements >>> between consenting service providers and work with CUA >>> vendors on how the data is displayed aka Apple, Samsung, >>> Microsoft in the context of a formal liaison with 3GPP. >>> Certainly the relevance of CNAM+/CNIT in enterprise and >>> residential access markets is important but we all know >>> "Money is the answer what is the question .." >>>=20 >>> I've asked for time in Dispatch to look at the >>> CNAM/CNIT issue and report on the JTF on NNI. As you well >>> know we have made considerable progress. >>>=20 >>> Last week I gave a talk on this to a panel that >>> included many of our friends among the national regulators. >>>=20 >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>=20 >>>=20 >>>=20 >>> =20 >>> From: "Holmes, David W [CTO]" >>> Date: Tuesday, February 24, 2015 at 5:06 PM >>> To: "Peterson, Jon" , >>> "modern@ietf.org" >>> Subject: Re: [Modern] draft charter >>> =20 >>>=20 >>>=20 >>> Jon,=20 >>>=20 >>> =20 >>>=20 >>> Thank you for the work in assembling this draft of the >>> charter for MODERN. >>>=20 >>> =20 >>>=20 >>> We would like to suggest some minor clarifications to >>> the bullets describing the deliverables, to align them with >>> the statement regarding flexibility to support the needs of >>> different regulatory regimes, & thus to ensure that if quoted >>> alone they are not taken out of context; i.e. the group >>> product will be the protocols to support the allocation etc. >>> activities, & it would not attempt to define the allocation >>> processes. We also would like the charter to note the >>> relevant work that has already been performed by both IETF & >>> the ATIS/SIP Forum JTF, & incorporate that into the output >>> from the MODERN WG as appropriate. These changes/additions >>> are have been added to your text inline below. >>>=20 >>> =20 >>>=20 >>> We are hoping that the MODERN session at IETF#92 will >>> have remote access, to allow participation by those of us >>> that cannot attend in person due to other commitments that week. >>>=20 >>> =20 >>>=20 >>> Regards,=20 >>>=20 >>> =20 >>>=20 >>> David/Sprint=20 >>>=20 >>> =20 >>> ______________________________________________________________ >>> ________________ >>>=20 >>> =20 >>>=20 >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>> Of Peterson, Jon >>> Sent: Wednesday, February 11, 2015 9:19 AM >>> To: modern@ietf.org >>> Subject: [Modern] draft charter >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> At the Dallas IETF meeting in March, we'd like to get >>> together and talk about what a working group for MODERN might >>> look like. As an initial input to the discussion, a few of us >>> have put together a proposed charter. While the TeRQ work was >>> positively evaluated in the DISPATCH process, we feel this is >>> broader enough in scope to warrant its own BoF. >>>=20 >>> =20 >>>=20 >>> Comments are welcome, this is just a starting point. >>>=20 >>> =20 >>>=20 >>> ------ >>>=20 >>> =20 >>>=20 >>> Modern charter text: >>>=20 >>> =20 >>>=20 >>> 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. >>>=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. 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. >>>=20 >>> =20 >>>=20 >>> 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, STIR, and DRINKS. >>>=20 >>> =20 >>>=20 >>> The work of this group is limited to specifying a >>> solution for TNs and covers any service that can be addressed >>> using a TN. Expanding the work to other identifiers is 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. >>>=20 >>> =20 >>>=20 >>> The work group will deliver the following: >>>=20 >>> =20 >>>=20 >>> - An architecture overview document that >>> includes high level requirements and security/privacy >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum >>> JTF, that included: >>>=20 >>> o Call routing architecture >>>=20 >>> o Inter-carrier NNI >>>=20 >>> o Cryptographically-enabled Anti-spoofing (STIR) >>>=20 >>> o Enhanced Calling Name (CNIT/CNAM) >>>=20 >>> - A document describing the protocols to >>> support enrollment processes for existing and new TNs >>> including any modifications to metadata related to those TNs >>>=20 >>> - A document describing protocol mechanisms >>> for accessing contact information associated with enrollments >>>=20 >>> - A document describing protocol mechanisms >>> for resolving information related to TNs >>>=20 >>> =20 >>>=20 >>> - =20 >>>=20 >>>=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 >>> _______________________________________________ Modern >>> mailing list Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> =20 >>>=20 >>> _______________________________________________ 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 >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Wed Feb 25 11:40: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 835C01A8760; Wed, 25 Feb 2015 11:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_28=0.6, 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 YsKmhoxXX_0D; Wed, 25 Feb 2015 11:40:46 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC071A1B74; Wed, 25 Feb 2015 11:40:44 -0800 (PST) Message-ID: From: Henning Schulzrinne To: Hala Mowafy , Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUSyiwl3dyMGXLUa6M1mHs23DAJ0CENYA//+xAOk= Date: Wed, 25 Feb 2015 19:40:41 +0000 References: , <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> In-Reply-To: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> 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: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "cnit@ietf.org" , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 19:40:50 -0000 I wonder if we're just talking about an unstructured string, or rather some= thing more structured, e.g., to be able to distinguish the name of the call= er from the organization, such as=0A= =0A= name=3DHala Mowafy / ou=3DEricsson=0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Hala Mowafy [hala.mowafy@er= icsson.com]=0A= Sent: Wednesday, February 25, 2015 2:17 PM=0A= To: Richard Shockey=0A= Cc: Holmes, David W [CTO]; dispatch@ietf.org; cnit@ietf.org; DRAGE, Keith (= Keith); modern@ietf.org; DOLLY, MARTIN C=0A= Subject: Re: [cnit] [Modern] [dispatch] draft charter=0A= =0A= Not to my knowledge in North America.=0A= Keith, I believe you are referencing an ISDN PBX standard so it may have be= en just within a business group - not inter-network?? Correct me if I'm wro= ng.=0A= =0A= In our discussions at ATIS last year for CNAM in SIP headers someone brough= t up limitations on network elements handling more than 35 characters and t= hat is what we are planning to support with an objective of 60 ch in the fu= ture.=0A= I think 35 is more than enough even for some of the longest, hyphenated nam= es.=0A= =0A= Hala Mowafy=0A= ERICSSON=0A= =0A= > On Feb 25, 2015, at 1:55 PM, Richard Shockey wrote:= =0A= >=0A= >=0A= > Humm.. Thanks.=0A= >=0A= > I=B9m not sure anyone has actually deployed a 50 character service. Does= =0A= > anyone know?=0A= >=0A= >=0A= >=0A= > On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)"=0A= > wrote:=0A= >=0A= >> ITU-T Recommendation I.251.9 specifies:=0A= >>=0A= >> calling name: Information associated with a specific calling party=0A= >> number. The maximum length is at least 15 characters and may be up to 50= =0A= >> characters. The exact length, format and character set (e.g. T.51, T.52)= =0A= >> of the calling name to be delivered is a service provider option=0A= >>=0A= >> Therefore 15 would appear to be a deployment specific limitation.=0A= >>=0A= >> I believe QSIG defines 50 characters.=0A= >>=0A= >> The definition above also raises the question of character set.=0A= >>=0A= >> QSIG defines a number of different character sets.=0A= >>=0A= >>=0A= >>=0A= >> Regards=0A= >>=0A= >> Keith=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=0A= >>> Of Richard Shockey=0A= >>> Sent: 25 February 2015 17:05=0A= >>> To: DOLLY, MARTIN C=0A= >>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=0A= >>> modern@ietf.org=0A= >>> Subject: Re: [dispatch] [Modern] draft charter=0A= >>>=0A= >>>=0A= >>> Thanks Martin .. This is my very raw first cut at a charter.=0A= >>> Its hopefully simple and straight forward.=0A= >>>=0A= >>> Send me any edits etc.=0A= >>>=0A= >>> *****=0A= >>>=0A= >>> CNIT Charter [Calling Name Identity Trust]=0A= >>>=0A= >>>=0A= >>> WG Chairs TBD:=0A= >>>=0A= >>>=0A= >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII=0A= >>> Characters of information associated with a specific E.164=0A= >>> calling party number in the Public Switched Telephone Network=0A= >>> [PSTN]. In the PSTN this data is sent by the originating=0A= >>> network only at the specific request of the terminating=0A= >>> network via a SS7 Transaction Application Part [TCAP]=0A= >>> response message. In the Session Initiation Protocol [SIP]=0A= >>> this information can be inserted into the FROM: part of the=0A= >>> originating INVITE message or by other means.=0A= >>>=0A= >>>=0A= >>> As with the originating source telephone number, this data=0A= >>> can be altered in transit creating a variety of malicious=0A= >>> abuses similar to the ones identified by the IETF STIR working group.= =0A= >>>=0A= >>>=0A= >>> The purpose of the CNIT working group will be to define a=0A= >>> data structure, a new SIP header or repurpose an existing SIP=0A= >>> header to carry an advanced form of CNAM as well as=0A= >>> information from a STIR Validation Authority. The purpose of=0A= >>> this work is to present to the SIP called party trusted=0A= >>> information from the calling party in order that the called=0A= >>> party make a more reasoned and informed judgment on whether=0A= >>> to accept the INVITE or not.=0A= >>>=0A= >>>=0A= >>> The working group will not invalidate any existing SIP=0A= >>> mechanism for anonymous calling.=0A= >>>=0A= >>>=0A= >>> The working group will, to the best of its ability, reuse=0A= >>> existing IETF protocols.=0A= >>>=0A= >>>=0A= >>> Full Internationalization of the Calling Name Identity Trust=0A= >>> data object(s) is a requirement.=0A= >>>=0A= >>>=0A= >>> The working group will closely work with the IETF STIR working group=0A= >>>=0A= >>>=0A= >>> The working group will immediately liaison with 3GPP SA-1 in=0A= >>> order to coordinate efforts.=0A= >>>=0A= >>>=0A= >>> The working group will coordinate with National Numbering=0A= >>> Authorities and National Regulatory Authorities as needed.=0A= >>>=0A= >>>=0A= >>> The working group will deliver the flowing.=0A= >>>=0A= >>>=0A= >>> * A problem statement and requirements detailing the current=0A= >>> deployment environment and situations that motivate work on=0A= >>> Calling Name Identity Trust.=0A= >>> * Define either a new SIP header or document a repurpose of=0A= >>> an SIP existing header for Calling Name Identify Trust data *=0A= >>> Define a data model for the Calling Name Identity Trust=0A= >>> object (s) which may include various forms of multimedia data=0A= >>> * Deliver an analysis of privacy implications of the proposed=0A= >>> Calling Name Identity Trust mechanism.=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> Milestones:=0A= >>>=0A= >>>=0A= >>> -=0A= >>> Richard Shockey=0A= >>> Shockey Consulting LLC=0A= >>> Chairman of the Board SIP Forum=0A= >>> www.shockey.us=0A= >>> www.sipforum.org=0A= >>> richardshockey.us=0A= >>> Skype-Linkedin-Facebook rshockey101=0A= >>> PSTN +1 703-593-2683=0A= >>>=0A= >>>=0A= >>> From: "DOLLY, MARTIN C" =0A= >>> Date: Tuesday, February 24, 2015 at 9:02 PM=0A= >>> To: Richard Shockey =0A= >>> Cc: "Holmes, David W [CTO]" ,=0A= >>> "dispatch@ietf.org" , "modern@ietf.org"=0A= >>> , "Peterson, Jon" =0A= >>> Subject: Re: [Modern] [dispatch] draft charter=0A= >>>=0A= >>>=0A= >>> I support Richard on this=0A= >>>=0A= >>> Martin Dolly=0A= >>> Lead Member of Technical Staff=0A= >>> Core & Gov't/Regulatory Standards=0A= >>> AT&T Standards and=0A= >>> Industry Alliances=0A= >>> +1-609-903-3390=0A= >>>=0A= >>> Sent from my iPhone=0A= >>>=0A= >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey=0A= >>> wrote:=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> Excellent points David.=0A= >>>=0A= >>> My concern here is charter overreach. I really want to=0A= >>> keep CNAM+/CNIT out of this. IMHO that is a very separate=0A= >>> and highly focused effort to define both the modification of=0A= >>> the SIP headers necessary to support some enhanced calling=0A= >>> party identification and a very limited effort to define the=0A= >>> object and or the STIR validation data.=0A= >>>=0A= >>> I'm violently opposed to "end world hunger" WG's.=0A= >>>=0A= >>> If registries can be used fine but I certainly want to=0A= >>> see how this can be accomplished in bi lateral agreements=0A= >>> between consenting service providers and work with CUA=0A= >>> vendors on how the data is displayed aka Apple, Samsung,=0A= >>> Microsoft in the context of a formal liaison with 3GPP.=0A= >>> Certainly the relevance of CNAM+/CNIT in enterprise and=0A= >>> residential access markets is important but we all know=0A= >>> "Money is the answer what is the question .."=0A= >>>=0A= >>> I've asked for time in Dispatch to look at the=0A= >>> CNAM/CNIT issue and report on the JTF on NNI. As you well=0A= >>> know we have made considerable progress.=0A= >>>=0A= >>> Last week I gave a talk on this to a panel that=0A= >>> included many of our friends among the national regulators.=0A= >>>=0A= >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> From: "Holmes, David W [CTO]" =0A= >>> Date: Tuesday, February 24, 2015 at 5:06 PM=0A= >>> To: "Peterson, Jon" ,=0A= >>> "modern@ietf.org" =0A= >>> Subject: Re: [Modern] draft charter=0A= >>>=0A= >>>=0A= >>>=0A= >>> Jon,=0A= >>>=0A= >>>=0A= >>>=0A= >>> Thank you for the work in assembling this draft of the=0A= >>> charter for MODERN.=0A= >>>=0A= >>>=0A= >>>=0A= >>> We would like to suggest some minor clarifications to=0A= >>> the bullets describing the deliverables, to align them with=0A= >>> the statement regarding flexibility to support the needs of=0A= >>> different regulatory regimes, & thus to ensure that if quoted=0A= >>> alone they are not taken out of context; i.e. the group=0A= >>> product will be the protocols to support the allocation etc.=0A= >>> activities, & it would not attempt to define the allocation=0A= >>> processes. We also would like the charter to note the=0A= >>> relevant work that has already been performed by both IETF &=0A= >>> the ATIS/SIP Forum JTF, & incorporate that into the output=0A= >>> from the MODERN WG as appropriate. These changes/additions=0A= >>> are have been added to your text inline below.=0A= >>>=0A= >>>=0A= >>>=0A= >>> We are hoping that the MODERN session at IETF#92 will=0A= >>> have remote access, to allow participation by those of us=0A= >>> that cannot attend in person due to other commitments that week.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Regards,=0A= >>>=0A= >>>=0A= >>>=0A= >>> David/Sprint=0A= >>>=0A= >>>=0A= >>> ______________________________________________________________=0A= >>> ________________=0A= >>>=0A= >>>=0A= >>>=0A= >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf=0A= >>> Of Peterson, Jon=0A= >>> Sent: Wednesday, February 11, 2015 9:19 AM=0A= >>> To: modern@ietf.org=0A= >>> Subject: [Modern] draft charter=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> At the Dallas IETF meeting in March, we'd like to get=0A= >>> together and talk about what a working group for MODERN might=0A= >>> look like. As an initial input to the discussion, a few of us=0A= >>> have put together a proposed charter. While the TeRQ work was=0A= >>> positively evaluated in the DISPATCH process, we feel this is=0A= >>> broader enough in scope to warrant its own BoF.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Comments are welcome, this is just a starting point.=0A= >>>=0A= >>>=0A= >>>=0A= >>> ------=0A= >>>=0A= >>>=0A= >>>=0A= >>> Modern charter text:=0A= >>>=0A= >>>=0A= >>>=0A= >>> The MODERN working group will define a set of=0A= >>> Internet-based mechanisms for the purposes of managing and=0A= >>> resolving telephone numbers (TNs) in an IP environment.=0A= >>> Existing mechanisms for these purposes face obsolescence as=0A= >>> the voice communications infrastructure evolves to IP=0A= >>> technology and new applications for TNs become possible. The=0A= >>> traditional model of a TN having an association to a single=0A= >>> service provider and a single application is breaking down.=0A= >>> Its use as a network locator is going away, but its use as an=0A= >>> identifier for an individual or an organization will remain=0A= >>> for some time. Devices, applications, and network tools=0A= >>> increasingly need to manage TNs, including requesting and=0A= >>> acquiring TN delegations from authorities.=0A= >>>=0A= >>>=0A= >>>=0A= >>> The working group will define a framework for the roles=0A= >>> and functions involved in managing and resolving TNs in an IP=0A= >>> environment. This includes a protocol mechanism for acquiring=0A= >>> TNs, which will provide an enrollment process for the=0A= >>> individuals and entities that use and manage TNs. TNs may=0A= >>> either be managed in a hierarchical tree, or in a distributed=0A= >>> peer-to-peer architecture. Privacy of the enrollment data=0A= >>> and security of the resource will be primary considerations.=0A= >>>=0A= >>>=0A= >>>=0A= >>> Additionally, the working group will deliver a protocol=0A= >>> mechanism for resolving TNs which will allow entities such as=0A= >>> service providers, devices, and applications to access data=0A= >>> related to TNs, possibly including caller name data (CNAM).=0A= >>> Maintaining reliability, real time application performance,=0A= >>> security and privacy are primary considerations. The working=0A= >>> group will take into consideration existing IETF work=0A= >>> including ENUM, SPEERMINT, STIR, and DRINKS.=0A= >>>=0A= >>>=0A= >>>=0A= >>> The work of this group is limited to specifying a=0A= >>> solution for TNs and covers any service that can be addressed=0A= >>> using a TN. Expanding the work to other identifiers is out=0A= >>> of scope. Solutions and mechanisms created by the working=0A= >>> group will be flexible enough to accommodate different=0A= >>> policies, e.g., by different regulatory agencies.=0A= >>>=0A= >>>=0A= >>>=0A= >>> The work group will deliver the following:=0A= >>>=0A= >>>=0A= >>>=0A= >>> - An architecture overview document that=0A= >>> includes high level requirements and security/privacy=0A= >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum=0A= >>> JTF, that included:=0A= >>>=0A= >>> o Call routing architecture=0A= >>>=0A= >>> o Inter-carrier NNI=0A= >>>=0A= >>> o Cryptographically-enabled Anti-spoofing (STIR)=0A= >>>=0A= >>> o Enhanced Calling Name (CNIT/CNAM)=0A= >>>=0A= >>> - A document describing the protocols to=0A= >>> support enrollment processes for existing and new TNs=0A= >>> including any modifications to metadata related to those TNs=0A= >>>=0A= >>> - A document describing protocol mechanisms=0A= >>> for accessing contact information associated with enrollments=0A= >>>=0A= >>> - A document describing protocol mechanisms=0A= >>> for resolving information related to TNs=0A= >>>=0A= >>>=0A= >>>=0A= >>> -=0A= >>>=0A= >>>=0A= >>> ________________________________=0A= >>>=0A= >>>=0A= >>> This e-mail may contain Sprint proprietary information=0A= >>> intended for the sole use of the recipient(s). Any use by=0A= >>> others is prohibited. If you are not the intended recipient,=0A= >>> please contact the sender and delete all copies of the message.=0A= >>>=0A= >>> _______________________________________________ Modern=0A= >>> mailing list Modern@ietf.org =0A= >>> https://www.ietf.org/mailman/listinfo/modern=0A= >>>=0A= >>> _______________________________________________=0A= >>> dispatch mailing list=0A= >>> dispatch@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>>=0A= >>>=0A= >>> _______________________________________________ Modern=0A= >>> mailing list Modern@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/modern=0A= >> _______________________________________________=0A= >> Modern mailing list=0A= >> Modern@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/modern=0A= >=0A= >=0A= > _______________________________________________=0A= > Modern mailing list=0A= > Modern@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/modern=0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= From nobody Wed Feb 25 11:59:49 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 B429A1A1B71 for ; Wed, 25 Feb 2015 11:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.383 X-Spam-Level: * X-Spam-Status: No, score=1.383 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, J_CHICKENPOX_28=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 OHp-K6WRgZna for ; Wed, 25 Feb 2015 11:59:36 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id E43401A1EF6 for ; Wed, 25 Feb 2015 11:59:35 -0800 (PST) Received: (qmail 2453 invoked by uid 0); 25 Feb 2015 19:59:27 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 25 Feb 2015 19:59:27 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id wqxK1p00h1MNPNq01qyRCF; Wed, 25 Feb 2015 19:58:26 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=XW0vzNQbW2AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=gxZvrgisAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=cMayxExP5pIt7mkmhfUA:9 a=uswajqyHEnEVjzuM:21 a=5zZdin1h4iD8l6pQ:21 a=Spabb166XhwA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA: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=Kyd+iYNhB7Zsk2l+Ew7Yd9qqlZ7KcLkHsitC3EmFup0=; b=FJt1Q9oNba2UN5iJXDersm0jJAiL+2LW2+jofo5Zd9pe0rW4ldIBfBbRAPOIAarrRqN6ChX9FiM34EQwTvwHH81SFQvFmYSA77HNzhU06lldWGcwJ+4ZkZV78KEr1as7; Received: from [108.56.131.201] (port=58463 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YQi5r-00037x-P3; Wed, 25 Feb 2015 12:58:03 -0700 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 25 Feb 2015 14:57:57 -0500 From: Richard Shockey To: Henning Schulzrinne , Hala Mowafy Message-ID: Thread-Topic: [Modern] [dispatch] draft charter References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" 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: "Holmes, David W \[CTO\]" , "dispatch@ietf.org" , "cnit@ietf.org" , "DRAGE, Keith \(Keith\)" , "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 19:59:38 -0000 Structured. IMHO the easiest path to success would be repurpose the CALL-INFO header with a RFC 7095 (json vcard) object. The terminating CSCF would also insert the STIR validation data (what ever that was) CUA=A1=AFs could then have customized settings like we have ring tones =A1=AEWARNING WARNING WILL ROBINSON=A1=AF =A1=AEDIVE DIVE DIVE=A1=AF Klaxon, Sirens etc. We might be able to get this ready before iOS 12. On 2/25/15, 2:40 PM, "Henning Schulzrinne" wrote: >I wonder if we're just talking about an unstructured string, or rather >something more structured, e.g., to be able to distinguish the name of >the caller from the organization, such as > >name=3DHala Mowafy / ou=3DEricsson > >________________________________________ >From: cnit [cnit-bounces@ietf.org] on behalf of Hala Mowafy >[hala.mowafy@ericsson.com] >Sent: Wednesday, February 25, 2015 2:17 PM >To: Richard Shockey >Cc: Holmes, David W [CTO]; dispatch@ietf.org; cnit@ietf.org; DRAGE, Keith >(Keith); modern@ietf.org; DOLLY, MARTIN C >Subject: Re: [cnit] [Modern] [dispatch] draft charter > >Not to my knowledge in North America. >Keith, I believe you are referencing an ISDN PBX standard so it may have >been just within a business group - not inter-network?? Correct me if I'm >wrong. > >In our discussions at ATIS last year for CNAM in SIP headers someone >brought up limitations on network elements handling more than 35 >characters and that is what we are planning to support with an objective >of 60 ch in the future. >I think 35 is more than enough even for some of the longest, hyphenated >names. > >Hala Mowafy >ERICSSON > >> On Feb 25, 2015, at 1:55 PM, Richard Shockey wrote: >> >> >> Humm.. Thanks. >> >> I=A9=F6m not sure anyone has actually deployed a 50 character service. Does >> anyone know? >> >> >> >> On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" >> wrote: >> >>> ITU-T Recommendation I.251.9 specifies: >>> >>> calling name: Information associated with a specific calling party >>> number. The maximum length is at least 15 characters and may be up to >>>50 >>> characters. The exact length, format and character set (e.g. T.51, >>>T.52) >>> of the calling name to be delivered is a service provider option >>> >>> Therefore 15 would appear to be a deployment specific limitation. >>> >>> I believe QSIG defines 50 characters. >>> >>> The definition above also raises the question of character set. >>> >>> QSIG defines a number of different character sets. >>> >>> >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >>>> Of Richard Shockey >>>> Sent: 25 February 2015 17:05 >>>> To: DOLLY, MARTIN C >>>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org; >>>> modern@ietf.org >>>> Subject: Re: [dispatch] [Modern] draft charter >>>> >>>> >>>> Thanks Martin .. This is my very raw first cut at a charter. >>>> Its hopefully simple and straight forward. >>>> >>>> Send me any edits etc. >>>> >>>> ***** >>>> >>>> CNIT Charter [Calling Name Identity Trust] >>>> >>>> >>>> WG Chairs TBD: >>>> >>>> >>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >>>> Characters of information associated with a specific E.164 >>>> calling party number in the Public Switched Telephone Network >>>> [PSTN]. In the PSTN this data is sent by the originating >>>> network only at the specific request of the terminating >>>> network via a SS7 Transaction Application Part [TCAP] >>>> response message. In the Session Initiation Protocol [SIP] >>>> this information can be inserted into the FROM: part of the >>>> originating INVITE message or by other means. >>>> >>>> >>>> As with the originating source telephone number, this data >>>> can be altered in transit creating a variety of malicious >>>> abuses similar to the ones identified by the IETF STIR working group. >>>> >>>> >>>> The purpose of the CNIT working group will be to define a >>>> data structure, a new SIP header or repurpose an existing SIP >>>> header to carry an advanced form of CNAM as well as >>>> information from a STIR Validation Authority. The purpose of >>>> this work is to present to the SIP called party trusted >>>> information from the calling party in order that the called >>>> party make a more reasoned and informed judgment on whether >>>> to accept the INVITE or not. >>>> >>>> >>>> The working group will not invalidate any existing SIP >>>> mechanism for anonymous calling. >>>> >>>> >>>> The working group will, to the best of its ability, reuse >>>> existing IETF protocols. >>>> >>>> >>>> Full Internationalization of the Calling Name Identity Trust >>>> data object(s) is a requirement. >>>> >>>> >>>> The working group will closely work with the IETF STIR working group >>>> >>>> >>>> The working group will immediately liaison with 3GPP SA-1 in >>>> order to coordinate efforts. >>>> >>>> >>>> The working group will coordinate with National Numbering >>>> Authorities and National Regulatory Authorities as needed. >>>> >>>> >>>> The working group will deliver the flowing. >>>> >>>> >>>> * A problem statement and requirements detailing the current >>>> deployment environment and situations that motivate work on >>>> Calling Name Identity Trust. >>>> * Define either a new SIP header or document a repurpose of >>>> an SIP existing header for Calling Name Identify Trust data * >>>> Define a data model for the Calling Name Identity Trust >>>> object (s) which may include various forms of multimedia data >>>> * Deliver an analysis of privacy implications of the proposed >>>> Calling Name Identity Trust mechanism. >>>> >>>> >>>> >>>> >>>> Milestones: >>>> >>>> >>>> - >>>> Richard Shockey >>>> Shockey Consulting LLC >>>> Chairman of the Board SIP Forum >>>> www.shockey.us >>>> www.sipforum.org >>>> richardshockey.us >>>> Skype-Linkedin-Facebook rshockey101 >>>> PSTN +1 703-593-2683 >>>> >>>> >>>> From: "DOLLY, MARTIN C" >>>> Date: Tuesday, February 24, 2015 at 9:02 PM >>>> To: Richard Shockey >>>> Cc: "Holmes, David W [CTO]" , >>>> "dispatch@ietf.org" , "modern@ietf.org" >>>> , "Peterson, Jon" >>>> Subject: Re: [Modern] [dispatch] draft charter >>>> >>>> >>>> I support Richard on this >>>> >>>> Martin Dolly >>>> Lead Member of Technical Staff >>>> Core & Gov't/Regulatory Standards >>>> AT&T Standards and >>>> Industry Alliances >>>> +1-609-903-3390 >>>> >>>> Sent from my iPhone >>>> >>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>>> wrote: >>>> >>>> >>>> >>>> >>>> Excellent points David. >>>> >>>> My concern here is charter overreach. I really want to >>>> keep CNAM+/CNIT out of this. IMHO that is a very separate >>>> and highly focused effort to define both the modification of >>>> the SIP headers necessary to support some enhanced calling >>>> party identification and a very limited effort to define the >>>> object and or the STIR validation data. >>>> >>>> I'm violently opposed to "end world hunger" WG's. >>>> >>>> If registries can be used fine but I certainly want to >>>> see how this can be accomplished in bi lateral agreements >>>> between consenting service providers and work with CUA >>>> vendors on how the data is displayed aka Apple, Samsung, >>>> Microsoft in the context of a formal liaison with 3GPP. >>>> Certainly the relevance of CNAM+/CNIT in enterprise and >>>> residential access markets is important but we all know >>>> "Money is the answer what is the question .." >>>> >>>> I've asked for time in Dispatch to look at the >>>> CNAM/CNIT issue and report on the JTF on NNI. As you well >>>> know we have made considerable progress. >>>> >>>> Last week I gave a talk on this to a panel that >>>> included many of our friends among the national regulators. >>>> >>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>> >>>> >>>> >>>> >>>> From: "Holmes, David W [CTO]" >>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>> To: "Peterson, Jon" , >>>> "modern@ietf.org" >>>> Subject: Re: [Modern] draft charter >>>> >>>> >>>> >>>> Jon, >>>> >>>> >>>> >>>> Thank you for the work in assembling this draft of the >>>> charter for MODERN. >>>> >>>> >>>> >>>> We would like to suggest some minor clarifications to >>>> the bullets describing the deliverables, to align them with >>>> the statement regarding flexibility to support the needs of >>>> different regulatory regimes, & thus to ensure that if quoted >>>> alone they are not taken out of context; i.e. the group >>>> product will be the protocols to support the allocation etc. >>>> activities, & it would not attempt to define the allocation >>>> processes. We also would like the charter to note the >>>> relevant work that has already been performed by both IETF & >>>> the ATIS/SIP Forum JTF, & incorporate that into the output >>>> from the MODERN WG as appropriate. These changes/additions >>>> are have been added to your text inline below. >>>> >>>> >>>> >>>> We are hoping that the MODERN session at IETF#92 will >>>> have remote access, to allow participation by those of us >>>> that cannot attend in person due to other commitments that week. >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> David/Sprint >>>> >>>> >>>> ______________________________________________________________ >>>> ________________ >>>> >>>> >>>> >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf >>>> Of Peterson, Jon >>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>> To: modern@ietf.org >>>> Subject: [Modern] draft charter >>>> >>>> >>>> >>>> >>>> >>>> At the Dallas IETF meeting in March, we'd like to get >>>> together and talk about what a working group for MODERN might >>>> look like. As an initial input to the discussion, a few of us >>>> have put together a proposed charter. While the TeRQ work was >>>> positively evaluated in the DISPATCH process, we feel this is >>>> broader enough in scope to warrant its own BoF. >>>> >>>> >>>> >>>> Comments are welcome, this is just a starting point. >>>> >>>> >>>> >>>> ------ >>>> >>>> >>>> >>>> Modern 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, STIR, and DRINKS. >>>> >>>> >>>> >>>> The work of this group is limited to specifying a >>>> solution for TNs and covers any service that can be addressed >>>> using a TN. Expanding the work to other identifiers is 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. >>>> >>>> >>>> >>>> The work group will deliver the following: >>>> >>>> >>>> >>>> - An architecture overview document that >>>> includes high level requirements and security/privacy >>>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum >>>> JTF, that included: >>>> >>>> o Call routing architecture >>>> >>>> o Inter-carrier NNI >>>> >>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>> >>>> o Enhanced Calling Name (CNIT/CNAM) >>>> >>>> - A document describing the protocols to >>>> support enrollment processes for existing and new TNs >>>> including any modifications to metadata related to those TNs >>>> >>>> - A document describing protocol mechanisms >>>> for accessing contact information associated with enrollments >>>> >>>> - A document describing protocol mechanisms >>>> for resolving information related to TNs >>>> >>>> >>>> >>>> - >>>> >>>> >>>> ________________________________ >>>> >>>> >>>> This e-mail may contain Sprint proprietary information >>>> intended for the sole use of the recipient(s). Any use by >>>> others is prohibited. If you are not the intended recipient, >>>> please contact the sender and delete all copies of the message. >>>> >>>> _______________________________________________ Modern >>>> mailing list Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> _______________________________________________ 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 > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit > From nobody Wed Feb 25 14:28: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 A22151A9142; Wed, 25 Feb 2015 14:28:03 -0800 (PST) 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 SIGxMkU-bfob; Wed, 25 Feb 2015 14:27:59 -0800 (PST) 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 3F7EB1A913F; Wed, 25 Feb 2015 14:27:59 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 2DEF7E52C01FB; Wed, 25 Feb 2015 22:27:53 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t1PMRu0p026803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 23:27:56 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 23:27:56 +0100 From: "DRAGE, Keith (Keith)" To: Hala Mowafy , Richard Shockey Thread-Topic: [Modern] [dispatch] draft charter Thread-Index: AQHQUSydknc63+KxOU+TFO6SzsKOM50BrEEAgABCBJA= Date: Wed, 25 Feb 2015 22:27:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> In-Reply-To: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.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.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [Modern] [dispatch] draft 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, 25 Feb 2015 22:28:03 -0000 There were two ISDN standards directions for calling name.=20 1) The public network standards. The service definition is the ITU-T Recomm= endation I.251.9 reference. As far as I aware, ITU-T did not proceed to pro= duce the related protocol standards (DSS1 and ISUP) but I could be wrong on= this. 2) The private (or business network standards) defined in ECMA internationa= l, ETSI and ISO (the same document in all groups). These did result in a pr= otocol definition for QSIG. Both sets of documents quote 50 octets maximum length, and both specify tha= t different character sets are possible. And both are defined for internetw= ork operation as well as internal operation. I would suggest that if you think some other value is appropriate, then tha= t alternative figure is the one that should be justified, given that the en= tire charter is ISDN centric! In regards to assessing length of names in general use, please give source = references for what you think is reasonable. I am aware that this will vary= from country to country, and deployment to deployment, based on style of n= aming, language, formal or informal address, title or professional qualific= ations and so on. I would prefer not to work beginning from statements that= start "I think..." http://www.historyrundown.com/top-5-people-with-the-longest-names/ Regards Keith Regards Keith > -----Original Message----- > From: Hala Mowafy [mailto:hala.mowafy@ericsson.com]=20 > Sent: 25 February 2015 19:17 > To: Richard Shockey > Cc: DRAGE, Keith (Keith); DOLLY, MARTIN C; Holmes, David W=20 > [CTO]; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org > Subject: Re: [Modern] [dispatch] draft charter >=20 > Not to my knowledge in North America.=20 > Keith, I believe you are referencing an ISDN PBX standard so=20 > it may have been just within a business group - not=20 > inter-network?? Correct me if I'm wrong.=20 >=20 > In our discussions at ATIS last year for CNAM in SIP headers=20 > someone brought up limitations on network elements handling=20 > more than 35 characters and that is what we are planning to=20 > support with an objective of 60 ch in the future.=20 > I think 35 is more than enough even for some of the longest,=20 > hyphenated names.=20 >=20 > Hala Mowafy > ERICSSON=20 >=20 > > On Feb 25, 2015, at 1:55 PM, Richard Shockey=20 > wrote: > >=20 > >=20 > > Humm.. Thanks. > >=20 > > I=B9m not sure anyone has actually deployed a 50 character=20 > service. Does=20 > > anyone know? > >=20 > >=20 > >=20 > > On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)" > > wrote: > >=20 > >> ITU-T Recommendation I.251.9 specifies: > >>=20 > >> calling name: Information associated with a specific calling party=20 > >> number. The maximum length is at least 15 characters and=20 > may be up to=20 > >> 50 characters. The exact length, format and character set=20 > (e.g. T.51,=20 > >> T.52) of the calling name to be delivered is a service provider=20 > >> option > >>=20 > >> Therefore 15 would appear to be a deployment specific limitation. > >>=20 > >> I believe QSIG defines 50 characters. > >>=20 > >> The definition above also raises the question of character set. > >>=20 > >> QSIG defines a number of different character sets. > >>=20 > >>=20 > >>=20 > >> Regards > >>=20 > >> Keith > >>=20 > >>> -----Original Message----- > >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > >>> Richard Shockey > >>> Sent: 25 February 2015 17:05 > >>> To: DOLLY, MARTIN C > >>> Cc: Holmes, David W [CTO]; cnit@ietf.org; dispatch@ietf.org;=20 > >>> modern@ietf.org > >>> Subject: Re: [dispatch] [Modern] draft charter > >>>=20 > >>>=20 > >>> Thanks Martin .. This is my very raw first cut at a charter. > >>> Its hopefully simple and straight forward. > >>>=20 > >>> Send me any edits etc. > >>>=20 > >>> ***** > >>>=20 > >>> CNIT Charter [Calling Name Identity Trust] > >>>=20 > >>>=20 > >>> WG Chairs TBD: > >>>=20 > >>>=20 > >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII=20 > >>> Characters of information associated with a specific=20 > E.164 calling=20 > >>> party number in the Public Switched Telephone Network [PSTN]. In=20 > >>> the PSTN this data is sent by the originating network only at the=20 > >>> specific request of the terminating network via a SS7 Transaction=20 > >>> Application Part [TCAP] response message. In the Session=20 > Initiation=20 > >>> Protocol [SIP] this information can be inserted into the=20 > FROM: part=20 > >>> of the originating INVITE message or by other means. > >>>=20 > >>>=20 > >>> As with the originating source telephone number, this data can be=20 > >>> altered in transit creating a variety of malicious abuses=20 > similar to=20 > >>> the ones identified by the IETF STIR working group. > >>>=20 > >>>=20 > >>> The purpose of the CNIT working group will be to define a data=20 > >>> structure, a new SIP header or repurpose an existing SIP=20 > header to=20 > >>> carry an advanced form of CNAM as well as information from a STIR=20 > >>> Validation Authority. The purpose of this work is to=20 > present to the=20 > >>> SIP called party trusted information from the calling=20 > party in order=20 > >>> that the called party make a more reasoned and informed=20 > judgment on=20 > >>> whether to accept the INVITE or not. > >>>=20 > >>>=20 > >>> The working group will not invalidate any existing SIP=20 > mechanism for=20 > >>> anonymous calling. > >>>=20 > >>>=20 > >>> The working group will, to the best of its ability, reuse=20 > existing=20 > >>> IETF protocols. > >>>=20 > >>>=20 > >>> Full Internationalization of the Calling Name Identity Trust data=20 > >>> object(s) is a requirement. > >>>=20 > >>>=20 > >>> The working group will closely work with the IETF STIR=20 > working group > >>>=20 > >>>=20 > >>> The working group will immediately liaison with 3GPP SA-1=20 > in order=20 > >>> to coordinate efforts. > >>>=20 > >>>=20 > >>> The working group will coordinate with National Numbering=20 > >>> Authorities and National Regulatory Authorities as needed. > >>>=20 > >>>=20 > >>> The working group will deliver the flowing. > >>>=20 > >>>=20 > >>> * A problem statement and requirements detailing the current=20 > >>> deployment environment and situations that motivate work=20 > on Calling=20 > >>> Name Identity Trust. > >>> * Define either a new SIP header or document a repurpose=20 > of an SIP=20 > >>> existing header for Calling Name Identify Trust data *=20 > Define a data=20 > >>> model for the Calling Name Identity Trust object (s) which may=20 > >>> include various forms of multimedia data > >>> * Deliver an analysis of privacy implications of the proposed=20 > >>> Calling Name Identity Trust mechanism. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Milestones: > >>>=20 > >>>=20 > >>> - > >>> Richard Shockey > >>> Shockey Consulting LLC > >>> Chairman of the Board SIP Forum > >>> www.shockey.us > >>> www.sipforum.org > >>> richardshockey.us > >>> Skype-Linkedin-Facebook rshockey101 > >>> PSTN +1 703-593-2683 > >>>=20 > >>>=20 > >>> From: "DOLLY, MARTIN C" > >>> Date: Tuesday, February 24, 2015 at 9:02 PM > >>> To: Richard Shockey > >>> Cc: "Holmes, David W [CTO]" ,=20 > >>> "dispatch@ietf.org" , "modern@ietf.org" > >>> , "Peterson, Jon" > >>> Subject: Re: [Modern] [dispatch] draft charter > >>>=20 > >>>=20 > >>> I support Richard on this > >>>=20 > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core & Gov't/Regulatory Standards > >>> AT&T Standards and > >>> Industry Alliances > >>> +1-609-903-3390 > >>>=20 > >>> Sent from my iPhone > >>>=20 > >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey =20 > >>> wrote: > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Excellent points David. > >>>=20 > >>> My concern here is charter overreach. I really want to keep=20 > >>> CNAM+/CNIT out of this. IMHO that is a very separate and highly=20 > >>> focused effort to define both the modification of the SIP headers=20 > >>> necessary to support some enhanced calling party=20 > identification and=20 > >>> a very limited effort to define the object and or the STIR=20 > >>> validation data. > >>>=20 > >>> I'm violently opposed to "end world hunger" WG's. > >>>=20 > >>> If registries can be used fine but I certainly want to see how=20 > >>> this can be accomplished in bi lateral agreements between=20 > consenting=20 > >>> service providers and work with CUA vendors on how the data is=20 > >>> displayed aka Apple, Samsung, Microsoft in the context of=20 > a formal=20 > >>> liaison with 3GPP. > >>> Certainly the relevance of CNAM+/CNIT in enterprise and=20 > residential=20 > >>> access markets is important but we all know "Money is the answer=20 > >>> what is the question .." > >>>=20 > >>> I've asked for time in Dispatch to look at the CNAM/CNIT issue=20 > >>> and report on the JTF on NNI. As you well know we have made=20 > >>> considerable progress. > >>>=20 > >>> Last week I gave a talk on this to a panel that=20 > included many of=20 > >>> our friends among the national regulators. > >>>=20 > >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 > >>>=20 > >>>=20 > >>>=20 > >>> =20 > >>> From: "Holmes, David W [CTO]" > >>> Date: Tuesday, February 24, 2015 at 5:06 PM > >>> To: "Peterson, Jon" ,=20 > "modern@ietf.org"=20 > >>> > >>> Subject: Re: [Modern] draft charter > >>> =20 > >>>=20 > >>>=20 > >>> Jon, > >>>=20 > >>> =20 > >>>=20 > >>> Thank you for the work in assembling this draft of the charter=20 > >>> for MODERN. > >>>=20 > >>> =20 > >>>=20 > >>> We would like to suggest some minor clarifications to=20 > the bullets=20 > >>> describing the deliverables, to align them with the statement=20 > >>> regarding flexibility to support the needs of different=20 > regulatory=20 > >>> regimes, & thus to ensure that if quoted alone they are not taken=20 > >>> out of context; i.e. the group product will be the protocols to=20 > >>> support the allocation etc. > >>> activities, & it would not attempt to define the allocation=20 > >>> processes. We also would like the charter to note the=20 > relevant work=20 > >>> that has already been performed by both IETF & the ATIS/SIP Forum=20 > >>> JTF, & incorporate that into the output from the MODERN WG as=20 > >>> appropriate. These changes/additions are have been added to your=20 > >>> text inline below. > >>>=20 > >>> =20 > >>>=20 > >>> We are hoping that the MODERN session at IETF#92 will=20 > have remote=20 > >>> access, to allow participation by those of us that cannot=20 > attend in=20 > >>> person due to other commitments that week. > >>>=20 > >>> =20 > >>>=20 > >>> Regards, > >>>=20 > >>> =20 > >>>=20 > >>> David/Sprint > >>>=20 > >>> =20 > >>> ______________________________________________________________ > >>> ________________ > >>>=20 > >>> =20 > >>>=20 > >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of=20 > >>> Peterson, Jon > >>> Sent: Wednesday, February 11, 2015 9:19 AM > >>> To: modern@ietf.org > >>> Subject: [Modern] draft charter > >>>=20 > >>> =20 > >>>=20 > >>> =20 > >>>=20 > >>> At the Dallas IETF meeting in March, we'd like to get together=20 > >>> and talk about what a working group for MODERN might look=20 > like. As=20 > >>> an initial input to the discussion, a few of us have put=20 > together a=20 > >>> proposed charter. While the TeRQ work was positively evaluated in=20 > >>> the DISPATCH process, we feel this is broader enough in scope to=20 > >>> warrant its own BoF. > >>>=20 > >>> =20 > >>>=20 > >>> Comments are welcome, this is just a starting point. > >>>=20 > >>> =20 > >>>=20 > >>> ------ > >>>=20 > >>> =20 > >>>=20 > >>> Modern charter text: > >>>=20 > >>> =20 > >>>=20 > >>> The MODERN working group will define a set of Internet-based=20 > >>> mechanisms for the purposes of managing and resolving telephone=20 > >>> numbers (TNs) in an IP environment. > >>> Existing mechanisms for these purposes face obsolescence as the=20 > >>> voice communications infrastructure evolves to IP=20 > technology and new=20 > >>> applications for TNs become possible. The traditional=20 > model of a TN=20 > >>> having an association to a single service provider and a single=20 > >>> application is breaking down. > >>> Its use as a network locator is going away, but its use as an=20 > >>> identifier for an individual or an organization will=20 > remain for some=20 > >>> time. Devices, applications, and network tools=20 > increasingly need to=20 > >>> manage TNs, including requesting and acquiring TN=20 > delegations from=20 > >>> authorities. > >>>=20 > >>> =20 > >>>=20 > >>> 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=20 > acquiring TNs,=20 > >>> which will provide an enrollment process for the individuals and=20 > >>> entities that use and manage TNs. TNs may either be managed in a=20 > >>> hierarchical tree, or in a distributed peer-to-peer=20 > architecture. =20 > >>> Privacy of the enrollment data and security of the=20 > resource will be=20 > >>> primary considerations. > >>>=20 > >>> =20 > >>>=20 > >>> Additionally, the working group will deliver a=20 > protocol mechanism=20 > >>> for resolving TNs which will allow entities such as service=20 > >>> providers, devices, and applications to access data=20 > related to TNs,=20 > >>> possibly including caller name data (CNAM). > >>> Maintaining reliability, real time application=20 > performance, security=20 > >>> and privacy are primary considerations. The working=20 > group will take=20 > >>> into consideration existing IETF work including ENUM, SPEERMINT,=20 > >>> STIR, and DRINKS. > >>>=20 > >>> =20 > >>>=20 > >>> The work of this group is limited to specifying a solution for=20 > >>> TNs and covers any service that can be addressed using a TN. =20 > >>> Expanding the work to other identifiers is out of scope. =20 > Solutions=20 > >>> and mechanisms created by the working group will be=20 > flexible enough=20 > >>> to accommodate different policies, e.g., by different regulatory=20 > >>> agencies. > >>>=20 > >>> =20 > >>>=20 > >>> The work group will deliver the following: > >>>=20 > >>> =20 > >>>=20 > >>> - An architecture overview document that > >>> includes high level requirements and security/privacy=20 > >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF,=20 > >>> that included: > >>>=20 > >>> o Call routing architecture > >>>=20 > >>> o Inter-carrier NNI > >>>=20 > >>> o Cryptographically-enabled Anti-spoofing (STIR) > >>>=20 > >>> o Enhanced Calling Name (CNIT/CNAM) > >>>=20 > >>> - A document describing the protocols to > >>> support enrollment processes for existing and new TNs=20 > including any=20 > >>> modifications to metadata related to those TNs > >>>=20 > >>> - A document describing protocol mechanisms > >>> for accessing contact information associated with enrollments > >>>=20 > >>> - A document describing protocol mechanisms > >>> for resolving information related to TNs > >>>=20 > >>> =20 > >>>=20 > >>> - =20 > >>>=20 > >>>=20 > >>> ________________________________ > >>>=20 > >>> =20 > >>> This e-mail may contain Sprint proprietary information=20 > intended=20 > >>> for the sole use of the recipient(s). Any use by others is=20 > >>> prohibited. If you are not the intended recipient, please contact=20 > >>> the sender and delete all copies of the message. > >>> =20 > >>> _______________________________________________ Modern mailing=20 > >>> list Modern@ietf.org =20 > >>> https://www.ietf.org/mailman/listinfo/modern > >>>=20 > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> =20 > >>>=20 > >>> _______________________________________________ Modern=20 > mailing list=20 > >>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern > >> _______________________________________________ > >> 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 > = From nobody Thu Feb 26 10:03:51 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 CF9F11A90BD; Thu, 26 Feb 2015 10:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.515 X-Spam-Level: ** X-Spam-Status: No, score=2.515 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 u-F0O5BxMyvE; Thu, 26 Feb 2015 10:03:49 -0800 (PST) Received: from mia.egh.com (50-79-181-89-static.hfc.comcastbusiness.net [50.79.181.89]) (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 455E81A90AD; Thu, 26 Feb 2015 10:03:48 -0800 (PST) Received: from vpna164.egh.com (vpna164.egh.com [198.179.132.164]) by mia.egh.com (8.14.5/8.14.5/SuSE Linux 0.8) with ESMTP id t1QI3ah9015157; Thu, 26 Feb 2015 13:03:37 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Cronin In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 26 Feb 2015 13:03:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D3A9FA5-5703-4562-86AE-D537C4C407A2@egh.com> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Holmes, David W \[CTO\]" , Ken Pogran , Hala Mowafy , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [Modern] [cnit] [dispatch] draft 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, 26 Feb 2015 18:03:51 -0000 > On Feb 25, 2015, at 5:27 PM, DRAGE, Keith (Keith) = wrote: > In regards to assessing length of names in general use, please give = source references for what you think is reasonable. I am aware that this = will vary from country to country, and deployment to deployment, based = on style of naming, language, formal or informal address, title or = professional qualifications and so on. I would prefer not to work = beginning from statements that start "I think=85=94 We=92ve been compressing caller names down to 15 octets for caller-name = for a quarter-century or so. We store a long name of 40 octets used to = create the short name. I believe that at some point in the past that was = the length limit on listed name for Bell System standard service orders. = Just a reference point. There are cases other than single personal names that will benefit from = longer caller name: 1) Businesses, particularly professional firms (e.g Smith, Jones and = McGarrity)=20 2) Couples (e.g Donald & Millicent Scanlin)=20 3) Couples with different surnames: (John Doe and Mary Roe) (I know this from complaints. :)) (from different mail from Keith Drage) >=20 > The definition above also raises the question of character set. >=20 > QSIG defines a number of different character sets. I would use UTF-8 and be done with it. Other thoughts: I=92m not familiar (yet :)) with the ITU recommendation but what with = the wide variety terminating equipment intelligence, I don=92t think one = size fits all anymore. I think a network caller-name/caller-id database = should store rich data (like the JSON vcards, I think Richard Shockey = suggested?) The terminating equipment (or intermediate system) can query for as much = data as it can use, or just say =93I can display n chars, send me that=94.= =20 Jonathan Jonathan Cronin jcronin@egh.com 781 861 0670 EGH, Inc. 55 Waltham Street Lexington, MA 02421