From nobody Wed Jul 1 08:04:28 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C7F1A903F for ; Wed, 1 Jul 2015 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 VEDfVVPUv78m for ; Wed, 1 Jul 2015 08:04:25 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.111]) (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 A34011A8F33 for ; Wed, 1 Jul 2015 08:02:58 -0700 (PDT) Received: from [193.109.255.99] by server-7.bemta-14.messagelabs.com id 8F/83-01469-12104955; Wed, 01 Jul 2015 15:02:57 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-6.tower-48.messagelabs.com!1435762976!15326030!1 X-Originating-IP: [195.232.244.134] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6475 invoked from network); 1 Jul 2015 15:02:56 -0000 Received: from mailout02.vodafone.com (HELO mailout02.vodafone.com) (195.232.244.134) by server-6.tower-48.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 15:02:56 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout02.vodafone.com (Postfix) with ESMTP id 3mM5QR6CvdzbdMZ; Wed, 1 Jul 2015 17:02:55 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3mM5QR4wzKzxPBl; Wed, 1 Jul 2015 17:02:55 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3mM5QR4PZ5zxPp6; Wed, 1 Jul 2015 17:02:55 +0200 (CEST) Received: from VOEXM31W.internal.vodafone.com ([169.254.7.191]) by VOEXC04W.internal.vodafone.com ([145.230.101.24]) with mapi id 14.03.0224.002; Wed, 1 Jul 2015 17:02:53 +0200 From: "Dawes, Peter, Vodafone Group" To: "bruno.chatras@orange.com" , James Winterbottom , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-winterbottom-dispatch-locparam Thread-Index: AQHQrZSisXH6kE+SRUqXdYB3bm933Z3EnvCAgAIhkGA= Date: Wed, 1 Jul 2015 15:02:54 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEFFEC4@VOEXM31W.internal.vodafone.com> References: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> <21058_1435652512_559251A0_21058_4734_1_88CAD1D4E8773F42858B58CAA28272A015C228F4@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <21058_1435652512_559251A0_21058_4734_1_88CAD1D4E8773F42858B58CAA28272A015C228F4@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:04:27 -0000 SGVsbG8gSmFtZXMsDQpJIHJlYWQgdGhpcyBkcmFmdCBhbmQgSSBoYXZlIGEgY291cGxlIG9mIHF1 ZXN0aW9ucy4gVGhlIGludHJvZHVjdGlvbiBzYXlzIA0KDQoiIEtub3dpbmcgdGhlIGlkZW50aXR5 IG9mIHRoZSBlbnRpdHkgdGhhdCBhZGRlZCB0aGUgbG9jYXRpb24gdG8gdGhlDQogICBtZXNzYWdl IGFsbG93cyB0aGUgcmVjaXBpZW50IHRvIGNob29zZSB3aGljaCBsb2NhdGlvbiB0byBjb25zaWRl cg0KICAgZmlyc3QgcmF0aGVyIHRoYW4gcmVseWluZyBzb2xlbHkgb24gdGhlIG9yZGVyIG9mIHRo ZSBsb2NhdGlvbiB2YWx1ZXMNCiAgIGluIHRoZSBnZW9sb2NhdGlvbiBoZWFkZXIgZmllbGQuIg0K DQpidXQgdGhlIGRyYWZ0IGRvZXMgbm90IHNheSBob3cgdGhlIHJlY2lwaWVudCBzb3J0cyB0aGUg bXVsdGlwbGUgbG9jYXRpb24gc291cmNlcywgYW5kIGl0IGRvZXNuJ3Qgc2F5IHdoYXQgaXMgaW52 b2x2ZWQgaW4gImNvbnNpZGVyaW5nIiB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24uIA0KDQpBbHNv IHRoZSBkcmFmdCBzYXlzOg0KDQoiIElmIGEgcHJveHkgcmVjZWl2ZXMgYSBtZXNzYWdlDQogICBm cm9tIGFuIHVudHJ1c3RlZCBzb3VyY2Ugd2l0aCB0aGUgbG9jLXNyYyBwYXJhbWV0ZXIgc2V0IHRo ZW4gaXQgTVVTVA0KICAgcmVtb3ZlIHRoZSBsb2Mtc3JjIHBhcmFtZXRlciBiZWZvcmUgcGFzc2lu ZyB0aGUgbWVzc2FnZSBpbnRvIGENCiAgIHRydXN0ZWQgbmV0d29yay4iDQoNCmJ1dCBkb2VzIHRo YXQgaGVscD8gaS5lLiBkb2VzIGl0IG5vdCBzaW1wbHkgZ2l2ZSBsZXNzIGNob2ljZSBvZiBsb2Nh dGlvbiBkYXRhIHRvIHRoZSByZWNpcGllbnQ/DQoNClJlZ2FyZHMsDQpQZXRlcg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGJydW5vLmNoYXRyYXNAb3JhbmdlLmNv bQ0KPiBTZW50OiAzMCBKdW5lIDIwMTUgMDk6MjINCj4gVG86IEphbWVzIFdpbnRlcmJvdHRvbTsg ZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gZHJhZnQtd2ludGVy Ym90dG9tLWRpc3BhdGNoLWxvY3BhcmFtDQo+IA0KPiBJbmRlZWQsIGl0IGlzIGltcG9ydGFudCBm b3IgdGhhdCB0aGlzIHdvcmsgYmUgZGlzcGF0Y2hlZCB0byB0aGUgcmlnaHQgcGxhY2UNCj4gcXVp Y2tseSBhbmQgbW92ZXMgZm9yd2FyZC4NCj4gQnJ1bm8NCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEphbWVzDQo+ID4gV2ludGVyYm90dG9tIEVudm95w6nC oDogbWFyZGkgMjMganVpbiAyMDE1IDExOjEyIMOAwqA6IGRpc3BhdGNoQGlldGYub3JnDQo+ID4g T2JqZXTCoDogW2Rpc3BhdGNoXSBkcmFmdC13aW50ZXJib3R0b20tZGlzcGF0Y2gtbG9jcGFyYW0N Cj4gPg0KPiA+IEhpIEFsbCwNCj4gPg0KPiA+IEkgYSBub3RpY2UgYWJvdXQgdGhpcyBkcmFmdCBh IGZldyB3ZWVrcyBhZ28gYnV0IGhhdmVu4oCZdCBzZWVuIGFuZA0KPiA+IGZvbGxvdyB1cCBkaXNj dXNzaW9uLg0KPiA+IFRoaXMgd29yayBpcyByZXF1aXJlZCBpbiBFVFNJIGFuZCBJIGJlbGlldmUg dGhhdCBhcyBJIHVuZGVyc3RhbmQgZnJvbQ0KPiA+IHNvbWUgM0dQUCBmb2xrcyB0aGV5IHdvdWxk IGxpa2Ugc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhpcyBhbHNvLg0KPiA+DQo+ID4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbnRlcmJvdHRvbS1kaXNwYXRjaC1sb2NwYXJhbS0w MA0KPiA+DQo+ID4gSSBhbSBqdXN0IG5vdCBzdXJlIHdoZXJlIHRoZSByaWdodCBmaW5hbCBob21l IGZvciBpdCBpcy4NCj4gPg0KPiA+IENoZWVycw0KPiA+IEphbWVzDQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRpc3BhdGNoIG1h aWxpbmcgbGlzdA0KPiA+IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fDQo+IA0K PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcw0KPiBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXoNCj4gbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzDQo+IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUNCj4gcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLA0KPiB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlDQo+IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbg0KPiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRp c3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo= From nobody Mon Jul 6 10:39:41 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4B1A06FD for ; Mon, 6 Jul 2015 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUMTs6ZAn8TD for ; Mon, 6 Jul 2015 10:39:37 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD061A047A for ; Mon, 6 Jul 2015 10:39:36 -0700 (PDT) Received: by ykfs198 with SMTP id s198so50240381ykf.2 for ; Mon, 06 Jul 2015 10:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gpUL/e4BRoT5labJZaG3Zd2BuzXw6Xt8sEAPnJsUfnk=; b=HvNbbejoURFfSCrE0rYVNer98pBoYkOUJ14kRlNeedrMVYDOorsqNWJN+849HRpjcS TkC1h9X/9YiKGnejlXTVtCqasl2nZg81c+oApQo9zBO+KgHQZzpqsrsr96a2H0UePnje /WrgqD4Wr6Jdhm6EoITwZ6UdBHsAoT5PayU7/pCfJ/9kavMW1f/X7R/fIG1H1kJyVFcJ mINXZcj2KpzLFHq+PDVL7m4+hUMw+tI+b6cWxTWk5Y5LSGjQS/Qu18ZCSK+SCLpJ4Kab GJfJurLSRESIICh3NX0cZTn1Bghq5BCr4H0T6+qOEY246w3vbMOUOsAufdaIMXCcxaMR XHPw== MIME-Version: 1.0 X-Received: by 10.129.146.73 with SMTP id j70mr60098ywg.62.1436204376335; Mon, 06 Jul 2015 10:39:36 -0700 (PDT) Received: by 10.37.224.194 with HTTP; Mon, 6 Jul 2015 10:39:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jul 2015 12:39:36 -0500 Message-ID: From: Mary Barnes To: Dan York Content-Type: multipart/alternative; boundary=94eb2c08f6cead2a4f051a38636c Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:39:40 -0000 --94eb2c08f6cead2a4f051a38636c Content-Type: text/plain; charset=UTF-8 Hi Dan et al, In reviewing the documents/agenda requests put forth for IETF-93, we are not yet able to dispatch this document. Fundamentally, it comes back down to the points Hadriel made in the last discussion of this document way back in December, 2011 (in the SIPPING WG mailing list) to which I didn't see a response (on SIPPING nor did I see the discussion switch over to DISPATCH): https://www.ietf.org/mail-archive/web/sipping/current/msg17803.html Also, in that thread of discussion, I didn't see comments from the "lots of people" that are using this header - I saw some technical comments from Paul K and Brett (I wasn't quite sure if those were yet fully addressed or in which version doing a quick scan of the diffs). So, is this just a matter of documenting what a few vendors are doing and are there other proprietary mechanisms out there for carrying the same information or is this the defacto standard way such that there's value in having it document in an IETF RFC? Thanks, Mary. On Wed, Jun 10, 2015 at 2:06 PM, Dan York wrote: > DISPATCH participants, > > > I could use some help/guidance about how to move my > now-seemingly-ancient P-Charge-Info draft forward. The draft is at: > > > https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 > > > Way back in 2008, I first submitted the draft to the SIPPING WG. My goal > was simply to *document the existing usage* of the P-Charge-Info SIP header > per the then-relevant RFC 3427 so that the header could be listed in the > IANA registry of SIP parameters at: > > > > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > > > > My employer at the time, Voxeo, was (and still is) a strong user of the > header and encouraged me to document it so that others could use the header > within private networks. As an IETF participant and SIP advocate, I > personally wanted to document P-Charge-Info so that perhaps people could > find it and use that header instead of creating yet another private > header. Tolga Asveren of Sonus Networks joined on very early in the > process because Sonus was (and presumably still is) also actively using the > header. Lots of other people chimed in along the way. > > > After an initial flurry of commentary and changes on the SIPPING list > from 2008-2010, there's a longer story of why it took so long... there was > the RFC 3427bis process which became RFC 5727... life and job changes... > much more... > > > Anyway, at this point in 2015 I just want to move the document along and > get it published so that the header can be registered and, quite honestly, > so that I can stop renewing the document every 6 months. Given that I > still get inquiries about this header from time to time and that it is > still being used, I feel a certain responsibility to just "get this done" > rather than simply abandoning the draft. > > > From what I know, there are three ways I can move this forward to > publication: > > > 1. DISPATCH approval - this WG can approve the draft and send to the > IESG; [1] > > > 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; > > > 3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream > editor. > > > Am I correct? And if so, what would any of you suggest as the simplest > path to checking this off as done? > > > Comments on the actual draft are of course also welcome, with the > reminder that the aim of the draft was and is to document existing usage > rather than to create a new header, etc. (Because if it was to create a > new header, the "P-" would be removed, etc.) > > > Thanks, > > Dan > > > [1] And yes, I do realize there is actually a 4th path which is that > DISPATCH could "dispatch" this draft off to some other WG and I could then > bring it through *that* WG. And if that's the best path I'm glad to do > that, too... I just want to get this finished. > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --94eb2c08f6cead2a4f051a38636c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan et al,

In reviewing the document= s/agenda requests put forth for IETF-93, we are not yet able to dispatch th= is document.=C2=A0 Fundamentally, it comes back down to the points Hadriel = made in the last discussion of this document way back in December, 2011 (in= the SIPPING WG mailing list) to which I didn't see a response (on SIPP= ING nor did I see the discussion switch over to DISPATCH):=C2=A0

=

Thanks,
Mary.=C2=A0

=

O= n Wed, Jun 10, 2015 at 2:06 PM, Dan York <york@isoc.org> wrote:<= br>

DISPATCH participants,


I could use some help/guidance about how to move my now-seemingly-ancien= t P-Charge-Info draft forward. The draft is at:


https://tools.ietf.org/html/draft-york-dispatch-p-ch= arge-info-05


Way back in 2008, I first submitted the draft to the SIPPING WG. My goal= was simply to *document the existing usage*=C2=A0of the P-Charge-Info SIP = header per the then-relevant=C2=A0RFC 3427 so that the header could be list= ed in the IANA registry of SIP parameters at:


http://www.iana.org/assignments/= sip-parameters/sip-parameters.xhtml#sip-parameters-2=C2=A0


My employer at the time, Voxeo, was (and=C2=A0still is) a strong user of= the header and encouraged me to document it so that others could use the h= eader within private networks.=C2=A0 As an IETF participant and SIP=C2=A0ad= vocate, I personally=C2=A0wanted to document P-Charge-Info so that perhaps people could find it and use that header instead of creati= ng yet another private header.=C2=A0 Tolga Asveren of Sonus Networks joined= on very early in the process because Sonus was (and presumably still is) a= lso actively using the header.=C2=A0 Lots of other people =C2=A0chimed in along the way.


After an initial flurry of commentary and changes on the SIPPING list fr= om 2008-2010, there's a longer story of why it took so long... there wa= s the RFC 3427bis process which became RFC 5727... life and job changes... = much more...


Anyway, at this point in 2015 I just want to move the document along and= get it published so that the header can be registered and, quite honestly,= so that=C2=A0I can stop renewing the document every 6 months.=C2=A0 Given = that I still get inquiries about this header from time to time and that it is still being used, I feel a certain respon= sibility to just "get this done" rather than simply abandoning th= e draft.


From what I know, there are three ways I can move this forward to public= ation:


1. DISPATCH approval - this WG can approve the draft and send to the IES= G; [1]


2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG;=


3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream = editor.


Am I correct?=C2=A0 And if so, what would any of you suggest as the simp= lest path to checking this off as done?


Comments on the actual draft are of course also welcome, with the remind= er that the aim of the draft was and is to document existing usage rather t= han to create a new header, etc. =C2=A0(Because if it was to create a new h= eader, the "P-" would be removed, etc.)


Thanks,

Dan


[1] And yes, I do realize there is actually a 4th path which is that DIS= PATCH could "dispatch" this draft off to some other WG and I coul= d then bring it through *that* WG. And if that's the best path I'm = glad to do that, too... I just want to get this finished.




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


--94eb2c08f6cead2a4f051a38636c-- From nobody Wed Jul 8 04:02:53 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719D21B345B for ; Wed, 8 Jul 2015 04:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSvp86GZoRLJ for ; Wed, 8 Jul 2015 04:02:49 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58161B3453 for ; Wed, 8 Jul 2015 04:02:48 -0700 (PDT) Received: by wgck11 with SMTP id k11so192569766wgc.0 for ; Wed, 08 Jul 2015 04:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EOwws27NmsD7oEwc5Yy/G+HxuCH/GbEM3zak5vVb4qc=; b=Mqr7zKp4GnIbihwXRat+jOV7vEeDoN76Q5WKn1oXEwVQ0pbMY4IHEftRmWCiJqvN8C 41Z3slZ6kgJB6dusFazKISIvgt0nFNijyuzoxbfpLeCgaqS3rGlEDMMKpKCRaI8tVR7c 4/wOTbu39cUxENeN0+kmyhEFIZ0bm1INguX5WZRYx4DKsOMmcE99WMq4Bs1aYccAQS65 U9AAv1gf48TqA6Z6Fpq5YZDml12zz0VM4x+pe+m8LXCK3SBXzNlIfYGtrMm7ba7i9pvC dfjQYQ4ntd/C7yJlMimZCfeiYpgo3AG9eoE8xFjVQ5y5VyGUi1GwQn8Uf4pzWCSGY6LJ FkqA== MIME-Version: 1.0 X-Received: by 10.180.76.202 with SMTP id m10mr34543473wiw.63.1436353367608; Wed, 08 Jul 2015 04:02:47 -0700 (PDT) Received: by 10.28.155.202 with HTTP; Wed, 8 Jul 2015 04:02:47 -0700 (PDT) In-Reply-To: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 06:02:47 -0500 Message-ID: From: Alan Johnston To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7c543f91f1051a5b14a6 Archived-At: Subject: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 11:02:51 -0000 --f46d043c7c543f91f1051a5b14a6 Content-Type: text/plain; charset=UTF-8 All, Many of us have been talking about "Best Effort SRTP" for many years, and there are a number of deployments. In addition, the IMTC has recommended it, and the SIP Forum would like to recommend it in SIPconnect 2.0 which for the first time includes SRTP media. With the publication of RFC 7435 ( https://tools.ietf.org/html/rfc7435), the IETF has endorsed this approach as Opportunistic Security (OS), so it would be nice to bring standards in line with industry practice. Comments on the draft, "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)" and the best way forward are most welcome! - Alan - ---------- Forwarded message ---------- From: Date: Mon, Jul 6, 2015 at 1:48 PM Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) Authors : Alan Johnston Bernard Aboba Andy Hutton Laura Liess Thomas Stach Filename : draft-johnston-dispatch-osrtp-00.txt Pages : 8 Date : 2015-07-06 Abstract: Opportunistic Secure Real-time Transport Protocol (OSRTP) allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP is an implementation of Opportunistic Security, as defined in RFC 7435. OSRTP does not require advanced SDP extensions or features and is fully backwards compatible with existing secure and insecure implementations. OSRTP is not specific to any key management technique for SRTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --f46d043c7c543f91f1051a5b14a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Many of us have been ta= lking about "Best Effort SRTP" for many years, and there are a nu= mber of deployments.=C2=A0 In addition, the IMTC has recommended it, and th= e SIP Forum would like to recommend it in SIPconnect 2.0 which for the firs= t time includes SRTP media.=C2=A0 With the publication of RFC 7435 (https://tools.ietf.org/html/rfc743= 5), the IETF has endorsed this approach as Opportunistic Security (OS),= so it would be nice to bring standards in line with industry practice.

Comments on the draft, "An Opportunistic Approac= h for Secure Real-time Transport Protocol (OSRTP)" and the best way fo= rward are most welcome!

- Alan -

---------- Forwarded message ----------
Fr= om: <internet-drafts@ietf.org>
Da= te: Mon, Jul 6, 2015 at 1:48 PM
Subject: I-D Action: draft-johnston-disp= atch-osrtp-00.txt
To: i-d-annou= nce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alan= Johnston
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bernard Aboba
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Andy Hutton
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Laura Liess
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thomas Stach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-joh= nston-dispatch-osrtp-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0Opportunistic Secure Real-time Transport Protocol (OSRTP) allo= ws
=C2=A0 =C2=A0encrypted media to be used in environments where support for =C2=A0 =C2=A0encryption is not known in advance, and not required.=C2=A0 OS= RTP is an
=C2=A0 =C2=A0implementation of Opportunistic Security, as defined in RFC 74= 35.
=C2=A0 =C2=A0OSRTP does not require advanced SDP extensions or features and= is
=C2=A0 =C2=A0fully backwards compatible with existing secure and insecure =C2=A0 =C2=A0implementations.=C2=A0 OSRTP is not specific to any key manage= ment
=C2=A0 =C2=A0technique for SRTP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-johnston-dispatch-osrtp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-johnst= on-dispatch-osrtp-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--f46d043c7c543f91f1051a5b14a6-- From nobody Wed Jul 8 09:14:56 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC741A0250 for ; Wed, 8 Jul 2015 09:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYuthS4Oz2te for ; Wed, 8 Jul 2015 09:14:54 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C841A0252 for ; Wed, 8 Jul 2015 09:14:53 -0700 (PDT) Received: by ykey15 with SMTP id y15so15591502yke.3 for ; Wed, 08 Jul 2015 09:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dHteL8FxvfcXDp/vCqTlnIx+gHdMRGVuprogAGaHr8=; b=nHgQP/iueOZO7d2dlU1KMe3NzpnVjWBXUFk++Zff8Tt5oBSziZGlUtJHLfal3L69G2 cXh+X1XybYixuiqTccaeY99Yc8e9nPGzZweS9fCU4b2GrDH4DxCCiyQ2egcDNVRIl1U/ rhIOj+ScJLvZ6V6ph+7LDd5oxzvWfp2YGYKGSdo+xdJZX//khJZn3C1erCfs79rBsPA6 iWA8ZguA3Oa37Scsz90XR7J67vidoWe+HN8igmFr123Ose9N7zxR2bVmbKlB8jBjLMOy nuJX0Lp8AEn/IS35IhibOejYw0scscx3WpMwm6P63wwMahE3m5cZDwikPfgxH3OKEI7k 4ojQ== MIME-Version: 1.0 X-Received: by 10.170.124.19 with SMTP id q19mr12484721ykb.1.1436372093135; Wed, 08 Jul 2015 09:14:53 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 8 Jul 2015 09:14:53 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 09:14:53 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:14:55 -0000 How does this differ from: https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01 On 8 July 2015 at 04:02, Alan Johnston wrote: > All, > > Many of us have been talking about "Best Effort SRTP" for many years, and > there are a number of deployments. In addition, the IMTC has recommended > it, and the SIP Forum would like to recommend it in SIPconnect 2.0 which for > the first time includes SRTP media. With the publication of RFC 7435 > (https://tools.ietf.org/html/rfc7435), the IETF has endorsed this approach > as Opportunistic Security (OS), so it would be nice to bring standards in > line with industry practice. > > Comments on the draft, "An Opportunistic Approach for Secure Real-time > Transport Protocol (OSRTP)" and the best way forward are most welcome! > > - Alan - > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 6, 2015 at 1:48 PM > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An Opportunistic Approach for Secure Real-time > Transport Protocol (OSRTP) > Authors : Alan Johnston > Bernard Aboba > Andy Hutton > Laura Liess > Thomas Stach > Filename : draft-johnston-dispatch-osrtp-00.txt > Pages : 8 > Date : 2015-07-06 > > Abstract: > Opportunistic Secure Real-time Transport Protocol (OSRTP) allows > encrypted media to be used in environments where support for > encryption is not known in advance, and not required. OSRTP is an > implementation of Opportunistic Security, as defined in RFC 7435. > OSRTP does not require advanced SDP extensions or features and is > fully backwards compatible with existing secure and insecure > implementations. OSRTP is not specific to any key management > technique for SRTP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Jul 8 09:17:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFE31A0334 for ; Wed, 8 Jul 2015 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxBJAulF107o for ; Wed, 8 Jul 2015 09:17:48 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5F61A026E for ; Wed, 8 Jul 2015 09:17:48 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so217764169wib.1 for ; Wed, 08 Jul 2015 09:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r+4z2g7i5Jv0OGfHhI2q2wllxoQCHwrX57pv8lugxvo=; b=I0+45DJ0YiuZAWXne3TX8lutIYZ0EAm1AgJPSpp0hLjostUF4QRAkCPgRFv06GspL5 QMYwlaOBqNn94onuBiEu4Qu6YOMJ+xBL+XPhtPG898hzaQMDSghUtpwDobo+nVDsgDJr 1e03vDfuxnCNPmnzI2YWu3b5nqGoHcrSXyfyHRvHW/qRO0putXBDvftj4y48RYH+i178 jcdVGd8yWrYjipLpmc6dCtLoQPKWZ3NVrMlukyWYXk6o/PDxf07brG95TlgdCAbRMzK2 kZ3QWY+BD1hI7sC1He4Cm3ZTWuMaDgSmAPUwJRRwkNvwr+a70+5LOZTynAhUwx4Wuhgx g/9A== MIME-Version: 1.0 X-Received: by 10.180.78.136 with SMTP id b8mr72889489wix.89.1436372267086; Wed, 08 Jul 2015 09:17:47 -0700 (PDT) Received: by 10.28.132.68 with HTTP; Wed, 8 Jul 2015 09:17:47 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 11:17:47 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d0435c034beb92e051a5f7a9b Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:17:51 -0000 --f46d0435c034beb92e051a5f7a9b Content-Type: text/plain; charset=UTF-8 Hi Martin, It is the version of the draft that is actually implemented and used. There are also a few slight differences due to the way that Opportunistic Security is defined. - Alan - On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson wrote: > How does this differ from: > https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01 > > On 8 July 2015 at 04:02, Alan Johnston wrote: > > All, > > > > Many of us have been talking about "Best Effort SRTP" for many years, and > > there are a number of deployments. In addition, the IMTC has recommended > > it, and the SIP Forum would like to recommend it in SIPconnect 2.0 which > for > > the first time includes SRTP media. With the publication of RFC 7435 > > (https://tools.ietf.org/html/rfc7435), the IETF has endorsed this > approach > > as Opportunistic Security (OS), so it would be nice to bring standards in > > line with industry practice. > > > > Comments on the draft, "An Opportunistic Approach for Secure Real-time > > Transport Protocol (OSRTP)" and the best way forward are most welcome! > > > > - Alan - > > > > ---------- Forwarded message ---------- > > From: > > Date: Mon, Jul 6, 2015 at 1:48 PM > > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : An Opportunistic Approach for Secure Real-time > > Transport Protocol (OSRTP) > > Authors : Alan Johnston > > Bernard Aboba > > Andy Hutton > > Laura Liess > > Thomas Stach > > Filename : draft-johnston-dispatch-osrtp-00.txt > > Pages : 8 > > Date : 2015-07-06 > > > > Abstract: > > Opportunistic Secure Real-time Transport Protocol (OSRTP) allows > > encrypted media to be used in environments where support for > > encryption is not known in advance, and not required. OSRTP is an > > implementation of Opportunistic Security, as defined in RFC 7435. > > OSRTP does not require advanced SDP extensions or features and is > > fully backwards compatible with existing secure and insecure > > implementations. OSRTP is not specific to any key management > > technique for SRTP. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > --f46d0435c034beb92e051a5f7a9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

It is the version of the dra= ft that is actually implemented and used.=C2=A0 There are also a few slight= differences due to the way that Opportunistic Security is defined.

- Alan -

On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
How does this differ from:
https://tools.ietf.org/html/draft= -kaplan-mmusic-best-effort-srtp-01

On 8 July 2015 at 04:02, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> Many of us have been talking about "Best Effort SRTP" for ma= ny years, and
> there are a number of deployments.=C2=A0 In addition, the IMTC has rec= ommended
> it, and the SIP Forum would like to recommend it in SIPconnect 2.0 whi= ch for
> the first time includes SRTP media.=C2=A0 With the publication of RFC = 7435
> (https://tools.ietf.org/html/rfc7435), the IETF has endo= rsed this approach
> as Opportunistic Security (OS), so it would be nice to bring standards= in
> line with industry practice.
>
> Comments on the draft, "An Opportunistic Approach for Secure Real= -time
> Transport Protocol (OSRTP)" and the best way forward are most wel= come!
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Mon, Jul 6, 2015 at 1:48 PM
> Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
> To: i-d-announce@ietf.org=
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: An Opportunistic Approach for Secure Real-time
> Transport Protocol (OSRTP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Alan Johnston
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Bernard Aboba
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy Hutton
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Laura Liess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Thomas Stach
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-johnston-dispatch-osrtp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-07-06
>
> Abstract:
>=C2=A0 =C2=A0 Opportunistic Secure Real-time Transport Protocol (OSRTP)= allows
>=C2=A0 =C2=A0 encrypted media to be used in environments where support = for
>=C2=A0 =C2=A0 encryption is not known in advance, and not required.=C2= =A0 OSRTP is an
>=C2=A0 =C2=A0 implementation of Opportunistic Security, as defined in R= FC 7435.
>=C2=A0 =C2=A0 OSRTP does not require advanced SDP extensions or feature= s and is
>=C2=A0 =C2=A0 fully backwards compatible with existing secure and insec= ure
>=C2=A0 =C2=A0 implementations.=C2=A0 OSRTP is not specific to any key m= anagement
>=C2=A0 =C2=A0 technique for SRTP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc= /draft-johnston-dispatch-osrtp/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-j= ohnston-dispatch-osrtp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

--f46d0435c034beb92e051a5f7a9b-- From nobody Wed Jul 8 11:01:38 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6B1A21A2 for ; Wed, 8 Jul 2015 11:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 maRDGgBMPA9X for ; Wed, 8 Jul 2015 11:01:35 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714EF1A212D for ; Wed, 8 Jul 2015 11:01:34 -0700 (PDT) Received: by wifm2 with SMTP id m2so97057566wif.1 for ; Wed, 08 Jul 2015 11:01:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MVIJAVv7451HsoKFM9juPQFfZKRR55OvYx3g+4Z0w0w=; b=UmozpQ7irW8OiRZhcu7MixNQrD9SrmX9iyW7k3SxBXeaPUveaCymsjpDlPrQVxNa87 qpbz6aJe52E+ipq0ALikLckUvwj+cpRRB82yeVzVQOKWtE9Y1ouTfZFuwGffy2UNftuR UDnTYKGZK0tlFY9qKXoW7lUc4Ch9/BGNaAcLMBbIZCOIh0gMty2XIxzWi1imIXHhI8uQ /ek0ZKRdmWUTlMj0eMjgpgbF9lYXieVvv4+pwEStr2vUxTE0XaJCVzD8XmxstNQfbGUp 6xZ/aET6rcxgwL/Dx/zeNuL/2gAQVnEO24VyteQoq6e6tmqAn+6ZRzW6w7//cQuWYLJO tAeg== X-Gm-Message-State: ALoCoQk30q7TlpUf93AiMWm3jOejwagfk51UaLBB+ayOUTJH+pBFPSBTQXU9qxwYiqJQzWMHNB0L X-Received: by 10.180.72.179 with SMTP id e19mr117677926wiv.53.1436378493196; Wed, 08 Jul 2015 11:01:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Wed, 8 Jul 2015 11:00:53 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 8 Jul 2015 11:00:53 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=f46d043c7ba2d9b3af051a60edea Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 18:01:37 -0000 --f46d043c7ba2d9b3af051a60edea Content-Type: text/plain; charset=UTF-8 This seems like a good idea. I have three comments: 1. You should forbid the answerer from sending back two types of keying parameters (e.g., a=crypto and a=fingerprint) because that creates confusion. 2. You probably shouldn't relax the need to send SDES over HTTPS because the security properties there are still fairly bad. 3. I would suggest that failure to negotiate a secure channel (for DTLS-SRTP and ZRTP) should lead to media failure not falling back. There's basically no good reason for this to fail and it seems like it will make diagnosing issues easier. -Ekr On Wed, Jul 8, 2015 at 9:17 AM, Alan Johnston wrote: > Hi Martin, > > It is the version of the draft that is actually implemented and used. > There are also a few slight differences due to the way that Opportunistic > Security is defined. > > - Alan - > > On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson > wrote: > >> How does this differ from: >> https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01 >> >> On 8 July 2015 at 04:02, Alan Johnston wrote: >> > All, >> > >> > Many of us have been talking about "Best Effort SRTP" for many years, >> and >> > there are a number of deployments. In addition, the IMTC has >> recommended >> > it, and the SIP Forum would like to recommend it in SIPconnect 2.0 >> which for >> > the first time includes SRTP media. With the publication of RFC 7435 >> > (https://tools.ietf.org/html/rfc7435), the IETF has endorsed this >> approach >> > as Opportunistic Security (OS), so it would be nice to bring standards >> in >> > line with industry practice. >> > >> > Comments on the draft, "An Opportunistic Approach for Secure Real-time >> > Transport Protocol (OSRTP)" and the best way forward are most welcome! >> > >> > - Alan - >> > >> > ---------- Forwarded message ---------- >> > From: >> > Date: Mon, Jul 6, 2015 at 1:48 PM >> > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt >> > To: i-d-announce@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > >> > >> > Title : An Opportunistic Approach for Secure Real-time >> > Transport Protocol (OSRTP) >> > Authors : Alan Johnston >> > Bernard Aboba >> > Andy Hutton >> > Laura Liess >> > Thomas Stach >> > Filename : draft-johnston-dispatch-osrtp-00.txt >> > Pages : 8 >> > Date : 2015-07-06 >> > >> > Abstract: >> > Opportunistic Secure Real-time Transport Protocol (OSRTP) allows >> > encrypted media to be used in environments where support for >> > encryption is not known in advance, and not required. OSRTP is an >> > implementation of Opportunistic Security, as defined in RFC 7435. >> > OSRTP does not require advanced SDP extensions or features and is >> > fully backwards compatible with existing secure and insecure >> > implementations. OSRTP is not specific to any key management >> > technique for SRTP. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> > Internet-Draft directories: http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> > >> > _______________________________________________ >> > 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 > > --f46d043c7ba2d9b3af051a60edea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like a good idea.

I have thr= ee comments:

1. You should forbid the answerer fro= m sending back two types of
keying parameters (e.g., a=3Dcrypto a= nd a=3Dfingerprint) because that creates
confusion.
2. You probably shouldn't relax the need to send SDES over = HTTPS because
the security properties there are still fairly bad.=

3. I would suggest that failure to negotiate a se= cure channel (for DTLS-SRTP
and ZRTP) should lead to media failur= e not falling back. There's basically
no good reason for this= to fail and it seems like it will make diagnosing
issues easier.=

-Ekr


On Wed, Jul 8, 2015 at 9:17 AM, Ala= n Johnston <alan.b.johnston@gmail.com> wrote:
Hi Martin,

= It is the version of the draft that is actually implemented and used.=C2=A0= There are also a few slight differences due to the way that Opportunistic = Security is defined.

- Alan -
<= div class=3D"h5">

= On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson <martin.thomson@gma= il.com> wrote:
How does thi= s differ from:
https://tools.ietf.org/html/draft= -kaplan-mmusic-best-effort-srtp-01

On 8 July 2015 at 04:02, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> Many of us have been talking about "Best Effort SRTP" for ma= ny years, and
> there are a number of deployments.=C2=A0 In addition, the IMTC has rec= ommended
> it, and the SIP Forum would like to recommend it in SIPconnect 2.0 whi= ch for
> the first time includes SRTP media.=C2=A0 With the publication of RFC = 7435
> (https://tools.ietf.org/html/rfc7435), the IETF has endo= rsed this approach
> as Opportunistic Security (OS), so it would be nice to bring standards= in
> line with industry practice.
>
> Comments on the draft, "An Opportunistic Approach for Secure Real= -time
> Transport Protocol (OSRTP)" and the best way forward are most wel= come!
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Mon, Jul 6, 2015 at 1:48 PM
> Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
> To: i-d-ann= ounce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: An Opportunistic Approach for Secure Real-time
> Transport Protocol (OSRTP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Alan Johnston
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Bernard Aboba
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy Hutton
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Laura Liess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Thomas Stach
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-johnston-dispatch-osrtp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-07-06
>
> Abstract:
>=C2=A0 =C2=A0 Opportunistic Secure Real-time Transport Protocol (OSRTP)= allows
>=C2=A0 =C2=A0 encrypted media to be used in environments where support = for
>=C2=A0 =C2=A0 encryption is not known in advance, and not required.=C2= =A0 OSRTP is an
>=C2=A0 =C2=A0 implementation of Opportunistic Security, as defined in R= FC 7435.
>=C2=A0 =C2=A0 OSRTP does not require advanced SDP extensions or feature= s and is
>=C2=A0 =C2=A0 fully backwards compatible with existing secure and insec= ure
>=C2=A0 =C2=A0 implementations.=C2=A0 OSRTP is not specific to any key m= anagement
>=C2=A0 =C2=A0 technique for SRTP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc= /draft-johnston-dispatch-osrtp/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-j= ohnston-dispatch-osrtp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>


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


--f46d043c7ba2d9b3af051a60edea-- From nobody Wed Jul 8 11:43:02 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5001A701A for ; Wed, 8 Jul 2015 11:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, 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 PTfbPUcN9F0t for ; Wed, 8 Jul 2015 11:42:54 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753131A700B for ; Wed, 8 Jul 2015 11:42:53 -0700 (PDT) Received: by wgck11 with SMTP id k11so203854636wgc.0 for ; Wed, 08 Jul 2015 11:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pM7ELbfSoh4j6X5UIVAeXt5ovHUWVHwsPZdR1HgkCO4=; b=v7NpjT5T1SOvZeFr8RaUMI0VJRRYFQfRHTtMi+4WXX7HIKf3etBFz8LDYJgjMCA3nz G+AU0idkXZj09FXQQsZBRnNVQfXjz2875/k7k6W5h8jOSUQRYNsJvRv28rDoWeqmA85B e6vf2YPMzuHC1iz0zOk9E3aW+LBDlYfgI06A3ufYAFsCyTUCh/f9aKC/Pyw3UVHTmUES WWgQWpX9xXDVbqP9pF/CZ+iim6P6jP2lLkDRhQ+SWKqRQnSAa14qEUOfR5EwtY89OjjK liQizPDqu/Ddy9jGl+ExhzB4+oyBc5rYAS5PlW7X5/d5OUGi92leQUuNvC1z23iP7LCh FhBw== MIME-Version: 1.0 X-Received: by 10.194.185.146 with SMTP id fc18mr21135815wjc.46.1436380972170; Wed, 08 Jul 2015 11:42:52 -0700 (PDT) Received: by 10.28.155.202 with HTTP; Wed, 8 Jul 2015 11:42:52 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 13:42:52 -0500 Message-ID: From: Alan Johnston To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7bb03d969bc4fd051a618152 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 18:42:57 -0000 --047d7bb03d969bc4fd051a618152 Content-Type: text/plain; charset=UTF-8 Hi Ekr, Thanks for the feedback. See below. More feedback on #3 from others would be very helpful. - Alan - On Wed, Jul 8, 2015 at 1:00 PM, Eric Rescorla wrote: > This seems like a good idea. > > I have three comments: > > 1. You should forbid the answerer from sending back two types of > keying parameters (e.g., a=crypto and a=fingerprint) because that creates > confusion. > Agreed - I'll put that in. > > 2. You probably shouldn't relax the need to send SDES over HTTPS because > the security properties there are still fairly bad. > Right. I tried to say that in the Security Considerations: "For SDP Security Descriptions key agreement [RFC4568], an authenticated signaling channel does not need to be used with OSRTP if it is not available, although an encrypted signaling channel must still be used." Did I get it wrong? > > 3. I would suggest that failure to negotiate a secure channel (for > DTLS-SRTP > and ZRTP) should lead to media failure not falling back. There's basically > no good reason for this to fail and it seems like it will make diagnosing > issues easier. > > I was on the fence about this one. Agree that it shouldn't happen for DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY modes. Should that really fail the whole session? > -Ekr > > > On Wed, Jul 8, 2015 at 9:17 AM, Alan Johnston > wrote: > >> Hi Martin, >> >> It is the version of the draft that is actually implemented and used. >> There are also a few slight differences due to the way that Opportunistic >> Security is defined. >> >> - Alan - >> >> On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson > > wrote: >> >>> How does this differ from: >>> https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01 >>> >>> On 8 July 2015 at 04:02, Alan Johnston >>> wrote: >>> > All, >>> > >>> > Many of us have been talking about "Best Effort SRTP" for many years, >>> and >>> > there are a number of deployments. In addition, the IMTC has >>> recommended >>> > it, and the SIP Forum would like to recommend it in SIPconnect 2.0 >>> which for >>> > the first time includes SRTP media. With the publication of RFC 7435 >>> > (https://tools.ietf.org/html/rfc7435), the IETF has endorsed this >>> approach >>> > as Opportunistic Security (OS), so it would be nice to bring standards >>> in >>> > line with industry practice. >>> > >>> > Comments on the draft, "An Opportunistic Approach for Secure Real-time >>> > Transport Protocol (OSRTP)" and the best way forward are most welcome! >>> > >>> > - Alan - >>> > >>> > ---------- Forwarded message ---------- >>> > From: >>> > Date: Mon, Jul 6, 2015 at 1:48 PM >>> > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt >>> > To: i-d-announce@ietf.org >>> > >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> > directories. >>> > >>> > >>> > Title : An Opportunistic Approach for Secure >>> Real-time >>> > Transport Protocol (OSRTP) >>> > Authors : Alan Johnston >>> > Bernard Aboba >>> > Andy Hutton >>> > Laura Liess >>> > Thomas Stach >>> > Filename : draft-johnston-dispatch-osrtp-00.txt >>> > Pages : 8 >>> > Date : 2015-07-06 >>> > >>> > Abstract: >>> > Opportunistic Secure Real-time Transport Protocol (OSRTP) allows >>> > encrypted media to be used in environments where support for >>> > encryption is not known in advance, and not required. OSRTP is an >>> > implementation of Opportunistic Security, as defined in RFC 7435. >>> > OSRTP does not require advanced SDP extensions or features and is >>> > fully backwards compatible with existing secure and insecure >>> > implementations. OSRTP is not specific to any key management >>> > technique for SRTP. >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ >>> > >>> > There's also a htmlized version available at: >>> > https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 >>> > >>> > >>> > Please note that it may take a couple of minutes from the time of >>> submission >>> > until the htmlized version and diff are available at tools.ietf.org. >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > I-D-Announce mailing list >>> > I-D-Announce@ietf.org >>> > https://www.ietf.org/mailman/listinfo/i-d-announce >>> > Internet-Draft directories: http://www.ietf.org/shadow.html >>> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> > >>> > >>> > _______________________________________________ >>> > 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 >> >> > --047d7bb03d969bc4fd051a618152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ekr,

Thanks for the feedback.=C2=A0 = See below. =C2=A0

More feedback on #3 from others = would be very helpful.

- Alan -

On Wed, Jul 8, 2015 at 1:00 PM= , Eric Rescorla <ekr@rtfm.com> wrote:
This seems like a good idea.

I have three comm= ents:

1. You should forbid the answerer from sendi= ng back two types of
keying parameters (e.g., a=3Dcrypto and a=3D= fingerprint) because that creates
confusion.

Agreed - I'll put that in.
=C2=A0

2. You probably sho= uldn't relax the need to send SDES over HTTPS because
the sec= urity properties there are still fairly bad.
<= br>
Right.=C2=A0 I tried to say that in the Security Consideratio= ns: "For SDP Security Descriptions key agreement [RFC4568], an authent= icated signaling channel does not need to be used with OSRTP if it is not a= vailable, although an encrypted signaling channel must still be used."= =C2=A0Did I get it wrong?
=C2=A0

3. I would suggest that failure to negotiate a= secure channel (for DTLS-SRTP
and ZRTP) should lead to media fai= lure not falling back. There's basically
no good reason for t= his to fail and it seems like it will make diagnosing
issues easi= er.


I was on the= fence about this one.=C2=A0 Agree that it shouldn't happen for DTLS-SR= TP or ZRTP, but I could imagine it happening for certain MIKEY modes.=C2=A0= Should that really fail the whole session?=C2=A0

= =C2=A0
-Ekr


On Wed, Jul 8, 2015 at 9:17 AM, Alan Johnston <alan.b.johnston@gm= ail.com> wrote:
Hi Marti= n,

It is the version of the draft that is actually imple= mented and used.=C2=A0 There are also a few slight differences due to the w= ay that Opportunistic Security is defined.

- Alan -

On Wed, Jul 8, 2015 at 11= :14 AM, Martin Thomson <martin.thomson@gmail.com> wro= te:
How does this differ from:
https://tools.ietf.org/html/draft= -kaplan-mmusic-best-effort-srtp-01

On 8 July 2015 at 04:02, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> Many of us have been talking about "Best Effort SRTP" for ma= ny years, and
> there are a number of deployments.=C2=A0 In addition, the IMTC has rec= ommended
> it, and the SIP Forum would like to recommend it in SIPconnect 2.0 whi= ch for
> the first time includes SRTP media.=C2=A0 With the publication of RFC = 7435
> (https://tools.ietf.org/html/rfc7435), the IETF has endo= rsed this approach
> as Opportunistic Security (OS), so it would be nice to bring standards= in
> line with industry practice.
>
> Comments on the draft, "An Opportunistic Approach for Secure Real= -time
> Transport Protocol (OSRTP)" and the best way forward are most wel= come!
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Mon, Jul 6, 2015 at 1:48 PM
> Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
> To: i-d-ann= ounce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: An Opportunistic Approach for Secure Real-time
> Transport Protocol (OSRTP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Alan Johnston
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Bernard Aboba
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy Hutton
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Laura Liess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Thomas Stach
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-johnston-dispatch-osrtp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-07-06
>
> Abstract:
>=C2=A0 =C2=A0 Opportunistic Secure Real-time Transport Protocol (OSRTP)= allows
>=C2=A0 =C2=A0 encrypted media to be used in environments where support = for
>=C2=A0 =C2=A0 encryption is not known in advance, and not required.=C2= =A0 OSRTP is an
>=C2=A0 =C2=A0 implementation of Opportunistic Security, as defined in R= FC 7435.
>=C2=A0 =C2=A0 OSRTP does not require advanced SDP extensions or feature= s and is
>=C2=A0 =C2=A0 fully backwards compatible with existing secure and insec= ure
>=C2=A0 =C2=A0 implementations.=C2=A0 OSRTP is not specific to any key m= anagement
>=C2=A0 =C2=A0 technique for SRTP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc= /draft-johnston-dispatch-osrtp/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-j= ohnston-dispatch-osrtp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>


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



--047d7bb03d969bc4fd051a618152-- From nobody Wed Jul 8 12:50:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2DC1A8737 for ; Wed, 8 Jul 2015 12:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fUUkqMnUk4W for ; Wed, 8 Jul 2015 12:50:21 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314FD1A872F for ; Wed, 8 Jul 2015 12:50:21 -0700 (PDT) Received: by ykee186 with SMTP id e186so17438221yke.2 for ; Wed, 08 Jul 2015 12:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T9YmVufp8q8E5Z/I1CJGNRLO/CDi+6JFGzQc+7jNJ4g=; b=gvH6UWoE/Z3GVZ+wzsbaLFFcR0RIV2eivPcCM3BZZs17iFMsJZ7fStSemxM9/Ldx5/ ch5tyejnzKU0ilIt8dXtP02KUe5keXQ5UY86z6qrozRqhQGUlFapHlFeRmgzvbrow8V6 36LqCvt/RyOH1/a/K5OOpJQnVuY7L/ZnnFpcGvwzilA9aibHJ2YGoqpdc2M0cJRJxyax Uhsqc/H8J9WapDB4qG1UjSZbSNAb6q6lVEY3xJReDp/Xa8t2UqIpmAXmLr4Gkyvkty7j IfUiwjFeuepgr9WAtFAmEGwPr+V+nQEFmVkAI4/wHltMVhP/3qaDEs7Hv2qTtEfKdSZU xRnA== MIME-Version: 1.0 X-Received: by 10.13.226.202 with SMTP id l193mr13622160ywe.89.1436385020629; Wed, 08 Jul 2015 12:50:20 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 8 Jul 2015 12:50:20 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 12:50:20 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:50:26 -0000 On 8 July 2015 at 11:42, Alan Johnston wrote: > I was on the fence about this one. Agree that it shouldn't happen for > DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY modes. > Should that really fail the whole session? At the point that you have established that both peers support a common baseline, accepting downgrade from that baseline removes any of the benefit that an opportunistic upgrade provided. An attacker that can't attack your signaling now has a chance to downgrade you. I've no good information on what MIKEY mode might fail and how, but that seems like a problem you could address specifically without weakening other options. From nobody Wed Jul 8 13:25:16 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679F01A8789 for ; Wed, 8 Jul 2015 13:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 wMBYgezJwuh1 for ; Wed, 8 Jul 2015 13:25:12 -0700 (PDT) Received: from mail-vn0-f50.google.com (mail-vn0-f50.google.com [209.85.216.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CC41A8782 for ; Wed, 8 Jul 2015 13:25:12 -0700 (PDT) Received: by vnbf62 with SMTP id f62so32361207vnb.9 for ; Wed, 08 Jul 2015 13:25:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xX6Uz9FLFRPFavBCgrO2txkQctDo2pit+s7bBwoiANU=; b=a++WQIRbLNWF+B6XBvkC/ZJiNY/Gm5tIPKw2veOoIGiurRarbxJW89koDxOHZG80lE pSYDN3ChNy+0Bq4/ctfeMEJGD/BTZ+GcLbvdn46DrhHsQJBxY89DFeRm6qECGio6ZVwy lHXOFiCM4NHOl79l3n/mZByL1FsfI4QTzzSeVM95OVNrpKQqLWmqLi04f4DHdqIDn6LI K+sEMgy8807ncwCTufT/trnLbLOw9wVluCXvnrrZLCLdQxtYuDY/cBVN5cu9SOcYfSEy +P4ZntcralVyVCbVFi7+BYHB1fQnGkKCNM6OiOilhteIt3xigjLL9m6jrKSwMm1NOgPS quGg== X-Gm-Message-State: ALoCoQlSQvQwVNs9z/ozBer+jKvsPu+RZMsdCzDYIAfkLorPDrJnx84h7CwixO1STKzk2cIL5nzp MIME-Version: 1.0 X-Received: by 10.52.139.105 with SMTP id qx9mr11731381vdb.81.1436387111378; Wed, 08 Jul 2015 13:25:11 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Wed, 8 Jul 2015 13:25:11 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 16:25:11 -0400 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 20:25:14 -0000 On Wed, Jul 8, 2015 at 3:50 PM, Martin Thomson wrote: > On 8 July 2015 at 11:42, Alan Johnston wrote: >> I was on the fence about this one. Agree that it shouldn't happen for >> DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY modes. >> Should that really fail the whole session? > > At the point that you have established that both peers support a > common baseline, accepting downgrade from that baseline removes any of > the benefit that an opportunistic upgrade provided. An attacker that > can't attack your signaling now has a chance to downgrade you. +1 The idea is "opportunistic" in the sense of "if both peers can negotiate in signaling", not in the sense of "keep going if the security fails". > I've no good information on what MIKEY mode might fail and how, but > that seems like a problem you could address specifically without > weakening other options. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jul 8 13:30:51 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32791A8790 for ; Wed, 8 Jul 2015 13:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 cyYEiNXjvlXO for ; Wed, 8 Jul 2015 13:30:47 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D43A1A878E for ; Wed, 8 Jul 2015 13:30:47 -0700 (PDT) Received: by wgov12 with SMTP id v12so21282121wgo.1 for ; Wed, 08 Jul 2015 13:30:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Pg4lU5y1AFUqKZlJLyIOJhgkHcSX/jg5pN28KlUU4DY=; b=X73FZ3zbSBXPD3H2+sPNR8QDbBdc0gs4feoqlJtJaU39QVlTVNLkF8iQIK2E7TgQFR DIsBeddVbTBn+uG2kd9hiMsLtHLI6dRrnVAvDBPwAmzG0bvtCOCT9J/0da9GuHetWBfH cy1ivl+3VHnntpF0VoskXx97nAHdEdz52IfR5YAzEXiRvyz5LM6HrUU73wO5LNkOD9y/ BrTBnqoFyK0MrrEF45RaPxuzP3EajRalTzUM3BXvJxUHhWYRAwRCsT0CkIqm+wfe0hAo 02zV7E9RECmQ6xisy4+xmUlfyu8FS7I8i79MGMARuWOqlGEndLcbNRrKTrr0j96Xptnl ILqw== X-Gm-Message-State: ALoCoQnysMBRSL4Gem3M6jubZVZ+Br0FsLeJNSRHHLTqFZloXg1dMZJmVrevh4SLPzt/lVpgLKpZ X-Received: by 10.194.133.73 with SMTP id pa9mr22876892wjb.148.1436387445718; Wed, 08 Jul 2015 13:30:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Wed, 8 Jul 2015 13:30:06 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 8 Jul 2015 13:30:06 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=089e011771a9765c99051a630339 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 20:30:49 -0000 --089e011771a9765c99051a630339 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 8, 2015 at 11:42 AM, Alan Johnston wrote: > Hi Ekr, > > Thanks for the feedback. See below. > > More feedback on #3 from others would be very helpful. > > - Alan - > > On Wed, Jul 8, 2015 at 1:00 PM, Eric Rescorla wrote: > >> This seems like a good idea. >> >> I have three comments: >> >> 1. You should forbid the answerer from sending back two types of >> keying parameters (e.g., a=crypto and a=fingerprint) because that creates >> confusion. >> > > Agreed - I'll put that in. > > >> >> 2. You probably shouldn't relax the need to send SDES over HTTPS because >> the security properties there are still fairly bad. >> > > Right. I tried to say that in the Security Considerations: "For SDP > Security Descriptions key agreement [RFC4568], an authenticated signaling > channel does not need to be used with OSRTP if it is not available, > although an encrypted signaling channel must still be used." Did I get it > wrong? > No, the problem is on my end. 3. I would suggest that failure to negotiate a secure channel (for DTLS-SRTP >> and ZRTP) should lead to media failure not falling back. There's basically >> no good reason for this to fail and it seems like it will make diagnosing >> issues easier. >> >> > I was on the fence about this one. Agree that it shouldn't happen for > DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY > modes. Should that really fail the whole session? > I don't have a strong opinion about MIKEY on this one. -Ekr > >> -Ekr >> >> >> On Wed, Jul 8, 2015 at 9:17 AM, Alan Johnston >> wrote: >> >>> Hi Martin, >>> >>> It is the version of the draft that is actually implemented and used. >>> There are also a few slight differences due to the way that Opportunistic >>> Security is defined. >>> >>> - Alan - >>> >>> On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson < >>> martin.thomson@gmail.com> wrote: >>> >>>> How does this differ from: >>>> https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01 >>>> >>>> On 8 July 2015 at 04:02, Alan Johnston >>>> wrote: >>>> > All, >>>> > >>>> > Many of us have been talking about "Best Effort SRTP" for many years, >>>> and >>>> > there are a number of deployments. In addition, the IMTC has >>>> recommended >>>> > it, and the SIP Forum would like to recommend it in SIPconnect 2.0 >>>> which for >>>> > the first time includes SRTP media. With the publication of RFC 7435 >>>> > (https://tools.ietf.org/html/rfc7435), the IETF has endorsed this >>>> approach >>>> > as Opportunistic Security (OS), so it would be nice to bring >>>> standards in >>>> > line with industry practice. >>>> > >>>> > Comments on the draft, "An Opportunistic Approach for Secure Real-time >>>> > Transport Protocol (OSRTP)" and the best way forward are most welcome! >>>> > >>>> > - Alan - >>>> > >>>> > ---------- Forwarded message ---------- >>>> > From: >>>> > Date: Mon, Jul 6, 2015 at 1:48 PM >>>> > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt >>>> > To: i-d-announce@ietf.org >>>> > >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line Internet-Drafts >>>> > directories. >>>> > >>>> > >>>> > Title : An Opportunistic Approach for Secure >>>> Real-time >>>> > Transport Protocol (OSRTP) >>>> > Authors : Alan Johnston >>>> > Bernard Aboba >>>> > Andy Hutton >>>> > Laura Liess >>>> > Thomas Stach >>>> > Filename : draft-johnston-dispatch-osrtp-00.txt >>>> > Pages : 8 >>>> > Date : 2015-07-06 >>>> > >>>> > Abstract: >>>> > Opportunistic Secure Real-time Transport Protocol (OSRTP) allows >>>> > encrypted media to be used in environments where support for >>>> > encryption is not known in advance, and not required. OSRTP is an >>>> > implementation of Opportunistic Security, as defined in RFC 7435. >>>> > OSRTP does not require advanced SDP extensions or features and is >>>> > fully backwards compatible with existing secure and insecure >>>> > implementations. OSRTP is not specific to any key management >>>> > technique for SRTP. >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 >>>> > >>>> > >>>> > Please note that it may take a couple of minutes from the time of >>>> submission >>>> > until the htmlized version and diff are available at tools.ietf.org. >>>> > >>>> > Internet-Drafts are also available by anonymous FTP at: >>>> > ftp://ftp.ietf.org/internet-drafts/ >>>> > >>>> > _______________________________________________ >>>> > I-D-Announce mailing list >>>> > I-D-Announce@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/i-d-announce >>>> > Internet-Draft directories: http://www.ietf.org/shadow.html >>>> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >>> >> > --089e011771a9765c99051a630339 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 8, 2015 at 11:42 AM, Alan Johnston <alan.b.johnsto= n@gmail.com> wrote:
Hi Ekr,

Thanks for the feedback.=C2=A0 See bel= ow. =C2=A0

More feedback on #3 from others would b= e very helpful.

- Alan -

On Wed, Jul 8, 2015 = at 1:00 PM, Eric Rescorla <ekr@rtfm.com> wrote:
This seems like a good idea.

I have = three comments:

1. You should forbid the answerer = from sending back two types of
keying parameters (e.g., a=3Dcrypt= o and a=3Dfingerprint) because that creates
confusion.

Agreed - I'll put that in.
=C2=A0
=
2. You probably shouldn't relax the need to send SDES ov= er HTTPS because
the security properties there are still fairly b= ad.

Right.=C2=A0 I tried= to say that in the Security Considerations: "For SDP Security Descrip= tions key agreement [RFC4568], an authenticated signaling channel does not = need to be used with OSRTP if it is not available, although an encrypted si= gnaling channel must still be used." =C2=A0Did I get it wrong?

No, the problem is on my e= nd.


3. I would suggest that fail= ure to negotiate a secure channel (for DTLS-SRTP
and ZRTP) should= lead to media failure not falling back. There's basically
no= good reason for this to fail and it seems like it will make diagnosing
issues easier.


I was on the fence about this one.=C2=A0 Agree that it shouldn= 't happen for DTLS-SRTP or ZRTP, but I could imagine it happening for c= ertain MIKEY modes.=C2=A0 Should that really fail the whole session?=C2=A0<= /div>

I don't have a = strong opinion about MIKEY on this one.

-Ekr
=

=C2= =A0
-Ekr
<= br>

On= Wed, Jul 8, 2015 at 9:17 AM, Alan Johnston <alan.b.johnston@gma= il.com> wrote:
Hi Martin= ,

It is the version of the draft that is actually implem= ented and used.=C2=A0 There are also a few slight differences due to the wa= y that Opportunistic Security is defined.

- Alan -

On Wed, Jul 8, 2015 at 11:= 14 AM, Martin Thomson <martin.thomson@gmail.com> wrot= e:
How does this differ from:
https://tools.ietf.org/html/draft= -kaplan-mmusic-best-effort-srtp-01

On 8 July 2015 at 04:02, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> Many of us have been talking about "Best Effort SRTP" for ma= ny years, and
> there are a number of deployments.=C2=A0 In addition, the IMTC has rec= ommended
> it, and the SIP Forum would like to recommend it in SIPconnect 2.0 whi= ch for
> the first time includes SRTP media.=C2=A0 With the publication of RFC = 7435
> (https://tools.ietf.org/html/rfc7435), the IETF has endo= rsed this approach
> as Opportunistic Security (OS), so it would be nice to bring standards= in
> line with industry practice.
>
> Comments on the draft, "An Opportunistic Approach for Secure Real= -time
> Transport Protocol (OSRTP)" and the best way forward are most wel= come!
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Mon, Jul 6, 2015 at 1:48 PM
> Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
> To: i-d-ann= ounce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: An Opportunistic Approach for Secure Real-time
> Transport Protocol (OSRTP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Alan Johnston
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Bernard Aboba
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy Hutton
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Laura Liess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Thomas Stach
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-johnston-dispatch-osrtp-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-07-06
>
> Abstract:
>=C2=A0 =C2=A0 Opportunistic Secure Real-time Transport Protocol (OSRTP)= allows
>=C2=A0 =C2=A0 encrypted media to be used in environments where support = for
>=C2=A0 =C2=A0 encryption is not known in advance, and not required.=C2= =A0 OSRTP is an
>=C2=A0 =C2=A0 implementation of Opportunistic Security, as defined in R= FC 7435.
>=C2=A0 =C2=A0 OSRTP does not require advanced SDP extensions or feature= s and is
>=C2=A0 =C2=A0 fully backwards compatible with existing secure and insec= ure
>=C2=A0 =C2=A0 implementations.=C2=A0 OSRTP is not specific to any key m= anagement
>=C2=A0 =C2=A0 technique for SRTP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc= /draft-johnston-dispatch-osrtp/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-j= ohnston-dispatch-osrtp-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>


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




--089e011771a9765c99051a630339-- From nobody Thu Jul 9 18:18:35 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDE71A1B76 for ; Thu, 9 Jul 2015 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frH1qq7okYhf for ; Thu, 9 Jul 2015 18:18:33 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015FF1A1AB9 for ; Thu, 9 Jul 2015 18:18:33 -0700 (PDT) Received: by widjy10 with SMTP id jy10so2863804wid.1 for ; Thu, 09 Jul 2015 18:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GGhnf2DSIUSKiAwmqIJxpn2mQo6KVqlpf8y3cBR2aiM=; b=u0nQttGsrQpwI2D/HF/qU5ERU6o6i2heNppL3osXoTOlizocXT+Xt1zhV6A4cHA6RG ZF/IOBgBwsr8SnOF028WybMq9mSX0DAaXWVWhufNEpcP6FPZaNCX5+iJ4Xm/8j5UHaPq Tpf/XER2o1O9bzGJyO07gACVo37rBkHIWc90+2Rc1Jk9FkreB/22eAjoyhH0yj8fthHU mAzmiwA1TLYRbSe1Ir+XaMKKHY8rZcyzfhGmI2zeKCAN1AmeYFGZGQNhX3RzJOFda8aP E7m/psdtz7OEK2pZBsfsCahsMpP93d3hT5NUTS1WiyvQv+cOHcvyifJ6f9WGXQ+nWhsF pIoQ== MIME-Version: 1.0 X-Received: by 10.194.75.132 with SMTP id c4mr33844547wjw.80.1436491111806; Thu, 09 Jul 2015 18:18:31 -0700 (PDT) Received: by 10.28.155.202 with HTTP; Thu, 9 Jul 2015 18:18:31 -0700 (PDT) In-Reply-To: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> Date: Thu, 9 Jul 2015 20:18:31 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bb04b7c713e68051a7b26d2 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 01:18:34 -0000 --047d7bb04b7c713e68051a7b26d2 Content-Type: text/plain; charset=UTF-8 Martin, That makes perfect sense. I'll change it in the next version to fail the session if the key agreement fails. - Alan - On Wed, Jul 8, 2015 at 2:50 PM, Martin Thomson wrote: > On 8 July 2015 at 11:42, Alan Johnston wrote: > > I was on the fence about this one. Agree that it shouldn't happen for > > DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY > modes. > > Should that really fail the whole session? > > At the point that you have established that both peers support a > common baseline, accepting downgrade from that baseline removes any of > the benefit that an opportunistic upgrade provided. An attacker that > can't attack your signaling now has a chance to downgrade you. > > I've no good information on what MIKEY mode might fail and how, but > that seems like a problem you could address specifically without > weakening other options. > --047d7bb04b7c713e68051a7b26d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

That makes perfect sense.=C2=A0= I'll change it in the next version to fail the session if the key agre= ement fails.

- Alan -=C2=A0

On Wed, Jul 8, 2015 at 2:50= PM, Martin Thomson <martin.thomson@gmail.com> wrote:=
On 8 July 2015 at 11:42, Alan Johnston &= lt;alan.b.johnston@gmail.com> wrote:
> I was on the fence about this one.=C2=A0 Agree that it shouldn't h= appen for
> DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY = modes.
> Should that really fail the whole session?

At the point that you have established that both peers support a
common baseline, accepting downgrade from that baseline removes any of
the benefit that an opportunistic upgrade provided.=C2=A0 An attacker that<= br> can't attack your signaling now has a chance to downgrade you.

I've no good information on what MIKEY mode might fail and how, but
that seems like a problem you could address specifically without
weakening other options.

--047d7bb04b7c713e68051a7b26d2-- From nobody Wed Jul 15 13:15:49 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5CA1AD074 for ; Wed, 15 Jul 2015 13:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrWz_tET_z9l for ; Wed, 15 Jul 2015 13:15:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423271ACECF for ; Wed, 15 Jul 2015 13:15:30 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6FKFIbj033672 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2015 15:15:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: DISPATCH , appsawg@ietf.org Date: Wed, 15 Jul 2015 15:15:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: [dispatch] draft-campbell-art-rfc5727-update-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 20:15:48 -0000 Hi, RFC5727 describes the SIP Change process, part of which is the DISPATCH process. Much of the language in that RFC was "hard-coded" to RAI and its working group structure. While the concepts are still valid, some of the language has become obsolete since we've combined APP and RAI into ART. The ART ADs have written an draft that seeks to correct that, and also to generalize the dispatch process so it can be used by other working groups and areas. We wrote this as an update rather than a "bis" draft, in order focus on the organizational changes and keep the "good parts" of RFC 5727 intact. Please comment. https://tools.ietf.org/html/draft-campbell-art-rfc5727-update-02 Thanks! Ben. From nobody Wed Jul 15 13:18:29 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5031AD36F; Wed, 15 Jul 2015 13:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DzkaXPejV6v; Wed, 15 Jul 2015 13:18:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44FB1AD364; Wed, 15 Jul 2015 13:18:24 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6FKIEIZ033936 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2015 15:18:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: DISPATCH , "IETF Apps Discuss" Date: Wed, 15 Jul 2015 15:18:13 -0500 Message-ID: <521E2A2C-D25E-4B54-B038-CBA0A44D877B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: [dispatch] draft-campbell-art-rfc5727-update-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 20:18:27 -0000 [oops, resending with the correct address for the appsawg.] Hi, RFC5727 describes the SIP Change process, part of which is the DISPATCH process. Much of the language in that RFC was "hard-coded" to RAI and its working group structure. While the concepts are still valid, some of the language has become obsolete since we've combined APP and RAI into ART. The ART ADs have written an draft that seeks to correct that, and also to generalize the dispatch process so it can be used by other working groups and areas. We wrote this as an update rather than a "bis" draft, in order focus on the organizational changes and keep the "good parts" of RFC 5727 intact. Please comment. https://tools.ietf.org/html/draft-campbell-art-rfc5727-update-02 Thanks! Ben. From nobody Thu Jul 16 07:51:40 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FDF1A00DC for ; Thu, 16 Jul 2015 07:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, SPF_SOFTFAIL=0.665] 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 IMD8ghHcYazG for ; Thu, 16 Jul 2015 07:51:37 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99B91A0364 for ; Thu, 16 Jul 2015 07:51:21 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-07v.sys.comcast.net with comcast id t2pd1q0092JGN3p012rMqo; Thu, 16 Jul 2015 14:51:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-10v.sys.comcast.net with comcast id t2rL1q00j3Ge9ey012rMD4; Thu, 16 Jul 2015 14:51:21 +0000 Message-ID: <55A7C4E7.2090504@alum.mit.edu> Date: Thu, 16 Jul 2015 10:51:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> In-Reply-To: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437058281; bh=QT7X8Dz+hyItDyAA+urBhSXIjthzdD7ClStjkBnzfAc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XtB3ax3ZDXiSkQBrzpL8m5AGhIzIgImX0t/Hsn+WMl3O5EzTifkAY/KI3AqfFhbGn qaqO7QnnhAgVgCfEnOfyBQWNTN95cNJzgfW0oIgCGtS4XGkLkul7K3OOhlF1h71TpC u6LtVbFcc5zcWAY/qPgGTlh2paS33zM8Pvt9JJBeHEAwz9kh4cI02NnzL6NxsS7vcn DMOIsc/JYjpD71ovyYt/nrE70Evd/2jgu0i8NOn0FDBxPs5apIeTdKxs0iy+OjrYKM 5RWhjd5092Y3Gp1g/NoPik7CEsovQqH4ZsLwehFEENNbXfnf417TKRO+nWAx+8IdRK p9SNTwulRYTRQ== Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 14:51:38 -0000 James, I was just looking at this draft. I don't understand what assumptions it is making regarding trust model. Is this intended specifically for 3gpp and its trust model? Section 4 says: If a proxy receives a message from an untrusted source with the loc-src parameter set then it MUST remove the loc-src parameter before passing the message into a trusted network. Are we assuming a Spec(t) as defined in 3325? And is that enough? The obvious issue is the potential for somebody to lie about the location source. Also, the location is specified as a 'host'. I assume you mean that as defined in 3261, where it is defined as: host = hostname / IPv4address / IPv6reference Is it really meaningful to use an IP? Is the expectation that the recipient will simply use these with a whitelist or blacklist to determine preferences? Or else how will it be used? Thanks, Paul On 6/23/15 5:11 AM, James Winterbottom wrote: > Hi All, > > I a notice about this draft a few weeks ago but haven’t seen and follow up discussion. > This work is required in ETSI and I believe that as I understand from some 3GPP folks they would like something similar to this also. > > https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-00 > > I am just not sure where the right final home for it is. > > Cheers > James > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Jul 16 13:23:38 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB881A8A8B for ; Thu, 16 Jul 2015 13:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7] 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 oPSy87HfTAyI for ; Thu, 16 Jul 2015 13:23:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236271A8A43 for ; Thu, 16 Jul 2015 13:22:41 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7F111207F2 for ; Thu, 16 Jul 2015 16:22:40 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 16 Jul 2015 16:22:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=KwkWUfZFhzqZ7CoE1vjaofqmyP8 =; b=JEXyXFUHNwO8scIQbjTER5DalvbTY+kXv3vV2p9NwcTyGGRsXulbt6Jizf1 Csp5rUAmIvTSJnZT6Bd0e3q6+CzvOrKHsFhqnr7tYQmKByx30hyKkoUuhndHrcb5 RWLJT62luL11NcdwFesKruU8AU7wNoJ1NRFplqbXiYH5lk7Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Kw kWUfZFhzqZ7CoE1vjaofqmyP8=; b=PcI6CWZN08mrTwfqiS3RgVbgoTTW6xkhY8 E05eKQeDhYtwbptZPm4rYA9XmyPTDxBWR5ZbIFoQeG0eI7vPDb/W+B+NZcohV5Lq RcMEy5YqvNRXFxUPSk9aLeTri9cExfX92yawiNKyE2E/CFWcp8dtSOaIhp5nBaw2 HFSZqS6Hg= X-Sasl-enc: hzZEkaI/5gb6C7ShFmBuQm0X6AZSYMl1uoxm5zMTE3aS 1437078160 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id EEAFD6800FF for ; Thu, 16 Jul 2015 16:22:39 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_26F9BC16-529D-4C4D-A41D-AED0C9AC2B12" Message-Id: Date: Thu, 16 Jul 2015 13:22:37 -0700 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [dispatch] geojson charter suggestion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 20:23:36 -0000 --Apple-Mail=_26F9BC16-529D-4C4D-A41D-AED0C9AC2B12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was looking at the proposed geojson charter [1] and back at the = minutes from dispatch at IETF 92 [2]. As discussed at IETF 92, the = charter needs to be clearer about the relationship to the work done in = geopriv. I think there is text from RFC 5870 that can be adapted for = this purpose, at least partially. I would suggest adding something along = the following lines to the charter: GeoJSON objects represent geographic features only and do not specify = associations between geographic features and particular devices, users, = or facilities. Any association with a particular device, user, or = facility requires another protocol. As such, a GeoJSON object does not = fit the "Location Information" definition according to Section 5.2 of = RFC 3693, because there is not necessarily a "Device" involved. Because = there is also no way to specify the identity of a "Target" within the = confines of a GeoJSON object, it also does not fit the specification of = a "Location Object" (Section 5.2 of RFC 3693, Section 3.2 of RFC 6280). = When a GeoJSON object is used in a context where it identifies the = location of a Target, it becomes subject to the architectural, security, = and privacy considerations in RFC 6280. The application of those = considerations is specific to protocols that make use of GeoJSON objects = and is out of scope for the GeoJSON WG. Alissa [1] https://github.com/geojson/draft-geojson/blob/master/charter.md/ [2] https://www.ietf.org/proceedings/92/minutes/minutes-92-dispatch= --Apple-Mail=_26F9BC16-529D-4C4D-A41D-AED0C9AC2B12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I was = looking at the proposed geojson charter [1] and back at the minutes from = dispatch at IETF 92 [2]. As discussed at IETF 92, the charter needs to = be clearer about the relationship to the work done in geopriv. I think = there is text from RFC 5870 that can be adapted for this purpose, at = least partially. I would suggest adding something along the following = lines to the charter:

GeoJSON objects represent = geographic features only and do not specify associations between = geographic features and particular devices, users, or facilities. Any = association with a particular device, user, or facility requires another = protocol. As such, a GeoJSON object does not fit the "Location = Information" definition according to Section 5.2 of RFC 3693, because = there is not necessarily a "Device" involved. Because there is also no = way to specify the identity of a "Target" within the confines of a = GeoJSON object, it also does not fit the specification of a "Location = Object" (Section 5.2 of RFC 3693, Section 3.2 of RFC 6280). When a = GeoJSON object is used in a context where it identifies the location of = a Target, it becomes subject to the architectural, security, and privacy = considerations in RFC 6280. The application of those considerations is = specific to protocols that make use of GeoJSON objects and is out of = scope for the GeoJSON = WG.

Alissa

= = --Apple-Mail=_26F9BC16-529D-4C4D-A41D-AED0C9AC2B12-- From nobody Sat Jul 18 18:49:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8681A1BBC for ; Sat, 18 Jul 2015 18:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, 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 ATqRJroDQZDa for ; Sat, 18 Jul 2015 18:49:57 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B03D1A1A34 for ; Sat, 18 Jul 2015 18:49:57 -0700 (PDT) Received: by pacan13 with SMTP id an13so82295138pac.1 for ; Sat, 18 Jul 2015 18:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IM/GQjjnM2dd9LKz7wPgrDkHGiNYNk264TBf6XoKYAc=; b=pKScrK3gajKkqDz13EEOFbiiM1tudSDix42OhTlZNY7t4B0WUO+yEtWDgr1OSH8FOa qUIwaNSS0ihdOvPIEVkrL7OzOqztg3M0n8Czh4c02JykuFfH9qQD/at+jY72dJOvvvtB 6wGmA9KNXhdclR/C3dfrDnRAUbW9YxVQic4Laj3vx4BlnYYMkFOaBSNGn0d5uqbLmJSc wCAEWWUlYAwxXSN4RAQ2oOaNboJBn+fwWcvgAvfszpqEOtIWRvTjsI549LAR1XfI1dEo I7kBxxN+FB9NNoMKByrwDhebjunOLSqHATZU8gpI5TbUGrBKCizxugGT+3MvqUvget6g h50Q== X-Received: by 10.66.234.101 with SMTP id ud5mr43563137pac.23.1437270596942; Sat, 18 Jul 2015 18:49:56 -0700 (PDT) Received: from [192.168.1.100] ([1.129.65.6]) by smtp.gmail.com with ESMTPSA id gi6sm15481352pbd.69.2015.07.18.18.49.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jul 2015 18:49:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: <55A7C4E7.2090504@alum.mit.edu> Date: Sun, 19 Jul 2015 11:49:52 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> <55A7C4E7.2090504@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2098) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 01:49:58 -0000 Hi Paul, Thanks for the comments. I will get to the questions in a second. I just wanted to say that draft = is kind of a stawman to indicate what we would like to do and what we = had in mind, we are totally aware that it needs work, we just want to = get it to the right group to get the work done. I can answer the second set of questions quickly, I will need to look up = the 3325 question. Yes, somebody could lie, but if we were to assume some kind of trusted = network then there are a multitude of other things that they could also = lie about couldn=E2=80=99t they?=20 Yes, I was referring to the host from 3261, and I agree that an IP = address make little sense. Is there are a better way to specify what we = are looking for? I was thinking some kind of whitelist if terms of preference (how this = gets created I see as being largely out of scope), I am not sure how = much sense it makes to have a blacklist. Cheers James > On 17 Jul 2015, at 12:51 am, Paul Kyzivat = wrote: >=20 > James, >=20 > I was just looking at this draft. I don't understand what assumptions = it is making regarding trust model. Is this intended specifically for = 3gpp and its trust model? Section 4 says: >=20 > If a proxy receives a message > from an untrusted source with the loc-src parameter set then it MUST > remove the loc-src parameter before passing the message into a > trusted network. >=20 > Are we assuming a Spec(t) as defined in 3325? >=20 > And is that enough? The obvious issue is the potential for somebody to = lie about the location source. >=20 > Also, the location is specified as a 'host'. I assume you mean that as = defined in 3261, where it is defined as: >=20 > host =3D hostname / IPv4address / IPv6reference >=20 > Is it really meaningful to use an IP? >=20 > Is the expectation that the recipient will simply use these with a = whitelist or blacklist to determine preferences? Or else how will it be = used? >=20 > Thanks, > Paul >=20 > On 6/23/15 5:11 AM, James Winterbottom wrote: >> Hi All, >>=20 >> I a notice about this draft a few weeks ago but haven=E2=80=99t seen = and follow up discussion. >> This work is required in ETSI and I believe that as I understand from = some 3GPP folks they would like something similar to this also. >>=20 >> https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-00 >>=20 >> I am just not sure where the right final home for it is. >>=20 >> Cheers >> James >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Jul 19 10:27:20 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC91A1B30 for ; Sun, 19 Jul 2015 10:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, SPF_SOFTFAIL=0.665] 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 EK8wW3qlXnsk for ; Sun, 19 Jul 2015 10:27:17 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AA41A871A for ; Sun, 19 Jul 2015 10:27:17 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-07v.sys.comcast.net with comcast id uHSy1q0022D5gil01HTGW6; Sun, 19 Jul 2015 17:27:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id uHTG1q00F3Ge9ey01HTGCv; Sun, 19 Jul 2015 17:27:16 +0000 Message-ID: <55ABDDF3.8000902@alum.mit.edu> Date: Sun, 19 Jul 2015 13:27:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: James Winterbottom References: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> <55A7C4E7.2090504@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437326836; bh=jlMORw59yglRBgSDeu8tSG6HwecQ0sur6Wt4TIIZnEs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=l/Omcq6fCb1+gtJ5kOxC3SQw/Sj8Ryol+McelpztVLhjwO86s3xaXFGm6z0lT9Ljm zHwn2qXWQdgcG5Hb4oQtWZ+Jq7lkgsWek5uVZuSE5lTUHQbs03AOUT8Nq0ZLB+DVmG 3aD0hvyKUMmi9Fpt4KqQZR9QIgtadHpqKCY5I/dNCoKvUTt0FFIy2NCnA2qVO5lpmr rAEjTiKERp12UthIIb3dCmS5DAcHYyS/pj71IsIyct82tZjVhJcgxRmKcEybNrUrCs YgMCxFPpSrCZPDD1V8rstOveXJ253bnfzuavUTuXWEE2lx9NEQSRi/uP6SXEYkefKq fpLmUwGQan54w== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 17:27:19 -0000 On 7/18/15 9:49 PM, James Winterbottom wrote: > Hi Paul, > > Thanks for the comments. > > I will get to the questions in a second. I just wanted to say that draft is kind of a stawman to indicate what we would like to do and what we had in mind, we are totally aware that it needs work, we just want to get it to the right group to get the work done. OK. It helps to know that. > I can answer the second set of questions quickly, I will need to look up the 3325 question. > > Yes, somebody could lie, but if we were to assume some kind of trusted network then there are a multitude of other things that they could also lie about couldn’t they? Ideally there would be some way of signing the assertion, proving a right to use that name. Something like the stuff STIR is working on. But the STIR work won't cover this. > Yes, I was referring to the host from 3261, and I agree that an IP address make little sense. Is there are a better way to specify what we are looking for? If IP makes no sense, then you could simply require 'hostname'. > I was thinking some kind of whitelist if terms of preference (how this gets created I see as being largely out of scope), I am not sure how much sense it makes to have a blacklist. If that is the case, then I guess maybe a proxy inserting this may not want to insert the actual hostname of itself - it may want to insert a more general hostname for the domain it represents, since otherwise the whitelist might get long, or else might have to consist of patterns that match multiple hostnames. Thanks, Paul > Cheers > James > >> On 17 Jul 2015, at 12:51 am, Paul Kyzivat wrote: >> >> James, >> >> I was just looking at this draft. I don't understand what assumptions it is making regarding trust model. Is this intended specifically for 3gpp and its trust model? Section 4 says: >> >> If a proxy receives a message >> from an untrusted source with the loc-src parameter set then it MUST >> remove the loc-src parameter before passing the message into a >> trusted network. >> >> Are we assuming a Spec(t) as defined in 3325? >> >> And is that enough? The obvious issue is the potential for somebody to lie about the location source. >> >> Also, the location is specified as a 'host'. I assume you mean that as defined in 3261, where it is defined as: >> >> host = hostname / IPv4address / IPv6reference >> >> Is it really meaningful to use an IP? >> >> Is the expectation that the recipient will simply use these with a whitelist or blacklist to determine preferences? Or else how will it be used? >> >> Thanks, >> Paul >> >> On 6/23/15 5:11 AM, James Winterbottom wrote: >>> Hi All, >>> >>> I a notice about this draft a few weeks ago but haven’t seen and follow up discussion. >>> This work is required in ETSI and I believe that as I understand from some 3GPP folks they would like something similar to this also. >>> >>> https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-00 >>> >>> I am just not sure where the right final home for it is. >>> >>> Cheers >>> James >>> >>> _______________________________________________ >>> 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 > > From nobody Tue Jul 21 02:09:10 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57621B2C3E for ; Tue, 21 Jul 2015 02:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ov2MNnjFDbZ6 for ; Tue, 21 Jul 2015 02:09:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3D51B2C30 for ; Tue, 21 Jul 2015 02:09:03 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 669241901B5; Tue, 21 Jul 2015 11:09:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2C0EC1580A9; Tue, 21 Jul 2015 11:09:01 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0235.001; Tue, 21 Jul 2015 11:09:00 +0200 From: To: Mary Barnes , "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-mohali-dispatch-cause-for-service-number-03.txt Thread-Index: AdDDlM+kVN2w+uD/QbCQUggjZIRPKw== Date: Tue, 21 Jul 2015 09:09:00 +0000 Message-ID: <19574_1437469741_55AE0C2D_19574_364_2_8B970F90C584EA4E97D5BAAC9172DBB81574DA5A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81574DA5AOPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.92416 Archived-At: Cc: Ben Campbell Subject: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:09:09 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81574DA5AOPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyeSBhbmQgYWxsLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCBhbmQgY29u c3RydWN0aXZlIHJldmlldyBvZiB0aGUgZHJhZnQuDQpJbiB0aGlzIG5ldyB2ZXJzaW9uIEkgaW5j bHVkZWQgeW91ciBzdWdnZXN0aW9ucyBhbmQgY2hhbmdlZCB0aGUgc3RydWN0dXJlIG9mIHRoZSBz ZWN0aW9ucy4NCkFkZGl0aW9uYWwgcG9zc2libGUgdXNlIGNhc2VzIGFuZCBpbmZvcm1hdGlvbiBv biBob3cgdGhlIG5ldyB2YWx1ZSBoYXMgdG8gYmUgdXNlZCBhcmUgZGVzY3JpYmUgdG8gcHJvdmlk ZSBiZXR0ZXIgZ3VpZGVsaW5lcyBmb3IgaW1wbGVtZW50b3JzLg0KVGhlIGNhbGwgZmxvdyBoYXMg YmVlbiBlbmhhbmNlZCB3aXRoIHNvbWUgYWRkaXRpb25hbCBleHBsYW5hdGlvbnMuDQoNCllvdSBj YW4gZmluZCB0aGUgbmV3IHZlcnNpb24gLTAzIG9mIHRoZSBkcmFmdCBoZXJlOg0KDQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1vaGFs aS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDMudHh0DQoNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb2hhbGktZGlzcGF0 Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLw0KDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2Vydmlj ZS1udW1iZXItMDMNCg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTAz DQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJpYW5uZSBNb2hhbGkNCg0KRGUgOiBNYXJ5IEJhcm5l cyBbbWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tXQ0KRW52b3nDqSA6IHZlbmRyZWRp IDIyIG1haSAyMDE1IDAxOjUwDQrDgCA6IE1PSEFMSSBNYXJpYW5uZSBJTVQvT0xODQpDYyA6IGRp c3BhdGNoQGlldGYub3JnOyBCZW4gQ2FtcGJlbGwNCk9iamV0IDogQ29tbWVudHM6IGRyYWZ0LW1v aGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDIudHh0DQoNCkluIGFudGlj aXBhdGlvbiBvZiBkb2luZyB0aGUgc2hlcGhlcmQgd3JpdGUtdXAsIEkgaGF2ZSBjYXJlZnVsbHkg cmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgaXQgc3RpbGwgbmVlZHMgc29tZSB3b3JrIGJlZm9y ZSB3ZSBjYW4gcHJvZ3Jlc3MgaXQuDQpQZXIgdGhlIGVtYWlsIGRpc2N1c3Npb24gd2l0aCBQYXVs LCBJIHRoaW5rIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoaXMgZG9jdW1lbnQgaXMgcGFydGljdWxh cmx5IGNsZWFyIHRoYXQgdGhlIG5ldyB2YWx1ZSBkZWZpbmVkIGZvciB0aGUg4oCcY2F1c2XigJ0g VVJJIHBhcmFtZXRlciBpcyBvbmx5IGFkZGVkIHRvIHRoZSBSZXF1ZXN0LVVSSSBwZXIgUkZDIDQ0 NTguICAgVGhlIHByZXNlbmNlIG9mIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIGluIHRo ZSBSZXF1ZXN0LVVSSSBpcyB0b3RhbGx5IHRyYW5zcGFyZW50IHRvIHRoZSBIaXN0b3J5LUluZm8g aGVhZGVyIGZpZWxkIHByb2Nlc3Npbmcgd2hlbiB0aGUgUmVxdWVzdC1VUkkgaXMgY2FwdHVyZWQg aW4gdGhlIGhpLXRhcmdldGVkLXRvLXVyaSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLg0KRm9yIHRo ZSBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgYWNoaWV2ZWQgd2l0aCBhIG5l dyB2YWx1ZSBmb3IgdGhlIOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIsIHRoZSByZXRhcmdldGlu ZyBlbnRpdHkgbmVlZHMgdG8gYWRkIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkLCBvdGhl cndpc2UgdGhlIFJlcXVlc3QtVVJJIHRoYXQgY29udGFpbnMgdGhlIGRlc2lyZWQgaW5mb3JtYXRp b24gaXMgbG9zdCwgYnV0IHRoYXQgaXMgZ2VuZXJpYyBmdW5jdGlvbmFsaXR5IGZvciBhbnkgYXBw bGljYXRpb24gdGhhdCBuZWVkcyB0byBtYWtlIGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUgb3JpZ2lu YWwvcmV0YXJnZXRlZCBVUklzLiAgICBCYXNpY2FsbHksIHRoaXMgcHJvcG9zYWwgaXMgdGFraW5n IGFkdmFudGFnZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBkZWZpbmVkIGluIFJGQyA0NDU4IGZvciB0 aGUgbmV3IOKAnGNhdXNl4oCdIHZhbHVlIGFuZCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kgb24gdGhl IEhpc3RvcnktSW5mbyBoZWFkZXIgZmllbGQgdG8gY2FwdHVyZSB0aGF0IGluZm9ybWF0aW9uLiAg QnV0LCBpdOKAmXMgdGhlIGVuZCBhcHBsaWNhdGlvbiB0aGF0IHByb2Nlc3NlcyB0aGUgSGlzdG9y eS1JbmZvIGhlYWRlciBmaWVsZCB0aGF0IGtub3dzIHdoYXQgdG8gZG8gd2l0aCB0aGF0IOKAnGNh dXNl4oCdIHZhbHVlLiAgIFRoZXJlIGNvdWxkIHN0aWxsIGJlIHNvbWUgY2FzZXMgdGhhdCBtaWdo dCB3b3JrIHdpdGhvdXQgSGlzdG9yeS1JbmZvIGlmIHlvdSB3ZXJlbuKAmXQgZG9pbmcgbXVsdGlw bGUgcmV0YXJnZXRzLg0KTXkgc3VnZ2VzdGVkIGNoYW5nZXMgYmVsb3cgYXJlIGludGVuZGVkIHRv IGZvY3VzIHRoZSBkb2N1bWVudCBvbiB0aGUgbmV3IHByb3RvY29sIGltcGFjdHMsIGxlYXZpbmcg b3V0IG1lbnRpb24gb2YgSGlzdG9yeS1JbmZvIHVudGlsIGEgbGF0dGVyIHNlY3Rpb24gd2hlcmUg dGhlIHVzZSBvZiB0aGUgbmV3IOKAnGNhdXNl4oCdIHZhbHVlIGlzIGRlc2NyaWJlZC4NCk5vdGUs IEnigJl2ZSBhbHNvIGlkZW50aWZpZWQgc29tZSBvdGhlciBlZGl0b3JpYWwgY2hhbmdlcyB0aGF0 IEkgdGhpbmsgY2FuIGJlIGRvbmUgd2l0aG91dCBsb3NpbmcgaW1wb3J0YW50IGFzcGVjdHMgb2Yg dGhlIHByb3Bvc2FsIGFuZCB0aGVuIEkgaGF2ZSBpZGVudGlmaWVkIHNvbWUgIG5pdHMgYXQgdGhl IGVuZDoNCjEpIEFic3RyYWN0Og0KSSBkb27igJl0IHRoaW5rIHlvdSByZWFsbHkgZXZlbiBuZWVk IHRvIG1lbnRpb24gSGlzdG9yeS1JbmZvIGluIHRoZSBhYnN0cmFjdC4gIFJlYWxseSwgd2hhdCB5 b3UgYXJlIGRvaW5nIGlzIGVuYWJsaW5nIGEgc2VydmljZSBpbiBtdWNoIHRoZSBzYW1lIG1hbm5l ciBhcyBSRkMgNDQ1OCBlbmFibGVkIHZvaWNlbWFpbCBmb3Igc29tZSBzY2VuYXJpb3MuICAgU28s IEkgc3VnZ2VzdCB0aGF0IHlvdSByZXdvcmQgdGhlIGFic3RyYWN0IHNvbWV0aGluZyBsaWtlIHRo ZSBmb2xsb3dpbmc6DQpPTEQ6DQogICBbUkZDNDQ1OF0gZGVmaW5lcyBhICJjYXVzZSIgVVJJIHBh cmFtZXRlciBhcyBoYXZpbmcgcHJlZGVmaW5lZCB2YWx1ZXMNCiAgIGZvciBSZWRpcmVjdGluZyBy ZWFzb25zIGFzIGEgbWFwcGluZyBmcm9tIElUVS1UIFEuNzMyLjItNSBSZWRpcmVjdGluZw0KICAg UmVhc29ucy4gIFRoZSAiY2F1c2UiIFVSSSBwYXJhbWV0ZXIgaXMgdG8gYmUgdXNlZCBpbiBTSVAg b3IgU0lQcyBVUkkuDQogICBJbiBwYXJ0aWN1bGFyLCBpdCBtYXkgYXBwZWFyIGluIHRoZSBSZXF1 ZXN0LVVSSSBhbmQgaW4gdGhlIEhpc3RvcnktDQogICBJbmZvIGhlYWRlciBmaWVsZCBkZWZpbmVk IGluIFtSRkM3MDQ0XSBpbiBzb21lIHNwZWNpZmljIHJldGFyZ2V0ZWQNCiAgIHJlcXVlc3RzIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBjcmVhdGVzIGEg bmV3IHByZWRlZmluZWQgdmFsdWUgZm9yIGNhc2VzIHdoZW4gdGhlDQogICByZXRhcmdldGluZyBp cyBjYXVzZWQgYnkgYSBzcGVjaWZpYyBzZXJ2aWNlIGFjdGlvbiBsZWFkaW5nIHRvIGENCiAgIGNh bGxlZCBzZXJ2aWNlIGFjY2VzcyBudW1iZXIgdHJhbnNsYXRpb24uDQogICBUaGlzIGRvY3VtZW50 IHVwZGF0ZXMgW1JGQzQ0NThdLg0KTkVXOg0KICAgW1JGQzQ0NThdIGRlZmluZXMgYSAiY2F1c2Ui IFVSSSBwYXJhbWV0ZXIgYXMgaGF2aW5nIHByZWRlZmluZWQgdmFsdWVzDQogICBmb3IgUmVkaXJl Y3RpbmcgcmVhc29ucyBiYXNlZCBvbiBhIG1hcHBpbmcgZnJvbSBJVFUtVCBRLjczMi4yLTUNCiAg IFJlZGlyZWN0aW5nIFJlYXNvbnMuIFRoZSAiY2F1c2UiIFVSSSBwYXJhbWV0ZXIgY2FuIGJlIHVz ZWQgaW4gYSBTSVAgb3INCiAgIFNJUHMgVVJJLiBJbiBwYXJ0aWN1bGFyLCBpdCBtYXkgYXBwZWFy IGluIHRoZSBSZXF1ZXN0LVVSSSBpbiBhIFNJUA0KICAgUmVxdWVzdC4gIFRoaXMgc3BlY2lmaWNh dGlvbiBjcmVhdGVzIGEgbmV3IHByZWRlZmluZWQgdmFsdWUgZm9yIHRoZQ0KICAgImNhdXNlIiBV UkkgcGFyYW1ldGVyIGZvciBjYXNlcyB3aGVuIHRoZSByZXRhcmdldGluZyBpcyBkdWUgdG8gYSBz cGVjaWZpYw0KICAgc2VydmljZSBhY3Rpb24gbGVhZGluZyB0byBhIGNhbGxlZCBzZXJ2aWNlIGFj Y2VzcyBudW1iZXIgdHJhbnNsYXRpb24uDQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgW1JGQzQ0 NThdLg0KMikgSW50cm9kdWN0aW9uOg0KYSkgSSBzdWdnZXN0IHRvIG1vdmUgdGhlIGZpcnN0IDIg cGFyYWdyYXBocyB0byBhIG5ldyBzZWN0aW9uIHRoYXQgZGVzY3JpYmVzIGhhbmRsaW5nIG9mIFJl cXVlc3QtVVJJcyB0aGF0IGNvbnRhaW4gYSDigJxjYXVzZeKAnSB2YWx1ZSBpbmRpY2F0aW5nIFNl cnZpY2UgTnVtYmVyIFRyYW5zbGF0aW9uLg0KYikgM3JkIHBhcmFncmFwaC4gIEkgc3VnZ2VzdCB0 byByZXdvcmQgdGhpcyBwYXJhZ3JhcGg6DQpPTEQ6DQogICBUaGUgImNhdXNlIiBVUkkgcGFyYW1l dGVyIG1heSBiZSB1c2VkIGluIHRoZQ0KICAgUmVxdWVzdC1VUkkgYW5kIGluIHRoZSBIaXN0b3J5 LWluZm8gaGVhZGVyIGZpZWxkIHRvIGluZGljYXRlIHRoZQ0KICAgc2VydmljZSB0aGF0IHRoZSBV c2VyQWdlbnQgU2VydmVyIChVQVMpIHJlY2VpdmluZyB0aGUgbWVzc2FnZSBzaG91bGQNCiAgIHBl cmZvcm0uDQpORVc6DQogICBUaGUgImNhdXNlIiBVUkkgcGFyYW1ldGVyIG1heSBiZSB1c2VkIGlu IHRoZQ0KICAgUmVxdWVzdC1VUkkgdG8gaW5kaWNhdGUgdGhlDQogICBzZXJ2aWNlIHRoYXQgdGhl IFVzZXIgQWdlbnQgU2VydmVyIChVQVMpIHJlY2VpdmluZyB0aGUgbWVzc2FnZSBzaG91bGQgcGVy Zm9ybS4NCmMpIDR0aCBwYXJhZ3JhcGg6IFJlbW92ZSB0aGUg4oCcQ29uY3VycmVudGx5LOKAnSBh bmQgc3RhcnQgd2l0aCDigJxBIG1lY2hhbmlzbeKApuKAnQ0KZCkgNXRoIHBhcmFncmFwaC4gUmVt b3ZlIHNpbmNlIHlvdSBoYXZlbuKAmXQgYnJvdWdodCBIaXN0b3J5LUluZm8gaW50byB0aGlzIGRp c2N1c3Npb24geWV0LiAgWW91IGNhbiBhZGQgdGhpcyBjbGFyaWZ5aW5nIHBvaW50IGxhdGVyIHRv IHRoZSBzZWN0aW9uIHRoYXQgZGVzY3JpYmVzIHRoZSBoYW5kbGluZyBvZiBSZXF1ZXN0LVVSSXMg dGhhdCBjb250YWluIHRoZSBuZXcgY2F1c2UgdmFsdWUuDQozKSBTZWN0aW9uIDQgLSBFeGFtcGxl LiAgIEFsb25nIHRoZSBsaW5lcyBvZiB0aGUgcHJvcG9zYWwgdG8gZGVzY3JpYmUgdGhlIHByb2Nl c3NpbmcgZm9yIHRoZSBuZXcg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciwgSSB0aGluayBpdCB3 b3VsZCBoZWxwIHRvIGhhdmUgYSB0ZXh0dWFsIGRlc2NyaXB0aW9uIGZvciBlYWNoIG9mIHRoZSBz dGVwcyBpbiB0aGUgbWVzc2FnZSBmbG93Lg0KDQpQcm9wb3NlZCBuZXcgc2VjdGlvbiBvbiBob3cg dGhlIG5ldyDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIHZhbHVlIGlzIGhhbmRsZWQvcHJvY2Vz c2VkOg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KSXQgbWlnaHQgYmUgYmVzdCB0byBkZXNjcmliZSB3aGVuIHRoYXQg c3BlY2lmaWMgdmFsdWUgZm9yIHRoZSDigJxjYXVzZeKAnSBpcyB1c2VkIGJ5IHRoZSBwcm94eS9p bnRlcm1lZGlhcnkgYW5kIHRoZW4gc2VwYXJhdGVseSBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2Yg dGhlIFVBUyB1cG9uIHJlY2VpcHQgb2YgaGktdGFyZ2V0ZWQtdG8tdXJpcyB0aGF0IGNvbnRhaW4g dGhhdCDigJxjYXVzZeKAnSB2YWx1ZS4gICAgSSB3b3VsZCBzdWdnZXN0IHRvIGFkZCB0aGlzIHNl Y3Rpb24gYXMgYSBzdWItc2VjdGlvbiBvZiBzZWN0aW9uIDMgb3IgYXMgYSBuZXcgc2VjdGlvbiBi ZXR3ZWVuIHNlY3Rpb25zIDMgJiA0IChub3RlLCB5b3UgY291bGQgZm9sbG93IHRoZSBtb2RlbCBp biBzZWN0aW9uIDIgb2YgUkZDIDQ0NTgpDQpJbiB0ZXJtcyBvZiB3aGVuIHRoZSDigJxjYXVzZeKA nSBpcyBhZGRlZCB0byB0aGUgUmVxdWVzdCBVUkkgYnkgdGhlIHByb3h5L2ludGVybWVkaWFyeSwg aXTigJlzIGltcG9ydGFudCB0aGF0IGl04oCZcyBjbGVhciB0aGF0IHRoZSBkZXRlcm1pbmF0aW9u IG9mIHRoZSBuZXcgdGFyZ2V0IGlzIGluZGVwZW5kZW50IG9mIHByb2Nlc3NpbmcgZG9uZSB3aGVu IHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkIGlzIGFkZGVkIC0gd2Ugd29ya2VkIHZlcnkg aGFyZCB0byBtYWtlIHRoYXQgcXVpdGUgY2xlYXIgKG9yIGFzIGNsZWFyIGFzIHBvc3NpYmxlIGdp dmVuIFNJUCkgaW4gdGVybXMgb2Ygbm90IGRldmlhdGluZyBmcm9tIHRoZSBwcm9jZXNzaW5nIGFz IGRlc2NyaWJlZCBpbiBSRkMgMzI2MS4gICBUaGlzIHNlY3Rpb24gd291bGQgYmUgd2hlcmUgeW91 IGFkZCB0aGUgd2FybmluZyBhYm91dCBub3QgY29uZnVzaW5nIHRoZSBuZXcg4oCcY2F1c2XigJ0g dmFsdWUgd2l0aCB0aGUg4oCcY2F1c2XigJ0gaW4gdGhlIFJlYXNvbiBoZWFkZXIgZmllbGQgdGhh dCBpcyBwYXJ0IG9mIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkLg0KSW4gdGhpcyBuZXcg c2VjdGlvbiwgSSB0aGluayB5b3Ugb3VnaHQgdG8gZGVzY3JpYmUgYW55IGludGVyYWN0aW9ucyBi ZXR3ZWVuIHRoZSBuZXcgdmFsdWUgZm9yIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVycyBh bmQgdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZmllbGQgcGFyYW1ldGVycyBhcyB3YXMgZG9uZSBp biBSRkMgNDQ1OCAoc2VjdGlvbiAzKS4gIFlvdSBjb3VsZCBwcmVmYWNlIHRoaXMgZGlzY3Vzc2lv biB3aXRoIHRoZSB0d28gcGFyYWdyYXBocyB5b3UgaGFkIGluIHRoZSBpbnRybyB3aXRoIGJhY2tn cm91bmQgb24gUkZDIDQyNDQuIEluIHRoaXMgc2VjdGlvbiwgSSB3b3VsZCBleHBlY3QgdG8gc2Vl IHRoaW5ncyBsaWtlIHRoZSBmb2xsb3dpbmcgYWRkcmVzc2VkL2NsYXJpZmllZDogICBkb2VzIHRo ZSBVQVMgb25seSBsb29rIGZvciB0aGUg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciBpZiB0aGVy ZSBpcyBhbiDigJxtcOKAnSBvciDigJxyY+KAnSB0YWcgb3IgZG9lcyBpdCBsb29rIGZvciB0aGUg 4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciBhbmQgdGhlbiBsb29rIGZvciDigJxtcOKAnSBhbmQg 4oCccmPigJ0gdG8ga25vdyB3aGV0aGVyIHRoZSBVQVMgbmVlZHMgdG8gcGVyZm9ybSB0aGF0IHNw ZWNpZmljIHNlcnZpY2UuICBJdCBhbHNvIG5lZWRzIHRvIGJlIGNsZWFyLCBvZiBjb3Vyc2UsIHRo YXQgdGhlIGVuZCBmdW5jdGlvbmFsaXR5IHlvdSBkZXNpcmUgbWF5IG5vdCBiZSBhY2hpZXZhYmxl IHdpdGhvdXQgdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgc3Vic2VxdWVudGx5IGJlaW5nIGFkZGVk IHRvIHRoZSBtZXNzYWdlIGFuZCBOT1QgYmVpbmcgcmVtb3ZlZCBhbG9uZyB0aGUgd2F5LiAgIEFs dGhvdWdoLCBJIHdvdWxkIHRoaW5rIHlvdXIgYXBwbGljYXRpb24gb3VnaHQgdG8gd29yayBhcyBl eHBlY3RlZCBpZiB0aGF0IOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIgdmFsdWUgaXMgaW4gdGhl IFJlcXVlc3QtVVJJLiAgIFBlciBSRkMgNzA0NCwgeW91IG91Z2h0IHRvIGRlc2NyaWJlIHdoYXQg d2lsbCBoYXBwZW4gaWYgYSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkIHdpdGggYSBSZXF1ZXN0 LVVSSSBjb250YWluaW5nIHRoYXQgdmFsdWUgZm9yIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1l dGVyIGlzIHJlbW92ZWQuDQpNaW5vciBlZGl0b3JpYWwgY2hhbmdlczoNCj09PT09PT09PT09PT09 PT09PT0NCjEpIEludHJvZHVjdGlvbiAtIDZ0aCBwYXJhZ3JhcGg6IEkgd291bGQgc3VnZ2VzdCBk ZWxldGluZyB0aGF0IDJuZCBzZW50ZW5jZSBhcyBJIHRoaW5rIG1hbnkgd291bGQgZGViYXRlIHdo ZXRoZXIgdGhhdCBpbnRlbnRpb24gd2FzIGFjdHVhbGx5IHJlYWxpemVkIGJ5IHRoYXQgc3BlY2lm aWNhdGlvbi4gICBUaGVuLCB5b3UgbGlrZWx5IHNob3VsZCBhZGQgdGhhdCByZWZlcmVuY2UgYXQg dGhlIGVuZCBvZiB0aGUgZmlyc3Qgc2VudGVuY2UuDQoyKSBJ4oCZbSBub3Qgc3VyZSB0aGF0IHNl Y3Rpb24gMiAoUHJvYmxlbSBzdGF0ZW1lbnQpIGFkZHMgbXVjaCBtb3JlIHRoYW4gd2hhdOKAmXMg aW4gdGhlIEludHJvZHVjdGlvbiAod2hpY2ggaW4gdGhlIGVuZCBpcyByZWFsbHkgbW9yZSBvZiBh biBJbnRyb2R1Y3Rpb24gYW5kIE92ZXJ2aWV3KS4gIFNvLCB5b3UgY291bGQganVzdCBtb3ZlIHRo ZSAybmQgcGFyYWdyYXBoIGluIHRoaXMgc2VjdGlvbiB0byB0aGUgZW5kIG9mIHNlY3Rpb24gMSBh bmQgc3RhdGUgZGVjbGFyYXRpdmVseSwgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyAodXNp bmcg4oCcYXQgbGVhc3TigJ0gaW1wbGllcyB0aGF0IGl0IG1pZ2h0IGNvdmVyIG90aGVyIHRoaW5n cyB3aGljaCBiZWdzIHRoZSBxdWVzdGlvbiB3aGF0IGVsc2UgbWlnaHQgaXQgY292ZXIgdW5sZXNz IHlvdSBhY3R1YWxseSAgaGF2ZSBzb21ldGhpbmcgaW4gbWluZCkgOg0KICAgVGhlIG1lY2hhbmlz bSBjb3ZlcnMgdGhlIElOIHNlcnZpY2VzIHRoYXQgY2FuIGJlDQogICBpZGVudGlmaWVkIGluIHRo ZSBJU1VQIHNpZ25hbGluZyBpbiB0aGUgImNhbGxlZCBJTiBudW1iZXIiIGFuZA0KICAgIm9yaWdp bmFsIGNhbGxlZCBJTiBudW1iZXIiIG9wdGlvbmFsIHBhcmFtZXRlcnMgZGVmaW5lZCBpbg0KICAg W0lUVS1UX1EuNzYzXSBhbmQgdXNlZCBpbiBJU1VQL0lOQVAgaW50ZXJ3b3JraW5nIGFzIGRlc2Ny aWJlZCBpbg0KICAgW0lUVS1UX1EuMTYwMF0uDQpFZGl0b3JpYWwgbml0czoNCj09PT09PT09PT0N CjEpIEludHJvZHVjdGlvbiwgM3JkIHBhcmFncmFwaDoNCi0g4oCcc2VydmljZXMgZm9ybeKAnSAt PiDigJxzZXJ2aWNlcyBmcm9t4oCdDQotIEV4cGFuZCB0aGUgYWNyb255bSBURE0NCjIpIFNlY3Rp b24gMyAtIFNvbHV0aW9uOg0KLSAxc3Qgc2VudGVuY2UgcmVtb3ZlIHRoZSB3b3JkIOKAnGFsdGVy bmF0aXZl4oCdDQotIDJuZCBwYXJhZ3JhcGgsIDFzdCBzZW50ZW5jZTog4oCccmVtaW5kZWTigJ0g LT4g4oCcc3VtbWFyaXplZOKAnQ0KDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_8B970F90C584EA4E97D5BAAC9172DBB81574DA5AOPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlRleHRlYnJ1dENhcg0KCXtt c28tc3R5bGUtbmFtZToiVGV4dGUgYnJ1dCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiVGV4dGUgYnJ1dCI7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+SGkgTWFyeSBhbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5NYW55IHRo YW5rcyBmb3IgeW91ciBkZXRhaWxlZCBhbmQgY29uc3RydWN0aXZlIHJldmlldyBvZiB0aGUgZHJh ZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkluIHRoaXMgbmV3IHZl cnNpb24gSSBpbmNsdWRlZCB5b3VyIHN1Z2dlc3Rpb25zIGFuZCBjaGFuZ2VkIHRoZSBzdHJ1Y3R1 cmUgb2YgdGhlIHNlY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5BZGRpdGlvbmFsIHBvc3NpYmxlIHVzZSBjYXNlcyBhbmQgaW5mb3JtYXRpb24gb24gaG93IHRo ZSBuZXcgdmFsdWUgaGFzIHRvIGJlIHVzZWQgYXJlIGRlc2NyaWJlIHRvIHByb3ZpZGUgYmV0dGVy IGd1aWRlbGluZXMgZm9yIGltcGxlbWVudG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+VGhlIGNhbGwgZmxvdyBoYXMgYmVlbiBlbmhhbmNlZCB3aXRoIHNvbWUgYWRk aXRpb25hbCBleHBsYW5hdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3UgY2Fu IGZpbmQgdGhlIG5ldyB2ZXJzaW9uIC0wMyBvZiB0aGUgZHJhZnQgaGVyZTo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNh dXNlLWZvci1zZXJ2aWNlLW51bWJlci0wMy50eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNl LWZvci1zZXJ2aWNlLW51bWJlci0wMy50eHQ8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci8iPjxzcGFuIGxh bmc9IkVOLVVTIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb2hhbGkt ZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t b2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTAzIj48c3BhbiBsYW5nPSJF Ti1VUyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vaGFsaS1kaXNwYXRjaC1j YXVzZS1mb3Itc2VydmljZS1udW1iZXItMDM8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVy LTAzIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDM8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJl c3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5NYXJpYW5uZSBNb2hhbGk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hcnkgQmFybmVzIFttYWls dG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gdmVuZHJlZGkgMjIgbWFpIDIwMTUgMDE6NTA8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IE1PSEFM SSBNYXJpYW5uZSBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBkaXNwYXRjaEBpZXRmLm9y ZzsgQmVuIENhbXBiZWxsPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBDb21tZW50czogZHJhZnQt bW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci0wMi50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBhbnRpY2lwYXRpb24gb2Yg ZG9pbmcgdGhlIHNoZXBoZXJkIHdyaXRlLXVwLCBJIGhhdmUgY2FyZWZ1bGx5IHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYW5kIGl0IHN0aWxsIG5lZWRzIHNvbWUgd29yayBiZWZvcmUgd2UgY2FuIHBy b2dyZXNzIGl0LiAmbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlBlciB0aGUgZW1haWwgZGlzY3Vzc2lvbiB3aXRoIFBhdWwsIEkgdGhpbmsgd2UgbmVl ZCB0byBtYWtlIHN1cmUgdGhpcyBkb2N1bWVudCBpcyBwYXJ0aWN1bGFybHkgY2xlYXIgdGhhdCB0 aGUgbmV3IHZhbHVlIGRlZmluZWQgZm9yIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIGlz IG9ubHkgYWRkZWQgdG8gdGhlDQogUmVxdWVzdC1VUkkgcGVyIFJGQyA0NDU4LiAmbmJzcDsgVGhl IHByZXNlbmNlIG9mIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIGluIHRoZSBSZXF1ZXN0 LVVSSSBpcyB0b3RhbGx5IHRyYW5zcGFyZW50IHRvIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZp ZWxkIHByb2Nlc3Npbmcgd2hlbiB0aGUgUmVxdWVzdC1VUkkgaXMgY2FwdHVyZWQgaW4gdGhlIGhp LXRhcmdldGVkLXRvLXVyaSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLiAmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQg aXMgaW50ZW5kZWQgdG8gYmUgYWNoaWV2ZWQgd2l0aCBhIG5ldyB2YWx1ZSBmb3IgdGhlIOKAnGNh dXNl4oCdIFVSSSBwYXJhbWV0ZXIsIHRoZSByZXRhcmdldGluZyBlbnRpdHkgbmVlZHMgdG8gYWRk IHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkLCBvdGhlcndpc2UNCiB0aGUgUmVxdWVzdC1V UkkgdGhhdCBjb250YWlucyB0aGUgZGVzaXJlZCBpbmZvcm1hdGlvbiBpcyBsb3N0LCBidXQgdGhh dCBpcyBnZW5lcmljIGZ1bmN0aW9uYWxpdHkgZm9yIGFueSBhcHBsaWNhdGlvbiB0aGF0IG5lZWRz IHRvIG1ha2UgZGVjaXNpb25zIGJhc2VkIG9uIHRoZSBvcmlnaW5hbC9yZXRhcmdldGVkIFVSSXMu Jm5ic3A7ICZuYnNwOyBCYXNpY2FsbHksIHRoaXMgcHJvcG9zYWwgaXMgdGFraW5nIGFkdmFudGFn ZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBkZWZpbmVkDQogaW4gUkZDIDQ0NTggZm9yIHRoZSBuZXcg 4oCcY2F1c2XigJ0gdmFsdWUgYW5kIHRoZXJlIGlzIGEgZGVwZW5kZW5jeSBvbiB0aGUgSGlzdG9y eS1JbmZvIGhlYWRlciBmaWVsZCB0byBjYXB0dXJlIHRoYXQgaW5mb3JtYXRpb24uJm5ic3A7IEJ1 dCwgaXTigJlzIHRoZSBlbmQgYXBwbGljYXRpb24gdGhhdCBwcm9jZXNzZXMgdGhlIEhpc3Rvcnkt SW5mbyBoZWFkZXIgZmllbGQgdGhhdCBrbm93cyB3aGF0IHRvIGRvIHdpdGggdGhhdCDigJxjYXVz ZeKAnSB2YWx1ZS4gJm5ic3A7IFRoZXJlDQogY291bGQgc3RpbGwgYmUgc29tZSBjYXNlcyB0aGF0 IG1pZ2h0IHdvcmsgd2l0aG91dCBIaXN0b3J5LUluZm8gaWYgeW91IHdlcmVu4oCZdCBkb2luZyBt dWx0aXBsZSByZXRhcmdldHMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5NeSBzdWdnZXN0ZWQgY2hhbmdlcyBiZWxvdyBhcmUgaW50ZW5kZWQgdG8gZm9jdXMg dGhlIGRvY3VtZW50IG9uIHRoZSBuZXcgcHJvdG9jb2wgaW1wYWN0cywgbGVhdmluZyBvdXQgbWVu dGlvbiBvZiBIaXN0b3J5LUluZm8gdW50aWwgYSBsYXR0ZXIgc2VjdGlvbiB3aGVyZSB0aGUgdXNl IG9mIHRoZSBuZXcg4oCcY2F1c2XigJ0NCiB2YWx1ZSBpcyBkZXNjcmliZWQuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ob3RlLCBJ4oCZdmUgYWxzbyBpZGVu dGlmaWVkIHNvbWUgb3RoZXIgZWRpdG9yaWFsIGNoYW5nZXMgdGhhdCBJIHRoaW5rIGNhbiBiZSBk b25lIHdpdGhvdXQgbG9zaW5nIGltcG9ydGFudCBhc3BlY3RzIG9mIHRoZSBwcm9wb3NhbCBhbmQg dGhlbiBJIGhhdmUgaWRlbnRpZmllZCBzb21lJm5ic3A7IG5pdHMgYXQgdGhlIGVuZDombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSkgQWJzdHJhY3Q6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9u4oCZdCB0aGluayB5b3UgcmVh bGx5IGV2ZW4gbmVlZCB0byBtZW50aW9uIEhpc3RvcnktSW5mbyBpbiB0aGUgYWJzdHJhY3QuJm5i c3A7Jm5ic3A7UmVhbGx5LCB3aGF0IHlvdSBhcmUgZG9pbmcgaXMgZW5hYmxpbmcgYSBzZXJ2aWNl IGluIG11Y2ggdGhlIHNhbWUgbWFubmVyIGFzIFJGQyA0NDU4IGVuYWJsZWQgdm9pY2VtYWlsDQog Zm9yIHNvbWUgc2NlbmFyaW9zLiZuYnNwOyZuYnNwOyZuYnNwO1NvLCBJIHN1Z2dlc3QgdGhhdCB5 b3UgcmV3b3JkIHRoZSBhYnN0cmFjdCBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nOiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PTEQ6Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtbUkZDNDQ1OF0g ZGVmaW5lcyBhICZxdW90O2NhdXNlJnF1b3Q7IFVSSSBwYXJhbWV0ZXIgYXMgaGF2aW5nIHByZWRl ZmluZWQgdmFsdWVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyZuYnNwOyBmb3IgUmVkaXJlY3RpbmcgcmVhc29ucyBhcyBhIG1hcHBpbmcgZnJvbSBJVFUtVCBR LjczMi4yLTUgUmVkaXJlY3Rpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7IFJlYXNvbnMuJm5ic3A7IFRoZSAmcXVvdDtjYXVzZSZxdW90OyBVUkkg cGFyYW1ldGVyIGlzIHRvIGJlIHVzZWQgaW4gU0lQIG9yIFNJUHMgVVJJLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgSW4gcGFydGljdWxhciwgaXQg bWF5IGFwcGVhciBpbiB0aGUgUmVxdWVzdC1VUkkgYW5kIGluIHRoZSBIaXN0b3J5LTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgSW5mbyBoZWFkZXIg ZmllbGQgZGVmaW5lZCBpbiBbUkZDNzA0NF0gaW4gc29tZSBzcGVjaWZpYyByZXRhcmdldGVkPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyByZXF1ZXN0 cyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gY3JlYXRlcyBhIG5ldyBw cmVkZWZpbmVkIHZhbHVlIGZvciBjYXNlcyB3aGVuIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgcmV0YXJnZXRpbmcgaXMgY2F1c2VkIGJ5IGEg c3BlY2lmaWMgc2VydmljZSBhY3Rpb24gbGVhZGluZyB0byBhPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBjYWxsZWQgc2VydmljZSBhY2Nlc3MgbnVt YmVyIHRyYW5zbGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFtSRkM0NDU4XS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TkVXOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7W1JGQzQ0NThdIGRlZmluZXMgYSAmcXVvdDtjYXVz ZSZxdW90OyBVUkkgcGFyYW1ldGVyIGFzIGhhdmluZyBwcmVkZWZpbmVkIHZhbHVlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgZm9yIFJlZGlyZWN0 aW5nIHJlYXNvbnMgYmFzZWQgb24gYSBtYXBwaW5nIGZyb20gSVRVLVQgUS43MzIuMi01Jm5ic3A7 ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJz cDsgUmVkaXJlY3RpbmcgUmVhc29ucy4gVGhlICZxdW90O2NhdXNlJnF1b3Q7IFVSSSBwYXJhbWV0 ZXIgY2FuIGJlIHVzZWQgaW4gYSBTSVAgb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFNJUHMgVVJJLiBJbiBwYXJ0aWN1bGFyLCBpdCBtYXkgYXBw ZWFyIGluIHRoZSBSZXF1ZXN0LVVSSSBpbiBhIFNJUCZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFJlcXVlc3QuJm5ic3A7IFRo aXMgc3BlY2lmaWNhdGlvbiBjcmVhdGVzIGEgbmV3IHByZWRlZmluZWQgdmFsdWUgZm9yIHRoZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgJnF1b3Q7 Y2F1c2UmcXVvdDsgVVJJIHBhcmFtZXRlciBmb3IgY2FzZXMgd2hlbiB0aGUgcmV0YXJnZXRpbmcg aXMgZHVlIHRvIGEgc3BlY2lmaWMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IHNlcnZpY2UgYWN0aW9uIGxlYWRpbmcgdG8gYSBjYWxsZWQg c2VydmljZSBhY2Nlc3MgbnVtYmVyIHRyYW5zbGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFtSRkM0 NDU4XS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MikgSW50cm9kdWN0 aW9uOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hKSBJIHN1 Z2dlc3QgdG8gbW92ZSB0aGUgZmlyc3QgMiBwYXJhZ3JhcGhzIHRvIGEgbmV3IHNlY3Rpb24gdGhh dCBkZXNjcmliZXMgaGFuZGxpbmcgb2YgUmVxdWVzdC1VUklzIHRoYXQgY29udGFpbiBhIOKAnGNh dXNl4oCdIHZhbHVlIGluZGljYXRpbmcgU2VydmljZSBOdW1iZXIgVHJhbnNsYXRpb24uJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmIpIDNyZCBwYXJhZ3JhcGgu Jm5ic3A7IEkgc3VnZ2VzdCB0byByZXdvcmQgdGhpcyBwYXJhZ3JhcGg6Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9MRDombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFRoZSAmcXVvdDtjYXVzZSZxdW90 OyBVUkkgcGFyYW1ldGVyIG1heSBiZSB1c2VkIGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgUmVxdWVzdC1VUkkgYW5kIGluIHRoZSBIaXN0 b3J5LWluZm8gaGVhZGVyIGZpZWxkIHRvIGluZGljYXRlIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgc2VydmljZSB0aGF0IHRoZSBVc2VyQWdl bnQgU2VydmVyIChVQVMpIHJlY2VpdmluZyB0aGUgbWVzc2FnZSBzaG91bGQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IHBlcmZvcm0uICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ORVc6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7Y2F1c2UmcXVv dDsgVVJJIHBhcmFtZXRlciBtYXkgYmUgdXNlZCBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFJlcXVlc3QtVVJJIHRvIGluZGljYXRlIHRo ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgc2Vy dmljZSB0aGF0IHRoZSBVc2VyIEFnZW50IFNlcnZlciAoVUFTKSByZWNlaXZpbmcgdGhlIG1lc3Nh Z2Ugc2hvdWxkIHBlcmZvcm0uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5jKSA0dGggcGFyYWdyYXBoOiBSZW1vdmUgdGhlIOKAnENvbmN1cnJlbnRseSzigJ0g YW5kIHN0YXJ0IHdpdGgg4oCcQSBtZWNoYW5pc23igKbigJ0mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZCkgNXRoIHBhcmFncmFwaC4gUmVtb3ZlIHNpbmNlIHlv dSBoYXZlbuKAmXQgYnJvdWdodCBIaXN0b3J5LUluZm8gaW50byB0aGlzIGRpc2N1c3Npb24geWV0 LiZuYnNwOyBZb3UgY2FuIGFkZCB0aGlzIGNsYXJpZnlpbmcgcG9pbnQgbGF0ZXIgdG8gdGhlIHNl Y3Rpb24gdGhhdCBkZXNjcmliZXMgdGhlIGhhbmRsaW5nIG9mDQogUmVxdWVzdC1VUklzIHRoYXQg Y29udGFpbiB0aGUgbmV3IGNhdXNlIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4zKSBTZWN0aW9uIDQgLSBFeGFtcGxlLiAmbmJzcDsgQWxvbmcgdGhlIGxpbmVz IG9mIHRoZSBwcm9wb3NhbCB0byBkZXNjcmliZSB0aGUgcHJvY2Vzc2luZyBmb3IgdGhlIG5ldyDi gJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyLCBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gaGF2ZSBh IHRleHR1YWwgZGVzY3JpcHRpb24gZm9yIGVhY2gNCiBvZiB0aGUgc3RlcHMgaW4gdGhlIG1lc3Nh Z2UgZmxvdy4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Qcm9wb3Nl ZCBuZXcgc2VjdGlvbiBvbiBob3cgdGhlIG5ldyDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIHZh bHVlIGlzIGhhbmRsZWQvcHJvY2Vzc2VkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pkl0IG1pZ2h0IGJlIGJlc3QgdG8gZGVzY3JpYmUgd2hlbiB0aGF0IHNwZWNpZmljIHZhbHVlIGZv ciB0aGUg4oCcY2F1c2XigJ0gaXMgdXNlZCBieSB0aGUgcHJveHkvaW50ZXJtZWRpYXJ5IGFuZCB0 aGVuIHNlcGFyYXRlbHkgZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBVQVMgdXBvbiByZWNl aXB0IG9mIGhpLXRhcmdldGVkLXRvLXVyaXMNCiB0aGF0IGNvbnRhaW4gdGhhdCDigJxjYXVzZeKA nSB2YWx1ZS4mbmJzcDsgJm5ic3A7IEkgd291bGQgc3VnZ2VzdCB0byBhZGQgdGhpcyBzZWN0aW9u IGFzIGEgc3ViLXNlY3Rpb24gb2Ygc2VjdGlvbiAzIG9yIGFzIGEgbmV3IHNlY3Rpb24gYmV0d2Vl biBzZWN0aW9ucyAzICZhbXA7IDQgKG5vdGUsIHlvdSBjb3VsZCBmb2xsb3cgdGhlIG1vZGVsIGlu IHNlY3Rpb24gMiBvZiBSRkMgNDQ1OCkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SW4gdGVybXMgb2Ygd2hlbiB0aGUg4oCcY2F1c2XigJ0gaXMgYWRkZWQgdG8g dGhlIFJlcXVlc3QgVVJJIGJ5IHRoZSBwcm94eS9pbnRlcm1lZGlhcnksIGl04oCZcyBpbXBvcnRh bnQgdGhhdCBpdOKAmXMgY2xlYXIgdGhhdCB0aGUgZGV0ZXJtaW5hdGlvbiBvZiB0aGUgbmV3IHRh cmdldCBpcyBpbmRlcGVuZGVudCBvZiBwcm9jZXNzaW5nDQogZG9uZSB3aGVuIHRoZSBIaXN0b3J5 LUluZm8gaGVhZGVyIGZpZWxkIGlzIGFkZGVkIC0gd2Ugd29ya2VkIHZlcnkgaGFyZCB0byBtYWtl IHRoYXQgcXVpdGUgY2xlYXIgKG9yIGFzIGNsZWFyIGFzIHBvc3NpYmxlIGdpdmVuIFNJUCkgaW4g dGVybXMgb2Ygbm90IGRldmlhdGluZyBmcm9tIHRoZSBwcm9jZXNzaW5nIGFzIGRlc2NyaWJlZCBp biBSRkMgMzI2MS4gJm5ic3A7IFRoaXMgc2VjdGlvbiB3b3VsZCBiZSB3aGVyZSB5b3UgYWRkIHRo ZSB3YXJuaW5nIGFib3V0DQogbm90IGNvbmZ1c2luZyB0aGUgbmV3IOKAnGNhdXNl4oCdIHZhbHVl IHdpdGggdGhlIOKAnGNhdXNl4oCdIGluIHRoZSBSZWFzb24gaGVhZGVyIGZpZWxkIHRoYXQgaXMg cGFydCBvZiB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZC4mbmJzcDsgJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRoaXMgbmV3IHNlY3Rpb24sIEkg dGhpbmsgeW91IG91Z2h0IHRvIGRlc2NyaWJlIGFueSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUg bmV3IHZhbHVlIGZvciB0aGUg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlcnMgYW5kIHRoZSBIaXN0 b3J5LUluZm8gaGVhZGVyIGZpZWxkIHBhcmFtZXRlcnMgYXMgd2FzIGRvbmUNCiBpbiBSRkMgNDQ1 OCAoc2VjdGlvbiAzKS4mbmJzcDsgWW91IGNvdWxkIHByZWZhY2UgdGhpcyBkaXNjdXNzaW9uIHdp dGggdGhlIHR3byBwYXJhZ3JhcGhzIHlvdSBoYWQgaW4gdGhlIGludHJvIHdpdGggYmFja2dyb3Vu ZCBvbiBSRkMgNDI0NC4gSW4gdGhpcyBzZWN0aW9uLCBJIHdvdWxkIGV4cGVjdCB0byBzZWUgdGhp bmdzIGxpa2UgdGhlIGZvbGxvd2luZyBhZGRyZXNzZWQvY2xhcmlmaWVkOiAmbmJzcDsgZG9lcyB0 aGUgVUFTIG9ubHkgbG9vayBmb3IgdGhlIOKAnGNhdXNl4oCdDQogVVJJIHBhcmFtZXRlciBpZiB0 aGVyZSBpcyBhbiDigJxtcOKAnSBvciDigJxyY+KAnSB0YWcgb3IgZG9lcyBpdCBsb29rIGZvciB0 aGUg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciBhbmQgdGhlbiBsb29rIGZvciDigJxtcOKAnSBh bmQg4oCccmPigJ0gdG8ga25vdyB3aGV0aGVyIHRoZSBVQVMgbmVlZHMgdG8gcGVyZm9ybSB0aGF0 IHNwZWNpZmljIHNlcnZpY2UuJm5ic3A7IEl0IGFsc28gbmVlZHMgdG8gYmUgY2xlYXIsIG9mIGNv dXJzZSwgdGhhdCB0aGUgZW5kIGZ1bmN0aW9uYWxpdHkgeW91DQogZGVzaXJlIG1heSBub3QgYmUg YWNoaWV2YWJsZSB3aXRob3V0IHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIHN1YnNlcXVlbnRseSBi ZWluZyBhZGRlZCB0byB0aGUgbWVzc2FnZSBhbmQgTk9UIGJlaW5nIHJlbW92ZWQgYWxvbmcgdGhl IHdheS4gJm5ic3A7IEFsdGhvdWdoLCBJIHdvdWxkIHRoaW5rIHlvdXIgYXBwbGljYXRpb24gb3Vn aHQgdG8gd29yayBhcyBleHBlY3RlZCBpZiB0aGF0IOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIg dmFsdWUgaXMgaW4gdGhlIFJlcXVlc3QtVVJJLg0KICZuYnNwOyBQZXIgUkZDIDcwNDQsIHlvdSBv dWdodCB0byBkZXNjcmliZSB3aGF0IHdpbGwgaGFwcGVuIGlmIGEgSGlzdG9yeS1JbmZvIGhlYWRl ciBmaWVsZCB3aXRoIGEgUmVxdWVzdC1VUkkgY29udGFpbmluZyB0aGF0IHZhbHVlIGZvciB0aGUg 4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciBpcyByZW1vdmVkLiZuYnNwOyAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWlub3IgZWRpdG9yaWFsIGNoYW5nZXM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09PT09PT09PT09PT09PT09 PT08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSkgSW50cm9kdWN0aW9u IC0gNnRoIHBhcmFncmFwaDogSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5nIHRoYXQgMm5kIHNlbnRl bmNlIGFzIEkgdGhpbmsgbWFueSB3b3VsZCBkZWJhdGUgd2hldGhlciB0aGF0IGludGVudGlvbiB3 YXMgYWN0dWFsbHkgcmVhbGl6ZWQgYnkgdGhhdCBzcGVjaWZpY2F0aW9uLiAmbmJzcDsgVGhlbiwN CiB5b3UgbGlrZWx5IHNob3VsZCBhZGQgdGhhdCByZWZlcmVuY2UgYXQgdGhlIGVuZCBvZiB0aGUg Zmlyc3Qgc2VudGVuY2UuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4yKSBJ4oCZbSBub3Qgc3VyZSB0aGF0IHNlY3Rpb24gMiAoUHJvYmxlbSBzdGF0ZW1lbnQp IGFkZHMgbXVjaCBtb3JlIHRoYW4gd2hhdOKAmXMgaW4gdGhlIEludHJvZHVjdGlvbiAod2hpY2gg aW4gdGhlIGVuZCBpcyByZWFsbHkgbW9yZSBvZiBhbiBJbnRyb2R1Y3Rpb24gYW5kIE92ZXJ2aWV3 KS4mbmJzcDsgU28sIHlvdSBjb3VsZA0KIGp1c3QgbW92ZSB0aGUgMm5kIHBhcmFncmFwaCBpbiB0 aGlzIHNlY3Rpb24gdG8gdGhlIGVuZCBvZiBzZWN0aW9uIDEgYW5kIHN0YXRlIGRlY2xhcmF0aXZl bHksIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgKHVzaW5nIOKAnGF0IGxlYXN04oCdIGlt cGxpZXMgdGhhdCBpdCBtaWdodCBjb3ZlciBvdGhlciB0aGluZ3Mgd2hpY2ggYmVncyB0aGUgcXVl c3Rpb24gd2hhdCBlbHNlIG1pZ2h0IGl0IGNvdmVyIHVubGVzcyB5b3UgYWN0dWFsbHkmbmJzcDsg aGF2ZQ0KIHNvbWV0aGluZyBpbiBtaW5kKSA6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtUaGUgbWVjaGFuaXNtIGNvdmVycyB0aGUgSU4gc2Vydmlj ZXMgdGhhdCBjYW4gYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7IGlkZW50aWZpZWQgaW4gdGhlIElTVVAgc2lnbmFsaW5nIGluIHRoZSAmcXVvdDtj YWxsZWQgSU4gbnVtYmVyJnF1b3Q7IGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsmbmJzcDsgJnF1b3Q7b3JpZ2luYWwgY2FsbGVkIElOIG51bWJlciZxdW90 OyBvcHRpb25hbCBwYXJhbWV0ZXJzIGRlZmluZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFtJVFUtVF9RLjc2M10gYW5kIHVzZWQgaW4gSVNV UC9JTkFQIGludGVyd29ya2luZyBhcyBkZXNjcmliZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFtJVFUtVF9RLjE2MDBdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FZGl0b3JpYWwgbml0czombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PT09PT09PT09PTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xKSBJbnRyb2R1Y3Rpb24sIDNyZCBwYXJhZ3JhcGg6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0g4oCcc2VydmljZXMgZm9y beKAnSAtJmd0OyDigJxzZXJ2aWNlcyBmcm9t4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPi0gRXhwYW5kIHRoZSBhY3JvbnltIFRETTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4yKSBTZWN0aW9uIDMgLSBTb2x1dGlvbjo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSAxc3Qgc2VudGVuY2UgcmVtb3ZlIHRoZSB3b3Jk IOKAnGFsdGVybmF0aXZl4oCdJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPi0gMm5kIHBhcmFncmFwaCwgMXN0IHNlbnRlbmNlOiDigJxyZW1pbmRlZOKAnSAtJmd0 OyDigJxzdW1tYXJpemVk4oCdJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_8B970F90C584EA4E97D5BAAC9172DBB81574DA5AOPEXCLILMA4corp_-- From nobody Tue Jul 21 04:00:26 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970581A003A; Tue, 21 Jul 2015 04:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 9JS-NK-zWh3u; Tue, 21 Jul 2015 04:00:21 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 56A5F1A001A; Tue, 21 Jul 2015 04:00:20 -0700 (PDT) Received: from [IPv6:2001:df8:ffff:6:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:ffff:6:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id ED56C204FA; Tue, 21 Jul 2015 13:00:18 +0200 (CEST) Message-ID: <55AE2641.60308@acm.org> Date: Tue, 21 Jul 2015 13:00:17 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "tram@ietf.org" , "mmusic@ietf.org" , DISPATCH list Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Discussions about an ICE WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 11:00:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There will be a short discussion about creating a new WG for ICE during the DISPATCH session Wednesday morning. There is also time scheduled for this in the MMUSIC session on Friday. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVriZAAAoJECnERZXWan7ErAcQAKaXXM5ib5W4qBjPX+pAHSco gjbpPUonT2QZ4cxob6xUwGbovSC+XtO2i8qjrz1/BiuA8RVmHcHQlTT6D0bZAGHF GQRSpFCR+F3Lqvbq2GjF5wKt7LoVB1ywocAMvqo87in6f+xgo8EXHZaPWKaeo2xY 29+PuGzV2rIaifXQLIDuKP55dzu6pBedD+T0XC/AVYx9JOt9u+cK2lvwjdBcz2Lh owG7cxO4a0I3yDeUjWU7qtJWhISsUKXk3iOc9vpKZWL10i/7ySN+K7BriNTNs3Mh i7o7VtnhWpgA6IL/IMCvVL6WrcOfw2t7ZXkAE0pMSqi27LtzHB0zfNko1ADPC01l 2pLdgKxmCnvbhS830Al5yoyFae0XxH3XsZEAT6R2F4qZ4fSJ4XVg4jnSPXxxuttS ZofjV6aiJFaKBPZs8Lb/6GDEXmUKCJULKYkRhyYxBIBzfbNoqGkO8NbZauSgqQo0 ovwHJLFooilU5OtnPJKt3qSxdfnVbqEyYoJDlQs8CkfXBtct8JiU3PNF5sLJ8cSj cO3HOZ2E9AKK6gc4K1w8k5Dt6sfdXVgknKa+iDQPCAmZnu5Z+9rNyAqVYQm91KgC TGT84BNHmHPJLyAjkY0P7GJu4Iedk7cYkkiGyJC+f7thPJpr+crXXbI/A+IkY/6k pCFdtK2+scjMArrN0Lzh =ynES -----END PGP SIGNATURE----- From nobody Tue Jul 21 14:01:49 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79B1B3054 for ; Tue, 21 Jul 2015 14:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8fl_SGwCInc for ; Tue, 21 Jul 2015 14:01:46 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54401B2C8C for ; Tue, 21 Jul 2015 14:01:45 -0700 (PDT) Received: by wibud3 with SMTP id ud3so143341857wib.0 for ; Tue, 21 Jul 2015 14:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XIOVixsOtnS3W3uqfDRediEiD6/FC2M51PK3dZTc/hQ=; b=eSt5hNlxg/7oT1JVhvFBNaOgE7vGGuTESWBAGpHm175I7F6ZuCfKBPI5C3QPMm5iVU oOsE0iXXohvhjB6whMAwIELV4IIoLl6Oo8WnYbWfTvbdppMft1xCvinqrIfGggOjk88W OHOBUuf3aCE1lTWoi69ue6ACNlG9HG2HdDk/zlyJuhZ1SbUa4Z/2VvD2xeH6PqSgPH1X LabKteNo+SWVTpGJGqlcufsY3bSe2z4EX2HsAwxA+U1bsKlfgyGXQMdS4y+bBjHC1e/J BnJu9AJqeJngPur46NcLOy5DA7NvXj7/zf7bmxy5qTU01q5xYwfylJmYHdzrOkziXDlq macQ== MIME-Version: 1.0 X-Received: by 10.180.96.1 with SMTP id do1mr32780625wib.37.1437512504435; Tue, 21 Jul 2015 14:01:44 -0700 (PDT) Received: by 10.27.100.3 with HTTP; Tue, 21 Jul 2015 14:01:44 -0700 (PDT) Date: Tue, 21 Jul 2015 23:01:44 +0200 Message-ID: From: Sean Gillies To: DISPATCH list Content-Type: multipart/mixed; boundary=f46d04447fc5305059051b68f689 Archived-At: Subject: [dispatch] Updated GeoJSON charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 21:01:48 -0000 --f46d04447fc5305059051b68f689 Content-Type: multipart/alternative; boundary=f46d04447fc5305051051b68f687 --f46d04447fc5305051051b68f687 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, Thank you for your comments on the charter =E2=80=93 especially yours, Alis= sa. A new version of the GeoJSON charter is at https://github.com/geojson/draft-geojson/blob/master/charter.md and is also attached. Yours, --=20 Sean Gillies --f46d04447fc5305051051b68f687 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Thank you for your commen= ts on the charter =E2=80=93 especially yours, Alissa. A new version of the = GeoJSON charter is at https://github.com/geojson/draft-geojson/blob/master= /charter.md and is also attached.

Yours,
=

--
Sean Gillies
--f46d04447fc5305051051b68f687-- --f46d04447fc5305059051b68f689 Content-Type: text/markdown; charset=US-ASCII; name="charter.md" Content-Disposition: attachment; filename="charter.md" Content-Transfer-Encoding: base64 X-Attachment-Id: f_icdtizvj0 UHJvcG9zZWQgR2VvSlNPTiBXRyBDaGFydGVyCj09PT09PT09PT09PT09PT09PT09PT09PT09PQoK R2VvSlNPTgotLS0tLS0tCgpHZW9KU09OIGlzIGEgZm9ybWF0IGZvciBlbmNvZGluZyBkYXRhIGFi b3V0IGdlb2dyYXBoaWMgZmVhdHVyZXMgdXNpbmcKSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24g KEpTT04pIFtSRkM3MTU5XS4gR2VvZ3JhcGhpYyBmZWF0dXJlcyBuZWVkIG5vdCBiZQpwaHlzaWNh bCB0aGluZ3M7IGFueSB0aGluZyB3aXRoIHByb3BlcnRpZXMgdGhhdCBhcmUgYm91bmRlZCBpbiBz cGFjZSBtYXkgYmUKY29uc2lkZXJlZCBhIGZlYXR1cmUuIEdlb0pTT04gcHJvdmlkZXMgYSBtZWFu cyBvZiByZXByZXNlbnRpbmcgYm90aCB0aGUKcHJvcGVydGllcyBhbmQgc3BhdGlhbCBleHRlbnQg b2YgZmVhdHVyZXMuCgpUaGUgR2VvSlNPTiBmb3JtYXQgc3BlY2lmaWNhdGlvbiB3YXMgcHVibGlz aGVkIGF0IGh0dHA6Ly9nZW9qc29uLm9yZyBpbiAyMDA4LgpHZW9KU09OIHRvZGF5IHBsYXlzIGFu IGltcG9ydGFudCBhbmQgZ3Jvd2luZyByb2xlIGluIG1hbnkgc3BhdGlhbCBkYXRhYmFzZXMsCndl YiBBUElzLCBhbmQgb3BlbiBkYXRhIHBsYXRmb3Jtcy4gQ29uc2VxdWVudGx5IHRoZSBpbXBsZW1l bnRlcnMgaW5jcmVhc2luZ2x5CmRlbWFuZCBmb3JtYWwgc3RhbmRhcmRpemF0aW9uLCBpbXByb3Zl bWVudHMgaW4gdGhlIHNwZWNpZmljYXRpb24sIGd1aWRhbmNlCm9uIGV4dGVuc2liaWxpdHksIGFu ZCB0aGUgbWVhbnMgdG8gdXRpbGl6ZSBsYXJnZXIgR2VvSlNPTiBkYXRhc2V0cy4KClRoaXMgV0cg d2lsbCB3b3JrIG9uIGEgR2VvSlNPTiBGb3JtYXQgUkZDIHRoYXQgc3BlY2lmaWVzIHRoZSBmb3Jt YXQgbW9yZQpwcmVjaXNlbHksIHNlcnZlcyBhcyBhIGJldHRlciBndWlkZSBmb3IgaW1wbGVtZW50 ZXJzLCBhbmQgaW1wcm92ZXMKZXh0ZW5zaWJpbGl0eSBvZiB0aGUgZm9ybWF0LiBUaGUgd29yayB3 aWxsIHN0YXJ0IGZyb20gYW4gSW50ZXJuZXQtRHJhZnQgd3JpdHRlbgpieSB0aGUgb3JpZ2luYWwg R2VvSlNPTiBhdXRob3JzOiBkcmFmdC1idXRsZXItZ2VvanNvbiBbMV0uCgpUaGlzIFdHIHdpbGwg d29yayBvbiBHZW9KU09OIG1hcHBpbmdzIG9mICdnZW8nIFVSSXMsIHJlaW5mb3JjaW5nIHRoZSB1 c2Ugb2YKUkZDIDU4NzAuCgpUaGlzIFdHIHdpbGwgd29yayBvbiBhIGZvcm1hdCBmb3IgYSBzdHJl YW1hYmxlIHNlcXVlbmNlIG9mIEdlb0pTT04gdGV4dHMgYmFzZWQKb24gUkZDIDc0NjQgdG8gYWRk cmVzcyB0aGUgZGlmZmljdWx0aWVzIGluIHNlcmlhbGl6aW5nIHZlcnkgbGFyZ2Ugc2VxdWVuY2Vz IG9mCmZlYXR1cmVzIG9yIGZlYXR1cmUgc2VxdWVuY2VzIG9mIGluZGV0ZXJtaW5hdGUgbGVuZ3Ro LgoKR2VvSlNPTiBvYmplY3RzIHJlcHJlc2VudCBnZW9ncmFwaGljIGZlYXR1cmVzIG9ubHkgYW5k IGRvIG5vdCBzcGVjaWZ5CmFzc29jaWF0aW9ucyBiZXR3ZWVuIGdlb2dyYXBoaWMgZmVhdHVyZXMg YW5kIHBhcnRpY3VsYXIgZGV2aWNlcywgdXNlcnMsIG9yCmZhY2lsaXRpZXMuIEFueSBhc3NvY2lh dGlvbiB3aXRoIGEgcGFydGljdWxhciBkZXZpY2UsIHVzZXIsIG9yIGZhY2lsaXR5CnJlcXVpcmVz IGFub3RoZXIgcHJvdG9jb2wuIEFzIHN1Y2gsIGEgR2VvSlNPTiBvYmplY3QgZG9lcyBub3QgZml0 IHRoZSAiTG9jYXRpb24KSW5mb3JtYXRpb24iIGRlZmluaXRpb24gYWNjb3JkaW5nIHRvIFNlY3Rp b24gNS4yIG9mIFJGQyAzNjkzLCBiZWNhdXNlIHRoZXJlIGlzCm5vdCBuZWNlc3NhcmlseSBhICJE ZXZpY2UiIGludm9sdmVkLiBCZWNhdXNlIHRoZXJlIGlzIGFsc28gbm8gd2F5IHRvIHNwZWNpZnkK dGhlIGlkZW50aXR5IG9mIGEgIlRhcmdldCIgd2l0aGluIHRoZSBjb25maW5lcyBvZiBhIEdlb0pT T04gb2JqZWN0LCBpdCBhbHNvCmRvZXMgbm90IGZpdCB0aGUgc3BlY2lmaWNhdGlvbiBvZiBhICJM b2NhdGlvbiBPYmplY3QiIChTZWN0aW9uIDUuMiBvZiBSRkMgMzY5MywKU2VjdGlvbiAzLjIgb2Yg UkZDIDYyODApLiBXaGVuIGEgR2VvSlNPTiBvYmplY3QgaXMgdXNlZCBpbiBhIGNvbnRleHQgd2hl cmUgaXQKaWRlbnRpZmllcyB0aGUgbG9jYXRpb24gb2YgYSBUYXJnZXQsIGl0IGJlY29tZXMgc3Vi amVjdCB0byB0aGUgYXJjaGl0ZWN0dXJhbCwKc2VjdXJpdHksIGFuZCBwcml2YWN5IGNvbnNpZGVy YXRpb25zIGluIFJGQyA2MjgwLiBUaGUgYXBwbGljYXRpb24gb2YgdGhvc2UKY29uc2lkZXJhdGlv bnMgaXMgc3BlY2lmaWMgdG8gcHJvdG9jb2xzIHRoYXQgbWFrZSB1c2Ugb2YgR2VvSlNPTiBvYmpl Y3RzIGFuZCBpcwpvdXQgb2Ygc2NvcGUgZm9yIHRoZSBHZW9KU09OIFdHLgoKRGVsaXZlcmFibGVz OgoKKiBBIEdlb0pTT04gZm9ybWF0IHNwZWNpZmljYXRpb24gZG9jdW1lbnQgaW5jbHVkaW5nIG1h cHBpbmdzIG9mICdnZW8nIFVSSXMKKiBBIGRvY3VtZW50IGRlc2NyaWJpbmcgYSBmb3JtYXQgZm9y IGEgc3RyZWFtYWJsZSBzZXF1ZW5jZSBvZiBHZW9KU09OIHRleHRzCgpbMV0gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1dGxlci1nZW9qc29uCg== --f46d04447fc5305059051b68f689-- From nobody Wed Jul 22 00:17:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA321ACE33 for ; Wed, 22 Jul 2015 00:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEanW0HbLCN9 for ; Wed, 22 Jul 2015 00:17:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F2F1ACE36 for ; Wed, 22 Jul 2015 00:17:47 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 28D88F98460E9 for ; Wed, 22 Jul 2015 07:17:44 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6M7HjDY001452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Jul 2015 09:17:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 09:17:44 +0200 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" Thread-Topic: New ICE WG Thread-Index: AdDETnr4qXlHVCOYQSGtch4MRuxeUw== Date: Wed, 22 Jul 2015 07:17:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69748D6D@FR712WXCHMBA11.zeu.alcatel-lucent.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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] New ICE WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:17:58 -0000 Why is the first time this comes to the dispatch WG is by jumping the agend= a and dispatch deadlines at 9:15 on the face to face meeting itself. Is there a dispatch process? Keith= From nobody Wed Jul 22 00:39:18 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC21B2B4B for ; Wed, 22 Jul 2015 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 HnRe1ODBXm9u for ; Wed, 22 Jul 2015 00:39:14 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232F01B2AF2 for ; Wed, 22 Jul 2015 00:39:14 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 947F53B0B4216 for ; Wed, 22 Jul 2015 07:39:07 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6M7cY3N011761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 09:39:05 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 09:38:46 +0200 From: "DRAGE, Keith (Keith)" To: Tessa Fallon , "dispatch@ietf.org" Thread-Topic: [dispatch] Standardization of FFV1, Matroska Thread-Index: AQHQk+OGXmymzChqXk6u7QHlinThIJ3neo/w Date: Wed, 22 Jul 2015 07:38:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69748DF6@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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B69748DF6FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:39:16 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B69748DF6FR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can I ask how much buy in these have from the archives community. So for example, if I search The National Archives site in the UK, I can fin= d no mention of it, despite The National Archives claiming to be front runn= ers in the preservation of digital material. Are we talking here about one input of many from the archives community, or= are we talking about a proposal that already has consensus internationally= in the archives community? Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Tessa Fallon Sent: 21 May 2015 17:31 To: dispatch@ietf.org Subject: [dispatch] Standardization of FFV1, Matroska Greetings! MediaConch: Media Conformance Checker (maintained by MediaArea and funded b= y PREFORMA*) is looking to solicit feedback from the IETF for proposed stan= dardization of FFV1 and Matroska. The current (and under development) specifications for FFV1 exist here: htt= ps://mediaarea.net/ffv1.html and here for Matroska: http://matroska.org/technical/specs/index.html The goal of the PREFORMA project is to address the challenge of implementin= g good quality standardised file formats for preserving data content in the= long term. Our objective in regards to standardization FFV1 and Matroska i= s to improve the sustainability factors for both formats including disclosu= re, credibility, and transparency while also creating a mechanism to clarif= y, authoritatively, the intent of the specifications. After careful researc= h into past IETF work (in particular Daala and Opus), we are planning to pr= epare FFV1 and Matroska for submission to the IETF. Our preparations are not yet at the stage where we have created a formal dr= aft or submission for the IETF. Before we proceed, we'd like to engage the= IETF community in discussion of the specifications and suitability for IET= F. Briefly, FFV1 is a lossless video codec and Matroska is an extensible open = source media container. Matroska is the base of WebM, and WebM is the pre= ferred container for VP9, which has a draft RFC: https://tools.ietf.org/htm= l/draft-grange-vp9-bitstream-00 Work on FFV1 is coordinated through the GitHub and the ffmpeg-devel mailing= list (http://ffmpeg.org/mailman/listinfo/ffmpeg-devel). Work on Matroska i= s coordinated through GitHub and the Matroska.org devel mailing list (http:= //lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel). GitHub repositories are here: https://github.com/MediaArea/FFV1 https://github.com/Matroska-Org/ebml-specification We look forward to hearing your thoughts and suggestions. Best wishes, Tessa Fallon, on behalf of MediaArea * PREFORMA is a project funded by the European Union as part of FP7. More i= nformation about PREFORMA can be found here: http://www.preforma-project.eu= / --_000_949EF20990823C4C85C18D59AA11AD8B69748DF6FR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Can I ask how much buy in these h= ave from the archives community.
 
So for example, if I search The N= ational Archives site in the UK, I can find no mention of it, despite The N= ational Archives claiming to be front runners in the preservation of digital material.
 
Are we talking here about one inp= ut of many from the archives community, or are we talking about a proposal = that already has consensus internationally in the archives community?
 
Keith

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Tessa Fallon
Sent: 21 May 2015 17:31
To: dispatch@ietf.org
Subject: [dispatch] Standardization of FFV1, Matroska

Greetings!

MediaConch: Media Conformance Checker (maint= ained by MediaArea and funded by PREFORMA*) is looking to solicit feedback = from the IETF for proposed standardization of FFV1 and Matroska.  

The current (and under development) specific= ations for FFV1 exist here: https://mediaarea.net/ffv1.html
and here for Matroska:

The goal of the PREFORMA project is to addre= ss the challenge of implementing good quality standardised file formats for= preserving data content in the long term. Our objective in regards to stan= dardization FFV1 and Matroska is to improve the sustainability factors for both formats including disclosure, = credibility, and transparency while also creating a mechanism to clarify, a= uthoritatively, the intent of the specifications. After careful research in= to past IETF work (in particular Daala and Opus), we are planning to prepare FFV1 and Matroska for submissi= on to the IETF.

Our preparations are not yet at the stage wh= ere we have created a formal draft or submission for the IETF.  Before= we proceed, we'd like to engage the IETF community in discussion of the sp= ecifications and suitability for IETF.

Briefly, FFV1 is a lossless video codec and = Matroska is an extensible open source media container.   Matroska is t= he base of WebM, and WebM is the preferred container for VP9, which has a d= raft RFC: https://tools.ietf.org/html/draft-grange-vp9-bi= tstream-00

Work on FFV1 is coordinated through the GitH= ub and the ffmpeg-devel mailing list (http://ffmpeg.org/mailman/listinfo= /ffmpeg-devel). Work on Matroska is coordinated through GitHub and the Matroska.org devel mailing list (http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-= devel). 

GitHub repositories are here:

 
We look forward to hearing your thoughts and= suggestions.

Best wishes,


Tessa Fallon, on behalf of MediaArea

* PREFORMA is a project funded by the Europe= an Union as part of FP7. More information about PREFORMA can be found here:=  http://= www.preforma-project.eu/
--_000_949EF20990823C4C85C18D59AA11AD8B69748DF6FR712WXCHMBA11z_-- From nobody Wed Jul 22 00:52:48 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B771AD0BA for ; Wed, 22 Jul 2015 00:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_FAIL=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 jCtvbgfcN1OL for ; Wed, 22 Jul 2015 00:52:44 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 0E54C1ACE34 for ; Wed, 22 Jul 2015 00:52:40 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id CC13DC06EF for ; Wed, 22 Jul 2015 07:52:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k4Dg5TQUdVi for ; Wed, 22 Jul 2015 07:52:39 +0000 (UTC) Received: from [31.133.171.145] (dhcp-ab91.meeting.ietf.org [31.133.171.145]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 4701DC05F8 for ; Wed, 22 Jul 2015 07:52:39 +0000 (UTC) Message-ID: <55AF4BC5.8090302@xiph.org> Date: Wed, 22 Jul 2015 00:52:37 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B69748DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69748DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:52:46 -0000 DRAGE, Keith (Keith) wrote: > Can I ask how much buy in these have from the archives community. > So for example, if I search The National Archives site in the UK, I can > find no mention of it, despite The National Archives claiming to be > front runners in the preservation of digital material. The commentary at http://download.das-werkstatt.com/pb/mthk/info/video/FAQ-digital_video_archiving.html suggests that the National Archives are at least looking at it. http://www.vancouverarchives.ca/2011/10/a-day-in-the-lives-of-2-archivists-gone-digital/ and https://wiki.archivematica.org/Media_type_preservation_plans are additional relevant examples. But I am by no means an expert in the archives community. From nobody Wed Jul 22 01:03:05 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6541B30FA for ; Wed, 22 Jul 2015 01:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8Xx-ffHPWnI for ; Wed, 22 Jul 2015 01:02:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB4A1B2F9D for ; Wed, 22 Jul 2015 01:02:24 -0700 (PDT) Received: from [31.133.176.150] (dhcp-b096.meeting.ietf.org [31.133.176.150]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6M82JWR012246 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jul 2015 03:02:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-b096.meeting.ietf.org [31.133.176.150] claimed to be [31.133.176.150] From: "Ben Campbell" To: "DRAGE, Keith" Date: Wed, 22 Jul 2015 10:02:13 +0200 Message-ID: <26C44125-B805-4CEE-989C-B882BD927C05@nostrum.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69748D6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B69748D6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] New ICE WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:02:59 -0000 This was an AD insertion, mainly to let people know that this was being discussed and to get it on people's radar. We could have done a better job of conveying that. It probably would have been better to treat it as a status item (that is, "go look at this") than an agenda item for discussion. Ben. On 22 Jul 2015, at 9:17, DRAGE, Keith (Keith) wrote: > Why is the first time this comes to the dispatch WG is by jumping the > agenda and dispatch deadlines at 9:15 on the face to face meeting > itself. > > Is there a dispatch process? > > Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jul 22 01:05:22 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64A71B3080 for ; Wed, 22 Jul 2015 01:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, 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 IPRf6VOMZFWc for ; Wed, 22 Jul 2015 01:05:18 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id E70931B304F for ; Wed, 22 Jul 2015 01:05:16 -0700 (PDT) Received: (qmail 16666 invoked by uid 0); 22 Jul 2015 08:05:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 22 Jul 2015 08:05:15 -0000 Received: from host131.hostmonster.com ([74.220.207.131]) by cmgw3 with id vS521q00a2qe8E201S553V; Wed, 22 Jul 2015 08:05:14 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=Cffq2Vk/ek2/TUKMhd3Qog==:117 a=Cffq2Vk/ek2/TUKMhd3Qog==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=X9O7dlxLAAAA:8 a=IkcTkHD0fZMA:10 a=GwD05ahvAacA:10 a=NMjMokLwiLAA:10 a=zOBTXjUuO1YA:10 a=L2IpWlmwAAAA:8 a=EsyHQpenAAAA:8 a=NEAV23lmAAAA:8 a=TVEH-UcQAAAA:8 a=YNNHu_EsAAAA:8 a=8pif782wAAAA:8 a=aYx6f0IBAAAA:8 a=egIAeEBIAAAA:8 a=VD3AEkS2AAAA:8 a=ucDoD7QaszWTZfNuya8A:9 a=hBmAv2d5wY9WGujd:21 a=u7At2ACgAHbKtsrE:21 a=QEXdDO2ut3YA:10 a=JPboItsqPcAA:10 a=QRLao2q957gA:10 Received: from [208.120.18.83] (port=49068 helo=[10.0.1.6]) by host131.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZHp1T-0000e6-9k; Wed, 22 Jul 2015 02:05:03 -0600 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=utf-8 From: Dave Rice In-Reply-To: <55AF4BC5.8090302@xiph.org> Date: Wed, 22 Jul 2015 04:04:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1C6C7E82-6EF4-4BE8-9DBB-404DB6CE2458@dericed.com> References: <949EF20990823C4C85C18D59AA11AD8B69748DF6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55AF4BC5.8090302@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.2098) X-Identified-User: {1687:host131.hostmonster.com:dericedc:dericed.com} {sentby:smtp auth 208.120.18.83 authed with dave@dericed.com} Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:05:21 -0000 > On Jul 22, 2015, at 3:52 AM, Timothy B. Terriberry = wrote: >=20 > DRAGE, Keith (Keith) wrote: >> Can I ask how much buy in these have from the archives community. >> So for example, if I search The National Archives site in the UK, I = can >> find no mention of it, despite The National Archives claiming to be >> front runners in the preservation of digital material. >=20 > The commentary at = http://download.das-werkstatt.com/pb/mthk/info/video/FAQ-digital_video_arc= hiving.html suggests that the National Archives are at least looking at = it. Actually, we conducted an interview Ian Henderson of the UK National = Archives last December. The notes are here: = https://github.com/MediaArea/MediaConch/blob/master/Interviews/InterviewHe= nderson.md. He discusses the reason for selecting FFV1 and Matroska for = various preservation purposes. Within the interview he actually = discusses issues related specifically to the standardization of these = formats. > = http://www.vancouverarchives.ca/2011/10/a-day-in-the-lives-of-2-archivists= -gone-digital/ and = https://wiki.archivematica.org/Media_type_preservation_plans are = additional relevant examples. Peter Bubestinger has drafted a list of FFV1 users on wikipedia at = https://en.wikipedia.org/wiki/FFV1#List_of_institutions_known_to_use_FFV1.= Additionally Indiana University is undertaking a large scale campus-wide = digitization effort and recently selected FFV1 and Matroska. The formats are in use in large scale digitization efforts in television = archives in Europe. See = http://www.tvbeurope.com/rtv-slovenia-installs-noa-systems-2/ and = https://news.creativecow.net/story/876820. Also the call for proposals = for the next FIAT/IFTA World Conference leads their call for proposals = on =E2=80=9CArchives and technology evolution=E2=80=9D with the question = =E2=80=9CIs FFV1 the new JPEG2000?=E2=80=9D See: = http://fiatifta.org/wp-content/uploads/2015/06/call-for-presentation-world= -conference.pdf As FFV1 and Matroska are finding increased implementations, archives are = increasingly invested in furthering the standardization of these = formats. > But I am by no means an expert in the archives community. I am happy to play that role. :) Best Regards, Dave Rice= From nobody Wed Jul 22 01:09:51 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989701B30FD for ; Wed, 22 Jul 2015 01:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7tOYbdojmqF for ; Wed, 22 Jul 2015 01:09:48 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D3C1B3083 for ; Wed, 22 Jul 2015 01:09:46 -0700 (PDT) Received: by pdbbh15 with SMTP id bh15so89221203pdb.1 for ; Wed, 22 Jul 2015 01:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=bX0L9yXwgK9FYzBszZ7LhS5v7Bvg/XsL0lDMdU7MN18=; b=aj5aqC4iim4TEkIsiRLZIDBdmxPyMzUAQkSg+D4SbLmHa7RcpCmck0NlnoPss8NhQp +fcpS9bFkDaawaWN4kD8dDu3RG2/KAZ9Q8t8Hlnd3wAlZxEihk58meaduvJCu3UJPv1v smNdiwf4mkxZIGAKfJmKBJP01uu8kVUYv5fJG+9/I6B1JiRyLD9dahk1jD/hQ+f7hSD7 GCudOZu7DvUxD6V0KHb0ah1MDPgjAITbb5Xm9kXNN0P/mzHHZg1Dk01bn+N91QCG18Tp 7QY9f5Nt3uCLFLhDDE2u1o/3RDD3XG+eYoCQYLcxpbaRkojjVdeFKE/JRJ/UxcO1kK/0 FN5w== X-Received: by 10.66.165.8 with SMTP id yu8mr3333675pab.82.1437552586439; Wed, 22 Jul 2015 01:09:46 -0700 (PDT) Received: from [192.168.1.11] (124-168-131-205.dyn.iinet.net.au. [124.168.131.205]) by smtp.gmail.com with ESMTPSA id u8sm1661110pdj.46.2015.07.22.01.09.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 01:09:45 -0700 (PDT) From: James Winterbottom Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 22 Jul 2015 18:09:45 +1000 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dispatch] GeoJSON question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:09:49 -0000 It feels like the question is the target of the location ever going to = be conveyed with the location information?= From nobody Wed Jul 22 01:26:45 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572251A009D for ; Wed, 22 Jul 2015 01:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtaE6cqkKCnF for ; Wed, 22 Jul 2015 01:26:43 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D141A006D for ; Wed, 22 Jul 2015 01:26:43 -0700 (PDT) Received: by pabkd10 with SMTP id kd10so62840238pab.2 for ; Wed, 22 Jul 2015 01:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=SozD0yDvhm933pFBnXlJzpLiXNxLsJ8ERFPIqzXBAxg=; b=HAo1cZfmu3UvUx+2+H/A2RCJ7yGfXS3OjPJVhLZx00YkNy9dk5yK9nQf2oxv7XySHs 6fu3pcn4Semyrmt0JwSFS4JnvGOYECN8SPw7GDkivDIJRZdBR/sUlJQV1DViVB/6IUYS qIYsdsILN6ftkjxCeMdgZsrEAiWjXFUkXIBxFqUn15QoPOYDMFXDbUgK4vJIbWaIW1Am 12n/dJBpyWjS/MWGq66T4YupWTsxav4f35dvSBFAWSy+e1fs4LiIlvjkNj0bMHbeWZaf 9JlYwjcwZIKmA46BCi+fAWyEpaYVnvZ/yg4FawYRYjFwQ0xCPHYCUUBGxhLG2h8Zg1SK vpYw== X-Received: by 10.70.65.38 with SMTP id u6mr3235734pds.99.1437553602800; Wed, 22 Jul 2015 01:26:42 -0700 (PDT) Received: from [192.168.1.11] (124-168-131-205.dyn.iinet.net.au. [124.168.131.205]) by smtp.gmail.com with ESMTPSA id cj7sm1769410pdb.33.2015.07.22.01.26.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 01:26:41 -0700 (PDT) From: James Winterbottom Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <80F2BCC4-DB73-461F-AE75-46784105BA2A@gmail.com> Date: Wed, 22 Jul 2015 18:26:41 +1000 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dispatch] loc-src follow-up X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:26:44 -0000 Location URI says which LIS, not who added the location value to the message. From nobody Wed Jul 22 01:58:00 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74D1ACF55 for ; Wed, 22 Jul 2015 01:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5eb6IFoYx_i for ; Wed, 22 Jul 2015 01:57:56 -0700 (PDT) Received: from smtp112.iad3a.emailsrvr.com (smtp112.iad3a.emailsrvr.com [173.203.187.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CA01ACEC5 for ; Wed, 22 Jul 2015 01:57:56 -0700 (PDT) Received: from smtp31.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 18DA23801B5; Wed, 22 Jul 2015 04:57:56 -0400 (EDT) Received: by smtp31.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 420823800FB; Wed, 22 Jul 2015 04:57:55 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-a276.meeting.ietf.org (dhcp-a276.meeting.ietf.org [31.133.162.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 22 Jul 2015 08:57:56 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Cullen Jennings Date: Wed, 22 Jul 2015 10:57:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <776E7383-EFDF-4119-9176-D05C54F06054@iii.ca> To: IETF Dispatch X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Cullen Jennings Subject: [dispatch] Cullen raw notes from Dispatch Session IETF93 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:57:58 -0000 Theses are not the official minutes just some random notes I took as an = individual contributor. The chairs will merge various notes together and = form the minutes.=20 --------------- Minute taker: Jean Mahoney Agenda based to put ICE first.=20 Would like to move all the ICE stuff in mmusic out to a separate WG.=20 Flemming raise there is core ICE work and ICE SDP work. Need to get = clarity on on=20 No one spoke against forming new ICE WG.=20 * We need to send the charter to the dispatch list.=20 ---------------------- Matroska / ffv1 - start 9:18 Q. around what is internet standard=20 - more IETF has right openness=20 Q. do these need to be done together - could be separated but both useful Q. why not at SMPTE - specs there are behind a paywall Q. does development community meet in person - mostly not Q. what is the support in development community to bring this - support from both Q. Will they join actively=20 - depends on outcome of if the IETF wants, both communities want to have = these=20 Mary - clear there is interest in the room Q. Do we have people people willing to review this work=20 - we had more than a handful of people=20 - need to get the=20 * Action Chairs - ping the netvc and codec list=20 --------------------------------- GeoJson - start 9:50=20 - not addressing location, location objects etc - described some of the changes wanted to the spec=20 Discussion around geopriv and privacy. One can look at Geo URL and there = is a difference between specifying a location, and attaching that to = something such as a device. GeoJSON may be a layer down from the = geolocation issues.=20 Probably an interesting technical conversation around if relation of = this and a geopriv location object.=20 Who in room would sign up mailing list, read docs, and provide feedback?=20= Handfull of people in the room said yes=20 ---------------- Location Source - start 10:15=20 Asked who had read it=20 - had a handfull of people in room=20 Proposal - have the authors spin a rev of this document that clarifies = this privcay and usage issue.=20 No one was opposed to doing somehtin -------------------- Received Real - via parameter=20 Propose we AD sponsor this but decision to be made by AD after security = review. Use SIP Core mailing list. Need security review - we should ask = EKR. And a side note that Adam Roach would make a great shepherd for = draft.=20 ----------------- SLIM - start 10:38 Some discussion around routing. Multiple that had previously had issues = had not problem with this version of charter.=20 The charter is designed to allow the WG to decide what to do with = routing or not. Will likely change words to not require a recharter=20 Further discussion of charter to happen on slim mailing list=20 From nobody Wed Jul 22 02:17:06 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B971AD0A7 for ; Wed, 22 Jul 2015 02:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ_KS7gXWDIx for ; Wed, 22 Jul 2015 02:16:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A391AD0A5 for ; Wed, 22 Jul 2015 02:16:55 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 70A7BA54C050D for ; Wed, 22 Jul 2015 09:16:51 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6M9GqE0024158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Jul 2015 11:16:52 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 11:16:52 +0200 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" Thread-Topic: draft-winterbottom-dispatch-locparam Thread-Index: AdDEXyQD/iDurzCzTN+VcVMxRrjtLw== Date: Wed, 22 Jul 2015 09:16:51 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B697490B9@FR712WXCHMBA11.zeu.alcatel-lucent.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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:16:57 -0000 Issues from the dispatch meeting discussion: 1) In regard to trust, what is needed is a mechanism to meet the following = from the EC mandate: ". The enhancement, i.e. location data provision, is expected to be determi= ned by the originating telephony or electronic communications service provi= der, capable of originating voice calls through a number or numbers in nati= onal telephone numbering plans, and be provided at call setup to the PSAP a= s soon as the call reaches the authority handling the emergency calls." The proposal in the document is that the recipient of a SIP request will ei= ther know that the entity that sent or proxied the SIP request is either an= "originating telephony or electronic communications service provider" or t= rusts that entity to make a proper discrimination of that. Relying on certificates or known domain names would require PSAPs and netwo= rks routeing emergency calls to have a maintained database of all known "or= iginating telephony or electronic communications service provider" worldwid= e. 2) The question was raised as to whether it should be specific for emergenc= y call. I see no reason why it should be. It does not interfere with the lo= cation itself, or the privacy of the location itself. Further, I have a con= cern of any protocol mechanism that is emergency call specific, as it never= gets tested until one wants to make an emergency call. 3) I believe Cullen mentioned privacy, but I am not sure in what context. T= he mechanism does not interfere with any of the privacy requirements define= d for the Geolocation header field. Further if the trust in 1) above is not= met, it is only the parameter that is removed, not the Geolocation header = field itself. Regards Keith= From nobody Wed Jul 22 03:42:33 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014151AD259 for ; Wed, 22 Jul 2015 03:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOuZSy0ogcGq for ; Wed, 22 Jul 2015 03:42:31 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035E41ACECB for ; Wed, 22 Jul 2015 03:42:31 -0700 (PDT) Received: by lahe2 with SMTP id e2so72886903lah.1 for ; Wed, 22 Jul 2015 03:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=JzbesZhfXvotzjAW2Z7xc7ZFOfka25jrKGFVUYvGrhM=; b=KOuVrBVBAZSV8qPdql+Rca39m+3e38mKGaOYxCs01D5G5m5xjHHV2cJuy+Wpd6Pjcl oETMBOqa1p655eZIJLSVYrlHI5IvPZwjv7wa8uoh7e/GifWLMf/3KFF1svJQcHGskS4R r49FBC4IIuux/8/QCx565bVWs0VhRVJg8p4uO7fUtdIdBYXHzjVvWUWQeo9YyR9ZzmBZ JvpNIiwjxUqAu1Xk6y9rtTyDzZlnqs1PC41UF+hl3aet1DsU+nLiMw1EdRYeK0Pg86o3 gk/Omw88+pw2027C4ACMF0YZmmyC/qxo1ocMYljqsQCQIL6iRc+g6JH/PhsHUshrGnUY zZgw== MIME-Version: 1.0 X-Received: by 10.112.124.164 with SMTP id mj4mr1689374lbb.3.1437561749417; Wed, 22 Jul 2015 03:42:29 -0700 (PDT) Received: by 10.25.44.73 with HTTP; Wed, 22 Jul 2015 03:42:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 05:42:29 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7bfcf6066ab39e051b746d82 Archived-At: Subject: [dispatch] Fwd: QUIC BarBoF this Wednesday X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 10:42:33 -0000 --047d7bfcf6066ab39e051b746d82 Content-Type: text/plain; charset=UTF-8 FYI...this is the bar Bof that Ted mentioned at the end of the DISPATCH WG session. Regards, Mary. ---------- Forwarded message ---------- From: Jana Iyengar Date: Mon, Jul 20, 2015 at 4:20 AM Subject: QUIC BarBoF this Wednesday To: tsv-area@ietf.org Cc: Ian Swett , Ted Hardie Hello all, We will be running a BarBoF on QUIC this week, where we will be presenting the current state of QUIC and gauging interest in other implementations of QUIC, with an eye towards kicking off a standardization effort in the near future. When: Wednesday (July 22), from 8:20PM to 10:00PM. Where: Congress Hall 1. There will be light snacks, etc. Relevant drafts: https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01 https://tools.ietf.org/html/draft-tsvwg-quic-loss-recovery-00 These are works-in-progress, and we very much appreciate any feedback on the docs! Hope to see you there! - jana --047d7bfcf6066ab39e051b746d82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...this is the bar Bof that Ted mentioned at the end of= the DISPATCH WG session.

Regards,
Mary.
---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername">Jana Iyengar <jri@google.com>
Date: Mon, Jul = 20, 2015 at 4:20 AM
Subject: QUIC BarBoF this Wednesday
To: tsv-area@ietf.org
Cc: Ian Swett <ianswett@google.com>, Ted Hardi= e <hardie@google.com>

Hello all,
We w= ill be running a=C2=A0BarBoF on QUIC this week, where we will be pres= enting=C2=A0the current state=C2=A0of=C2=A0QUIC= =C2=A0and gauging interest in=C2=A0other implementations=C2=A0= of=C2=A0QUIC, with an eye towards kicking off a standar= dization effort in the near future.
When: Wednesday (July 22), from 8:2= 0PM to 10:00PM.
Where: Congress Ha= ll 1.
There will be light snacks, etc.

Relevant=C2=A0drafts:
These are works-in-= progress, and we very much appreciate any feedback on the docs!
<= /div>

Hope to see you there!
- jana

--047d7bfcf6066ab39e051b746d82-- From Ian.Henderson@nationalarchives.gsi.gov.uk Wed Jul 22 04:25:23 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3E1ACE6D for ; Wed, 22 Jul 2015 04:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 xbdn9EiFjTf8 for ; Wed, 22 Jul 2015 04:25:21 -0700 (PDT) Received: from server-11.bemta-105.messagelabs.com (mail1.bemta105.messagelabs.com [62.25.80.157]) by ietfa.amsl.com (Postfix) with ESMTP id 997241B2BF6 for ; Wed, 22 Jul 2015 04:25:02 -0700 (PDT) X-Env-Sender: Ian.Henderson@nationalarchives.gsi.gov.uk X-SpamWhitelisted: IP whitelist X-StarScan-Received: X-StarScan-Version: 7.13; banners=-,-,- X-VirusChecked: Checked From: "Henderson, Ian" To: "dispatch@ietf.org" Date: Wed, 22 Jul 2015 12:24:57 +0100 Thread-Topic: Re: [dispatch] Standardization of FFV1, Matroska Thread-Index: AdDEcQpWKydcXblzQ5Kc3sIpIAPEUg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-egms-rights-protectivemarking: NONE x-egms-rights-descriptor: None acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_B6EA190C4B458A43B95B014128FD812D4B0D7006NAEXCH2K7intnal_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 04:38:41 -0700 Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:27:41 -0000 --_000_B6EA190C4B458A43B95B014128FD812D4B0D7006NAEXCH2K7intnal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello=20all, We=20have=20not=20in=20fact=20published=20details=20regarding=20our=20use= =20of=20FFV1/=20MKV=20but=20I=20can=20confirm=20that=20we=20did=20make=20= use=20of=20this=20combination=20here=20at=20the=20(UK)=20National=20Archi= ves=20and=20have=20been=20happy=20with=20the=20results.=20FFV1/=20MKV=20w= as=20selected=20for=20use=20in=20the=20transfer=20of=20digital=20video=20= from=20HD=20tape=20source.=20This=20is=20an=20unusual=20scenario=20for=20= us,=20as=20we=20generally=20receive=20material=20already=20in=20digital=20= file=20form.=20FFV1=20was=20selected=20after=20conducting=20research=20in= to=20the=20available=20options. FFV1=20certainly=20seems=20to=20be=20gaining=20ground=20and=20more=20wide= spread=20recognition=20as=20a=20viable=20preservation=20option=20amongst=20= AV=20institutions=20and=20archives.=20I=20have=20recently=20been=20contac= ted=20by=20other=20UK=20institutions,=20potentially=20interested=20in=20u= sing=20it.=20I=20think=20there=20has=20been=20an=20understandable=20tende= ncy=20to=20hold=20back=20on=20making=20decision=20on=20preservation=20opt= ions,=20pending=20an=20authoritative=20declaration=20of=20legitimate=20ta= rget=20formats.=20Given=20further=20support=20and=20credibility=20via=20s= tandardisation,=20I=20would=20expect=20that=20FFV1=20would=20gain=20great= er=20prominence=20in=20the=20archival=20community=20as=20confidence=20bui= lds. Best=20Regards, Ian=20Henderson Please=20don't=20print=20this=20e-mail=20unless=20you=20really=20need=20t= o. -------------------------------------------------------------------------= ---------- =20 National=20Archives=20Disclaimer =20 This=20email=20and=20any=20files=20transmitted=20with=20it=20are=20intend= ed=20solely=20for=20the=20use=20of=20the=20 individual(s)=20to=20whom=20they=20are=20addressed.=20If=20you=20are=20no= t=20the=20intended=20recipient=20and=20 have=20received=20this=20email=20in=20error,=20please=20notify=20the=20se= nder=20and=20delete=20the=20email.=20 Opinions,=20conclusions=20and=20other=20information=20in=20this=20message= =20and=20attachments=20that=20do=20 not=20relate=20to=20the=20official=20business=20of=20The=20National=20Arc= hives=20are=20neither=20given=20nor=20 endorsed=20by=20it. -------------------------------------------------------------------------= ----------- --_000_B6EA190C4B458A43B95B014128FD812D4B0D7006NAEXCH2K7intnal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=20all,

We=20hav= e=20not=20in=20fact=20published=20details=20regarding=20our=20use=20of=20= FFV1/=20MKV=20but=20I=20can=20confirm=20that=20we=20did=20make=20use=20of= =20this=20combination=20here=20at=20the=20(UK)=20National=20Archives=20an= d=20have=20been=20happy=20with=20the=20results.=20FFV1/=20MKV=20was=20sel= ected=20for=20use=20in=20the=20transfer=20of=20digital=20video=20from=20H= D=20tape=20source.=20This=20is=20an=20unusual=20scenario=20for=20us,=20as= =20we=20generally=20receive=20material=20already=20in=20digital=20file=20= form.=20FFV1=20was=20selected=20after=20conducting=20research=20into=20th= e=20available=20options.=20

FFV1=20certainly=20seems=20to=20be=20gaining=20ground=20and=20more=20= widespread=20recognition=20as=20a=20viable=20preservation=20option=20amon= gst=20AV=20institutions=20and=20archives.=20I=20have=20recently=20been=20= contacted=20by=20other=20UK=20institutions,=20potentially=20interested=20= in=20using=20it.=20I=20think=20there=20has=20been=20an=20understandable=20= tendency=20to=20hold=20back=20on=20making=20decision=20on=20preservation=20= options,=20pending=20an=20authoritative=20declaration=20of=20legitimate=20= target=20formats.=20Given=20further=20support=20and=20credibility=20via=20= standardisation,=20I=20would=20expect=20that=20FFV1=20would=20gain=20grea= ter=20prominence=20in=20the=20archival=20community=20as=20confidence=20bu= ilds.

Best=20Regards,

Ian=20= Henderson



Please=20don't=20print=20this=20e-mail=20unless=20you=20really=20need=20t=
o.

-------------------------------------------------------------------------=
----------

=20
National=20Archives=20Disclaimer
=20
This=20email=20and=20any=20files=20transmitted=20with=20it=20are=20intend=
ed=20solely=20for=20the=20use=20of=20the=20
individual(s)=20to=20whom=20they=20are=20addressed.=20If=20you=20are=20no=
t=20the=20intended=20recipient=20and=20
have=20received=20this=20email=20in=20error,=20please=20notify=20the=20se=
nder=20and=20delete=20the=20email.=20
Opinions,=20conclusions=20and=20other=20information=20in=20this=20message=
=20and=20attachments=20that=20do=20
not=20relate=20to=20the=20official=20business=20of=20The=20National=20Arc=
hives=20are=20neither=20given=20nor=20
endorsed=20by=20it.


-------------------------------------------------------------------------=
-----------

--_000_B6EA190C4B458A43B95B014128FD812D4B0D7006NAEXCH2K7intnal_-- From nobody Wed Jul 22 04:38:58 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1879C1A0242; Tue, 21 Jul 2015 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 xpmAWcsJ9E4w; Tue, 21 Jul 2015 05:01:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069201A01AE; Tue, 21 Jul 2015 05:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6850; q=dns/txt; s=iport; t=1437480084; x=1438689684; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8GbEhxUCwRhU6ZjAzT64lJAsBmGXk1fkNUs0hz20bGc=; b=FhFscnbw8TOqOi0USXKC3Fyi22ZgRFYICkNifbyQFMNbae/sOXCWQw5W QjDxMTe/O80hswtziPEBNOy4jCpus0Ol5EScWOLgDhi7xLf50q2CpQWHY 1gQfuDvE6v4/3Ejd9bkwTAT2+QQ/uTa0MUKJUsEBu/zTQu3lYuJITW+MW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQDVM65V/40NJK1cgxNUaQaDHLhCKgmBawEJhTdKAhyBHDgUAQEBAQEBAYEKhCQBAQQBAQEgSwsQAgEIBDsDAgICJQsUEQIEDgWILg2zNJZXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMgj6BZREBTQQHCYJfL4EUBZRTAYR0hzWCCZcFERVjgSkdgVNvAYEMOoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,515,1432598400"; d="scan'208,217"; a="11669062" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2015 12:01:23 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6LC1MR0024464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 12:01:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 07:01:22 -0500 From: "Pal Martinsen (palmarti)" To: Marc Petit-Huguenin Thread-Topic: [MMUSIC] Discussions about an ICE WG Thread-Index: AQHQw6R14DypyX+mfkW9kPxPQpceeZ3mJniA Date: Tue, 21 Jul 2015 12:01:21 +0000 Message-ID: <3A3AC8DF-38F1-45AC-93F6-5A1DEA59E486@cisco.com> References: <55AE2641.60308@acm.org> In-Reply-To: <55AE2641.60308@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.127] Content-Type: multipart/alternative; boundary="_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 04:38:56 -0700 Cc: DISPATCH list , "tram@ietf.org" , "mmusic@ietf.org" Subject: Re: [dispatch] [MMUSIC] Discussions about an ICE WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:01:26 -0000 --_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMjEgSnVsIDIwMTUsIGF0IDEzOjAwLCBNYXJjIFBldGl0LUh1Z3VlbmluIDxwZXRpdGh1Z0Bh Y20ub3JnPG1haWx0bzpwZXRpdGh1Z0BhY20ub3JnPj4gd3JvdGU6DQoNCi0tLS0tQkVHSU4gUEdQ IFNJR05FRCBNRVNTQUdFLS0tLS0NCkhhc2g6IFNIQTI1Ng0KDQpUaGVyZSB3aWxsIGJlIGEgc2hv cnQgZGlzY3Vzc2lvbiBhYm91dCBjcmVhdGluZyBhIG5ldyBXRyBmb3IgSUNFIGR1cmluZyB0aGUg RElTUEFUQ0ggc2Vzc2lvbiBXZWRuZXNkYXkgbW9ybmluZy4NCg0KQSBtYWlsaW5nIGxpc3QgaGF2 ZSBiZWVuIGNyZWF0ZWQgZm9yIHRoaXMgZGlzY3Vzc2lvbiBhdCBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQouLS4NClDDpWwtRXJpaw0KDQoNCg0KVGhlcmUgaXMg YWxzbyB0aW1lIHNjaGVkdWxlZCBmb3IgdGhpcyBpbiB0aGUgTU1VU0lDIHNlc3Npb24gb24gRnJp ZGF5Lg0KDQotIC0tDQpNYXJjIFBldGl0LUh1Z3VlbmluDQpFbWFpbDogbWFyY0BwZXRpdC1odWd1 ZW5pbi5vcmc8bWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPg0KQmxvZzogaHR0cDovL2Js b2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcNClByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4u Y29tL2luL3BldGl0aHVnDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u OiBHbnVQRyB2Mg0KDQppUUljQkFFQkNBQUdCUUpWcmlaQUFBb0pFQ25FUlpYV2FuN0VyQWNRQUth WFhNNWliNVc0cUJqUFgrcEFIU2NvDQpnamJwUFVvblQyUVo0Y3hvYjZ4VXdHYm92U0MrWHRPMmk4 cWpyejEvQml1QThSVm1IY0hRbFRUNkQwYlpBR0hGDQpHUVJTcEZDUitGM0xxdmJxMkdqRjV3S3Q3 TG9WQjF5d29jQU12cW84N2luNmYreGdvOEVYSFphUFdLYWVvMnhZDQoyOStQdUd6VjJySWFpZlhR TElEdUtQNTVkenU2cEJlZEQrVDBYQy9BVll4OUpPdDl1K2NLMmx2d2pkQmN6MkxoDQpvd0c3Y3hP NGEwSTN5RGVValdVN3F0SldoSVNzVUtYazNpT2M5dnBLWldMMTBpLzd5U04rSzdCcmlOVE5zM01o DQppN283VnRuaFdwZ0E2SUwvSU1DdlZMNldyY09mdzJ0N1pYa0FFMHBNU3FpMjdMdHpIQjB6Zk5r bzFBRFBDMDFsDQoycExkZ0t4bUNudmJoUzgzMEFsNXlveUZhZTBYeEgzWHNaRUFUNlIyRjRxWjRm U0o0WFZnNGpuU1BYeHh1dHRTDQpab2ZqVjZhaUpGYUtCUFpzOExiLzZHREVYbVVLQ0pVTEtZa1Jo eVl4QklCemZiTm9xR2tPOE5iWmF1U2dxUW8wDQpvdndISkxGb29pbFU1T3RuUEpLdDNxU3hkZm5W YnFFeVlvSkRsUXM4Q2tmWEJ0Y3Q4SmlVM1BORjVzTEo4Y1NqDQpjTzNIT1oyRTlBS0s2Z2M0SzF3 OGs1RHQ2c2ZkWFZna25LYStpRFFQQ0FtWm51NVorOXJOeUFxVllRbTkxS2dDDQpUR1Q4NEJOSG1I UEpMeUFqa1kwUDdHSnU0SWVkazdjWWtraUd5SkMrZjd0aFBKcHIrY3JYWGJJL0ErSWtZLzZrDQpw Q0ZkdEsyK3Njak1BcnJOMEx6aA0KPXluRVMNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2lj IG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <207CCBF74E511E4F90940F39E1EF0331@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyMSBKdWwgMjAxNSwgYXQgMTM6 MDAsIE1hcmMgUGV0aXQtSHVndWVuaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRpdGh1Z0BhY20u b3JnIiBjbGFzcz0iIj5wZXRpdGh1Z0BhY20ub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4tLS0tLUJF R0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tPGJyIGNsYXNzPSIiPg0KSGFzaDogU0hBMjU2PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUgd2lsbCBiZSBhIHNob3J0IGRpc2N1c3Np b24gYWJvdXQgY3JlYXRpbmcgYSBuZXcgV0cgZm9yIElDRSBkdXJpbmcgdGhlIERJU1BBVENIIHNl c3Npb24gV2VkbmVzZGF5IG1vcm5pbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkEgbWFpbGluZyBsaXN0IGhhdmUgYmVlbiBjcmVhdGVk IGZvciB0aGlzIGRpc2N1c3Npb24gYXQmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pY2U8L2E+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pi4tLjwvZGl2Pg0KPGRpdj5Qw6Vs LUVyaWs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGlzIGFsc28gdGltZSBzY2hlZHVsZWQgZm9yIHRoaXMg aW4gdGhlIE1NVVNJQyBzZXNzaW9uIG9uIEZyaWRheS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQotIC0tIDxiciBjbGFzcz0iIj4NCk1hcmMgUGV0aXQtSHVndWVuaW48YnIgY2xhc3M9IiI+ DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnIiBjbGFzcz0i Ij5tYXJjQHBldGl0LWh1Z3VlbmluLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpCbG9nOiA8YSBocmVm PSJodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1Z3VlbmluLm9yZyIgY2xhc3M9IiI+aHR0cDovL2Js b2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KUHJvZmlsZTogPGEg aHJlZj0iaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcGV0aXRodWciIGNsYXNzPSIiPmh0dHA6 Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPGJyIGNsYXNzPSIiPg0KVmVyc2lv bjogR251UEcgdjI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQppUUljQkFFQkNBQUdCUUpW cmlaQUFBb0pFQ25FUlpYV2FuN0VyQWNRQUthWFhNNWliNVc0cUJqUFgmIzQzO3BBSFNjbzxiciBj bGFzcz0iIj4NCmdqYnBQVW9uVDJRWjRjeG9iNnhVd0dib3ZTQyYjNDM7WHRPMmk4cWpyejEvQml1 QThSVm1IY0hRbFRUNkQwYlpBR0hGPGJyIGNsYXNzPSIiPg0KR1FSU3BGQ1ImIzQzO0YzTHF2YnEy R2pGNXdLdDdMb1ZCMXl3b2NBTXZxbzg3aW42ZiYjNDM7eGdvOEVYSFphUFdLYWVvMnhZPGJyIGNs YXNzPSIiPg0KMjkmIzQzO1B1R3pWMnJJYWlmWFFMSUR1S1A1NWR6dTZwQmVkRCYjNDM7VDBYQy9B Vll4OUpPdDl1JiM0MztjSzJsdndqZEJjejJMaDxiciBjbGFzcz0iIj4NCm93RzdjeE80YTBJM3lE ZVVqV1U3cXRKV2hJU3NVS1hrM2lPYzl2cEtaV0wxMGkvN3lTTiYjNDM7SzdCcmlOVE5zM01oPGJy IGNsYXNzPSIiPg0KaTdvN1Z0bmhXcGdBNklML0lNQ3ZWTDZXcmNPZncydDdaWGtBRTBwTVNxaTI3 THR6SEIwemZOa28xQURQQzAxbDxiciBjbGFzcz0iIj4NCjJwTGRnS3htQ252YmhTODMwQWw1eW95 RmFlMFh4SDNYc1pFQVQ2UjJGNHFaNGZTSjRYVmc0am5TUFh4eHV0dFM8YnIgY2xhc3M9IiI+DQpa b2ZqVjZhaUpGYUtCUFpzOExiLzZHREVYbVVLQ0pVTEtZa1JoeVl4QklCemZiTm9xR2tPOE5iWmF1 U2dxUW8wPGJyIGNsYXNzPSIiPg0Kb3Z3SEpMRm9vaWxVNU90blBKS3QzcVN4ZGZuVmJxRXlZb0pE bFFzOENrZlhCdGN0OEppVTNQTkY1c0xKOGNTajxiciBjbGFzcz0iIj4NCmNPM0hPWjJFOUFLSzZn YzRLMXc4azVEdDZzZmRYVmdrbkthJiM0MztpRFFQQ0FtWm51NVomIzQzOzlyTnlBcVZZUW05MUtn QzxiciBjbGFzcz0iIj4NClRHVDg0Qk5IbUhQSkx5QWprWTBQN0dKdTRJZWRrN2NZa2tpR3lKQyYj NDM7Zjd0aFBKcHImIzQzO2NyWFhiSS9BJiM0MztJa1kvNms8YnIgY2xhc3M9IiI+DQpwQ0ZkdEsy JiM0MztzY2pNQXJyTjBMemg8YnIgY2xhc3M9IiI+DQo9eW5FUzxiciBjbGFzcz0iIj4NCi0tLS0t RU5EIFBHUCBTSUdOQVRVUkUtLS0tLTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K bW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNA aWV0Zi5vcmciIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_-- From nobody Wed Jul 22 07:36:46 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF11A87C2 for ; Wed, 22 Jul 2015 07:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlubiufQn1sx for ; Wed, 22 Jul 2015 07:36:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87151A886C for ; Wed, 22 Jul 2015 07:36:41 -0700 (PDT) Received: from dhcp-8c60.meeting.ietf.org (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6MEacCe057073 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 22 Jul 2015 09:36:40 -0500 (CDT) (envelope-from mahoney@nostrum.com) To: dispatch@ietf.org From: "A. Jean Mahoney" Message-ID: <55AFAA76.1020108@nostrum.com> Date: Wed, 22 Jul 2015 16:36:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Summary notes from Dispatch 93 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 14:36:45 -0000 Hi all, Here are my summary notes from the meeting this morning. Jean ------------------------------------------------------------------ Dispatch 93 2015-07-22 09:00-11:30 Congress Hall III Status and agenda bash ____________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-3.pdf Presenters: Mary Barnes, Cullen Jennings Note Taker: Jean Mahoney Jabber Relay: Ted Hardy Change to agenda - ICE WG to be presented first. Proposed ICE WG ___________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-4.pdf Presenter: Pal-Erick Martinsen Flemming Andreasen, as MMUSIC chair, felt there were a lot of advantages, but wanted to clarify that there would be both core ICE and ICE SDP work. Ben Campbell, as AD, felt that ICE-specific SDP could be handled on a case-by-case basis, like the payload WG does. Roland felt that the charter may need more text regarding the interactions with other working groups, which should be discussed on the ICE mailing list. No one in the meeting room was opposed to the formation of the working group. ACTIONs: Send charter to the dispatch mailing list. Discuss interactions with other working groups on the ICE mailing list. FFV1 and Matroska ________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-6.pdf Presenter: Tessa Fallon, Emmanuel References: - FFV1 Video Specification: https://mediaarea.net/temp/ffv1.html - Github: http://matroska.org/technical/specs/index.html Robert Sparks and Roni Even asked what was Internet-specific about this work. Jerome Martinez pointed out that Matroska was used with VP8, VP9 and WebM. Steve Lhome said that Matroska was designed for streaming in networks and that Opus could be stored in Matroska for streaming. Matroska is supported in Chrome, Firefox and MS Edge. Jerome Martinez said that, while the main purpose of Matroska was storage, it could be used for transport and that they were looking for transparency, open source and openness for their specification. They didn't take it to SMPTE because it's paywalled. Tessa said that although the specifications are already available and the work is complete, the specifications would benefit from the IETF review process. Ben Campbell asked if it was ok if IETF take over change control, and Tessa said that was understood. Ted Hardy said that the community would need to participate in the IETF or the effort would fail. Tessa said that she hoped the community and IETF would come together. Steve Lhome, an original author of Matroska, said he would continue to participate where ever the work was going to happen. Cullen and Dave Rice pointed out the needs for lossless video. Cullen felt the specifications didn't support interoperability as they were currently written, but didn't see the effort as a huge leap for the IETF. Steve Bozko and ??? voiced concerns about the ongoing maintenance aspects of the work. By raising hands, two people at the meeting showed interest in contributing. 8-10 people indicated that they were willing to review documents. Richard Barnes pointed out that netvc people were not in the room and that they may be interested. ACTION: Dispatch chairs to take the discussion to the list, contact the netvc list. GeoJSON ________________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-5.pdf Presenter: Sean Gillies Charter: https://github.com/geojson/draft-geojson/blob/master/charter.md Document: draft-butler-geojson There was a discussion about whether GeoJSON was Location Information or Location Object, and whether GeoJSON would carry a Location Object or whether a Location Object would carry GeoJSON. Privacy considerations were also discussed: unlike geopriv, GeoJSON can describe a large area with multiple points with in it. Privacy considerations would be different for collections of points than for a single point. Roger Marshall voiced support for this work. A show of hands indicated that a few people would sign up for a mailing list, read documents and provide comments. If the work was taken on, it would go to a new working group; geopriv would not be reopened. ACTION: Post the question of starting a new working group on the dispatch mailing list and geopriv mailing list, which is still open. Location source parameter _______________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-0.pdf Presenter: Andrew Hutton Document: draft-winterbottom-dispatch-locparam-00 Conrad said that this was required to satisfy safety regulations. It was discussed whether this parameter would ever be used for non-emergency situations. Andy said that once specified, it could be, but that the emergency situation was the only use case he knew of. Alissa Cooper asked that the document clearly identify the use cases that it would be supporting. ACTION: Authors to update the draft with supported use cases. Via header field parm for received realm _________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-1.pdf Presenter: Christer Holmberg Document: draft-holmberg-dispatch-received-realm-00 Adam Roach, as sipcore chair, explained that this draft did not fall under sipcore's narrow charter. Ben Campbell, as AD, said that the document could be AD-sponsored, but it needed a security review first. ACTIONs: Adam Roach to become document shepherd. RAI security advisor to review. Ben to discuss with security advisor if it can be AD-sponsored. Draft can be discussed on the SIPCORE mailing list. SLIM charter _________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-2.pdf Presenter: Randell Gellens Charter: https://datatracker.ietf.org/wg/slim/charter/ The charter wording around routing was discussed. People felt that since routing would probably be handled by the working group at some point, the charter should capture it now rather than go through a re-chartering process later. ACTIONs: Henning Schulzrinne to submit a draft usable for common use cases based on his experience with caller prefs. Discuss charter wording on the SLIM mailing list. Other items __________________________________________________ Ted Hardy announced the QUIC protocol bar bof this evening in Congress I. From nobody Wed Jul 22 07:41:46 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11351A87C2 for ; Wed, 22 Jul 2015 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lltwY-E4yglK for ; Wed, 22 Jul 2015 07:41:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92C91B2E02 for ; Wed, 22 Jul 2015 07:41:39 -0700 (PDT) Received: from dhcp-8c60.meeting.ietf.org (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6MEfb9T057551 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 22 Jul 2015 09:41:38 -0500 (CDT) (envelope-from mahoney@nostrum.com) To: dispatch@ietf.org From: "A. Jean Mahoney" Message-ID: <55AFABA0.20601@nostrum.com> Date: Wed, 22 Jul 2015 16:41:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] More verbose notes from Dispatch 93 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 14:41:44 -0000 Hi all, And here are rougher, more verbose notes from this morning's session. Jean ----------------------------------------------------------------- Dispatch 93 2015-07-22 09:00-11:30 Congress Hall III 09:00-09:10 (10m) Status and agenda bash Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-3.pdf Presenters: Mary Barnes, Cullen Jennings Note Taker: Jean Mahoney Jabber Relay: Ted Hardy Slides presented - change to agenda, ICE WG presented first. Proposed ICE WG ______________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-4.pdf Presenter: Pal-Erick Martinsen Cullen: comments? Flemming: As MMUSIC chair - this has a lot of advantages, but we need to clarify that there is both core ICE and ICE SDP work. Ben: Marc had sent out some proposed charter text, but not to dispatch. On the SDP question, we have WG like payload, they do SDP in their own group. ICE would handle ICE-specific SDP, unless complex. Handle this on a case by case basis. Cullen showed the proposed charter. Roland: probably need more text regarding interacting with other WGs, to discuss on the ICE mailing list. Alissa: send the charter to dispatch. ACTION. We've had hallway conversations. Any opposed? Need to update MMUSIC charter also. No opposition or comments. Summary: Send to the proposed charter text to list FFV1 and Matroska __________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-6.pdf Presenter: Tessa Fallon, Emmanuel References: - FFV1 Video Specification: https://mediaarea.net/temp/ffv1.html - Github: http://matroska.org/technical/specs/index.html slide 1: Title slide 2: PREFORMA Project Tessa: wanting legitimacy from SDO to encourage uptake slide 3: FFV1 and Matroska slide 4: FFV1: Current Work slide 5: Matroska: Current Work slide 6: Objectives slide 7: History of development slide 8: Why FFV1 and Matroska slide 9: Why IETF slide 10: Charter Not sent to the ml yet. Ben: to the room - we should talk about whether this is interesting work for IETF, not charter text. slide 11: Charter slide 12: Charter slide 13: Charter slide 14: Deliverables slide 15: Questions for Discussion Mary: several people on ml voiced interest. RjS: What is it about this that is internet-centric? Look at OPUS. The codec group in OPUS was focused on internet realtime apps. That will inform if IETF is a good venue. Jerome: Matroska used with VP8 and VP9, used with YouTube (WebM). Not completely internet based but maybe later. We want transparency, open source and openness. We would like to go through IETF. Alissa: Are these a package deal? Tessa: No. Looking for feedback on what IETF wants to do - both or either. Roni: this looks like storage. Why IETF? Tessa: I think Jerome's answer covered that. Roni: Will it be used to transfer over the Internet? Tessa: the specs for these are proprietary, the goal is to be open source. Jerome Martinez: Matroska is used over the internet. Matroska can transfer Opus. We use MP4 and 264, but want something more open. It is for storage - main purpose, but may be used as transport. FFV1 is good candidate for video. robux4 (Steve Lhome), from Jabber: Matroska is currently supported in Chrome, Firefox and MS Edge, for streaming video. Opus can also be stored in Matroska for streaming and unlike MP4, Matroska was designed for streaming on networks, even live streams Dave Rice, from Jabber: The preservation of the video of the internet is longterm a complex matter filled with codecs that the gain wide use and then gradually fall into obsolescence. The role of a lossless codec helps preserve internet video in some form that is long-lasting Mei??: I work on mpeg MP4. ... There's a lot of maintenance work I assume. Does the IETF take that? (something about why needing a lossless codec) Tessa: we didn't take it to SMPTE because it's paywalled. Dave Rice, from Jabber: SMPTE standards are behind paywalls and lack the features of IETF that are most appealing, such as the openness and transparency of the process Jerome: there's lossy formats on net. Maybe we want a lossless format in future. Want to discuss how to maintain with IETF. Ben, as individual: You've come here because of our openness and open spec. But you can put it out somewhere yourself. Mary: It's already out there. Ben: You don't need the IETF for publishing. We might be able to help with technical work. Does it need technical help? Tessa: Yes, the specs are public, but would benefit from the IETF review process - vetted and thoroughly reviewed. There's been a lot of work already done, they don't need to be developed. They exist. But they don't have authority, need to be thoroughly vetted. But if people aren't interested, that's good to know. Ben, as AD: if this comes into IETF as a standards effort, the IETF takes change control and may change things. Is that OK? Tessa: yes, that's understood. Dave Rice, from Jabber: today we are well familiar with the role of FLAC lossless audio on the internet, there is a similar need for FFV1 for lossless video as well. Just as we have lossless documents, audio, and photos on the internet, there is a future for lossless video on the internet as well. For reference http://github.com/ffmpeg/ffv1 and https://github.com/mediaarea/ebml-specification Ted Hardy: Yes, IETF requires change control. The IETF is a nebulous thing, who ever turns up in this room is IETF. If your dev team doesn't want to participate in IETF, it will fail. You need to bring the community into the IETF also. Tessa: thanks, we're not going to just hand over the files and be done. We hope the development community and the IETF come together. Cullen, as individual: There's lots of needs for lossless video - medical images for instance. Long term storage - I see that a standardized version is valuable. I've reviewed these specs. The codecs are good, but the specs are not. Wouldn't be interoperable. XMPP came to the IETF mainly done and then evolved. We have container formats that we're standardizing - JSON is a good example. I don't see this as a huge leap for IETF. Steve Bozko: Personally, I think it's interesting and valuable. Concern - on Matroska - work will be ongoing, maybe never-ending maintenance. Unless it's limited to FFV1. Alissa: Does your dev community meet in person? Tessa: No. On the lists. Dave Rice: some in-person meetings at FOSDEM, but most is virtual robux4, from Jabber: As the original author of Matroska I'm already involved with the more formal specifications of EBML and Matroska that started a few months ago and will continue participating wherever it is going to happen. robux4, from Jabber: how each codec is defined in Matroska is outside of the main specs, it's a top layer and not all codec have to be defined formally Ben: what's the level of support in your community? Tessa: We have support from both communities. Ben: Will the community be active in the process? Tessa: based on the outcome on this meeting. Mary: There sounds like there's interest. We need people from IETF willing to contribute - who is willing to review and provide input? Raise hands. 2 people. Alissa: I'd like to clarify - who would review? Cullen: please raise hands 8-10 people robux4,from Jabber: Matroska actually stands on top of EBML which can be used for a lot of other storage, just like a binary XML. Dave Rice, from Jabber: discussions on working on FFV1 within the IETF context starting in discussion on listservs in 2012. Matroska has an RFC Draft from 2004 (unfortunately this work wasn't completed, but there is sincere support to move forward with this now) Richard: I'm not seeing folks interested in netvc in this room. They should be asked. Mary: Take it to the list. Sounds like there's interest. ACTION. 09:45-10:15 (30m) GeoJSON____________________________________________________________ Presentation: Presenter: Sean Gillies Charter: https://github.com/geojson/draft-geojson/blob/master/charter.md Document: draft-butler-geojson slide 1: Title slide 2: GeoJSON slide 3: Status slide 4: Proposed Charter slide 5: Refinements slide 6: Coordinate Precision slide 7: Undefined Elevation slide 8: Anti-Meridian slide 9: Timestamps slide 10: High Volume slide 11: Extensibility slide 12: Geopriv slide 13: Other Groups slide 14: Docs RjS: on Geopriv - who did the analysis? did it happen on list? Sean: On dispatch list. The original geoJSON creators are from the OGC and they are ignorant of geopriv. RjS: Depends on the context about whether they are location objects. PIDFs and PIDF-LOs take location and policy rules. On extensibility - adding policy rules would allow adding geopriv into this format. Alissa: I looked at this spec and I looked at geo URI. What you can do with geo URI, you have to have some other protocol to specify location. This seemed very similar, this says this is a point. If you want to say something lives at this point, then it's a geo URI object. Extending it could change things. Richard: I did a similar analysis. There's a distinction between location description and location object. The privacy applies to objects. This is a layer down, like the geo URI. RjS: We chose not to ask the geo URI to encode some of the location object, because not feasible, but I think you can do all sorts of encoding here. There's a interesting conversation here - would this carry a location object, or would a location object carry this? Mary: There had been interest in this at the previous meeting. Roger Marshall: I support the work, I think it's important. Alissa: Geopriv is closed. We are not opening it back up. Mary: we may charter a new WG for this. Roger: this seems like this can talk about layers, and multiple points and features. Sean: yes. It's about talking about ensembles of features. A collection that provides extra context. GeoJSON seems to be down stream of geopriv. Henning: We're talking about 3 different things in mapping. One is a map - a geographic area - can render in GeoJSOn Sean: yes Henning: We have developed constrained objects - for PSAPs, uncertainty area of an object. It could be a GIS layer, but it's not part of a GIS system. 3rd - a realtime description with geographic properties, generalization of a point. ... Sean: fair to say. Richard: This is a layer down from geopriv. It describes location of a thing. But geoJSON can describe where lots of things are or city areas, and those have different privacy considerations. Mary: who would sign up on ML, read docs, provide comments? A few hands ACTION: Post on dispatch and geopriv, which is still open. Lennox: I'm glad we don't have ask if this goes in Apps or RAI. 10:15-10:35 (20m) Location source parameter__________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-0.pdf Presenter: Andrew Hutton Document: draft-winterbottom-dispatch-locparam-00 slide 1: Title slide 2: General Principle slide 3: Issues slide 4: Who Wants It? Cullen, from floor: On the trusted domain, we defined a spec-t which is required. I've never seen a spec-T doc delivered ever. All privacy bets are off in an emergency call. I don't think the trust domain concept has worked. Conrad: The trust domain works. We're requiring this to satisfy regulations. Mary: Would people like to work on this, or is this is specific to the M/493? This would have gone to the sipping or geopriv. Alissa: Or ecrit. Andy: The use case is. Cullen: would this be used in a situation that is not an emergency call? Andy: it could be used when it's defined. jon-ietf@jabber.org, from Jabber: why doesn't the url of the lis tell you the source of the location data anyway? Andy: It could be a PIDF-LO. Not sure that's true. Alissa: If you want this used out of the emergency content, you don't get the pass anymore on the privacy. Andy: The only use case I'm aware of is emergency. Mary: Who has read the draft? Handful Mary: Could be used outside of emergency services. Andy: ... Ben: Let's worry about the use cases we have in mind first. Alissa: Ask the authors to take the feedback here under advisement. And rev a draft ACTION. 10:35-10:55 (20m) Via header field parm for received realm____________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-1.pdf Presenter: Christer Holmberg Document: draft-holmberg-dispatch-received-realm-00 slide 1: Title slide 2: Problem slide 3: Solution Adam: this was an off the cuff solution, probably something better than this if we do this work. slide 4: Example slide 5: Why Not Look at the Vias? Andrew allen: They may have been tokenized by an SBC. slide 6: Suggestion Christer: I think this should be AD sponsor. Cullen: why did it go to sipcore and come out. Adam, as chair: our charter is narrow, and this isn't a core change. We would need to recharter to take this on. I'm game to have this conversation. Ben: I would say this should be AD sponsor, but if it needs work from more than just the authors. Need to make sure the input on authentication. Adam: if we had one sec guy look at it. Cullen: RAI sec advisor to review. sipcore ML? ACTION: Adam: I'm ok with that. Ben: Just need a good shepherd. Adam: send me email Christer. ACTION. Discuss with security to see if can be AD sponsored first. ACTION: slide 7: The End 10:55-11:25 (30m) SLIM charter____________________________________________________ Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-2.pdf Presenter: Randell Gellens Charter: https://datatracker.ietf.org/wg/slim/charter/ slide 1: Title slide 2: Real-Time Language Negotiation slide 3: Proposal slide 4: (show proposed charter) Mary: Is Bernard ok with this? (Bernard not in the room) Randy: not at the lunch. He's on the email. Cullen: anyone share Bernard's concern? Henning: We had overlapping concerns. This covers mine. If there's routing work to be done, the chairs would allow discussion on it. It helps if we have rough notion of big picture. Randy: That's why it says "won't focus", not out of scope. Christer: My concern was about a new attribute, and the charter doesn't discuss it. If you say, "won't focus". Have to make the decision on whether it's used for routing or not, and it changes the mechanism. If we assume SIP entities don't understand this, but we have caller prefs. Barry: the chairs should allow enough discussion to move ahead properly to routing discussions. The charter text allows the chairs more flexibility. Propose text if we need to change it. Christer: I'm fine to discuss, if someone brings a solution that supports routing, can't sweep aside because the charter says we're not doing it. Ben: I don't think the charter says go away if you want to talk about routing. The only reason the chairs would say "Go away" is that they are not ready to talk about it yet. Paul Kyzivat, from Jabber: is there any doubt that, lacking anything else, the labeling *will* be used for routing? Henning: I'll submit draft that will be usable for common use cases based on my experience with caller prefs. Cullen: People thinking that routing will end up in this group. Barry: Maybe we can tweak charter wording, get specific wording changes in right now. Randy: We'll recharter. Ben: Just say won't focus on routing now, but later. Not sure we need to trigger a recharter. Barry: agree. ACTION. Discuss on the SLIM ML. ACTION. Mary: Anything else? Ted: QIC protocol bar bof this evening in Congress I. From nobody Wed Jul 22 08:26:49 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151F91A0AC8 for ; Wed, 22 Jul 2015 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF4FCTwDp5FI for ; Wed, 22 Jul 2015 08:26:43 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212D31A0100 for ; Wed, 22 Jul 2015 08:26:43 -0700 (PDT) Received: by lblf12 with SMTP id f12so139035347lbl.2 for ; Wed, 22 Jul 2015 08:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hxzu6ppU6alQRcwoW9Uz0oqZ1Qlc135F+cIFemFTNiE=; b=v0aDv8kwg9ZljWqx/Fzpj24V0rJfiAewRDYMUh9qAGnXudDy+6WDjbOKY8MXP3m5/v u/p+S+HH+OKjLsYAF+KwYE5VXyXAb5tPOjfOAJqpgrCfrXJjfe+2J6qTr08v+2nylcBB 4RYD51SG9VkmLbqodbiGngv9GfuRdUsiFYERXr0HZZZyjEfXCHmEDRYpznWuJjZOe6es APtbo7j/6JOsvLJFwOGzTDhFZT1CvcPj+SUf54zFUQTzpTWKOhALL0YCrx7dAOvB4JNe 7WjGh3K4UqJ41V7Pzun13vjpT06VzKoadJu4csKrY+7sIgWhFMjn5ctZx/AHhoP6iEzf XJLw== MIME-Version: 1.0 X-Received: by 10.112.26.225 with SMTP id o1mr2905091lbg.5.1437578801255; Wed, 22 Jul 2015 08:26:41 -0700 (PDT) Received: by 10.25.44.73 with HTTP; Wed, 22 Jul 2015 08:26:41 -0700 (PDT) In-Reply-To: <55AFAA76.1020108@nostrum.com> References: <55AFAA76.1020108@nostrum.com> Date: Wed, 22 Jul 2015 10:26:41 -0500 Message-ID: From: Mary Barnes To: "A. Jean Mahoney" Content-Type: multipart/alternative; boundary=001a11336b98c919de051b78659f Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Summary notes from Dispatch 93 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:26:47 -0000 --001a11336b98c919de051b78659f Content-Type: text/plain; charset=UTF-8 Thanks Jean! As always, awesome notes. Mary. On Wed, Jul 22, 2015 at 9:36 AM, A. Jean Mahoney wrote: > Hi all, > > Here are my summary notes from the meeting this morning. > > Jean > > > ------------------------------------------------------------------ > > Dispatch 93 > 2015-07-22 > 09:00-11:30 Congress Hall III > > > Status and agenda bash ____________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-3.pdf > Presenters: Mary Barnes, Cullen Jennings > > Note Taker: Jean Mahoney > Jabber Relay: Ted Hardy > > Change to agenda - ICE WG to be presented first. > > > > Proposed ICE WG ___________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-4.pdf > Presenter: Pal-Erick Martinsen > > > Flemming Andreasen, as MMUSIC chair, felt there were a lot of advantages, > but wanted to clarify that there would be both core ICE and ICE SDP work. > Ben Campbell, as AD, felt that ICE-specific SDP could be handled on a > case-by-case basis, like the payload WG does. Roland felt that the charter > may need more text regarding the interactions with other working groups, > which should be discussed on the ICE mailing list. No one in the meeting > room was opposed to the formation of the working group. > > ACTIONs: Send charter to the dispatch mailing list. Discuss interactions > with other working groups on the ICE mailing list. > > > > FFV1 and Matroska ________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-6.pdf > Presenter: Tessa Fallon, Emmanuel > References: > - FFV1 Video Specification: https://mediaarea.net/temp/ffv1.html > - Github: http://matroska.org/technical/specs/index.html > > > Robert Sparks and Roni Even asked what was Internet-specific about this > work. Jerome Martinez pointed out that Matroska was used with VP8, VP9 and > WebM. Steve Lhome said that Matroska was designed for streaming in networks > and that Opus could be stored in Matroska for streaming. Matroska is > supported in Chrome, Firefox and MS Edge. > > Jerome Martinez said that, while the main purpose of Matroska was storage, > it could be used for transport and that they were looking for transparency, > open source and openness for their specification. They didn't take it to > SMPTE because it's paywalled. > > Tessa said that although the specifications are already available and the > work is complete, the specifications would benefit from the IETF review > process. Ben Campbell asked if it was ok if IETF take over change control, > and Tessa said that was understood. Ted Hardy said that the community would > need to participate in the IETF or the effort would fail. Tessa said that > she hoped the community and IETF would come together. Steve Lhome, an > original author of Matroska, said he would continue to participate where > ever the work was going to happen. > > Cullen and Dave Rice pointed out the needs for lossless video. Cullen felt > the specifications didn't support interoperability as they were currently > written, but didn't see the effort as a huge leap for the IETF. > > Steve Bozko and ??? voiced concerns about the ongoing maintenance aspects > of the work. > > By raising hands, two people at the meeting showed interest in > contributing. 8-10 people indicated that they were willing to review > documents. > > Richard Barnes pointed out that netvc people were not in the room and that > they may be interested. > > ACTION: Dispatch chairs to take the discussion to the list, contact the > netvc list. > > > > GeoJSON ________________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-5.pdf > Presenter: Sean Gillies > Charter: https://github.com/geojson/draft-geojson/blob/master/charter.md > Document: draft-butler-geojson > > > There was a discussion about whether GeoJSON was Location Information or > Location Object, and whether GeoJSON would carry a Location Object or > whether a Location Object would carry GeoJSON. > > Privacy considerations were also discussed: unlike geopriv, GeoJSON can > describe a large area with multiple points with in it. Privacy > considerations would be different for collections of points than for a > single point. > > Roger Marshall voiced support for this work. > > A show of hands indicated that a few people would sign up for a mailing > list, read documents and provide comments. If the work was taken on, it > would go to a new working group; geopriv would not be reopened. > > ACTION: Post the question of starting a new working group on the dispatch > mailing list and geopriv mailing list, which is still open. > > > > Location source parameter _______________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-0.pdf > Presenter: Andrew Hutton > Document: draft-winterbottom-dispatch-locparam-00 > > > Conrad said that this was required to satisfy safety regulations. It was > discussed whether this parameter would ever be used for non-emergency > situations. Andy said that once specified, it could be, but that the > emergency situation was the only use case he knew of. Alissa Cooper asked > that the document clearly identify the use cases that it would be > supporting. > > ACTION: Authors to update the draft with supported use cases. > > > > Via header field parm for received realm _________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-1.pdf > Presenter: Christer Holmberg > Document: draft-holmberg-dispatch-received-realm-00 > > > Adam Roach, as sipcore chair, explained that this draft did not fall under > sipcore's narrow charter. Ben Campbell, as AD, said that the document could > be AD-sponsored, but it needed a security review first. > > ACTIONs: Adam Roach to become document shepherd. RAI security advisor to > review. Ben to discuss with security advisor if it can be AD-sponsored. > Draft can be discussed on the SIPCORE mailing list. > > > > SLIM charter _________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-2.pdf > Presenter: Randell Gellens > Charter: https://datatracker.ietf.org/wg/slim/charter/ > > > The charter wording around routing was discussed. People felt that since > routing would probably be handled by the working group at some point, the > charter should capture it now rather than go through a re-chartering > process later. > > ACTIONs: Henning Schulzrinne to submit a draft usable for common use cases > based on his experience with caller prefs. Discuss charter wording on the > SLIM mailing list. > > > > Other items __________________________________________________ > > Ted Hardy announced the QUIC protocol bar bof this evening in Congress I. > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11336b98c919de051b78659f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Jean!=C2=A0 As always, awesome notes.

Mary.

On Wed, Jul 22, 2015 at 9:36 AM, A. Jean Mahoney &l= t;mahoney@nostrum.= com> wrote:
Hi all,

Here are my summary notes from the meeting this morning.

Jean


------------------------------------------------------------------

Dispatch 93
2015-07-22
09:00-11:30 Congress Hall III


Status and agenda bash ____________________________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-3.pdf
Presenters: Mary Barnes, Cullen Jennings

Note Taker: Jean Mahoney
Jabber Relay: Ted Hardy

Change to agenda - ICE WG to be presented first.



Proposed ICE WG ___________________________________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-4.pdf
Presenter: Pal-Erick Martinsen


Flemming Andreasen, as MMUSIC chair, felt there were a lot of advantages, b= ut wanted to clarify that there would be both core ICE and ICE SDP work. Be= n Campbell, as AD, felt that ICE-specific SDP could be handled on a case-by= -case basis, like the payload WG does. Roland felt that the charter may nee= d more text regarding the interactions with other working groups, which sho= uld be discussed on the ICE mailing list. No one in the meeting room was op= posed to the formation of the working group.

ACTIONs: Send charter to the dispatch mailing list. Discuss interactions wi= th other working groups on the ICE mailing list.



FFV1 and Matroska ________________________________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-6.pdf
Presenter:=C2=A0 Tessa Fallon, Emmanuel
References:
- FFV1 Video Specification: https://mediaarea.net/temp/ffv1.html=
- Github: http://matroska.org/technical/specs/index.ht= ml


Robert Sparks and Roni Even asked what was Internet-specific about this wor= k. Jerome Martinez pointed out that Matroska was used with VP8, VP9 and Web= M. Steve Lhome said that Matroska was designed for streaming in networks an= d that Opus could be stored in Matroska for streaming. Matroska is supporte= d in Chrome, Firefox and MS Edge.

Jerome Martinez said that, while the main purpose of Matroska was storage, = it could be used for transport and that they were looking for transparency,= open source and openness for their specification. They didn't take it = to SMPTE because it's paywalled.

Tessa said that although the specifications are already available and the w= ork is complete, the specifications would benefit from the IETF review proc= ess. Ben Campbell asked if it was ok if IETF take over change control, and = Tessa said that was understood. Ted Hardy said that the community would nee= d to participate in the IETF or the effort would fail. Tessa said that she = hoped the community and IETF would come together. Steve Lhome, an original = author of Matroska, said he would continue to participate where ever the wo= rk was going to happen.

Cullen and Dave Rice pointed out the needs for lossless video. Cullen felt = the specifications didn't support interoperability as they were current= ly written, but didn't see the effort as a huge leap for the IETF.

Steve Bozko and ??? voiced concerns about the ongoing maintenance aspects o= f the work.

By raising hands, two people at the meeting showed interest in contributing= . 8-10 people indicated that they were willing to review documents.

Richard Barnes pointed out that netvc people were not in the room and that = they may be interested.

ACTION: Dispatch chairs to take the discussion to the list, contact the net= vc list.



GeoJSON ________________________________________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-5.pdf
Presenter: Sean Gillies
Charter: https://github.com/geojson/d= raft-geojson/blob/master/charter.md
Document: draft-butler-geojson


There was a discussion about whether GeoJSON was Location Information or Lo= cation Object, and whether GeoJSON would carry a Location Object or whether= a Location Object would carry GeoJSON.

Privacy considerations were also discussed: unlike geopriv, GeoJSON can des= cribe a large area with multiple points with in it. Privacy considerations = would be different for collections of points than for a single point.

Roger Marshall voiced support for this work.

A show of hands indicated that a few people would sign up for a mailing lis= t, read documents and provide comments. If the work was taken on, it would = go to a new working group; geopriv would not be reopened.

ACTION: Post the question of starting a new working group on the dispatch m= ailing list and geopriv mailing list, which is still open.



Location source parameter _______________________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-0.pdf
Presenter: Andrew Hutton
Document: draft-winterbottom-dispatch-locparam-00


Conrad said that this was required to satisfy safety regulations. It was di= scussed whether this parameter would ever be used for non-emergency situati= ons. Andy said that once specified, it could be, but that the emergency sit= uation was the only use case he knew of. Alissa Cooper asked that the docum= ent clearly identify the use cases that it would be supporting.

ACTION: Authors to update the draft with supported use cases.



Via header field parm for received realm _________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-1.pdf
Presenter: Christer Holmberg
Document: draft-holmberg-dispatch-received-realm-00


Adam Roach, as sipcore chair, explained that this draft did not fall under = sipcore's narrow charter. Ben Campbell, as AD, said that the document c= ould be AD-sponsored, but it needed a security review first.

ACTIONs: Adam Roach to become document shepherd. RAI security advisor to re= view. Ben to discuss with security advisor if it can be AD-sponsored. Draft= can be discussed on the SIPCORE mailing list.



SLIM charter _________________________________________________
Presentation: https://www.ietf.or= g/proceedings/93/slides/slides-93-dispatch-2.pdf
Presenter: Randell Gellens
Charter: https://datatracker.ietf.org/wg/slim/charter/<= /a>


The charter wording around routing was discussed. People felt that since ro= uting would probably be handled by the working group at some point, the cha= rter should capture it now rather than go through a re-chartering process l= ater.

ACTIONs: Henning Schulzrinne to submit a draft usable for common use cases = based on his experience with caller prefs. Discuss charter wording on the S= LIM mailing list.



Other items __________________________________________________

Ted Hardy announced the QUIC protocol bar bof this evening in Congress I.




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

--001a11336b98c919de051b78659f-- From nobody Wed Jul 22 08:31:05 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEFA1A037C for ; Wed, 22 Jul 2015 08:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XowObFRZWEMj for ; Wed, 22 Jul 2015 08:31:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7C81A0113 for ; Wed, 22 Jul 2015 08:30:28 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A065372D1CC2B; Wed, 22 Jul 2015 15:30:23 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MFUQF0008170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:30:26 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 17:30:26 +0200 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" , Cullen Jennings Thread-Topic: draft-winterbottom-dispatch-locparam Thread-Index: AdDEXyQD/iDurzCzTN+VcVMxRrjtLwAMPgPg Date: Wed, 22 Jul 2015 15:30:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:31:02 -0000 I've now read all the versions of meeting notes distributed. None of these expand on Cullen's privacy concern, so perhaps he could elabo= rate. I would state that: 1) the trust statements in the document relate only to the additional heade= r field. The privacy requirements on the remainder of the Geolocation heade= r field are unchanged. 2) for SIP deployments that use trust, neither the trust nor the entities i= nvolved in that trust are the same for every header field. So the trust for= RFC 3325 is: a) on the sender to trust that the recipient to apply any "id= " privacy indicated; b) on the recipient that they trust the sender to asse= rt the identity. For this draft, the only trust required is that the receiv= er trusts the sender to assert that the new header field parameter was appl= ied by a "originating telephony or electronic communications service provid= er". 3) I do not believe there is any privacy issue about the recipient receivin= g information that any contained Geolocation header field came from a "orig= inating telephony or electronic communications service provider" as opposed= to anywhere else. If there is, then the trust requirements could be altere= d in the same manner as already used for a number of 3GPP specific header f= ields. Keith > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: 22 July 2015 10:17 > To: dispatch@ietf.org > Subject: draft-winterbottom-dispatch-locparam >=20 > Issues from the dispatch meeting discussion: >=20 > 1) In regard to trust, what is needed is a mechanism to=20 > meet the following from the EC mandate: >=20 > ". The enhancement, i.e. location data provision, is expected=20 > to be determined by the originating telephony or electronic=20 > communications service provider, capable of originating voice=20 > calls through a number or numbers in national telephone=20 > numbering plans, and be provided at call setup to the PSAP as=20 > soon as the call reaches the authority handling the emergency calls." >=20 > The proposal in the document is that the recipient of a SIP=20 > request will either know that the entity that sent or proxied=20 > the SIP request is either an "originating telephony or=20 > electronic communications service provider" or trusts that=20 > entity to make a proper discrimination of that. >=20 > Relying on certificates or known domain names would require=20 > PSAPs and networks routeing emergency calls to have a=20 > maintained database of all known "originating telephony or=20 > electronic communications service provider" worldwide. >=20 > 2) The question was raised as to whether it should be=20 > specific for emergency call. I see no reason why it should=20 > be. It does not interfere with the location itself, or the=20 > privacy of the location itself. Further, I have a concern of=20 > any protocol mechanism that is emergency call specific, as it=20 > never gets tested until one wants to make an emergency call. >=20 > 3) I believe Cullen mentioned privacy, but I am not sure=20 > in what context. The mechanism does not interfere with any of=20 > the privacy requirements defined for the Geolocation header=20 > field. Further if the trust in 1) above is not met, it is=20 > only the parameter that is removed, not the Geolocation=20 > header field itself. >=20 > Regards >=20 > Keith= From nobody Wed Jul 22 08:44:38 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC481A1BEE for ; Wed, 22 Jul 2015 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 DMPfaNJmXgIH for ; Wed, 22 Jul 2015 08:44:35 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5CA1A1BEC for ; Wed, 22 Jul 2015 08:44:33 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-06v.sys.comcast.net with comcast id vTis1q00352QWKC01TkZd7; Wed, 22 Jul 2015 15:44:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id vTkY1q00K3Ge9ey01TkZqh; Wed, 22 Jul 2015 15:44:33 +0000 Message-ID: <55AFBA60.6040802@alum.mit.edu> Date: Wed, 22 Jul 2015 11:44:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437579873; bh=xASpXnhQU16PX4klQxTOPgHG9bmg0SyUIdMOKo5euCo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JOUw6QgP0YDTe04k5mfxYicTwlZye+JAKFrAQA4bZVDbSb7O+tYBwzQS24HLr0RHq KiYiOt4DgTZcfUcdx4Di4o4JmFTyQnurtF+c+UqjwUTF7rFPliVFMOS0eYpoeB8oqo pBwvQA2cMjBaSSwH0FCpt08XuXg62Wr0Xi7l2kg+F50LqRnmajCuAo5c6yLM9N7I2e Cyw+ft4Ed8RCiZW7hkBinksL2O3S8p7qsTgd0FqI5LFH46yv9ODijEBjF23zDSxf5l fsHCsEZjdmMJ+H2vSw0+EEDQiu2wCCmW2SjBnEHkbncYgv+T5iFkOecXd4RbzvdkFZ 0e8WR9C5t+uUg== Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:44:36 -0000 On 7/22/15 11:30 AM, DRAGE, Keith (Keith) wrote: > I've now read all the versions of meeting notes distributed. > > None of these expand on Cullen's privacy concern, so perhaps he could elaborate. > > I would state that: > > 1) the trust statements in the document relate only to the additional header field. The privacy requirements on the remainder of the Geolocation header field are unchanged. > > 2) for SIP deployments that use trust, neither the trust nor the entities involved in that trust are the same for every header field. So the trust for RFC 3325 is: a) on the sender to trust that the recipient to apply any "id" privacy indicated; b) on the recipient that they trust the sender to assert the identity. For this draft, the only trust required is that the receiver trusts the sender to assert that the new header field parameter was applied by a "originating telephony or electronic communications service provider". There is also a need for some entity to police the incoming trust boundary, and remove assertions (locparam values in this case) inserted by untrusted elements. Thanks, Paul > 3) I do not believe there is any privacy issue about the recipient receiving information that any contained Geolocation header field came from a "originating telephony or electronic communications service provider" as opposed to anywhere else. If there is, then the trust requirements could be altered in the same manner as already used for a number of 3GPP specific header fields. > > Keith > >> -----Original Message----- >> From: DRAGE, Keith (Keith) >> Sent: 22 July 2015 10:17 >> To: dispatch@ietf.org >> Subject: draft-winterbottom-dispatch-locparam >> >> Issues from the dispatch meeting discussion: >> >> 1) In regard to trust, what is needed is a mechanism to >> meet the following from the EC mandate: >> >> ". The enhancement, i.e. location data provision, is expected >> to be determined by the originating telephony or electronic >> communications service provider, capable of originating voice >> calls through a number or numbers in national telephone >> numbering plans, and be provided at call setup to the PSAP as >> soon as the call reaches the authority handling the emergency calls." >> >> The proposal in the document is that the recipient of a SIP >> request will either know that the entity that sent or proxied >> the SIP request is either an "originating telephony or >> electronic communications service provider" or trusts that >> entity to make a proper discrimination of that. >> >> Relying on certificates or known domain names would require >> PSAPs and networks routeing emergency calls to have a >> maintained database of all known "originating telephony or >> electronic communications service provider" worldwide. >> >> 2) The question was raised as to whether it should be >> specific for emergency call. I see no reason why it should >> be. It does not interfere with the location itself, or the >> privacy of the location itself. Further, I have a concern of >> any protocol mechanism that is emergency call specific, as it >> never gets tested until one wants to make an emergency call. >> >> 3) I believe Cullen mentioned privacy, but I am not sure >> in what context. The mechanism does not interfere with any of >> the privacy requirements defined for the Geolocation header >> field. Further if the trust in 1) above is not met, it is >> only the parameter that is removed, not the Geolocation >> header field itself. >> >> Regards >> >> Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Jul 22 08:46:32 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B44A1A1BFA for ; Wed, 22 Jul 2015 08:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, 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 m6gFzLStcThI for ; Wed, 22 Jul 2015 08:46:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6875B1A1EEE for ; Wed, 22 Jul 2015 08:46:29 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 0C9204FC06890; Wed, 22 Jul 2015 15:46:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MFkRcu028773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:46:27 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 17:46:27 +0200 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" , Cullen Jennings Thread-Topic: draft-winterbottom-dispatch-locparam Thread-Index: AdDEXyQD/iDurzCzTN+VcVMxRrjtLwAMPgPgAAE5wKA= Date: Wed, 22 Jul 2015 15:46:26 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6974994A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:46:31 -0000 To correct one error. In item 1) 1st sentence "additional header field" sho= uld be "additional header field parameter" Keith > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of DRAGE, Keith (Keith) > Sent: 22 July 2015 16:30 > To: dispatch@ietf.org; Cullen Jennings > Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam >=20 > I've now read all the versions of meeting notes distributed. >=20 > None of these expand on Cullen's privacy concern, so perhaps=20 > he could elaborate. >=20 > I would state that: >=20 > 1) the trust statements in the document relate only to the=20 > additional header field. The privacy requirements on the=20 > remainder of the Geolocation header field are unchanged. >=20 > 2) for SIP deployments that use trust, neither the trust=20 > nor the entities involved in that trust are the same for=20 > every header field. So the trust for RFC 3325 is: a) on the=20 > sender to trust that the recipient to apply any "id" privacy=20 > indicated; b) on the recipient that they trust the sender to=20 > assert the identity. For this draft, the only trust required=20 > is that the receiver trusts the sender to assert that the new=20 > header field parameter was applied by a "originating=20 > telephony or electronic communications service provider". >=20 > 3) I do not believe there is any privacy issue about the=20 > recipient receiving information that any contained=20 > Geolocation header field came from a "originating telephony=20 > or electronic communications service provider" as opposed to=20 > anywhere else. If there is, then the trust requirements could=20 > be altered in the same manner as already used for a number of=20 > 3GPP specific header fields. >=20 > Keith >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: 22 July 2015 10:17 > > To: dispatch@ietf.org > > Subject: draft-winterbottom-dispatch-locparam > >=20 > > Issues from the dispatch meeting discussion: > >=20 > > 1) In regard to trust, what is needed is a mechanism to=20 > > meet the following from the EC mandate: > >=20 > > ". The enhancement, i.e. location data provision, is expected to be=20 > > determined by the originating telephony or electronic=20 > communications=20 > > service provider, capable of originating voice calls=20 > through a number=20 > > or numbers in national telephone numbering plans, and be=20 > provided at=20 > > call setup to the PSAP as soon as the call reaches the authority=20 > > handling the emergency calls." > >=20 > > The proposal in the document is that the recipient of a SIP request=20 > > will either know that the entity that sent or proxied the=20 > SIP request=20 > > is either an "originating telephony or electronic communications=20 > > service provider" or trusts that entity to make a proper=20 > > discrimination of that. > >=20 > > Relying on certificates or known domain names would require=20 > PSAPs and=20 > > networks routeing emergency calls to have a maintained=20 > database of all=20 > > known "originating telephony or electronic communications service=20 > > provider" worldwide. > >=20 > > 2) The question was raised as to whether it should be=20 > > specific for emergency call. I see no reason why it should=20 > be. It does=20 > > not interfere with the location itself, or the privacy of=20 > the location=20 > > itself. Further, I have a concern of any protocol mechanism that is=20 > > emergency call specific, as it never gets tested until one wants to=20 > > make an emergency call. > >=20 > > 3) I believe Cullen mentioned privacy, but I am not sure=20 > > in what context. The mechanism does not interfere with any of the=20 > > privacy requirements defined for the Geolocation header=20 > field. Further=20 > > if the trust in 1) above is not met, it is only the=20 > parameter that is=20 > > removed, not the Geolocation header field itself. > >=20 > > Regards > >=20 > > Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From nobody Wed Jul 22 08:55:54 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A61E1A1BEC for ; Wed, 22 Jul 2015 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptr9YPh-RI8L for ; Wed, 22 Jul 2015 08:55:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2A81A0120 for ; Wed, 22 Jul 2015 08:55:51 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B1ED2890EBD5A; Wed, 22 Jul 2015 15:55:45 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MFtmDO028279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:55:48 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 17:55:48 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-winterbottom-dispatch-locparam Thread-Index: AQHQxJVYe3eSb9jiG02hvSCRPJkZap3no7OQ Date: Wed, 22 Jul 2015 15:55:47 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69749996@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55AFBA60.6040802@alum.mit.edu> In-Reply-To: <55AFBA60.6040802@alum.mit.edu> 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: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:55:53 -0000 Yes. That is in the draft, and I thought it was reasonably implicit in the summa= ry. I'm not trying to rewrite the procedures here. But in general, if the received header field parameter is not trusted, then= it is removed by the receiver. Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 22 July 2015 16:45 > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam >=20 > On 7/22/15 11:30 AM, DRAGE, Keith (Keith) wrote: > > I've now read all the versions of meeting notes distributed. > > > > None of these expand on Cullen's privacy concern, so=20 > perhaps he could elaborate. > > > > I would state that: > > > > 1) the trust statements in the document relate only to the=20 > additional header field. The privacy requirements on the=20 > remainder of the Geolocation header field are unchanged. > > > > 2) for SIP deployments that use trust, neither the trust=20 > nor the entities involved in that trust are the same for=20 > every header field. So the trust for RFC 3325 is: a) on the=20 > sender to trust that the recipient to apply any "id" privacy=20 > indicated; b) on the recipient that they trust the sender to=20 > assert the identity. For this draft, the only trust required=20 > is that the receiver trusts the sender to assert that the new=20 > header field parameter was applied by a "originating=20 > telephony or electronic communications service provider". >=20 > There is also a need for some entity to police the incoming=20 > trust boundary, and remove assertions (locparam values in=20 > this case) inserted by untrusted elements. >=20 > Thanks, > Paul >=20 > > 3) I do not believe there is any privacy issue about the=20 > recipient receiving information that any contained=20 > Geolocation header field came from a "originating telephony=20 > or electronic communications service provider" as opposed to=20 > anywhere else. If there is, then the trust requirements could=20 > be altered in the same manner as already used for a number of=20 > 3GPP specific header fields. > > > > Keith > > > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) > >> Sent: 22 July 2015 10:17 > >> To: dispatch@ietf.org > >> Subject: draft-winterbottom-dispatch-locparam > >> > >> Issues from the dispatch meeting discussion: > >> > >> 1) In regard to trust, what is needed is a mechanism to > >> meet the following from the EC mandate: > >> > >> ". The enhancement, i.e. location data provision, is=20 > expected to be=20 > >> determined by the originating telephony or electronic=20 > communications=20 > >> service provider, capable of originating voice calls=20 > through a number=20 > >> or numbers in national telephone numbering plans, and be=20 > provided at=20 > >> call setup to the PSAP as soon as the call reaches the authority=20 > >> handling the emergency calls." > >> > >> The proposal in the document is that the recipient of a=20 > SIP request=20 > >> will either know that the entity that sent or proxied the=20 > SIP request=20 > >> is either an "originating telephony or electronic communications=20 > >> service provider" or trusts that entity to make a proper=20 > >> discrimination of that. > >> > >> Relying on certificates or known domain names would=20 > require PSAPs and=20 > >> networks routeing emergency calls to have a maintained database of=20 > >> all known "originating telephony or electronic=20 > communications service=20 > >> provider" worldwide. > >> > >> 2) The question was raised as to whether it should be > >> specific for emergency call. I see no reason why it should be. It=20 > >> does not interfere with the location itself, or the privacy of the=20 > >> location itself. Further, I have a concern of any protocol=20 > mechanism=20 > >> that is emergency call specific, as it never gets tested until one=20 > >> wants to make an emergency call. > >> > >> 3) I believe Cullen mentioned privacy, but I am not sure > >> in what context. The mechanism does not interfere with any of the=20 > >> privacy requirements defined for the Geolocation header field.=20 > >> Further if the trust in 1) above is not met, it is only=20 > the parameter=20 > >> that is removed, not the Geolocation header field itself. > >> > >> Regards > >> > >> Keith > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From nobody Wed Jul 22 09:24:55 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D31A89F1 for ; Wed, 22 Jul 2015 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 rJ8RAL_R4Xo7 for ; Wed, 22 Jul 2015 09:24:51 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D421D1A88B3 for ; Wed, 22 Jul 2015 09:24:45 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-12v.sys.comcast.net with comcast id vUQb1q0042Bo0NV01UQlE5; Wed, 22 Jul 2015 16:24:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id vUQk1q00U3Ge9ey01UQk7B; Wed, 22 Jul 2015 16:24:45 +0000 Message-ID: <55AFC3CB.1060906@alum.mit.edu> Date: Wed, 22 Jul 2015 12:24:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55AFBA60.6040802@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69749996@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69749996@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437582285; bh=TXDoCHW7FOEkKLsoElmxq64xsG+YPIxBvfixjnAGK7A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UMh8Npe4WjVPQfpwpe2dkVnqYR+ibSlIot8WYGr0SQNn71eL68BX7KV/5DV1hn3dS cFZUa8l7hDb2vZLSKxPFKeG+GdjckbEsb5xG4Z3qiEJQvlpW9jbrmcVW/1epfRxwfP CbDBqWD6SSuCgmvhmNc3tJ9ymhFE9xh3pbG6L2UdcZOv2h/W+7Y70mmoeItcIvlugd 7abVebMwnEw/f3n07LiHEc71fnR3AyqxgdVXRCtebCTz8mc6xQ6yL3QXh2ROkYfY06 HII9A3qJYmyJkoe1zII8UlbSDGaL8/eTjltwDublmaGdqNUUlAfvvx0OUP0xpYyhTz PwVl1wCMh0P4w== Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:24:53 -0000 On 7/22/15 11:55 AM, DRAGE, Keith (Keith) wrote: > Yes. > > That is in the draft, and I thought it was reasonably implicit in the summary. I'm not trying to rewrite the procedures here. > > But in general, if the received header field parameter is not trusted, then it is removed by the receiver. The point of Spec(T) was to enumerate the things that must be specified. ISTM it would make sense for this draft to reference 3325 for a definition of Trust, rather than leaving it vague and loosely specified. Since the chief customer for this is IMS, and it already depends on 3325, it doesn't seem like a big burden. In particular, it makes clear that some elements sit on a trust boundary and are responsible for policing, while other elements may not be on a boundary and have no responsibility for policing. Thanks, Paul > Keith > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 22 July 2015 16:45 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam >> >> On 7/22/15 11:30 AM, DRAGE, Keith (Keith) wrote: >>> I've now read all the versions of meeting notes distributed. >>> >>> None of these expand on Cullen's privacy concern, so >> perhaps he could elaborate. >>> >>> I would state that: >>> >>> 1) the trust statements in the document relate only to the >> additional header field. The privacy requirements on the >> remainder of the Geolocation header field are unchanged. >>> >>> 2) for SIP deployments that use trust, neither the trust >> nor the entities involved in that trust are the same for >> every header field. So the trust for RFC 3325 is: a) on the >> sender to trust that the recipient to apply any "id" privacy >> indicated; b) on the recipient that they trust the sender to >> assert the identity. For this draft, the only trust required >> is that the receiver trusts the sender to assert that the new >> header field parameter was applied by a "originating >> telephony or electronic communications service provider". >> >> There is also a need for some entity to police the incoming >> trust boundary, and remove assertions (locparam values in >> this case) inserted by untrusted elements. >> >> Thanks, >> Paul >> >>> 3) I do not believe there is any privacy issue about the >> recipient receiving information that any contained >> Geolocation header field came from a "originating telephony >> or electronic communications service provider" as opposed to >> anywhere else. If there is, then the trust requirements could >> be altered in the same manner as already used for a number of >> 3GPP specific header fields. >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: DRAGE, Keith (Keith) >>>> Sent: 22 July 2015 10:17 >>>> To: dispatch@ietf.org >>>> Subject: draft-winterbottom-dispatch-locparam >>>> >>>> Issues from the dispatch meeting discussion: >>>> >>>> 1) In regard to trust, what is needed is a mechanism to >>>> meet the following from the EC mandate: >>>> >>>> ". The enhancement, i.e. location data provision, is >> expected to be >>>> determined by the originating telephony or electronic >> communications >>>> service provider, capable of originating voice calls >> through a number >>>> or numbers in national telephone numbering plans, and be >> provided at >>>> call setup to the PSAP as soon as the call reaches the authority >>>> handling the emergency calls." >>>> >>>> The proposal in the document is that the recipient of a >> SIP request >>>> will either know that the entity that sent or proxied the >> SIP request >>>> is either an "originating telephony or electronic communications >>>> service provider" or trusts that entity to make a proper >>>> discrimination of that. >>>> >>>> Relying on certificates or known domain names would >> require PSAPs and >>>> networks routeing emergency calls to have a maintained database of >>>> all known "originating telephony or electronic >> communications service >>>> provider" worldwide. >>>> >>>> 2) The question was raised as to whether it should be >>>> specific for emergency call. I see no reason why it should be. It >>>> does not interfere with the location itself, or the privacy of the >>>> location itself. Further, I have a concern of any protocol >> mechanism >>>> that is emergency call specific, as it never gets tested until one >>>> wants to make an emergency call. >>>> >>>> 3) I believe Cullen mentioned privacy, but I am not sure >>>> in what context. The mechanism does not interfere with any of the >>>> privacy requirements defined for the Geolocation header field. >>>> Further if the trust in 1) above is not met, it is only >> the parameter >>>> that is removed, not the Geolocation header field itself. >>>> >>>> Regards >>>> >>>> Keith >>> _______________________________________________ >>> 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 >> From nobody Wed Jul 22 09:36:34 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8FC1A8997 for ; Wed, 22 Jul 2015 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKExrUKQillI for ; Wed, 22 Jul 2015 09:36:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA961A87EA for ; Wed, 22 Jul 2015 09:36:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 690A0DD3640EE; Wed, 22 Jul 2015 16:36:24 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MGaRIr025245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:36:27 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 18:36:27 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-winterbottom-dispatch-locparam Thread-Index: AQHQxJrqe3eSb9jiG02hvSCRPJkZap3nrPqQ Date: Wed, 22 Jul 2015 16:36:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69749AAB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55AFBA60.6040802@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69749996@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55AFC3CB.1060906@alum.mit.edu> In-Reply-To: <55AFC3CB.1060906@alum.mit.edu> 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: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:36:32 -0000 To be clear, the chief customer of this at the moment is VoIP providers and= emergency service providers in Europe that do not do IMS. IMS is a paralle= l architecture that currently does not specify this for location, although = possibly it could in the future. I do agree that the document needs to be clear about what is meant by trust= . But the point of my posting was to try and elaborate and close the issue Cu= llen was raising about privacy. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 22 July 2015 17:25 > To: DRAGE, Keith (Keith); dispatch@ietf.org > Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam >=20 > On 7/22/15 11:55 AM, DRAGE, Keith (Keith) wrote: > > Yes. > > > > That is in the draft, and I thought it was reasonably=20 > implicit in the summary. I'm not trying to rewrite the=20 > procedures here. > > > > But in general, if the received header field parameter is=20 > not trusted, then it is removed by the receiver. >=20 > The point of Spec(T) was to enumerate the things that must be=20 > specified.=20 > ISTM it would make sense for this draft to reference 3325 for=20 > a definition of Trust, rather than leaving it vague and=20 > loosely specified.=20 > Since the chief customer for this is IMS, and it already=20 > depends on 3325, it doesn't seem like a big burden. >=20 > In particular, it makes clear that some elements sit on a=20 > trust boundary and are responsible for policing, while other=20 > elements may not be on a boundary and have no responsibility=20 > for policing. >=20 > Thanks, > Paul >=20 > > Keith > > > >> -----Original Message----- > >> From: dispatch [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Paul=20 > >> Kyzivat > >> Sent: 22 July 2015 16:45 > >> To: dispatch@ietf.org > >> Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam > >> > >> On 7/22/15 11:30 AM, DRAGE, Keith (Keith) wrote: > >>> I've now read all the versions of meeting notes distributed. > >>> > >>> None of these expand on Cullen's privacy concern, so > >> perhaps he could elaborate. > >>> > >>> I would state that: > >>> > >>> 1) the trust statements in the document relate only to the > >> additional header field. The privacy requirements on the=20 > remainder of=20 > >> the Geolocation header field are unchanged. > >>> > >>> 2) for SIP deployments that use trust, neither the trust > >> nor the entities involved in that trust are the same for=20 > every header=20 > >> field. So the trust for RFC 3325 is: a) on the sender to=20 > trust that=20 > >> the recipient to apply any "id" privacy indicated; b) on the=20 > >> recipient that they trust the sender to assert the=20 > identity. For this=20 > >> draft, the only trust required is that the receiver trusts=20 > the sender=20 > >> to assert that the new header field parameter was applied by a=20 > >> "originating telephony or electronic communications service=20 > >> provider". > >> > >> There is also a need for some entity to police the incoming trust=20 > >> boundary, and remove assertions (locparam values in this case)=20 > >> inserted by untrusted elements. > >> > >> Thanks, > >> Paul > >> > >>> 3) I do not believe there is any privacy issue about the > >> recipient receiving information that any contained=20 > Geolocation header=20 > >> field came from a "originating telephony or electronic=20 > communications=20 > >> service provider" as opposed to anywhere else. If there=20 > is, then the=20 > >> trust requirements could be altered in the same manner as already=20 > >> used for a number of 3GPP specific header fields. > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: DRAGE, Keith (Keith) > >>>> Sent: 22 July 2015 10:17 > >>>> To: dispatch@ietf.org > >>>> Subject: draft-winterbottom-dispatch-locparam > >>>> > >>>> Issues from the dispatch meeting discussion: > >>>> > >>>> 1) In regard to trust, what is needed is a mechanism to > >>>> meet the following from the EC mandate: > >>>> > >>>> ". The enhancement, i.e. location data provision, is > >> expected to be > >>>> determined by the originating telephony or electronic > >> communications > >>>> service provider, capable of originating voice calls > >> through a number > >>>> or numbers in national telephone numbering plans, and be > >> provided at > >>>> call setup to the PSAP as soon as the call reaches the authority=20 > >>>> handling the emergency calls." > >>>> > >>>> The proposal in the document is that the recipient of a > >> SIP request > >>>> will either know that the entity that sent or proxied the > >> SIP request > >>>> is either an "originating telephony or electronic communications=20 > >>>> service provider" or trusts that entity to make a proper=20 > >>>> discrimination of that. > >>>> > >>>> Relying on certificates or known domain names would > >> require PSAPs and > >>>> networks routeing emergency calls to have a maintained=20 > database of=20 > >>>> all known "originating telephony or electronic > >> communications service > >>>> provider" worldwide. > >>>> > >>>> 2) The question was raised as to whether it should be > >>>> specific for emergency call. I see no reason why it=20 > should be. It=20 > >>>> does not interfere with the location itself, or the=20 > privacy of the=20 > >>>> location itself. Further, I have a concern of any protocol > >> mechanism > >>>> that is emergency call specific, as it never gets tested=20 > until one=20 > >>>> wants to make an emergency call. > >>>> > >>>> 3) I believe Cullen mentioned privacy, but I am not sure > >>>> in what context. The mechanism does not interfere with=20 > any of the=20 > >>>> privacy requirements defined for the Geolocation header field. > >>>> Further if the trust in 1) above is not met, it is only > >> the parameter > >>>> that is removed, not the Geolocation header field itself. > >>>> > >>>> Regards > >>>> > >>>> Keith > >>> _______________________________________________ > >>> 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 > >> >=20 > = From nobody Wed Jul 22 09:55:53 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9B1B2B1F for ; Wed, 22 Jul 2015 09:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] 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 OuT1Z6qxRJ6A for ; Wed, 22 Jul 2015 09:55:45 -0700 (PDT) Received: from smtpdg228.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 45F0B1A1B28 for ; Wed, 22 Jul 2015 09:55:45 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd04.ad.aruba.it with bizsmtp id vUvG1q00C2NEPrz01UvHKB; Wed, 22 Jul 2015 18:55:17 +0200 Date: Wed, 22 Jul 2015 18:55:18 +0200 (CEST) From: Meetecho Team To: dispatch@ietf.org Message-ID: <1612687302.5.1437584118079.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4_1984541037.1437584118077" Archived-At: Subject: [dispatch] Meetecho recordings of DISPATCH WG session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:55:46 -0000 ------=_Part_4_1984541037.1437584118077 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the DISPATCH WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#DISPATCH In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_4_1984541037.1437584118077-- From nobody Wed Jul 22 21:24:48 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910611A036A for ; Wed, 22 Jul 2015 21:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 dab1vb_fZYLH for ; Wed, 22 Jul 2015 21:24:46 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2881A0248 for ; Wed, 22 Jul 2015 21:24:46 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:136:c617:feff:feb6:86ed]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id BE5F320AB7 for ; Thu, 23 Jul 2015 06:24:43 +0200 (CEST) Message-ID: <55B06C88.7040601@acm.org> Date: Thu, 23 Jul 2015 06:24:40 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: DISPATCH list Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Draft charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 04:24:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Here's the draft of the ICE charter. Thanks. - ------------------------------------------------------------------------------------------------ Charter for Working Group Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. ICE was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including a multiplicity of IP addresses and ports in both the request and response messages of a connectivity establishment transaction. The IP addresses and ports provided by each side are paired and tested by peer-to-peer connectivity checks until one of these pair is selected to transport data. ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261) and later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocol. But it is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940). The goal of the ICE Working Group is to consolidate the various initiatives to update ICE to make it more suitable for the WebRTC environment but also to all the current usages of ICE. The Working Group will closely coordinate with the appropriate Working Groups, including RTCWEB, MMUSIC, TRAM, MIF, HIP and P2PSIP. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVsGyIAAoJECnERZXWan7EriIQAIbjM4t/2+20p5uPSYqcIY36 flSZXMHSIPhS3/UMO/AKc6A3B4bIffZHZ+PkU0ieipyjc+QTegkKceMh9kVTdz4R DTy+VCdlBG6YFTS/92Fd/ofA01UbJptIeDbdAVKk9j6qLSwEpj21yxUm7bkTVt0Y 0nPt61OsM6PYDv/SSjfUhPaQsH6J+SVsVXxzmjY2LsT0Nv92jeFgbQYdjK1Ofav/ LipwmXSP+uuLNFXS+AprXn1LidFfiwh+/YZ5wBzUwdy+Fvp8dHotGxvGA5RE2D22 bsPNlGBvkpAnM28mS3G9fiwOQHFDXalcL0KuKNxdjHwh3JWjuKICdu1ixADAcNHK E2Ae5phyxki3bGd0OJ6fQ9K6iwjvKzvQpvCWKie0ID1976Y79Hq7Qnpy9oas1hMx 2anT+5HIHRH2ksoiiJ/cRl/4YBiKiB7QhEI3CyoPp1tFJzOLZKHCRHd4ZpbdXqzT byFYOXnF5csLnAqnPIa9eyBSul3oUjiqjgkej8E1TpD08dtvTFq5YfmyGSFfa7YR KfB0DZUk1iNOVno87oHArupypGV8IchgPajMvhm9J20ALyKDk5Dh48tmnDlc9uO9 PDtv8SD0gBo9tY965CaXqhB3PfhKM0Wigw2xF9dD0G0sRibp9Q4HegTLOJ4LeReD 5bXhszAIjGBcxB5QnC98 =dgdO -----END PGP SIGNATURE----- From nobody Thu Jul 23 00:48:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D41A8925 for ; Thu, 23 Jul 2015 00:48:06 -0700 (PDT) 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 2aNC0hrPg77e for ; Thu, 23 Jul 2015 00:48:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EAB1A8923 for ; Thu, 23 Jul 2015 00:48:03 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-01-55b09c3163b3 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.FB.12828.13C90B55; Thu, 23 Jul 2015 09:48:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Thu, 23 Jul 2015 09:48:01 +0200 To: Marc Petit-Huguenin , DISPATCH list References: <55B06C88.7040601@acm.org> From: Magnus Westerlund Message-ID: <55B09C2F.3070903@ericsson.com> Date: Thu, 23 Jul 2015 09:47:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B06C88.7040601@acm.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+Jvja7RnA2hBq9ucFosnbSA1eLCmrtM Dkwel694eyxZ8pMpgCmKyyYlNSezLLVI3y6BK2Pj7L0sBbdEKjY2Rjcw3hfoYuTkkBAwkZgy 8yA7hC0mceHeerYuRi4OIYGjjBIX7pxlgXCWM0qc23qMFaRKWEBVYsrKeYwgtoiAr8Se/2+Y QWwhATWJs7+mgNlsAhYSN380Ak3i4OAV0JY4fDYMJMwC1Drn3iKwZaICMRLzV0wHK+cVEJQ4 OfMJC0g5p4C6xIs9YCazgL3Eg61lIBXMAvISzVtnQy3Slmho6mCdwCgwC0nzLISOWUg6FjAy r2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIDMaDW37r7mBc/drxEKMAB6MSD++Dpg2hQqyJ ZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmH/usKPCk5sG4f8X 8Gi7qe/tMmhwkdt/NLhMdfHvYs4LxaW/H5cWlOw6vXTJ+omzZuTtn/eLZ73y60mLczqvPLZ3 OrnzYWmCpcrevabfLW/p/9hwiffP1jWrts4w2Tlvo9xJyULN8yLZDfPqE5hD/ydo+nrYPZdI dPTTdfy4dXVEPUPE2xlPHyqxFGckGmoxFxUnAgCjk5dLJwIAAA== Archived-At: Subject: Re: [dispatch] Draft charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:48:06 -0000 Hi, First of all creating an ICE WG is in my opinion a good idea. However, I think this charter will need some work. The introduction appears fine, but the work the group should do is poorly specified. I think the charter need to be much more specific on what work the group should do. Please write clearer goals for the work that is to be done by the group. Cheers Magnus Den 2015-07-23 kl. 06:24, skrev Marc Petit-Huguenin: > > Charter for Working Group > > Interactive Connectivity Establishment was published as RFC 5245 in > April 2010. Until recently the protocol had seen rather limited > deployment. ICE was slow to achieve widespread adoption, as other > mechanisms were already being used by the VoIP industry. This > situation has changed drastically as ICE is mandatory to implement in > WebRTC, a set of technologies developed at the IETF and W3C to > standardize Real Time Communication on the Web. > > Interactive Connectivity Establishment (ICE) is at the same time a > NAT traversal technique, a multihomed address selection technique, > and a dual stack address selection technique that works by including > a multiplicity of IP addresses and ports in both the request and > response messages of a connectivity establishment transaction. The > IP addresses and ports provided by each side are paired and tested by > peer-to-peer connectivity checks until one of these pair is selected > to transport data. > > ICE was originally defined for the Offer-Answer (RFC 3264) protocol > used by SIP (RFC 3261) and later XMPP (XEP-0176), RTSP > (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and > other realtime media establishment protocol. But it is also used by > non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC > 6940). > > The goal of the ICE Working Group is to consolidate the various > initiatives to update ICE to make it more suitable for the WebRTC > environment but also to all the current usages of ICE. The Working > Group will closely coordinate with the appropriate Working Groups, > including RTCWEB, MMUSIC, TRAM, MIF, HIP and P2PSIP. > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jul 23 02:45:51 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0B1A1B77; Thu, 23 Jul 2015 02:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 STGu22GAZw1r; Thu, 23 Jul 2015 02:45:49 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CCA311A1A94; Thu, 23 Jul 2015 02:45:48 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:136:c617:feff:feb6:86ed]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9F55F20AB7; Thu, 23 Jul 2015 11:45:47 +0200 (CEST) Message-ID: <55B0B7C9.3050701@acm.org> Date: Thu, 23 Jul 2015 11:45:45 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , DISPATCH list , ice@ietf.org References: <55B06C88.7040601@acm.org> <55B09C2F.3070903@ericsson.com> In-Reply-To: <55B09C2F.3070903@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Draft charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:45:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/23/2015 09:47 AM, Magnus Westerlund wrote: > Hi, > > First of all creating an ICE WG is in my opinion a good idea. > However, I think this charter will need some work. The introduction > appears fine, but the work the group should do is poorly specified. I > think the charter need to be much more specific on what work the > group should do. Please write clearer goals for the work that is to > be done by the group. That was never meant as a complete charter, but as a minimal charter to which people can propose new and/or modified text. I am happy to serve as editor until someone better at it step in, but meanwhile sending text is probably the best way to iterate quickly towards an acceptable charter. Thanks. > > Cheers > > Magnus > > > Den 2015-07-23 kl. 06:24, skrev Marc Petit-Huguenin: >> >> Charter for Working Group >> >> Interactive Connectivity Establishment was published as RFC 5245 >> in April 2010. Until recently the protocol had seen rather limited >> deployment. ICE was slow to achieve widespread adoption, as other >> mechanisms were already being used by the VoIP industry. This >> situation has changed drastically as ICE is mandatory to implement >> in WebRTC, a set of technologies developed at the IETF and W3C to >> standardize Real Time Communication on the Web. >> >> Interactive Connectivity Establishment (ICE) is at the same time a >> NAT traversal technique, a multihomed address selection technique, >> and a dual stack address selection technique that works by >> including a multiplicity of IP addresses and ports in both the >> request and response messages of a connectivity establishment >> transaction. The IP addresses and ports provided by each side are >> paired and tested by peer-to-peer connectivity checks until one of >> these pair is selected to transport data. >> >> ICE was originally defined for the Offer-Answer (RFC 3264) >> protocol used by SIP (RFC 3261) and later XMPP (XEP-0176), RTSP >> (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and >> other realtime media establishment protocol. But it is also used >> by non-realtime media protocols, like HIP (RFC 5770) and RELOAD >> (RFC 6940). >> >> The goal of the ICE Working Group is to consolidate the various >> initiatives to update ICE to make it more suitable for the WebRTC >> environment but also to all the current usages of ICE. The >> Working Group will closely coordinate with the appropriate Working >> Groups, including RTCWEB, MMUSIC, TRAM, MIF, HIP and P2PSIP. >> > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVsLfJAAoJECnERZXWan7EAdEP/A09FITttbku24Reylj2X8Y2 CgB+/5kPCxRIy65neyXTleZIG/gvsRExAVcBHlL86+zX8JJ2rz7MoceRtUVRqnrZ JeQPOUQ1y03WSUDWkvjoMjk7hWYGdnXR5pganHEPP+dPDAWxSEj+s8vaXk2Mau72 AYGeWBeVr99ofRFSlEUB2Sdgpv0xhTJD2tcyb/J9rD4pgxQ6pDgoImvGdH0s/hRQ ex7z/5VWdxNDXHF4ggjaAwXJ/EH21rZDzqv4nYmaH3SQMk0NqWdfH8DR3Pb0SNI+ 3qFAN9BZYe5m9mhaiWbgH8ATjsFEy4FG3KcyMqZZ5942Hf5KUSgSR4brE6w/kWm/ E8cZCuFIYW4tWUQci50EIryIvK/NwNwGo3p6h3GMO442my0k+aQiOjjF7pYb7rLC Hw9OcKRKfrAUu/rHbpKSqmNYJrhSFtOqaoQk8a4U8YPWMdEB/rDRY3nwGD4ppoHM 6JeOLezXmdNFoVcdHEqLiJmCw/Ets696wZCnY1fgw+pLPZM0YMuRo/kEjNAyhjlo sXNTJgOZ11U3Hh5+/on9Pjn3peK2r45ylFA7ncoKy8B01csFqVImxeBRTU9gEoU5 yTYHHnYUhA2OEF8wHbV5FyYFEXC8TcVfMzmchiFTjIYGynvoG23bRkSh4FNP8A9K 9Hl7a6LU4Q13ddYWSqk1 =JSOi -----END PGP SIGNATURE----- From nobody Thu Jul 23 07:29:18 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6701A903F for ; Thu, 23 Jul 2015 07:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uOG-eGNYt3-G for ; Thu, 23 Jul 2015 07:29:15 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AAD1ACF6C for ; Thu, 23 Jul 2015 07:26:35 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 23 Jul 2015 07:26:35 -0700 From: Michael Hammer To: "keith.drage@alcatel-lucent.com" , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-winterbottom-dispatch-locparam Thread-Index: AdDEXyQD/iDurzCzTN+VcVMxRrjtLwAMPgPgAA/3ZwAAAGSWgAAgeeLA Date: Thu, 23 Jul 2015 14:26:34 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BC0EAF17@sc9-ex2k10mb1.corp.yaanatech.com> References: <949EF20990823C4C85C18D59AA11AD8B6974984A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55AFBA60.6040802@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B69749996@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69749996@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.185] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_015E_01D0C532.0BCE23C0" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 14:29:17 -0000 ------=_NextPart_000_015E_01D0C532.0BCE23C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Does that include any parameter that they just don't understand? That could break things. And not the general SIP policy? ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Wednesday, July 22, 2015 11:56 AM To: Paul Kyzivat ; dispatch@ietf.org Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam Yes. That is in the draft, and I thought it was reasonably implicit in the summary. I'm not trying to rewrite the procedures here. But in general, if the received header field parameter is not trusted, then it is removed by the receiver. Keith > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 22 July 2015 16:45 > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam > > On 7/22/15 11:30 AM, DRAGE, Keith (Keith) wrote: > > I've now read all the versions of meeting notes distributed. > > > > None of these expand on Cullen's privacy concern, so > perhaps he could elaborate. > > > > I would state that: > > > > 1) the trust statements in the document relate only to the > additional header field. The privacy requirements on the remainder of > the Geolocation header field are unchanged. > > > > 2) for SIP deployments that use trust, neither the trust > nor the entities involved in that trust are the same for every header > field. So the trust for RFC 3325 is: a) on the sender to trust that > the recipient to apply any "id" privacy indicated; b) on the recipient > that they trust the sender to assert the identity. For this draft, the > only trust required is that the receiver trusts the sender to assert > that the new header field parameter was applied by a "originating > telephony or electronic communications service provider". > > There is also a need for some entity to police the incoming trust > boundary, and remove assertions (locparam values in this case) > inserted by untrusted elements. > > Thanks, > Paul > > > 3) I do not believe there is any privacy issue about the > recipient receiving information that any contained Geolocation header > field came from a "originating telephony or electronic communications > service provider" as opposed to anywhere else. If there is, then the > trust requirements could be altered in the same manner as already used > for a number of 3GPP specific header fields. > > > > Keith > > > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) > >> Sent: 22 July 2015 10:17 > >> To: dispatch@ietf.org > >> Subject: draft-winterbottom-dispatch-locparam > >> > >> Issues from the dispatch meeting discussion: > >> > >> 1) In regard to trust, what is needed is a mechanism to > >> meet the following from the EC mandate: > >> > >> ". The enhancement, i.e. location data provision, is > expected to be > >> determined by the originating telephony or electronic > communications > >> service provider, capable of originating voice calls > through a number > >> or numbers in national telephone numbering plans, and be > provided at > >> call setup to the PSAP as soon as the call reaches the authority > >> handling the emergency calls." > >> > >> The proposal in the document is that the recipient of a > SIP request > >> will either know that the entity that sent or proxied the > SIP request > >> is either an "originating telephony or electronic communications > >> service provider" or trusts that entity to make a proper > >> discrimination of that. > >> > >> Relying on certificates or known domain names would > require PSAPs and > >> networks routeing emergency calls to have a maintained database of > >> all known "originating telephony or electronic > communications service > >> provider" worldwide. > >> > >> 2) The question was raised as to whether it should be > >> specific for emergency call. I see no reason why it should be. It > >> does not interfere with the location itself, or the privacy of the > >> location itself. Further, I have a concern of any protocol > mechanism > >> that is emergency call specific, as it never gets tested until one > >> wants to make an emergency call. > >> > >> 3) I believe Cullen mentioned privacy, but I am not sure > >> in what context. The mechanism does not interfere with any of the > >> privacy requirements defined for the Geolocation header field. > >> Further if the trust in 1) above is not met, it is only > the parameter > >> that is removed, not the Geolocation header field itself. > >> > >> Regards > >> > >> Keith > > _______________________________________________ > > 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 > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_015E_01D0C532.0BCE23C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzIzMTQyNjMzWjAjBgkqhkiG 9w0BCQQxFgQU6N46cE/87RgKK8r/D4LyY0YpVK4wgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwDQYJKoZIhvcNAQEBBQAEggEA f2OA9ewcOogEivXhp/3u7PX8nbXZ4mMGcRq9a88uo6L539DLT39Wjx+bYxLkSj24BiDeHImAF+oT cnWjZQ0aUZ8fv3pGy3hA2sC7iiMmnTRwutli5fe256Xm1rdh/v8uFtJid7CJcO4t47dzCJ/s4TOK i87HLq2xZJx/JsUR8YGNpiPY/UDiQzPGSHYsT/WKzt7z5JJx6tqh9GDAne9cTf1E/F5DSEAt1+Wo 2FuDZDDJd5N8bwTmAV+gQjWhQ86n+/wBnaOqKs0UdYJHPgqhqyHmX/FNdDoVkveK7jR/Lcy3A3zf OD9Ks4KyudXECO4JLChS2l68xESa/0uI7O6oxQAAAAAAAA== ------=_NextPart_000_015E_01D0C532.0BCE23C0-- From nobody Fri Jul 24 01:13:03 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0C21B302C for ; Fri, 24 Jul 2015 01:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTIJBNOy5FkO for ; Fri, 24 Jul 2015 01:13:01 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CFC1B3024 for ; Fri, 24 Jul 2015 01:13:00 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so17544834wib.0 for ; Fri, 24 Jul 2015 01:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LXdtBkYyNnJKsl+qTZ8vjmlCqdzOPVUkVK+Jbo8pqCs=; b=qW1TT6QH+z035aK9X5OstZZCer7OFBP54BEaZ8cR8dS/YBfmf9fdohPvpXQGZkmGLv 1SCwbepjU/YsRp6eeZOknpAFki/8nv69bQyceV+qG1kcBoK/uB0DMZTEgLOjuZerWSE2 Jkp87XekJ2KQ5O/g1eDOCZbObDSKjFjDsZLEs1aAUr/IPBRJ8GrkmUe9Gb8q5MX6QvFv Wt5pI4jdUvdewWdR8x5QAKLjPiPagJnIpSRlipxg8cEqV74v2xbJFpIbW3J4L/SRYD8C STk05Ye03hsujUyuKqeSlkg2sXXn7Jad3rD2O1uHCEfgEuz4rAZTXoEgVYZpsIOdXztN tl3A== MIME-Version: 1.0 X-Received: by 10.194.97.196 with SMTP id ec4mr24300142wjb.3.1437725579440; Fri, 24 Jul 2015 01:12:59 -0700 (PDT) Received: by 10.27.100.3 with HTTP; Fri, 24 Jul 2015 01:12:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Jul 2015 10:12:59 +0200 Message-ID: From: Sean Gillies To: DISPATCH list Content-Type: multipart/alternative; boundary=047d7bf0ef187276a4051b9a92f0 Archived-At: Subject: Re: [dispatch] GeoJSON question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:13:02 -0000 --047d7bf0ef187276a4051b9a92f0 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 10:09 AM, James Winterbottom < a.james.winterbottom@gmail.com> wrote: > It feels like the question is the target of the location ever going to be > conveyed with the location information? > Are you asking if it's possible to convey, say, phone numbers and locations of the the phones and the semantics needed to track the devices and their users together in GeoJSON? This would require a protocol or framework external to the GeoJSON format. GeoJSON specifies that Features should have an "id" property and that it should uniquely identify the feature within its collection. There's no requirement or implication that the id identifies the thing described by the Feature. GeoJSON's "id" is no more than Atom's Entry "id" (RFC 4287 has had a major influence on GeoJSON). Semantics such as what it would mean to use, eg, "tel:867-5309" as a feature id are not defined by GeoJSON. -- Sean Gillies --047d7bf0ef187276a4051b9a92f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 22, 2015 at 10:09 AM, James Winterbottom <a.james.winterbottom@gmail.com> wrote:
It feels like the question is the target of the location ever going to b= e conveyed with the location information?

