From nobody Wed Feb 25 09:07:04 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BEE1A90D8 for ; Wed, 25 Feb 2015 09:06:52 -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 2kkmrko0PDRb for ; Wed, 25 Feb 2015 09:06:46 -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 D6BD51A90BC 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: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:06:52 -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 10:55:38 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402341A1B8F for ; Wed, 25 Feb 2015 10:55:26 -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 TitTrD46WKMc for ; Wed, 25 Feb 2015 10:55:23 -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 DCEE61A1B23 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: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 18:55:26 -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:18:11 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust 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:52 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust 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:47 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DB11A870C for ; Wed, 25 Feb 2015 11:59:35 -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 Zyz9XZpBvb8y for ; Wed, 25 Feb 2015 11:59:32 -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 CA4B11A1EF6 for ; Wed, 25 Feb 2015 11:59:32 -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: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 19:59:35 -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 Thu Feb 26 06:17:49 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: Thu, 26 Feb 2015 06:17:49 -0800 Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [cnit] [dispatch] [Modern] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust 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 Thu Feb 26 06:17:51 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: X-Mailman-Approved-At: Thu, 26 Feb 2015 06:17:49 -0800 Cc: "Holmes, David W \[CTO\]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" , "DOLLY, MARTIN C" Subject: Re: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust 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:53 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [Modern] [dispatch] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust 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 From nobody Thu Feb 26 11:44:53 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B551A6FBC; Thu, 26 Feb 2015 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 G3-J5mjX_eq5; Thu, 26 Feb 2015 11:35:52 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id E95A51AC3F5; Thu, 26 Feb 2015 11:35:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1AAA5710E23; Thu, 26 Feb 2015 19:35:35 +0000 (GMT) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KBlEY774RZT; Thu, 26 Feb 2015 19:35:33 +0000 (GMT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id DEB0C710E1C; Thu, 26 Feb 2015 19:35:33 +0000 (GMT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 26 Feb 2015 19:35:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7D8D2ED4-2DFF-46B8-B401-F45CD522351D@insensate.co.uk> References: <8F037DFA-6243-4070-B9CB-6E961ECD0BBB@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B4A1095C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 11:44:51 -0800 Cc: "Holmes, David W \[CTO\]" , Hala Mowafy , "dispatch@ietf.org" , "cnit@ietf.org" , "modern@ietf.org" , Richard Shockey Subject: Re: [cnit] [dispatch] [Modern] draft charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 19:35:56 -0000 Hi Keith, folks, of historical interest only perhaps, but in the UK almost all fixed line = TEs were connected via analogue termination service. Thus, for the non-ISDN expected capabilities of TEs using this stuff ... BT's specs for Caller Display Service (their brand of CLID service) are = at Annex A (page 27 et seq) of: and in detail within: Tech. specs of the analogue line itself are spelt out in = In SIN242 a maximum message size of 64 octets is specified for Caller ID = messages. The underlying datalink from SIN227 allows an absolute maximum of 255 = octets per (basic mode) message. Thus, whilst decidedly -not- NNI, nor ISDN (and not QSIG/DPNSS...) UNI, = there's the spec and length limits for CDS in the UK. [The equivalent Telcordia CLASS docs spell out the service used "over = there" and no doubt set their own limits] We now return you to your previous channel. all the best, Lawrence On 25 Feb 2015, at 22:27, DRAGE, Keith (Keith) = wrote: > There were two ISDN standards directions for calling name.=20 >=20 > 1) The public network standards. The service definition is the = ITU-T Recommendation I.251.9 reference. As far as I aware, ITU-T did not = proceed to produce the related protocol standards (DSS1 and ISUP) but I = could be wrong on this. >=20 > 2) The private (or business network standards) defined in ECMA = international, ETSI and ISO (the same document in all groups). These did = result in a protocol definition for QSIG. >=20 > Both sets of documents quote 50 octets maximum length, and both = specify that different character sets are possible. And both are defined = for internetwork operation as well as internal operation. >=20 > I would suggest that if you think some other value is appropriate, = then that alternative figure is the one that should be justified, given = that the entire charter is ISDN centric! >=20 > 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..." >=20 > http://www.historyrundown.com/top-5-people-with-the-longest-names/ >=20 > Regards >=20 > Keith >=20 > Regards >=20 > Keith >=20 >> -----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 >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch