Re: [cnit] [Modern] [dispatch] CNIT and Modern Charter
Richard Shockey <richard@shockey.us> Tue, 10 March 2015 20:01 UTC
Return-Path: <richard@shockey.us>
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 BCBF21A892E for <cnit@ietfa.amsl.com>; Tue, 10 Mar 2015 13:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 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, 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 GpOSTfWPwkXH for <cnit@ietfa.amsl.com>; Tue, 10 Mar 2015 13:01:05 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 68A661A892C for <cnit@ietf.org>; Tue, 10 Mar 2015 13:01:00 -0700 (PDT)
Received: (qmail 5917 invoked by uid 0); 10 Mar 2015 20:01:00 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 10 Mar 2015 20:01:00 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 220t1q01M1MNPNq0120wgV; Tue, 10 Mar 2015 20:00:58 -0600
X-Authority-Analysis: v=2.1 cv=DeWE9JdW c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=AxLNCWWRI2xZ_7PomB4A:9 a=Bg1y9zWG01UkAtNh:21 a=q4NwGXh89CQRw-jm:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA: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:To:From:Subject:Date; bh=1dUIxM7kdknIET+WpgTbewA8ZOw1vYic7zCqkx2J5GU=; b=ivBBRWlGCWUhcndY939G3D8RMlHTa2GZkIt+0/4/sAfLViLv8nj0XRIIqQH0tMe1ZA5GOZZUMYA+NZqpHB+IYehyI7dubAUGhGeswhOQEgTUoNHJtfPEnmxYCFlPbQIO;
Received: from [108.56.131.201] (port=50853 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from <richard@shockey.us>) id 1YVQKk-0002MB-Py; Tue, 10 Mar 2015 14:00:55 -0600
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Tue, 10 Mar 2015 16:00:48 -0400
From: Richard Shockey <richard@shockey.us>
To: "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>, "cnit@ietf.org" <cnit@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>
Message-ID: <D124C56B.21816%richard@shockey.us>
Thread-Topic: [Modern] [dispatch] CNIT and Modern Charter
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
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: <http://mailarchive.ietf.org/arch/msg/cnit/6o_DbspVGnmxvRmN9bSlt25vnX0>
Subject: Re: [cnit] [Modern] [dispatch] CNIT and Modern Charter
X-BeenThere: cnit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Calling Name Identity Trust discussion list <cnit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cnit>, <mailto:cnit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cnit/>
List-Post: <mailto:cnit@ietf.org>
List-Help: <mailto:cnit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cnit>, <mailto:cnit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 20:01:08 -0000
Excellent point you’re absolutely right. Its a perfectly valid use case. On 3/10/15, 3:42 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com> wrote: >Why? A common scam is to get someone to call, text, e-mail, browse, to a >location of bad actions. If there was someway to authenticate that the >caller hasn't actually reached the "real" Bank of America, or whatever, >there is some value to the consumer. Just a thought. TLS includes a nod >to mutual authentication. I was just trying to think more about "trust >models" and what they can/should look like. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > >-----Original Message----- >From: Richard Shockey [mailto:richard@shockey.us] >Sent: March 10, 2015 2:37 PM >To: Gorman, Pierce A [CTO]; Cullen Jennings; cnit@ietf.org; >dispatch@ietf.org; modern@ietf.org >Subject: Re: [dispatch] CNIT and Modern Charter > > >As a matter of principal I wouldn’t rule anything like this out but there >could be some philshing issues. > >My question would be why? Sort of like the old out of band STIR idea >that I’m convinced is going no where. > >I’d like to fix one simple problem reasonably quickly. > > > >On 3/10/15, 2:58 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com> >wrote: > >>Should there be mutual authentication? Should the calling party >>receive a called party identity? >> >>Best regards, >> >> >>Pierce Gorman >>Voice Architecture >>Core Planning/Sprint >>913-439-4368 (Desk) >> >>-----Original Message----- >>From: Richard Shockey [mailto:richard@shockey.us] >>Sent: March 10, 2015 1:53 PM >>To: Gorman, Pierce A [CTO]; Cullen Jennings; cnit@ietf.org; >>dispatch@ietf.org; modern@ietf.org >>Subject: Re: [dispatch] CNIT and Modern Charter >> >> >>Exactly… studying the trust models are perfectly appropriate. >>Obviously the calling party data can come from different sources though >>I suspect in its earliest models it comes from the originating service >>provider through the SIP signaling mechanism to the terminating CUA. >>Especially in the VoLTE case. >> >>Enterprise to Enterprise would clearly be different. Certainly 3rd >>party databases could be involved in some way. >> >>I would remind folks that the rationale for this is consumers and >>National Regulators are NOT HAPPY AT ALL with the current state of how >>calling party data is presented to the consumer. STIR in and of itself >>is not enough. This is ultimately a consumer protection issue. >> >> >> >> >>On 3/9/15, 6:25 PM, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com> >>wrote: >> >>>I don't have any useful charter text. >>>I agree that the IETF should not propose business models, but it seems >>>important to consider trust model(s) to see if it/they drive protocol >>>considerations. >>>We could start with listing assumptions. I'll start by listing two. >>> 1) I assume there would be multiple authorities and multiple >>>levels of trust. >>> 2) I assume there are international tradename, and trademark and >>>the aforementioned UTF-8 international character code spoofing >>>considerations. >>> >>> >>>Best regards, >>> >>> >>>Pierce Gorman >>>Voice Architecture >>>Core Planning/Sprint >>>913-439-4368 (Desk) >>> >>>-----Original Message----- >>>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard >>>Shockey >>>Sent: March 09, 2015 2:18 PM >>>To: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org >>>Subject: Re: [Modern] [dispatch] CNIT and Modern Charter >>> >>> >>>The first order issue is properly defining what this looks like in SIP >>>and where in the headers it should reside. There is ample evidence >>>that any number of other SDO are looking at this and without some >>>proper standardization there will be no interoperability at all >>>especially even for STIR validation data at the CUA and IMHO doing >>>nothing is not a viable option. The basic FROM and PAI usage is not >>>helpful. >>> >>>We are all aware of how smart phones work. This is principally about >>>sessions that would originate outside a select number of phone book >>>entries and some display of whether that information has been >>>validated though we don¹t have to define policy at this stage and >>>frankly I don¹t think the IETF should try any more than it could try >>>and establish the business model for how this would deploy. >>> >>>The purpose here is simply adding more information about who >>>originated the session so the called party has more information than >>>they currently have. We already have enough bad actors as it is >>>impersonating tax authorities, banks, health care professionals and >>>other governmental entities. The purpose is to try and bound those >>>problems to a manageable level. There is no silver bullet here. >>> >>>I would appreciate any suggestions on charter text if you have them. >>> >>> >>> >>>‹ >>>Richard Shockey >>>Shockey Consulting LLC >>>Chairman of the Board SIP Forum >>>www.shockey.us >>>www.sipforum.org >>>richard<at>shockey.us >>>Skype-Linkedin-Facebook rshockey101 >>>PSTN +1 703-593-2683 >>> >>> >>> >>> >>> >>>On 3/9/15, 11:10 AM, "Cullen Jennings" <fluffy@cisco.com> wrote: >>> >>>> >>>>On the particular CNAM like topic ... >>>> >>>>I'm not keen on moving forward with something like this unless we can >>>>show the trust and human factors issues is an engineering problem not >>>>a research problem. We have seen the difficulty with human readable >>>>names in SPAM. Particularly when using UTF-8, how do we stop bad >>>>actor getting names that look the same as someone they wish to >>>>impersonate? >>>>Who will validate the names and issue some sort of trust token that >>>>says I can use "Cullen Jennings" or whatever. Who else can use that >>>>name and what about names visually similar to it. >>>> >>>>On the flip side we are seeing most smart phones take the incoming >>>>phone number, and look it up the personal address book of the user >>>>and display the name that the user of the smartphone assigned. We are >>>>seeing enterprise phones that do a similar things using the users >>>>social networks as well as personal address book. >>>> >>>>What would be bad is phone display a display name that some how >>>>claimed to be trustable but was not. That would be worse that the >>>>current situation. Perhaps people have a good way to solve this in >>>>mind but I'm not seeing that that is. >>>> >>>>Cullen (with my individual contribute hat on of course) >>>> >>>> >>>> >>>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey <richard@shockey.us> >>>>>wrote: >>>>> >>>>> >>>>> 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 >>>>> richard<at>shockey.us >>>>> Skype-Linkedin-Facebook rshockey101 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>, >>>>>"dispatch@ietf.org" <dispatch@ietf.org>, "modern@ietf.org" >>>>><modern@ietf.org>, "Peterson, Jon" <jon.peterson@neustar.biz> >>>>> Subject: Re: [Modern] [dispatch] draft charter >>>>> >>>>> I support Richard on this >>>>> >>>>> Martin Dolly >>>>> Lead Member of Technical Staff >>>>> Core & Gov't/Regulatory Standards >>>>> AT&T Standards and >>>>> Industry Alliances >>>>> +1-609-903-3390 >>>>> Sent from my iPhone >>>>> >>>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey <richard@shockey.us> >>>>>wrote: >>>>> >>>>>> >>>>>> Excellent points David. >>>>>> >>>>>> My concern here is charter overreach. I really want to keep >>>>>>CNAM+/CNIT out of this. IMHO that is a very separate and highly >>>>>>focused 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=60001033217 >>>>>> >>>>>> >>>>>> >>>>>> 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 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_________________________ >>>>>___ >>>>>_ >>>>>__________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>>_______________________________________________ >>>>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 >>> >>>________________________________ >>> >>>This e-mail may contain Sprint proprietary information intended for the >>>sole use of the recipient(s). Any use by others is prohibited. If you >>>are not the intended recipient, please contact the sender and delete >>>all copies of the message. >> >> >> >>________________________________ >> >>This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you are >>not the intended recipient, please contact the sender and delete all >>copies of the message. > > > >________________________________ > >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
- Re: [cnit] [dispatch] [Modern] CNIT and Modern Ch… Eric Burger
- Re: [cnit] [Modern] [dispatch] CNIT and Modern Ch… Richard Shockey
- Re: [cnit] [Modern] [dispatch] CNIT and Modern Ch… Richard Shockey