Are you askin= g if it's possible to convey, say, phone numbers and locations of the t= he phones and the semantics needed to track the devices and their users tog= ether in GeoJSON? This would require a protocol or framework external to th= e GeoJSON format. GeoJSON specifies that Features should have an "id&q= uot; property and that it should uniquely identify the feature within its c= ollection. There's no requirement or implication that the id identifies= the thing described by the Feature. GeoJSON's "id" is no mor= e than Atom's Entry "id" (RFC 4287 has had a major influence = on GeoJSON). Semantics such as what it would mean to use, eg, "tel:867= -5309" as a feature id are not defined by GeoJSON.

=
--
Sean Gillies
--047d7bf0ef187276a4051b9a92f0-- From nobody Fri Jul 24 14:48:00 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BED81A88CF for ; Fri, 24 Jul 2015 14:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax68lh8ck9qj for ; Fri, 24 Jul 2015 14:47:57 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9621A88BE for ; Fri, 24 Jul 2015 14:47:57 -0700 (PDT) Received: by pdbbh15 with SMTP id bh15so19195437pdb.1 for ; Fri, 24 Jul 2015 14:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZxVuTZQHtYrg/QMtxMOxc+UGpEWMGlQgoTarYqimMVg=; b=d/vQ8BzUSMXW0j7ALKCHbiircnNsA0zpvNeR/9vjyQUZ3yBZZFksTLk4gg0ROQhKki q+fdZ6w5HV0QybGc+eFL5O/OVS//uvwoPua+18azpjkM9bUkG1t0e4D8UcnW9liIc0uf o1dPBEtDH/M6aAKWupQ6wyhVvqZiegllwS1qMIvhnKbWaLPo8WvQHXb87Hiy92GoQL81 PZtPoYTcl0cYuNKsaMm+5KhVusslbt+OU4aY0pn5vMYsK/gr00jERAnrLq8by5qVenT7 6qJ6f8e8dwXHizwQ83U5R8Of9t/y1u7bciSJf51wCKQ4+FOdX6gF3lLAkn6xMgQM47bH dTmw== X-Received: by 10.70.96.2 with SMTP id do2mr35457538pdb.67.1437774477354; Fri, 24 Jul 2015 14:47:57 -0700 (PDT) Received: from [192.168.1.11] (124-168-131-205.dyn.iinet.net.au. [124.168.131.205]) by smtp.gmail.com with ESMTPSA id ra10sm16366615pab.19.2015.07.24.14.47.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jul 2015 14:47:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4E4010A-45A2-42D9-85C2-C6290351D4D1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: Date: Sat, 25 Jul 2015 07:47:52 +1000 Message-Id: <93B79A5A-777E-4F41-AC6F-5CE57ECB6CF9@gmail.com> References: To: Sean Gillies X-Mailer: Apple Mail (2.2098) Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] GeoJSON question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 21:47:59 -0000 --Apple-Mail=_C4E4010A-45A2-42D9-85C2-C6290351D4D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Sean. That clarifies my question. > On 24 Jul 2015, at 6:12 pm, Sean Gillies = wrote: >=20 > On Wed, Jul 22, 2015 at 10:09 AM, James Winterbottom = > = wrote: > It feels like the question is the target of the location ever going to = be conveyed with the location information? >=20 > Are you asking if it's possible to convey, say, phone numbers and = locations of the the phones and the semantics needed to track the = devices and their users together in GeoJSON? This would require a = protocol or framework external to the GeoJSON format. GeoJSON specifies = that Features should have an "id" property and that it should uniquely = identify the feature within its collection. There's no requirement or = implication that the id identifies the thing described by the Feature. = GeoJSON's "id" is no more than Atom's Entry "id" (RFC 4287 has had a = major influence on GeoJSON). Semantics such as what it would mean to = use, eg, "tel:867-5309" as a feature id are not defined by GeoJSON. >=20 > --=20 > Sean Gillies > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_C4E4010A-45A2-42D9-85C2-C6290351D4D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks Sean. That clarifies my question.



On = 24 Jul 2015, at 6:12 pm, Sean Gillies <sean.gillies@gmail.com> wrote:

On Wed, Jul 22, 2015 at 10:09 AM, James Winterbottom <a.james.winterbottom@gmail.com> wrote:
It feels like the = question is the target of the location ever going to be conveyed with = the location information?

Are = you asking if it's possible to convey, say, phone numbers and locations = of the the phones and the semantics needed to track the devices and = their users together in GeoJSON? This would require a protocol or = framework external to the GeoJSON format. GeoJSON specifies that = Features should have an "id" property and that it should uniquely = identify the feature within its collection. There's no requirement or = implication that the id identifies the thing described by the Feature. = GeoJSON's "id" is no more than Atom's Entry "id" (RFC 4287 has had a = major influence on GeoJSON). Semantics such as what it would mean to = use, eg, "tel:867-5309" as a feature id are not defined by GeoJSON.

--
Sean Gillies
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_C4E4010A-45A2-42D9-85C2-C6290351D4D1-- From nobody Fri Jul 24 23:47:44 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7051B2CF9 for ; Fri, 24 Jul 2015 23:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 mhfgT1nYxEwG for ; Fri, 24 Jul 2015 23:47:39 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500E21B2CFA for ; Fri, 24 Jul 2015 23:47:39 -0700 (PDT) Received: by pacan13 with SMTP id an13so25176611pac.1 for ; Fri, 24 Jul 2015 23:47:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oLVNMKX1+FK4aEpfzLv+ExYDLgfKPjidwUL6lIT2DdQ=; b=ayqXhGQLpreGD8+wU8xieHj0Oi7A5ZFLKWVWrR2XfXHTyLuEOSuzuxzWMgIJ2ZhiMn /LyHyiup7lO8Q3RRaa7jo9gyX5oMsRzrgyYMRh/W/TtT/nSw6ZahhgL0GTKh4iYTpdN1 ETGWRCame2moTe1wyr69VO43ZgufBTW68ZNZ5rhJT+3C3qZ1kKkxO4nWjahe0YGknNey dCgGgtwOnAP47GvzZnF91gwfVkBKQl4TmPAxghNnlrdeUGU0HQAWZiV3YIUfOknjN+Ac 2FiQ8Ps94Pt+c5Uujy84qRpUIsLn050eMJNIaoSL07wEkFFk4tyQqOFDWTnAMGGOiYX4 pABg== X-Gm-Message-State: ALoCoQm0WR7BfDi/S8pJZAtPflk+MKW9JorZG05cXUHuXlH//GhteQvkcD4dmjUlRh/Qc8sQTojP MIME-Version: 1.0 X-Received: by 10.66.122.4 with SMTP id lo4mr37897697pab.1.1437806858708; Fri, 24 Jul 2015 23:47:38 -0700 (PDT) Received: by 10.70.25.132 with HTTP; Fri, 24 Jul 2015 23:47:38 -0700 (PDT) In-Reply-To: <55AFABA0.20601@nostrum.com> References: <55AFABA0.20601@nostrum.com> Date: Sat, 25 Jul 2015 08:47:38 +0200 Message-ID: From: Steve Lhomme To: "A. Jean Mahoney" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] More verbose notes from Dispatch 93 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 06:47:43 -0000 On Wed, Jul 22, 2015 at 4:41 PM, A. Jean Mahoney wrote: > Hi all, > > And here are rougher, more verbose notes from this morning's session. > > Jean > > > ----------------------------------------------------------------- > Dispatch 93 > 2015-07-22 > 09:00-11:30 Congress Hall III > > > 09:00-09:10 (10m) Status and agenda bash > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-3.pdf > Presenters: Mary Barnes, Cullen Jennings > > Note Taker: Jean Mahoney > Jabber Relay: Ted Hardy > > Slides presented - change to agenda, ICE WG presented first. > > Proposed ICE WG ______________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-4.pdf > Presenter: Pal-Erick Martinsen > > Cullen: comments? > > Flemming: As MMUSIC chair - this has a lot of advantages, but we need to > clarify that there is both core ICE and ICE SDP work. > > Ben: Marc had sent out some proposed charter text, but not to dispatch. On > the SDP question, we have WG like payload, they do SDP in their own group. > ICE would handle ICE-specific SDP, unless complex. Handle this on a case by > case basis. > > Cullen showed the proposed charter. > > Roland: probably need more text regarding interacting with other WGs, to > discuss on the ICE mailing list. > > Alissa: send the charter to dispatch. ACTION. We've had hallway > conversations. Any opposed? Need to update MMUSIC charter also. > > No opposition or comments. > > Summary: Send to the proposed charter text to list > > FFV1 and Matroska __________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-6.pdf > Presenter: Tessa Fallon, Emmanuel > References: > - FFV1 Video Specification: https://mediaarea.net/temp/ffv1.html > - Github: http://matroska.org/technical/specs/index.html > > slide 1: Title > > slide 2: PREFORMA Project > > Tessa: wanting legitimacy from SDO to encourage uptake > > slide 3: FFV1 and Matroska > > slide 4: FFV1: Current Work > > slide 5: Matroska: Current Work > > slide 6: Objectives > > slide 7: History of development > > slide 8: Why FFV1 and Matroska > > slide 9: Why IETF > > slide 10: Charter > > Not sent to the ml yet. > > Ben: to the room - we should talk about whether this is interesting work for > IETF, not charter text. > > slide 11: Charter > > slide 12: Charter > > slide 13: Charter > > slide 14: Deliverables > > slide 15: Questions for Discussion > > Mary: several people on ml voiced interest. > > RjS: What is it about this that is internet-centric? Look at OPUS. The codec > group in OPUS was focused on internet realtime apps. That will inform if > IETF is a good venue. > > Jerome: Matroska used with VP8 and VP9, used with YouTube (WebM). Not > completely internet based but maybe later. We want transparency, open source > and openness. We would like to go through IETF. > > Alissa: Are these a package deal? > > Tessa: No. Looking for feedback on what IETF wants to do - both or either. > > Roni: this looks like storage. Why IETF? > > Tessa: I think Jerome's answer covered that. > > Roni: Will it be used to transfer over the Internet? > > Tessa: the specs for these are proprietary, the goal is to be open source. > > Jerome Martinez: Matroska is used over the internet. Matroska can transfer > Opus. We use MP4 and 264, but want something more open. It is for storage - > main purpose, but may be used as transport. FFV1 is good candidate for > video. > > robux4 (Steve Lhome), from Jabber: Matroska is currently supported in For the record it's Lhomme. I first misspelled it on the chat. > Chrome, Firefox and MS Edge, for streaming video. Opus can also be stored in > Matroska for streaming and unlike MP4, Matroska was designed for streaming > on networks, even live streams > > Dave Rice, from Jabber: The preservation of the video of the internet is > longterm a complex matter filled with codecs that the gain wide use and then > gradually fall into obsolescence. The role of a lossless codec helps > preserve internet video in some form that is long-lasting > > Mei??: I work on mpeg MP4. ... There's a lot of maintenance work I assume. > Does the IETF take that? (something about why needing a lossless codec) > > Tessa: we didn't take it to SMPTE because it's paywalled. > > Dave Rice, from Jabber: SMPTE standards are behind paywalls and lack the > features of IETF that are most appealing, such as the openness and > transparency of the process > > Jerome: there's lossy formats on net. Maybe we want a lossless format in > future. Want to discuss how to maintain with IETF. > > Ben, as individual: You've come here because of our openness and open spec. > But you can put it out somewhere yourself. > > Mary: It's already out there. > > Ben: You don't need the IETF for publishing. We might be able to help with > technical work. Does it need technical help? > > Tessa: Yes, the specs are public, but would benefit from the IETF review > process - vetted and thoroughly reviewed. There's been a lot of work already > done, they don't need to be developed. They exist. But they don't have > authority, need to be thoroughly vetted. But if people aren't interested, > that's good to know. > > Ben, as AD: if this comes into IETF as a standards effort, the IETF takes > change control and may change things. Is that OK? > > Tessa: yes, that's understood. > > Dave Rice, from Jabber: today we are well familiar with the role of FLAC > lossless audio on the internet, there is a similar need for FFV1 for > lossless video as well. Just as we have lossless documents, audio, and > photos on the internet, there is a future for lossless video on the internet > as well. For reference http://github.com/ffmpeg/ffv1 and > https://github.com/mediaarea/ebml-specification > > Ted Hardy: Yes, IETF requires change control. The IETF is a nebulous thing, > who ever turns up in this room is IETF. If your dev team doesn't want to > participate in IETF, it will fail. You need to bring the community into the > IETF also. > > Tessa: thanks, we're not going to just hand over the files and be done. We > hope the development community and the IETF come together. > > Cullen, as individual: There's lots of needs for lossless video - medical > images for instance. Long term storage - I see that a standardized version > is valuable. I've reviewed these specs. The codecs are good, but the specs > are not. Wouldn't be interoperable. XMPP came to the IETF mainly done and > then evolved. We have container formats that we're standardizing - JSON is a > good example. I don't see this as a huge leap for IETF. > > Steve Bozko: Personally, I think it's interesting and valuable. Concern - on > Matroska - work will be ongoing, maybe never-ending maintenance. Unless it's > limited to FFV1. > > Alissa: Does your dev community meet in person? > > Tessa: No. On the lists. > > Dave Rice: some in-person meetings at FOSDEM, but most is virtual > > robux4, from Jabber: As the original author of Matroska I'm already involved > with the more formal specifications of EBML and Matroska that started a few > months ago and will continue participating wherever it is going to happen. > > robux4, from Jabber: how each codec is defined in Matroska is outside of the > main specs, it's a top layer and not all codec have to be defined formally > > Ben: what's the level of support in your community? > > Tessa: We have support from both communities. > > Ben: Will the community be active in the process? > > Tessa: based on the outcome on this meeting. > > Mary: There sounds like there's interest. We need people from IETF willing > to contribute - who is willing to review and provide input? Raise hands. > > 2 people. > > Alissa: I'd like to clarify - who would review? > > Cullen: please raise hands > > 8-10 people > > robux4,from Jabber: Matroska actually stands on top of EBML which can be > used for a lot of other storage, just like a binary XML. > > Dave Rice, from Jabber: discussions on working on FFV1 within the IETF > context starting in discussion on listservs in 2012. Matroska has an RFC > Draft from 2004 (unfortunately this work wasn't completed, but there is > sincere support to move forward with this now) > > Richard: I'm not seeing folks interested in netvc in this room. They should > be asked. > > Mary: Take it to the list. Sounds like there's interest. ACTION. > > > > 09:45-10:15 (30m) > GeoJSON____________________________________________________________ > Presentation: > Presenter: Sean Gillies > Charter: https://github.com/geojson/draft-geojson/blob/master/charter.md > Document: draft-butler-geojson > > slide 1: Title > > slide 2: GeoJSON > > slide 3: Status > > slide 4: Proposed Charter > > slide 5: Refinements > > slide 6: Coordinate Precision > > slide 7: Undefined Elevation > > slide 8: Anti-Meridian > > slide 9: Timestamps > > slide 10: High Volume > > slide 11: Extensibility > > slide 12: Geopriv > > slide 13: Other Groups > > slide 14: Docs > > RjS: on Geopriv - who did the analysis? did it happen on list? > > Sean: On dispatch list. The original geoJSON creators are from the OGC and > they are ignorant of geopriv. > > RjS: Depends on the context about whether they are location objects. PIDFs > and PIDF-LOs take location and policy rules. On extensibility - adding > policy rules would allow adding geopriv into this format. > > Alissa: I looked at this spec and I looked at geo URI. What you can do with > geo URI, you have to have some other protocol to specify location. This > seemed very similar, this says this is a point. If you want to say something > lives at this point, then it's a geo URI object. Extending it could change > things. > > Richard: I did a similar analysis. There's a distinction between location > description and location object. The privacy applies to objects. This is a > layer down, like the geo URI. > > RjS: We chose not to ask the geo URI to encode some of the location object, > because not feasible, but I think you can do all sorts of encoding here. > There's a interesting conversation here - would this carry a location > object, or would a location object carry this? > > Mary: There had been interest in this at the previous meeting. > > Roger Marshall: I support the work, I think it's important. > > Alissa: Geopriv is closed. We are not opening it back up. > > Mary: we may charter a new WG for this. > > Roger: this seems like this can talk about layers, and multiple points and > features. > > Sean: yes. It's about talking about ensembles of features. A collection that > provides extra context. GeoJSON seems to be down stream of geopriv. > > Henning: We're talking about 3 different things in mapping. One is a map - a > geographic area - can render in GeoJSOn > > Sean: yes > > Henning: We have developed constrained objects - for PSAPs, uncertainty area > of an object. It could be a GIS layer, but it's not part of a GIS system. > 3rd - a realtime description with geographic properties, generalization of a > point. ... > > Sean: fair to say. > > Richard: This is a layer down from geopriv. It describes location of a > thing. But geoJSON can describe where lots of things are or city areas, and > those have different privacy considerations. > > Mary: who would sign up on ML, read docs, provide comments? > > A few hands ACTION: Post on dispatch and geopriv, which is still open. > > Lennox: I'm glad we don't have ask if this goes in Apps or RAI. > > > > 10:15-10:35 (20m) Location source > parameter__________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-0.pdf > Presenter: Andrew Hutton > Document: draft-winterbottom-dispatch-locparam-00 > > slide 1: Title > > slide 2: General Principle > > slide 3: Issues > > slide 4: Who Wants It? > > Cullen, from floor: On the trusted domain, we defined a spec-t which is > required. I've never seen a spec-T doc delivered ever. All privacy bets are > off in an emergency call. I don't think the trust domain concept has > worked. > > Conrad: The trust domain works. We're requiring this to satisfy regulations. > > Mary: Would people like to work on this, or is this is specific to the > M/493? This would have gone to the sipping or geopriv. > > Alissa: Or ecrit. > > Andy: The use case is. > > Cullen: would this be used in a situation that is not an emergency call? > > Andy: it could be used when it's defined. > > jon-ietf@jabber.org, from Jabber: why doesn't the url of the lis tell you > the source of the location data anyway? > > Andy: It could be a PIDF-LO. Not sure that's true. > > Alissa: If you want this used out of the emergency content, you don't get > the pass anymore on the privacy. > > Andy: The only use case I'm aware of is emergency. > > Mary: Who has read the draft? > > Handful > > Mary: Could be used outside of emergency services. > > Andy: ... > > Ben: Let's worry about the use cases we have in mind first. > > Alissa: Ask the authors to take the feedback here under advisement. And rev > a draft ACTION. > > > > 10:35-10:55 (20m) Via header field parm for received > realm____________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-1.pdf > Presenter: Christer Holmberg > Document: draft-holmberg-dispatch-received-realm-00 > > slide 1: Title > > slide 2: Problem > > slide 3: Solution > > Adam: this was an off the cuff solution, probably something better than this > if we do this work. > > slide 4: Example > > slide 5: Why Not Look at the Vias? > > Andrew allen: They may have been tokenized by an SBC. > > slide 6: Suggestion > > Christer: I think this should be AD sponsor. > > Cullen: why did it go to sipcore and come out. > > Adam, as chair: our charter is narrow, and this isn't a core change. We > would need to recharter to take this on. I'm game to have this conversation. > > Ben: I would say this should be AD sponsor, but if it needs work from more > than just the authors. Need to make sure the input on authentication. > > Adam: if we had one sec guy look at it. > > Cullen: RAI sec advisor to review. sipcore ML? ACTION: > > Adam: I'm ok with that. > > Ben: Just need a good shepherd. > > Adam: send me email Christer. ACTION. > > Discuss with security to see if can be AD sponsored first. ACTION: > > slide 7: The End > > > > > 10:55-11:25 (30m) SLIM > charter____________________________________________________ > Presentation: > https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-2.pdf > Presenter: Randell Gellens > Charter: https://datatracker.ietf.org/wg/slim/charter/ > > slide 1: Title > > slide 2: Real-Time Language Negotiation > > slide 3: Proposal > > slide 4: (show proposed charter) > > Mary: Is Bernard ok with this? (Bernard not in the room) > > Randy: not at the lunch. He's on the email. > > Cullen: anyone share Bernard's concern? > > Henning: We had overlapping concerns. This covers mine. If there's routing > work to be done, the chairs would allow discussion on it. It helps if we > have rough notion of big picture. > > Randy: That's why it says "won't focus", not out of scope. > > Christer: My concern was about a new attribute, and the charter doesn't > discuss it. If you say, "won't focus". Have to make the decision on whether > it's used for routing or not, and it changes the mechanism. If we assume SIP > entities don't understand this, but we have caller prefs. > > Barry: the chairs should allow enough discussion to move ahead properly to > routing discussions. The charter text allows the chairs more flexibility. > Propose text if we need to change it. > > Christer: I'm fine to discuss, if someone brings a solution that supports > routing, can't sweep aside because the charter says we're not doing it. > > Ben: I don't think the charter says go away if you want to talk about > routing. The only reason the chairs would say "Go away" is that they are not > ready to talk about it yet. > > Paul Kyzivat, from Jabber: is there any doubt that, lacking anything else, > the labeling *will* be used for routing? > > Henning: I'll submit draft that will be usable for common use cases based on > my experience with caller prefs. > > Cullen: People thinking that routing will end up in this group. > > Barry: Maybe we can tweak charter wording, get specific wording changes in > right now. > > Randy: We'll recharter. > > Ben: Just say won't focus on routing now, but later. Not sure we need to > trigger a recharter. > > Barry: agree. ACTION. Discuss on the SLIM ML. ACTION. > > Mary: Anything else? > > Ted: QIC protocol bar bof this evening in Congress I. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Steve Lhomme Matroska association Chairman From nobody Sat Jul 25 03:53:21 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18EB1A036C for ; Sat, 25 Jul 2015 03:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 T8tTox-z9MUJ for ; Sat, 25 Jul 2015 03:53:19 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085F61A0094 for ; Sat, 25 Jul 2015 03:53:18 -0700 (PDT) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 110BDC5A3C; Sat, 25 Jul 2015 12:53:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id K1JKKi8bjIrm; Sat, 25 Jul 2015 12:53:15 +0200 (CEST) X-Originating-IP: 84.114.129.144 Received: from localhost (chello084114129144.4.15.vie.surfer.at [84.114.129.144]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 1FB94C5A37; Sat, 25 Jul 2015 12:53:14 +0200 (CEST) Date: Sat, 25 Jul 2015 12:53:12 +0200 From: Michael Niedermayer To: "A. Jean Mahoney" Message-ID: <20150725105312.GA16221@nb4> References: <55AFABA0.20601@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <55AFABA0.20601@nostrum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] More verbose notes from Dispatch 93 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 10:53:21 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2015 at 04:41:36PM +0200, A. Jean Mahoney wrote: [...] > Ted Hardy: Yes, IETF requires change control. The IETF is a nebulous > thing, who ever turns up in this room is IETF. If your dev team > doesn't want to participate in IETF, it will fail. You need to bring > the community into the IETF also. >=20 > Tessa: thanks, we're not going to just hand over the files and be > done. We hope the development community and the IETF come together. >=20 > Cullen, as individual: There's lots of needs for lossless video - > medical images for instance. Long term storage - I see that a > standardized version is valuable. I've reviewed these specs. The > codecs are good, but the specs are not. Wouldn't be interoperable. > XMPP came to the IETF mainly done and then evolved. We have > container formats that we're standardizing - JSON is a good example. > I don't see this as a huge leap for IETF. >=20 > Steve Bozko: Personally, I think it's interesting and valuable. > Concern - on Matroska - work will be ongoing, maybe never-ending > maintenance. Unless it's limited to FFV1. >=20 > Alissa: Does your dev community meet in person? >=20 > Tessa: No. On the lists. >=20 > Dave Rice: some in-person meetings at FOSDEM, but most is virtual >=20 > robux4, from Jabber: As the original author of Matroska I'm already > involved with the more formal specifications of EBML and Matroska > that started a few months ago and will continue participating > wherever it is going to happen. As the original author of FFV1. Same here indeed, ive participated in getting the ffv1 spec into better shape over the previous weeks/months and will continue to participate in standarization efforts wherever they are going to happen [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWzapgACgkQYR7HhwQLD6umJgCfeNF+d5jjZWBR7H4cV+TvVvvL +xAAoIRSDTME1g4FUZDash413ovAgviw =w1eD -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1--