From nobody Wed Oct 1 03:40:40 2014 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 796F51ACD99 for ; Wed, 1 Oct 2014 03:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 Oz-9Q6EKkz63 for ; Wed, 1 Oct 2014 03:40:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE2D1ACD0B for ; Wed, 1 Oct 2014 03:40:36 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s91AeZwG004514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Oct 2014 10:40:36 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s91AeZK7022199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 10:40:35 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s91AeX0j027033; Wed, 1 Oct 2014 10:40:33 GMT MIME-Version: 1.0 Message-ID: <84094e87-9997-4444-bb09-7a6989a75c1b@default> Date: Wed, 1 Oct 2014 03:40:35 -0700 (PDT) From: Sergio Ibanez candela Sender: Sergio Ibanez candela To: dispatch@ietf.org, R.Jesske@telekom.de References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> In-Reply-To: <82a8083a078209c80187a46304ff5532@mail.gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 14.0.7113.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/egaOBotNw_8iyRpmJWLXm28hKVM Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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 Oct 2014 10:40:38 -0000 Hi, Some comments regarding draft-jesske-dispatch-forking-answer-correlation-01= . 1) It has already been mentioned, but the UAC don't have to send a CANCEL f= or the non-confirmed early dialogs after the 200OK. This is incorrect. The = forking proxy should cancel all the legs that have not been confirmed. The = UAC will just consider them as terminated after 64*T1 after the first 200OK= . 2) Do you have any specific logic to identify which 18x responses are going= to be forwarded back to the UAC and which won't? In your examples I see th= at, in the case of reliable responses, each provisional response will updat= e the dialog towards the UAC, and therefore always taking the latest one. I= s this just an example?, do you have any logic in mind to channel this upda= tes?=20 3) What happens if the UAC does not support reliable responses? 4) The early media scenario has not been covered, but I guess it'll be rela= ted to 4.3 and 4.4, and in this cases the dialog towards the UAC is always = updated with the newest SDP. Will this mean that the audio will be also upd= ated to the latest one?=20 Thanks, Sergio From nobody Wed Oct 1 05:50:58 2014 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 862061A0351 for ; Wed, 1 Oct 2014 05:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 AFamscITg9gC for ; Wed, 1 Oct 2014 05:50:54 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1261A0340 for ; Wed, 1 Oct 2014 05:50:53 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail31.telekom.de with ESMTP; 01 Oct 2014 14:50:05 +0200 X-IronPort-AV: E=Sophos;i="5.04,632,1406584800"; d="scan'208";a="144017900" Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 01 Oct 2014 14:50:05 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 1 Oct 2014 14:50:04 +0200 From: To: , Date: Wed, 1 Oct 2014 14:50:03 +0200 Thread-Topic: draft-jesske-dispatch-forking-answer-correlation-01: comments Thread-Index: Ac/c1in/6iJaHF2iQRaj03zwsUIHGgAjL2SA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> In-Reply-To: <82a8083a078209c80187a46304ff5532@mail.gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/N4JRXLd2x1mvlxWWmTN0iILCReU Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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 Oct 2014 12:50:56 -0000 SGkgQnJldHQNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBhbmQgcmV2aWV3IG9mIG15IGRy YWZ0Lg0KQW5zd2VycyBhbmQgc29tZSBxdWVzdGlvbnMgaW5saW5lLg0KSSB3aWxsIHVwZGF0ZSB0 aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQoNClRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzDQoNClJv bGFuZA0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBCcmV0 dCBUYXRlIFttYWlsdG86YnJldHRAYnJvYWRzb2Z0LmNvbV0NCj4gR2VzZW5kZXQ6IERpZW5zdGFn LCAzMC4gU2VwdGVtYmVyIDIwMTQgMTk6NDgNCj4gQW46IEplc3NrZSwgUm9sYW5kOyBkaXNwYXRj aEBpZXRmLm9yZw0KPiBCZXRyZWZmOiBkcmFmdC1qZXNza2UtZGlzcGF0Y2gtZm9ya2luZy1hbnN3 ZXItY29ycmVsYXRpb24tMDE6IGNvbW1lbnRzDQo+IA0KPiBIaSwNCj4gDQo+IFRoZSBmb2xsb3dp bmcgYXJlIGZldyBjb21tZW50cyBjb25jZXJuaW5nIGRyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3Jr aW5nLQ0KPiBhbnN3ZXItY29ycmVsYXRpb24tMDEuDQo+IA0KPiBUaGFua3MsDQo+IEJyZXR0DQo+ IA0KPiAtLS0tLS0tDQo+IA0KPiAxKSBTZWN0aW9uIDEgaW5kaWNhdGVzOg0KPiANCj4gIiBOb3cg dGhlIG9yaWdpbmF0aW5nIFNJUCBkZXZpY2UgaGFzIHRvIHVuZGVyc3RhbmQgdGhhdCB0d28gZGV2 aWNlcyBhcmUNCj4gICAgcmluZ2luZyBhbmQgb25lIHdpbGwgYW5zd2VyIHRoZSBjYWxsLiAgTm8g UHJvYmxlbSBzaW5jZSBSRkMzMjYxDQo+ICAgIFtSRkMzMjYxXSBhbGxvd3MgdGhpcyBhbmQgYWxs b3dzIGFsc28gdGhlIG9yaWdpbmF0aW5nIGRldmljZSB0bw0KPiAgICBoYW5kbGUgbXVsdGlwbGVz IHJlc3BvbnNlcy4gIEJ1dCB0aGlzIGlzIG5vdCBtYW5kYXRlZCBieSBSRkMzMjYxDQo+ICAgIFtS RkMzMjYxXSBhbmQgbGVkIHRvIGltcGxlbWVudGVycyBjaG9pY2UuICBUaGVyZSB3aWxsIHRoZSBm aXJzdA0KPiAgICBwcm9ibGVtIGFwcGx5IHRoYXQgb25seSBvbmUgb2YgdGhlIFJlc3BvbnNlcyB3 aWxsIGJlIHRha2VuIGludG8NCj4gICAgY29uc2lkZXJhdGlvbiBmb3IgY3JlYXRpbmcgYSBkaWFs b2cuIg0KPiANCj4gUkZDIDMyNjEgbWFuZGF0ZXMgdGhhdCB0aGUgVUFDIGJlIGFibGUgdG8gaGFu ZGxlIGludGVyYWN0aW9ucyB3aXRoIGENCj4gZm9ya2luZyBwcm94eS4gDQpPSyBJIGFncmVlIHRo YXQgbm9ybWFsbHkgYSBjb3JyZWN0IGludGVyYWN0aW9uIHNob3VsZCBoYXBwZW4gYXQgbGVhc3Qg d2hlbiBhIDIwMCBPSyBhcnJpdmVzLg0KUmVnYXJkaW5nIFJGQyAzMjYxIHRoZSAyMDAgT0sgbXVz dCBiZSBoYW5kbGVkIGNvcnJlY3QuIFRoZXJlIGlzIG5vdGhpbmcgc3RhdGVkIGFib3V0IHRoZSAx OHguIA0KT2sgbXkgY29uY2VybiBpcyB0aGUgaGFuZGxpbmcgb2YgcHJvdmlzaW9uYWwgcmVzcG9u c2VzIHZlcnN1cyBmaW5hbCByZXNwb25zZXMuDQoNCkkgd2lsbCByZXdyaXRlIGl0IGNvcnJlY3Rs eS4NCg0KPiBIb3dldmVyLCBJIGFncmVlIHRoYXQgc29tZSBCMkJVQXMgYXR0ZW1wdCB0byBwcm90 ZWN0DQo+IGNsaWVudHMgZnJvbSBuZWVkaW5nIHRvIHN1cHBvcnQgc3VjaCBmdW5jdGlvbmFsaXR5 Lg0KPiANClllcyB0aGF0IGlzIHJlYWwgbGlmZSwgYXMgd2Ugb2JzZXJ2ZWQuDQoNCj4gMikgU2Vj dGlvbiAyLjggaW5kaWNhdGVzOg0KPiANCj4gIlRodXMgdGhlIG9ubHkNCj4gICAgc29sdXRpb24g c2VlbiBpcyB0byBkZXNjcmliZSBwcm9jZWR1cmVzIHdoaWNoIGFwcGx5IGluIEIyQlVBIHRvDQo+ ICAgIHN1cHBvcnQgYW4gY29ycmVsYXRpb24gb2YgbXVsdGlwbGVzIGVhcmx5IGRpYWxvZ3MgYW5k IG90aGVyIHJlY2VpdmVkDQo+ICAgIDE4eCBSZXNwb25zZXMuIg0KPiANCj4gSSBkaXNhZ3JlZSB3 aXRoIHRoYXQgc3RhdGVtZW50LiAgT25lIHNvbHV0aW9uIGlzIHRvIHJlcGxhY2UvdXBncmFkZSB0 aGUNCj4gZGVmaWNpZW50IGRldmljZSBzbyB0aGF0IGl0IHN1cHBvcnRzIGZvcmtpbmcgaW50ZXJh Y3Rpb25zLg0KPiANCg0KWWVzIEkgY2FuIGFncmVlIG9uIHRoYXQgYnV0IGl0IGlzIG5vdCBwb3Nz aWJsZSB0byBkbyB0aGF0IGluIGVhY2ggY2FzZS4NCldlIGNhbm5vdCBtYW5kYXRlIHRoZSBkZXZp Y2VzIHVzZWQgd2l0aGluIG90aGVyIG5ldHdvcmtzLiANCkFuZCBmcm9tIG91ciBvYnNlcnZhdGlv bnMgdGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgd2UgaGF2ZSBzdWNoIHByb2JsZW1zLg0KU28g dGhlcmUgaXMgc29tZXRoaW5nIHdoYXQgd2UgaGF2ZSB0byBkbyB0byBzYXRpc2Z5IG91ciBjdXN0 b21lcnMgd2hpY2ggYXJlIHVzaW5nIG1vcmUgdGhhbiBvbmUgZGV2aWNlIHJlYWNoYWJsZSB1bmRl ciBvbmUgIm51bWJlciIuDQoNCj4gMykgU2VjdGlvbiAzIGluZGljYXRlczoNCj4gDQo+ICIgVG8g cHJvdmlkZSB0aGUgYmVzdCB1c2VyIGJlaGF2aW9yIGEgc2VydmljZSBwcm92aWRlciBzaGFsbCBo YXZlIHRoZQ0KPiAgICBwb3NzaWJpbGl0eSB0byBjb3JyZWxhdGUgbXVsdGlwbGVzIHJlY2VpdmVk IHJlc3BvbnNlcyB0byBvbmUgZGlhbG9nDQo+ICAgIGxlZyB0byB0aGUgVUFDLiINCj4gDQo+IEkg ZGlzYWdyZWUgd2l0aCB0aGF0IHN0YXRlbWVudC4gIEZvbGRpbmcgbXVsdGlwbGUgZWFybHkgZGlh bG9ncyBvbnRvIGENCj4gc2luZ2xlIGVhcmx5IGRpYWxvZyBkb2VzIG5vdCBwcm9kdWNlIHRoZSBi ZXN0IHVzZXIgZXhwZXJpZW5jZS4gIEl0DQo+IGNhdXNlcyBhbWJpZ3VpdGllcyBhcyB2YXJpb3Vz IHJlcXVlc3RzL3Jlc3BvbnNlL2hlYWRlcnMvYm9kaWVzIHRyYXZlcnNlDQo+IHRob3NlIGVhcmx5 IGRpYWxvZ3MuICBJdCBjYW4gY2F1c2UgdGhlIG5lZWQgZm9yIFVBQyB0byBzdXBwb3J0IFJGQyAz MjYyDQo+IGFuZCBSRkMNCj4gMzMxMSAoaWYgdGhlIEIyQlVBIG5lZWRzIHRvIGNvbW11bmljYXRl IFNEUCBtb2RpZmljYXRpb25zIG9uIGFuIGVhcmx5DQo+IGRpYWxvZykuDQo+DQpPSyBJIHRyeSB0 byByZXdvcmQgYXMgZm9sbG93czoNCg0KVG8gcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGJlaGF2aW9y IGEgc2VydmljZSBwcm92aWRlciBzaGFsbCBoYXZlIHRoZQ0KICAgcG9zc2liaWxpdHkgdG8gY29y cmVsYXRlIG11bHRpcGxlcyByZWNlaXZlZCByZXNwb25zZXMgdG8gYXBwbHkgYSBzdWNjZXNzZnVs IGNyZWF0aW9uIG9mIGEgZGlhbG9nIHdoaWNoIGltcGx5IHRoYXQgdGhlIHVzZWQgY2FwYWJpbGl0 aWVzIG9mIHRoZSBVQUMgc2hhbGwgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLg0KDQpJcyB0 aGlzIE9LPw0KDQo+IDQpIFNlY3Rpb24gNC4xIGZpZ3VyZSAxIHNob3dzIENBTkNFTC8yMDAvNDg3 L0FDSyBiZXR3ZWVuIFVBQywgUFJPWFksIGFuZA0KPiBGb3JraW5nIFByb3h5LiAgVGhpcyBzaG91 bGQgbm90IGJlIG9jY3VycmluZy4NCj4NCg0KT0sgSSBjaGFuZ2UgdGhhdC4NCiANCj4gNSkgU2Vj dGlvbiA0LjIgZmlndXJlIDIgc2hvd3MgQ0FOQ0VMLzIwMC80ODcvQUNLIGJldHdlZW4gQjJCVUEg YW5kDQo+IEZvcmtpbmcgUHJveHkuICBUaGlzIHNob3VsZCBub3QgYmUgb2NjdXJyaW5nLg0KPg0K DQpPSyBJIGNoYW5nZSBpdC4NCiANCj4gNikgU2VjdGlvbiA0LjIgc2hvd3MgQjJCVUEgb25seSBy ZWxheWluZyBmaXJzdCAxOHguICBXaGF0IGFyZSB5b3UNCj4gcHJvcG9zaW5nIHRvIGRvIGlmIHRo ZSBzZXJ2ZXJzIHNlbnQgZGlmZmVyZW50IDE4eCByZXNwb25zZXMgc3VjaCBhcw0KPiBVQUNfMiBz ZW50IDE4MSwgVUFDXzMgc2VudCAxODIsIGFuZCBVQUNfNCBzZW50IDE4Mz8NCj4NCg0KVGhhdCBp cyBzb21ldGhpbmcgdGhhdCBJIHNob3VsZCBoYW5kbGUgYWxzbyBpbiBhZGRpdGlvbi4NClF1ZXN0 aW9uIGlzIGlmIEkgcHV0IGl0IGRpcmVjdGx5IGludG8gdGhlIHJlZ2FyZGluZyBzZWN0aW9ucyBv ciBkbyBpdCBpbiBhbiBvd24gc2VjdGlvbi4NCg0KMTgxIGl0c2VsZiBzaG93cyB0aGF0IHRoZSBj YWxsIGlzIGZvcndhcmRlZC4gRnJvbSBteSB1bmRlcnN0YW5kaW5nIGl0IHdpbGwgbm90IGNvbnRh aW4gYW55IFNEUC4gDQpUaHVzIHdoZW4gcmVxdWVzdGluZyAxMDByZWwgaXQgd2lsbCBiZSBhY2tu b3dsZWRnZWQgYnkgdGhlIEIyQlVBIChQUkFDSykgYnV0IG5vIGFjdGl2aXR5IHdpbGwgYXBwbHkg YXQgdGhlIG9yaWdpbmF0aW5nIGxlZy4NCkJlY2F1c2UgaXQgaXMgbm90IHN1cmUgd2hpY2ggb2Yg dGhlIGVhcmx5IGRpYWxvZ3Mgd2lsbCBiZSBpbiBmaW5hbCBzdGF0ZSBsYXRlciBvbi4NCg0KUGVy IFJGQyAzMjYxIDE4MiBzb3dzIHRoYXQgdGhlIGNhbGxlZCBwYXJ0eSBpcyB0ZW1wb3JhcmlseSB1 bmF2YWlsYWJsZSwgYnV0IHRoZSBzZXJ2ZXIgaGFzDQogICBkZWNpZGVkIHRvIHF1ZXVlIHRoZSBj YWxsIHJhdGhlciB0aGFuIHJlamVjdCBpdC4gVGh1cyBubyBTRFAgd2lsbCBiZSBpbmNsdWRlZCBp bnRvIHRoaXMgcHJvdmlzaW9uYWwgcmVzcG9uc2UuDQpBcyBmb3IgMTgxIGl0IHdpbGwgYmUgYWNr bm93bGVkZ2VkIGJ5IHRoZSBCMkJVQSAoUFJBQ0spIGJ1dCBubyBhY3Rpdml0eSB3aWxsIGFwcGx5 IGF0IHRoZSBvcmlnaW5hdGluZyBsZWcuDQpCZWNhdXNlIGl0IGlzIG5vdCBzdXJlIHdoaWNoIG9m IHRoZSBlYXJseSBkaWFsb2dzIHdpbGwgYmUgaW4gZmluYWwgc3RhdGUgbGF0ZXIgb24NCg0KV2hl biBzdWNjZWVkaW5nIHJlc3BvbnNlcyBjb250YWluaW5nIHdpbGwgYmUgcmVjZWl2ZWQgYnkgdGhl IEIyQlVBIGl0IHNob3VsZCBhcHBseSBhY2NvcmRpbmdseSBhcyBkZXNjcmliZWQgaW4gdGhlIGRy YWZ0LiANCg0KSXMgdGhpcyBPSyBmb3IgeW91Pw0KIA0KIA0KPiA3KSBTZWN0aW9uIDQuMyBmaWd1 cmUgMyBzaG93cyBDQU5DRUwvMjAwLzQ4Ny9BQ0sgYmV0d2VlbiBCMkJVQSBhbmQNCj4gRm9ya2lu ZyBQcm94eS4gIFRoaXMgc2hvdWxkIG5vdCBiZSBvY2N1cnJpbmcuDQo+DQo+IDgpIFNlY3Rpb24g NC40IGZpZ3VyZSA0IHNob3dzIENBTkNFTC8yMDAgYmV0d2VlbiBCMkJVQSBhbmQgRm9ya2luZw0K PiBQcm94eS4NCj4gVGhpcyBzaG91bGQgbm90IGJlIG9jY3VycmluZy4gIEl0IGFsc28gbG9va3Mg bGlrZSB0aGVyZSBpcyBhIHN1YnNlcXVlbnQNCj4gZXh0cmEgMjAwIHJlc3BvbnNlLg0KPg0KNys4 KSBTbyBpbiB0aGUgY2FzZSB3aGVyZSBhIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGlucyBtYWRlIHJl bGlhYmxlIChpbmNsLiByZXNlcnZhdGlvbiBvZiByZXNvdXJjZXMpIGl0IGlzIHN0aWxsIHZhbGlk IHRoYXQgdGhlIGZvcmtpbmcgcHJveHkgaXMgcmVzcG9uc2libGUgdG8gcmVsZWFzZSB0aGUgZWFy bHkgZGlhbG9ncy4NCk1ZIHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpZiB5b3UgbWFrZSBzb21ldGhp bmcgcmVsaWFibGUgdGhhbiB0aGUgVUEgc3RvcmUgZXZlcnl0aGluZyB3aGF0IHdhcyByZWNlaXZl ZC4gDQpTbyBub3cgd2l0aCByZWNlaXZpbmcgdGhlIDIwMCBPSyBieSB0aGUgQjJCVUEgZm9yIG9u ZSBvZiB0aGUgZGlhbG9ncyBhbGwgb3RoZXIgZWFybHkgKGFuZCByZWxpYWJsZSBtYWRlKSBkaWFs b2dzIGFyZSBkZXN0cm95ZWQuDQpBbmQgbm8gZnVydGhlciBhY3Rpb24gaGFzIHRvIGJlIHRha2Vu IGJ5IHRoZSBVQUMgKEIyQlVBKSBvbmx5IHRoZSBmb3JraW5nIHByb3h5LiBSaWdodD8NCg0KPiA5 KSBTZWN0aW9uIDQuNCBmaWd1cmUgNCBpcyBtaXNzaW5nIHRoZSA0ODcvQUNLIGludGVyYWN0aW9u IHdpdGggVUFTXzIuDQo+DQoNCk9LIGNoYW5nZSBpdC4NCiANCj4gMTApIFNlY3Rpb24gNC40IGZp Z3VyZSA0IEY0MCBzaG91bGQgbWF5YmUgYmUgZHJhd24gZnJvbSBVQVNfNCB0byBtYXRjaA0KPiBu dW1iZXJpbmcgYW5kIEY1Ny4NCj4gDQpJIGRvbid0IHdhbnQgaXQgdG8gbWFrZSBpdCB0byBjb21w bGljYXRlZCBhbmQgZG8gdGhlIHVzZSBjYXNlIG9ubHkgZm9yIHR3byBVQVMuDQpJIHdpbGwgYWRv cHQgdGhlIGZpZ3VyZS4NCg0KPiAxMSkgU2VjdGlvbiA0LjQgc2Vjb25kIGZpZ3VyZSA0IHNob3Vs ZCBiZSBmaWd1cmUgNS4gIE15IHByaW9yIHNlY3Rpb24NCj4gNC40IGNvbW1lbnRzIGFsc28gYXBw bHkgdG8gdGhlIHNlY29uZCBmaWd1cmUgNCAoaS5lLiBmaWd1cmUgNSkgYWx0aG91Z2gNCj4gdGhl IEYgbnVtYmVyaW5nIGlzIGRpZmZlcmVudC4NCg0KWWVzIEkgd2lsbCBjaGFuZ2UgaXQuIEFsc28g YXBwbHlpbmcgaXQgdG8gdGhlIHVzZSBjYXNlIHdoZXJlIG9ubHkgMiBVQUMgYXJlIGluIHRoZSBj YWxsLg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQo= From nobody Wed Oct 1 06:43:39 2014 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 53FE61A19FC for ; Wed, 1 Oct 2014 06:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 d7og9GBI6dKC for ; Wed, 1 Oct 2014 06:43:36 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEA21A19E9 for ; Wed, 1 Oct 2014 06:43:35 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP; 01 Oct 2014 15:43:33 +0200 X-IronPort-AV: E=Sophos;i="5.04,632,1406584800"; d="scan'208";a="539993028" Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 01 Oct 2014 15:43:33 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 1 Oct 2014 15:43:33 +0200 From: To: , Date: Wed, 1 Oct 2014 15:43:32 +0200 Thread-Topic: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments Thread-Index: Ac/dZCU2C3FxonwVRbesCEWzul2tBgAFztAQ Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC41B@HE113667.emea1.cds.t-internal.com> References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> <84094e87-9997-4444-bb09-7a6989a75c1b@default> In-Reply-To: <84094e87-9997-4444-bb09-7a6989a75c1b@default> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IIoYojmDVBJAtO-kBZ6HnWQB1jw Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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 Oct 2014 13:43:38 -0000 Hi Sergio, Thank you for your comments. Answers Inline. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Sergio Ibanez candela [mailto:sergio.ibanez.candela@oracle.com] > Gesendet: Mittwoch, 1. Oktober 2014 12:41 > An: dispatch@ietf.org; Jesske, Roland > Betreff: RE: [dispatch] draft-jesske-dispatch-forking-answer- > correlation-01: comments >=20 > Hi, >=20 > Some comments regarding draft-jesske-dispatch-forking-answer- > correlation-01. >=20 > 1) It has already been mentioned, but the UAC don't have to send a > CANCEL for the non-confirmed early dialogs after the 200OK. This is > incorrect. The forking proxy should cancel all the legs that have not > been confirmed. The UAC will just consider them as terminated after > 64*T1 after the first 200OK. OK that I will change. >=20 > 2) Do you have any specific logic to identify which 18x responses are > going to be forwarded back to the UAC and which won't? In your examples > I see that, in the case of reliable responses, each provisional response > will update the dialog towards the UAC, and therefore always taking the > latest one. Is this just an example?, do you have any logic in mind to > channel this updates? >=20 Ok I see I have a lack of description. I see only the need to UPDATE the leg when the 18x contains a different SDP= . My understanding is that the B2BUA will add the additional codec. Thus the UAC will made the SDP reliable. Perhaps there are also other possibilities for a proper negotiation are als= o possible. I'm open for further solutions which we could document in addition or adopt= it.=20 Also some conclusions to describe what would be the best way to apply. > 3) What happens if the UAC does not support reliable responses? Then the initial INVITE will not include 100rel and the provisional respons= e will not require 100rel. That would then apply to Figure 2. >=20 > 4) The early media scenario has not been covered, but I guess it'll be > related to 4.3 and 4.4, and in this cases the dialog towards the UAC is > always updated with the newest SDP. Will this mean that the audio will > be also updated to the latest one? >=20 That is my place holder section. So there are a couple of possibilities. In= d I would like to describe what happens when two erly media are in the path= . Perhaps also some race conditions. Thank you=20 Best Regards Roland > Thanks, >=20 > Sergio From nobody Wed Oct 1 09:04:28 2014 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 76F361ACE5E for ; Wed, 1 Oct 2014 09:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-QRPKNrp-Jv for ; Wed, 1 Oct 2014 09:04:21 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B391A1A47 for ; Wed, 1 Oct 2014 09:04:18 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id a108so507853qge.12 for ; Wed, 01 Oct 2014 09:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=fIeJxBcX9KxPClHyxOhQFSAtR6aiRmD2AYddmUCxGr8=; b=HVKIfVdI8oohqU8pMC6/G+SzNWamrF7dmdfNDOahocKUC//5xUFOMVzlvk1EMe9hb/ 7foMUgDN6/wdKRSVAmlYn97Ldjj5tVJQiT1vZVRO5mEZyNyzxS8bKae407jM6URoj2np MTY0tWGLOp6AIlaB3onkJDhDtxjUTzXUWpt5+ToqwSfIPM/gFiWo3vMSDjvmzonhPbER FPOky9eIpLdVXCiK45natXistj6u2jd1IEA/nhCJXdaPYSVQSAXrQGMIxL25nGoG1cLj oAbemlaRaBqkfY/tNrTzIHSFZqEPYbpp7FeNRqcqZ884L1r/5AKE9tjrIKdYKBNpIqt7 N6OQ== X-Gm-Message-State: ALoCoQlZbcSLLQB2bOJJ25FCwkqgFa57qdNyI3ZOgwQV5RXmaMoxSQEUFrmIRVIbbo5XDiHIpCv/ X-Received: by 10.224.137.3 with SMTP id u3mr33265756qat.82.1412179457564; Wed, 01 Oct 2014 09:04:17 -0700 (PDT) From: Brett Tate References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLVA4+w6FtlQ91/xH836kVqt2LivQLBu1i1mfrZTfA= Date: Wed, 1 Oct 2014 12:04:16 -0400 Message-ID: To: R.Jesske@telekom.de, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6G3jxeRuMa3xGqqofgGtzbdCIng Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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 Oct 2014 16:04:26 -0000 Hi Roland, Reply is inline. > > RFC 3261 mandates that the UAC be able to handle interactions with > > a forking proxy. > > OK I agree that normally a correct interaction should happen at least > when a 200 OK arrives. > Regarding RFC 3261 the 200 OK must be handled correct. There is > nothing stated about the 18x. > Ok my concern is the handling of provisional responses versus final > responses. RFC 3261 indicates how the UAC must/should/may behave (some aspects updated by RFC 6026 and RFC 6141); this includes the impacts of receiving INVITE's 18x or 2xx on a known or unknown dialog. However, it frequently defers the human interaction decisions to the implementor. Similarly, a device can be fully compliant with RFC 3261 but decide to have a service to terminate call after or before answer (or individual early dialogs before answer) if more than 1 dialog was observed during call setup. Such a "service" likely indicates that the device doesn't really support forking proxies (or maybe doesn't trust forking interactions). > > 2) Section 2.8 indicates: > > > > "Thus the only > > solution seen is to describe procedures which apply in B2BUA to > > support an correlation of multiples early dialogs and other received > > 18x Responses." > > > > I disagree with that statement. One solution is to replace/upgrade > > the deficient device so that it supports forking interactions. > > > > Yes I can agree on that but it is not possible to do that in each case. > We cannot mandate the devices used within other networks. > And from our observations there are many cases where we have such > problems. > So there is something what we have to do to satisfy our customers which > are > using more than one device reachable under one "number". That is the issue. Someone deployed devices which are causing forking related interoperability issues. B2BUAs are frequently used to help overcome (while attempting to avoid) interoperability issues. Thus it is a matter of deciding if the IETF wants to do anything (such as producing an RFC) to help remedy the issue. > > 3) Section 3 indicates: > > > > " To provide the best user behavior a service provider shall have the > > possibility to correlate multiples received responses to one dialog > > leg to the UAC." > > > > I disagree with that statement. Folding multiple early dialogs onto a > > single early dialog does not produce the best user experience. It > > causes ambiguities as various requests/response/headers/bodies > > traverse those early dialogs. It can cause the need for UAC to > > support RFC 3262 and RFC > > 3311 (if the B2BUA needs to communicate SDP modifications on an early > > dialog). > > > OK I try to reword as follows: > > To provide the best user behavior a service provider shall have the > possibility to correlate multiples received responses to apply a > successful > creation of a dialog which imply that the used capabilities of the UAC > shall be > taken into consideration. > > Is this OK? The following might be good enough for now: "To improve interoperability with devices which do not support forking, a service provider shall have the possibility to use a B2BUA to correlate multiple dialogs into a single dialog." > > 6) Section 4.2 shows B2BUA only relaying first 18x. What are you > > proposing to do if the servers sent different 18x responses such as > > UAC_2 sent 181, UAC_3 sent 182, and UAC_4 sent 183? > > > > That is something that I should handle also in addition. > Question is if I put it directly into the regarding sections or do it in > an own > section. > > 181 itself shows that the call is forwarded. From my understanding it will > not > contain any SDP. Similar to the other 18x responses, the SDP is optional. > Thus when requesting 100rel it will be acknowledged by the B2BUA (PRACK) > but no activity will apply at the originating leg. > Because it is not sure which of the early dialogs will be in final state > later on. The B2BUA never knows which known/unknown dialog will generate the first INVITE 2xx response. The proposal delays communicating a 18x to caller. > Per RFC 3261 182 sows that the called party is temporarily unavailable, > but > the server has > decided to queue the call rather than reject it. Thus no SDP will be > included > into this provisional response. Similar to the other 18x responses, the SDP is optional. > As for 181 it will be acknowledged by the B2BUA (PRACK) but no activity > will > apply at the originating leg. > Because it is not sure which of the early dialogs will be in final state > later on > > When succeeding responses containing will be received by the B2BUA it > should apply accordingly as described in the draft. > > Is this OK for you? The proposal delays communicating a 18x to caller and may result in call release since B2BUA preventing caller from receiving 18x responses during call setup. > > 7) Section 4.3 figure 3 shows CANCEL/200/487/ACK between B2BUA and > > Forking Proxy. This should not be occurring. > > > > 8) Section 4.4 figure 4 shows CANCEL/200 between B2BUA and Forking > > Proxy. > > This should not be occurring. It also looks like there is a > > subsequent extra 200 response. > > > 7+8) So in the case where a provisional response ins made reliable (incl. > reservation of resources) it is still valid that the forking proxy is > responsible to > release the early dialogs. > MY understanding is that if you make something reliable than the UA store > everything what was received. > So now with receiving the 200 OK by the B2BUA for one of the dialogs all > other early (and reliable made) dialogs are destroyed. > And no further action has to be taken by the UAC (B2BUA) only the forking > proxy. Right? See RFC 3261 section 16.7 step 10. The forking proxy MUST send CANCEL; however a subsequent 2xx for INVITE may still be received by the caller. Thus you'd likely want the B2BUA to ACK/BYE late INVITE 2xx responses. From nobody Wed Oct 1 09:25:16 2014 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 10EFF1ACE4D for ; Wed, 1 Oct 2014 09:25:07 -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 IyXSqNNU05De for ; Wed, 1 Oct 2014 09:25:05 -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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0CE1ACE29 for ; Wed, 1 Oct 2014 09:25:05 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-06v.sys.comcast.net with comcast id xsR21o0084zp9eg01sR5zH; Wed, 01 Oct 2014 16:25:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-07v.sys.comcast.net with comcast id xsR41o0093Ge9ey01sR4Go; Wed, 01 Oct 2014 16:25:05 +0000 Message-ID: <542C2AE0.3090503@alum.mit.edu> Date: Wed, 01 Oct 2014 12:25:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43@HE113667.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412180705; bh=QuSEX7Zj/XAhyPlg9s4/lRVmKN1lfOzWorMTiuJjjSY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JXLx6Jinvvmu8QDK+cGi3HfV85B3w4mpCa1YheXbZ9NnxSUKlletEyORyiZslxoja OCfOSH1iXZIxTVn+REPol5GWbirVhXTJ44B9J0EhpUPAmxRlWvtemcnHkH5S4mCdAS snALzc5XNv7cecK2AcDsENr7VgzYwJyohjYYpBw04L6B/xaG920oP0r0IZrEiwcRQG dJEZzePngQQLvVohJvZ6LMzTqadKthHRGwy1HlHl0Y2ABPy9H1M9Bv4b9chRLyg+HE IZkIuGWQyYHp2K3iNr6j8Rza+kqvb8Vh8HVqzJtwx0/2OQuSIjZaRMN+NkjBVcTAS3 XfG1i3D5boRSg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/5VrlUSD8zRBEs-pkvuqlp1HxniI Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 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 Oct 2014 16:25:07 -0000 Roland, I see there are extensive changes in the -01 version. I haven't had time to study them all. From a high level it looks like a better organization. One comment on Figure 1: From a single INVITE sent by the UAC, the only *final* response(s) it will receive are: - *one* response in range 3xx-6xx - one *or more* 2xx responses. The forking proxy is responsible for preventing any error responses once a 2xx response has been passed along. So in this flow the UAC should not receive either of the 487 responses. And it is only responsible for ACKing the 2xx responses it receives. Thanks, Paul On 9/30/14 1:17 AM, R.Jesske@telekom.de wrote: > Hi Mary, > > Thank you for your mail and clarification. > > Now I have a reworked version of the draft which is now available. > > A new version of I-D, > draft-jesske-dispatch-forking-answer-correlation-01.txt > > has been successfully submitted by Roland Jesske and posted to the IETF > repository. > > Name: draft-jesske-dispatch-forking-answer-correlation > > Revision: 01 > > Title: Correlation of multiple responses of forked INVITES in > Back to Back User Agents > > Document date: 2014-09-29 > > Group: Individual Submission > > Pages: 18 > > URL: > http://www.ietf.org/internet-drafts/draft-jesske-dispatch-forking-answer-correlation-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-jesske-dispatch-forking-answer-correlation/ > > Htmlized: > http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-01 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-jesske-dispatch-forking-answer-correlation-01 > > Abstract: > > This document describe how a correlation of multiple responses of a > > forked INVITE in Back to Back User Agents can apply. > > Based on Paul’s comments I have restructured the draft. And changed the > call flows. > > I would be happy to get comments and of course an indication that people > would like to proceed with the work on the draft. > > Thank you and Best Regards > > Roland > > *Von:*dispatch [mailto:dispatch-bounces@ietf.org] *Im Auftrag von *Mary > Barnes > *Gesendet:* Freitag, 26. September 2014 19:25 > *An:* Christer Holmberg > *Cc:* dispatch@ietf.org > *Betreff:* Re: [dispatch] New draft > draft-jesske-dispatch-forking-answer-correlation-00 > > This discussion should continue in the DISPATCH WG until we get > community consensus that people think this problem is worth solving and > that there are people willing to do the work to complete a solution. As > Christer notes, this work is currently not within the scope of the > current STRAW charter and so it's not clear it should be immediately > dispatched there. > > Per the deadlines on the DISPATCH WG wiki, based on the DISPATCH WG > chairs discussion with the ADs, we will post the list of topics and the > handling thereof for the IETF-91 timeframe on October 13th. > > At this point, the only technical comments have been from Paul. > > Regards, > > Mary > > as DISPATCH WG co-chair > > On Fri, Sep 19, 2014 at 1:34 PM, Christer Holmberg > > > wrote: > > > (As STRAW co-chair) > > Hi Paul, > > > This document will describe how a correlation for multiples early > > dialogs and other received Responses can done within a B2BUA as > > described in the taxonomy document RFC7029 [RFC7029] The role of the > > B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use > > cases which will be possible looking on the used features are > > considered in this document > > > > If this is really about how B2BUAs do it, then perhaps this belongs > in STRAW. > > I actually told Roland to submit the draft to DISPATCH, as it doesn't > address any of the current STRAW deliveries. > > But, if there is no need to go via DISPATCH, we can ask Roland to submit > to STRAW directly :) > > Regards, > > Christer > > > > _______________________________________________ > 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 Oct 1 10:01:31 2014 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 6B7801A1A72 for ; Wed, 1 Oct 2014 10:01:29 -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 i8GFNr4PB7cP for ; Wed, 1 Oct 2014 10:01:28 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4521A1A6F for ; Wed, 1 Oct 2014 10:01:28 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-02v.sys.comcast.net with comcast id xt1L1o00856HXL001t1UzT; Wed, 01 Oct 2014 17:01:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-12v.sys.comcast.net with comcast id xt1T1o00H3Ge9ey01t1TKH; Wed, 01 Oct 2014 17:01:28 +0000 Message-ID: <542C3367.2090801@alum.mit.edu> Date: Wed, 01 Oct 2014 13:01:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412182888; bh=RteTMTrmbSDyaSTukpQvGxT5kpn0OsJpCZ6F+fv4tMY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JqutKqTQttV2yhLc7L5NuT84KDPHT1mBHYIz89GNB2a5w1POcswieFVFUpFlrujZS LYmbP9o/mf0VrGeNdyevLQ4CgoXU99djzEWFRaUcrTP2UQIKnEYghO/tnM8m9/kZdI nvqQsu6m2M8pS346dH+TDmBV2ALU7O7JO2NMFIXxVv+RGxY9Y9RVFlZXzdk00JZeIk 3W6lRn1GMfevzutEqpE/jjFnAOIGz5H4L/8Zs+v5P2KqlTvYRbu87l3ALmRH6sliP/ mgzK1zAi4ZIDsa07Hp8A4b40sByaJebCBTgzL1YdqXVqbKBOpK5tOE6M9zNyPxh2I6 hw7zPM2o/SPTw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/1SYWhxf-GPUObS-qTbBBGZ9flfI Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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 Oct 2014 17:01:29 -0000 I generally agree with Brett. (I usually do.) One comment: On 10/1/14 12:04 PM, Brett Tate wrote: > "To improve interoperability with devices which do not support forking, a > service provider shall have the possibility to use a B2BUA to correlate > multiple dialogs into a single dialog." Instead of "correlate", I suggest "multiplex": "To improve interoperability with devices which do not support forking, a service provider shall have the possibility to use a B2BUA to multiplex multiple downstream dialogs into a single dialog toward the caller." There is substantially more to do than simply correlate. Thanks, Paul From nobody Wed Oct 1 23:34:19 2014 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 084A61A0101 for ; Wed, 1 Oct 2014 23:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 Sl_qzRsNcyxI for ; Wed, 1 Oct 2014 23:34:15 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9C21A00FE for ; Wed, 1 Oct 2014 23:34:14 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP; 02 Oct 2014 08:34:12 +0200 X-IronPort-AV: E=Sophos;i="5.04,637,1406584800"; d="scan'208";a="144330040" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 02 Oct 2014 08:34:12 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Thu, 2 Oct 2014 08:34:12 +0200 From: To: , Date: Thu, 2 Oct 2014 08:34:11 +0200 Thread-Topic: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 Thread-Index: Ac/dlE0XoqUeRpQLRl6G8mwAKpHivAAdnIiw Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC5ED@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43@HE113667.emea1.cds.t-internal.com> <542C2AE0.3090503@alum.mit.edu> In-Reply-To: <542C2AE0.3090503@alum.mit.edu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/As7nl1qVPbSpxpSsdu2APyLk4I8 Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 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, 02 Oct 2014 06:34:18 -0000 Hi Paul, Thank you for your comment. I have it changed for the next version. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul > Kyzivat > Gesendet: Mittwoch, 1. Oktober 2014 18:25 > An: dispatch@ietf.org > Betreff: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer- > correlation-00 >=20 > Roland, >=20 > I see there are extensive changes in the -01 version. I haven't had time > to study them all. From a high level it looks like a better > organization. >=20 > One comment on Figure 1: >=20 > From a single INVITE sent by the UAC, the only *final* response(s) it > will receive are: > - *one* response in range 3xx-6xx > - one *or more* 2xx responses. >=20 > The forking proxy is responsible for preventing any error responses once > a 2xx response has been passed along. So in this flow the UAC should not > receive either of the 487 responses. And it is only responsible for > ACKing the 2xx responses it receives. >=20 > Thanks, > Paul >=20 > On 9/30/14 1:17 AM, R.Jesske@telekom.de wrote: > > Hi Mary, > > > > Thank you for your mail and clarification. > > > > Now I have a reworked version of the draft which is now available. > > > > A new version of I-D, > > draft-jesske-dispatch-forking-answer-correlation-01.txt > > > > has been successfully submitted by Roland Jesske and posted to the > > IETF repository. > > > > Name: draft-jesske-dispatch-forking-answer-correlation > > > > Revision: 01 > > > > Title: Correlation of multiple responses of forked INVITES > in > > Back to Back User Agents > > > > Document date: 2014-09-29 > > > > Group: Individual Submission > > > > Pages: 18 > > > > URL: > > http://www.ietf.org/internet-drafts/draft-jesske-dispatch-forking-answ > > er-correlation-01.txt > > > > Status: > > https://datatracker.ietf.org/doc/draft-jesske-dispatch-forking-answer- > > correlation/ > > > > Htmlized: > > http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correl > > ation-01 > > > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-jesske-dispatch-forking-answer= - > > correlation-01 > > > > Abstract: > > > > This document describe how a correlation of multiple responses of > > a > > > > forked INVITE in Back to Back User Agents can apply. > > > > Based on Paul's comments I have restructured the draft. And changed > > the call flows. > > > > I would be happy to get comments and of course an indication that > > people would like to proceed with the work on the draft. > > > > Thank you and Best Regards > > > > Roland > > > > *Von:*dispatch [mailto:dispatch-bounces@ietf.org] *Im Auftrag von > > *Mary Barnes > > *Gesendet:* Freitag, 26. September 2014 19:25 > > *An:* Christer Holmberg > > *Cc:* dispatch@ietf.org > > *Betreff:* Re: [dispatch] New draft > > draft-jesske-dispatch-forking-answer-correlation-00 > > > > This discussion should continue in the DISPATCH WG until we get > > community consensus that people think this problem is worth solving > > and that there are people willing to do the work to complete a > > solution. As Christer notes, this work is currently not within the > > scope of the current STRAW charter and so it's not clear it should be > > immediately dispatched there. > > > > Per the deadlines on the DISPATCH WG wiki, based on the DISPATCH WG > > chairs discussion with the ADs, we will post the list of topics and > > the handling thereof for the IETF-91 timeframe on October 13th. > > > > At this point, the only technical comments have been from Paul. > > > > Regards, > > > > Mary > > > > as DISPATCH WG co-chair > > > > On Fri, Sep 19, 2014 at 1:34 PM, Christer Holmberg > > > > > > wrote: > > > > > > (As STRAW co-chair) > > > > Hi Paul, > > > > > This document will describe how a correlation for multiples > early > > > dialogs and other received Responses can done within a B2BUA as > > > described in the taxonomy document RFC7029 [RFC7029] The role of > the > > > B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible > use > > > cases which will be possible looking on the used features are > > > considered in this document > > > > > > If this is really about how B2BUAs do it, then perhaps this belongs > > in STRAW. > > > > I actually told Roland to submit the draft to DISPATCH, as it doesn't > > address any of the current STRAW deliveries. > > > > But, if there is no need to go via DISPATCH, we can ask Roland to > > submit to STRAW directly :) > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Oct 2 05:41:58 2014 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 8FD541A6FD6 for ; Thu, 2 Oct 2014 05:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TZsz_7yA9vWs for ; Thu, 2 Oct 2014 05:41:54 -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 A16E01A6FD0 for ; Thu, 2 Oct 2014 05:41:53 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-c7-542d480fded9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.78.21334.F084D245; Thu, 2 Oct 2014 14:41:51 +0200 (CEST) Received: from [131.160.126.147] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.174.1; Thu, 2 Oct 2014 14:41:51 +0200 Message-ID: <542D480E.8090905@ericsson.com> Date: Thu, 2 Oct 2014 15:41:50 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvjS6/h26IwenzVhZLJy1gtXj2vIXR gcljyZKfTB63X89nDmCK4rJJSc3JLEst0rdL4MqY+mgVW8FKs4pHtxtYGhi/a3cxcnJICJhI fG99ygxhi0lcuLeerYuRi0NI4CijxPHjU5kgnDWMEv8e3Qaq4uDgFdCWuHNAHKSBRUBF4sy9 g0wgNpuAhcSWW/dZQGxRgSiJVytusILYvAKCEidnPgGLiwiISzR0vwNbxgxUM+fnSXYQW1jA WOLGgfdgNUICvhKdH9YzgticAn4Sf4/NAlsrAdTb0xgEcWekxNans1ggxuhJTLnawghhy0s0 b53NDDFGW2L5sxaWCYzCs5BcMQtJyywkLQsYmVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxi BAb3wS2/dXcwrn7teIhRgINRiYd3wUadECHWxLLiytxDjNIcLErivIvOzQsWEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwDhvQ1RwjwVL7OTl9+79mfgwoXzBch6fZUqzVs3TvTgz3eneKuvq RK32DW1hHa+15jhJs4RNWCNgcUlb5kLVCyu2bdlvJZl6l7Vu+fx+8d11sVnXC9izJllE1J6o vmK+SLN6/mX5NdsbJ3dmpFx7q55W0l39jWlKNreO9i69PxdU2OO91vvskVNiKc5INNRiLipO BAAbx5KZTwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/5IRlWeki_2e3a0_eNOERP6XyaiE Subject: [dispatch] Review of draft-jimenez-p2psip-coap-reload 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, 02 Oct 2014 12:41:56 -0000 Folks, per the agreed plan to progress this draft, we have gotten two dedicated reviewers to look at the draft. http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/ Cullen reviewed it from a RELOAD perspective and sent his review to this list some time ago. Matthias (in the cc:) has now reviewed the draft from a CoAP point of view. Please, find below his review and Jaime's initial responses (preceded by a '+' sign) to his comments. Cheers, Gonzalo -------- Original Message -------- Subject: RE: Reviewing a CoAP/P2PSIP draft Date: Tue, 12 Aug 2014 14:50:54 +0000 From: Kovatsch Matthias To: Ari Keränen Hi Ari Is there an official process to submit the review? If not, here it is simply by mail: Overall, I am missing the motivation for having a RELOAD abstraction on top of CoAP. There is no new functionality provided through this combination and it only weakens both concepts (REST and P2P overlays). + The abstraction layer is CoAP on top of RELOAD. Some of the advantages provided by RELOAD is that we can actually have discovery in a P2P way, without a server acting as RD. Another is that P2P intrinsically provides caching, resilience, etc. I will add text along those lines to the introduction of the draft. If a sensor/actuator Usage for RELOAD is required, I think it is better realized in a direct fashion without CoAP. + The main functionality we use from RELOAD is discovery. The rest of the sensor/actuator functionality is implemented via CoAP. Mixing actual CoAP URIs and URIs that serve as simple ID is very confusing. + Yeah you are right in the sense that a two-step discovery process is a bit more inefficient, but necessary when using DHTs and compensated by the possibility of having a distributed lookup using RELOAD. The contents of the RELOAD Sensor Type Registry (temperature, humidity, etc.) also imply that this draft defines an additional application layer that is not compatible with CoAP/REST. + The RELOAD sensor type registry is purely orientative, it is better that we use the IANA references specified in the CoAP RFC6690. I might be missing the use case for this draft, which might be helpful in the draft itself. + You are right, an example could be from this EURASIP paper in which we give some use cases, I will include one of them in the draft too (I will update it to the latest versions of RELOAD and CoAP). The paper can be found at: http://users.piuha.net/jaime/coap_reload_long.pdf My more specific comments are: 1. Introduction - The meaning of the relative URI paths in the 6th paragraph is unclear (later examples show how they are used with a draft-specific rule that is not explicitly described) + In the example, the full path for a sensor behind the proxy would be coap://overlay-1.com/proxy-1/temperature-1 .The Proxy device has to know the Overlay address (since it is connected to it) and has to know its own Node_ID, therefore he can create the whole path to itself and just append the two new devices. I think this should be clear enough for RELAOD implementors. If you have a suggestion to clarify the sentence, please let me know. - The use of URIs is fuzzy. A base URI (basically the DNS name) would relate to a node, but a node usually has several URIs for each of its resources + If a Proxy with three sensor devices would have the three following URIs (one per sensor) coap://overlay-1.com/proxy-1/temperature-1 coap://overlay-1.com/proxy-1/temperature-2 coap://overlay-1.com/proxy-1/temperature-3 - Registration and lookups are already provided by CoRE resource directories and Web Linking + RD is so far not distributed AFAIK, and RELOAD could provide an extra way to do discovery in a distributed way. - Rendezvous: Having URIs no P2P routing is required to exchange CoAP messages. Relying on CoAP proxies already solves the NAT/firewall problem for WSNs without RELOAD functionality. + In our use case we use the Overlay to look the domains up, not DNS. Of course a network of sensors could be implemented in the traditional way. This draft explains how to do it in an alternative way, a distributed way using overlays. - Caching is already a fundamental part of REST. + This would be overlay caching, providing extra resilience. 3. Architecture - It might be useful to align the terminology for constrained nodes with the LWIG terminology RFC 7228 (cf. LR-WPAN). + I will align the terms when applicable. - The description for PN missing (used in figure and probably a CoAP proxy node). + You are right, I should write that part too. 4. Registering CoAP URIs - From where do peers get the initial URI used in the hash? These URIs do not even address a working CoAP resource. + If the proxy is part of the RELOAD overlay it has to know both its own Node_Id and the overlay he is connecting to. The URI is coap://OVERLAYID/NODEID/ - The use of the .well-known location in "coap://overlay-1.com/proxy-1/.well-known/" is incorrect. Using the entry URI that is the base of the relative URIs would even make more sense. + Since we are not using the RD to register resources, but we use the Overlay instead, we have tried to adapt it to RELOAD's registration process. - The formal handling of the relative paths is still not defined. + Perhaps you could elaborate a bit more this comment cause I don't fully understand it. 5. Rendezvous - The RELOAD term "rendezvous" is misleading, since the described action is a simple lookup and not the establishment of a connection. + I will change the title to Lookup instead of Rendezvous. 6. Forming a direct connection and reading data - Should reading data be a normal, direct CoAP GET request? + The reading of data is, in a ways, a normal CoAP Get Request. However it is routed via RELOAD instead of using DNS. - All resulting URIs point to one central reverse-proxy, which completely removes the distributed P2P idea. + Perhaps you could elaborate a bit more this comment cause I don't fully understand it. 7. Caching Mechanisms - How are the CNs supposed to send their data to the proxy? + Each CN sits under a PN and sends the data through it. The PN can do caching in the Overlay like any other RELAOD node would. - What is the purpose of the additional caching mechanism? It furthermore breaks the underlying REST architecture, as the used structures are unaware of media types. + The additional caching mechanism adds resiliency to the network, since it is done in a distributed fashion. Editorial comments: Abstract - CoAP "Nodes" to lower case + I will change that 4. Registering CoAP URIs - "registering register" in first paragraph + I will change that 6. Forming a direct connection and reading data - Title capitalization is missing for this section heading + I will change that From nobody Thu Oct 2 06:25:14 2014 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 6C7351A02F7 for ; Thu, 2 Oct 2014 06:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 y5prx3hW7A2E for ; Thu, 2 Oct 2014 06:24:55 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD291A8713 for ; Thu, 2 Oct 2014 06:24:53 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail11.telekom.de with ESMTP; 02 Oct 2014 15:24:21 +0200 X-IronPort-AV: E=Sophos;i="5.04,638,1406584800"; d="scan'208";a="672893100" Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 02 Oct 2014 15:24:21 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Thu, 2 Oct 2014 15:24:20 +0200 From: To: , Date: Thu, 2 Oct 2014 15:24:19 +0200 Thread-Topic: draft-jesske-dispatch-forking-answer-correlation-01: comments Thread-Index: AQLVA4+w6FtlQ91/xH836kVqt2LivQLBu1i1mfrZTfCAAYrE0A== Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB7A47BD@HE113667.emea1.cds.t-internal.com> References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XqLW1KvLl5DFnDbveFxzgrb8TOY Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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, 02 Oct 2014 13:25:05 -0000 SGkgQnJldHQsDQp0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQpSZXBseSBpbmxpbmUuDQoN Cg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogQnJldHQgVGF0 ZSBbbWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb21dDQo+IEdlc2VuZGV0OiBNaXR0d29jaCwgMS4g T2t0b2JlciAyMDE0IDE4OjA0DQo+IEFuOiBKZXNza2UsIFJvbGFuZDsgZGlzcGF0Y2hAaWV0Zi5v cmcNCj4gQmV0cmVmZjogUkU6IGRyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1j b3JyZWxhdGlvbi0wMToNCj4gY29tbWVudHMNCj4gDQo+IEhpIFJvbGFuZCwNCj4gDQo+IFJlcGx5 IGlzIGlubGluZS4NCj4gDQo+ID4gPiBSRkMgMzI2MSBtYW5kYXRlcyB0aGF0IHRoZSBVQUMgYmUg YWJsZSB0byBoYW5kbGUgaW50ZXJhY3Rpb25zIHdpdGggYQ0KPiA+ID4gZm9ya2luZyBwcm94eS4N Cj4gPg0KPiA+IE9LIEkgYWdyZWUgdGhhdCBub3JtYWxseSBhIGNvcnJlY3QgaW50ZXJhY3Rpb24g c2hvdWxkIGhhcHBlbiBhdCBsZWFzdA0KPiA+IHdoZW4gYSAyMDAgT0sgYXJyaXZlcy4NCj4gPiBS ZWdhcmRpbmcgUkZDIDMyNjEgdGhlIDIwMCBPSyBtdXN0IGJlIGhhbmRsZWQgY29ycmVjdC4gVGhl cmUgaXMNCj4gPiBub3RoaW5nIHN0YXRlZCBhYm91dCB0aGUgMTh4Lg0KPiA+IE9rIG15IGNvbmNl cm4gaXMgdGhlIGhhbmRsaW5nIG9mIHByb3Zpc2lvbmFsIHJlc3BvbnNlcyB2ZXJzdXMgZmluYWwN Cj4gPiByZXNwb25zZXMuDQo+IA0KPiBSRkMgMzI2MSBpbmRpY2F0ZXMgaG93IHRoZSBVQUMgbXVz dC9zaG91bGQvbWF5IGJlaGF2ZSAoc29tZSBhc3BlY3RzDQo+IHVwZGF0ZWQgYnkgUkZDIDYwMjYg YW5kIFJGQyA2MTQxKTsgdGhpcyBpbmNsdWRlcyB0aGUgaW1wYWN0cyBvZg0KPiByZWNlaXZpbmcg SU5WSVRFJ3MgMTh4IG9yIDJ4eCBvbiBhIGtub3duIG9yIHVua25vd24gZGlhbG9nLiAgSG93ZXZl ciwgaXQNCj4gZnJlcXVlbnRseSBkZWZlcnMgdGhlIGh1bWFuIGludGVyYWN0aW9uIGRlY2lzaW9u cyB0byB0aGUgaW1wbGVtZW50b3IuDQo+IA0KPiBTaW1pbGFybHksIGEgZGV2aWNlIGNhbiBiZSBm dWxseSBjb21wbGlhbnQgd2l0aCBSRkMgMzI2MSBidXQgZGVjaWRlIHRvDQo+IGhhdmUgYSBzZXJ2 aWNlIHRvIHRlcm1pbmF0ZSBjYWxsIGFmdGVyIG9yIGJlZm9yZSBhbnN3ZXIgKG9yIGluZGl2aWR1 YWwNCj4gZWFybHkgZGlhbG9ncyBiZWZvcmUgYW5zd2VyKSBpZiBtb3JlIHRoYW4gMSBkaWFsb2cg d2FzIG9ic2VydmVkIGR1cmluZw0KPiBjYWxsIHNldHVwLg0KPiBTdWNoIGEgInNlcnZpY2UiIGxp a2VseSBpbmRpY2F0ZXMgdGhhdCB0aGUgZGV2aWNlIGRvZXNuJ3QgcmVhbGx5IHN1cHBvcnQNCj4g Zm9ya2luZyBwcm94aWVzIChvciBtYXliZSBkb2Vzbid0IHRydXN0IGZvcmtpbmcgaW50ZXJhY3Rp b25zKS4NCj4gDQoNClRoYW5rIHlvdSBmb3IgY2xhcmlmaWNhdGlvbi4gU28gSSBzZWUgdGhhdCB0 aGVyZSBpcyBhdCBsZWFzdCBldmVyeXRoaW5nIGRlc2NyaWJlZCBidXQgDQpJdCBpcyBtb3JlIGFz IHlvdSBzYWlkIHRoZTogIml0IGZyZXF1ZW50bHkgZGVmZXJzIHRoZSBodW1hbiBpbnRlcmFjdGlv biBkZWNpc2lvbnMgdG8gdGhlIGltcGxlbWVudG9yIg0KDQpJIHRha2UgeW91ciB3b3JkcyBhbmQg d2lsbCBpbXBsZW1lbnQgaXQgaW4gdGhlIGRyYWZ0LiBBbHNvIEkgd2lsbCB0YWtlIHRoZSBSRkM2 MDI2IGFuZCBSRkM2MTQxIGludG8gY29uc2lkZXJhdGlvbi4NCg0KPiA+ID4gMikgU2VjdGlvbiAy LjggaW5kaWNhdGVzOg0KPiA+ID4NCj4gPiA+ICJUaHVzIHRoZSBvbmx5DQo+ID4gPiAgICBzb2x1 dGlvbiBzZWVuIGlzIHRvIGRlc2NyaWJlIHByb2NlZHVyZXMgd2hpY2ggYXBwbHkgaW4gQjJCVUEg dG8NCj4gPiA+ICAgIHN1cHBvcnQgYW4gY29ycmVsYXRpb24gb2YgbXVsdGlwbGVzIGVhcmx5IGRp YWxvZ3MgYW5kIG90aGVyDQo+IHJlY2VpdmVkDQo+ID4gPiAgICAxOHggUmVzcG9uc2VzLiINCj4g PiA+DQo+ID4gPiBJIGRpc2FncmVlIHdpdGggdGhhdCBzdGF0ZW1lbnQuICBPbmUgc29sdXRpb24g aXMgdG8gcmVwbGFjZS91cGdyYWRlDQo+ID4gPiB0aGUgZGVmaWNpZW50IGRldmljZSBzbyB0aGF0 IGl0IHN1cHBvcnRzIGZvcmtpbmcgaW50ZXJhY3Rpb25zLg0KPiA+ID4NCj4gPg0KPiA+IFllcyBJ IGNhbiBhZ3JlZSBvbiB0aGF0IGJ1dCBpdCBpcyBub3QgcG9zc2libGUgdG8gZG8gdGhhdCBpbiBl YWNoDQo+IGNhc2UuDQo+ID4gV2UgY2Fubm90IG1hbmRhdGUgdGhlIGRldmljZXMgdXNlZCB3aXRo aW4gb3RoZXIgbmV0d29ya3MuDQo+ID4gQW5kIGZyb20gb3VyIG9ic2VydmF0aW9ucyB0aGVyZSBh cmUgbWFueSBjYXNlcyB3aGVyZSB3ZSBoYXZlIHN1Y2gNCj4gPiBwcm9ibGVtcy4NCj4gPiBTbyB0 aGVyZSBpcyBzb21ldGhpbmcgd2hhdCB3ZSBoYXZlIHRvIGRvIHRvIHNhdGlzZnkgb3VyIGN1c3Rv bWVycw0KPiA+IHdoaWNoIGFyZSB1c2luZyBtb3JlIHRoYW4gb25lIGRldmljZSByZWFjaGFibGUg dW5kZXIgb25lICJudW1iZXIiLg0KPiANCj4gVGhhdCBpcyB0aGUgaXNzdWUuICBTb21lb25lIGRl cGxveWVkIGRldmljZXMgd2hpY2ggYXJlIGNhdXNpbmcgZm9ya2luZw0KPiByZWxhdGVkIGludGVy b3BlcmFiaWxpdHkgaXNzdWVzLiAgQjJCVUFzIGFyZSBmcmVxdWVudGx5IHVzZWQgdG8gaGVscA0K PiBvdmVyY29tZSAod2hpbGUgYXR0ZW1wdGluZyB0byBhdm9pZCkgaW50ZXJvcGVyYWJpbGl0eSBp c3N1ZXMuICBUaHVzIGl0DQo+IGlzIGEgbWF0dGVyIG9mIGRlY2lkaW5nIGlmIHRoZSBJRVRGIHdh bnRzIHRvIGRvIGFueXRoaW5nIChzdWNoIGFzDQo+IHByb2R1Y2luZyBhbg0KPiBSRkMpIHRvIGhl bHAgcmVtZWR5IHRoZSBpc3N1ZS4NCj4gDQo+ID4gPiAzKSBTZWN0aW9uIDMgaW5kaWNhdGVzOg0K PiA+ID4NCj4gPiA+ICIgVG8gcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGJlaGF2aW9yIGEgc2Vydmlj ZSBwcm92aWRlciBzaGFsbCBoYXZlDQo+IHRoZQ0KPiA+ID4gICAgcG9zc2liaWxpdHkgdG8gY29y cmVsYXRlIG11bHRpcGxlcyByZWNlaXZlZCByZXNwb25zZXMgdG8gb25lDQo+IGRpYWxvZw0KPiA+ ID4gICAgbGVnIHRvIHRoZSBVQUMuIg0KPiA+ID4NCj4gPiA+IEkgZGlzYWdyZWUgd2l0aCB0aGF0 IHN0YXRlbWVudC4gIEZvbGRpbmcgbXVsdGlwbGUgZWFybHkgZGlhbG9ncyBvbnRvDQo+ID4gPiBh IHNpbmdsZSBlYXJseSBkaWFsb2cgZG9lcyBub3QgcHJvZHVjZSB0aGUgYmVzdCB1c2VyIGV4cGVy aWVuY2UuICBJdA0KPiA+ID4gY2F1c2VzIGFtYmlndWl0aWVzIGFzIHZhcmlvdXMgcmVxdWVzdHMv cmVzcG9uc2UvaGVhZGVycy9ib2RpZXMNCj4gPiA+IHRyYXZlcnNlIHRob3NlIGVhcmx5IGRpYWxv Z3MuICBJdCBjYW4gY2F1c2UgdGhlIG5lZWQgZm9yIFVBQyB0bw0KPiA+ID4gc3VwcG9ydCBSRkMg MzI2MiBhbmQgUkZDDQo+ID4gPiAzMzExIChpZiB0aGUgQjJCVUEgbmVlZHMgdG8gY29tbXVuaWNh dGUgU0RQIG1vZGlmaWNhdGlvbnMgb24gYW4NCj4gPiA+IGVhcmx5IGRpYWxvZykuDQo+ID4gPg0K PiA+IE9LIEkgdHJ5IHRvIHJld29yZCBhcyBmb2xsb3dzOg0KPiA+DQo+ID4gVG8gcHJvdmlkZSB0 aGUgYmVzdCB1c2VyIGJlaGF2aW9yIGEgc2VydmljZSBwcm92aWRlciBzaGFsbCBoYXZlIHRoZQ0K PiA+ICAgIHBvc3NpYmlsaXR5IHRvIGNvcnJlbGF0ZSBtdWx0aXBsZXMgcmVjZWl2ZWQgcmVzcG9u c2VzIHRvIGFwcGx5IGENCj4gPiBzdWNjZXNzZnVsIGNyZWF0aW9uIG9mIGEgZGlhbG9nIHdoaWNo IGltcGx5IHRoYXQgdGhlIHVzZWQgY2FwYWJpbGl0aWVzDQo+ID4gb2YgdGhlIFVBQyBzaGFsbCBi ZSB0YWtlbiBpbnRvIGNvbnNpZGVyYXRpb24uDQo+ID4NCj4gPiBJcyB0aGlzIE9LPw0KPiANCj4g VGhlIGZvbGxvd2luZyBtaWdodCBiZSBnb29kIGVub3VnaCBmb3Igbm93Og0KPiANCj4gIlRvIGlt cHJvdmUgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGRldmljZXMgd2hpY2ggZG8gbm90IHN1cHBvcnQg Zm9ya2luZywNCj4gYSBzZXJ2aWNlIHByb3ZpZGVyIHNoYWxsIGhhdmUgdGhlIHBvc3NpYmlsaXR5 IHRvIHVzZSBhIEIyQlVBIHRvDQo+IGNvcnJlbGF0ZSBtdWx0aXBsZSBkaWFsb2dzIGludG8gYSBz aW5nbGUgZGlhbG9nLiINCg0KT0sgSSB3aWxsIHRha2UgdGhlIHdvcmRzIGluY2x1ZGluZyBQYXVs J3MgY2hhbmdlIGZyb20gY29ycmVsYXRlIHRvIG11bHRpcGxleC4NCkkgaG9wZSB0aGF0IGlzIE9L IGZvciB5b3UuDQoNCj4gDQo+ID4gPiA2KSBTZWN0aW9uIDQuMiBzaG93cyBCMkJVQSBvbmx5IHJl bGF5aW5nIGZpcnN0IDE4eC4gIFdoYXQgYXJlIHlvdQ0KPiA+ID4gcHJvcG9zaW5nIHRvIGRvIGlm IHRoZSBzZXJ2ZXJzIHNlbnQgZGlmZmVyZW50IDE4eCByZXNwb25zZXMgc3VjaCBhcw0KPiA+ID4g VUFDXzIgc2VudCAxODEsIFVBQ18zIHNlbnQgMTgyLCBhbmQgVUFDXzQgc2VudCAxODM/DQo+ID4g Pg0KPiA+DQo+ID4gVGhhdCBpcyBzb21ldGhpbmcgdGhhdCBJIHNob3VsZCBoYW5kbGUgYWxzbyBp biBhZGRpdGlvbi4NCj4gPiBRdWVzdGlvbiBpcyBpZiBJIHB1dCBpdCBkaXJlY3RseSBpbnRvIHRo ZSByZWdhcmRpbmcgc2VjdGlvbnMgb3IgZG8gaXQNCj4gPiBpbiBhbiBvd24gc2VjdGlvbi4NCj4g Pg0KPiA+IDE4MSBpdHNlbGYgc2hvd3MgdGhhdCB0aGUgY2FsbCBpcyBmb3J3YXJkZWQuIEZyb20g bXkgdW5kZXJzdGFuZGluZyBpdA0KPiA+IHdpbGwgbm90IGNvbnRhaW4gYW55IFNEUC4NCj4gDQo+ IFNpbWlsYXIgdG8gdGhlIG90aGVyIDE4eCByZXNwb25zZXMsIHRoZSBTRFAgaXMgb3B0aW9uYWwu DQoNCk9LLg0KSSB3YXMgdGhpbmtpbmcgdG8gdXNlIDE4MSBtb3JlIGFzIGFuIGluZGljYXRpb24u IA0KQnV0IHlvdSBhcmUgcmlnaHQuIEl0IGNvdWxkIGJlIGFsc28gdG8gaW5jbHVkZSBTRFAgDQpX aXRoIGVhcmx5IG1lZGlhIHRvIHBsYXkgYW4gYW5ub3VuY2VtZW50IHdoZXJlIHRoZSBjYWxsZXIg Z2V0cyBzb21lIG1vcmUgaW5mb3JtYXRpb24uDQoNCj4gDQo+ID4gVGh1cyB3aGVuIHJlcXVlc3Rp bmcgMTAwcmVsIGl0IHdpbGwgYmUgYWNrbm93bGVkZ2VkIGJ5IHRoZSBCMkJVQQ0KPiA+IChQUkFD SykgYnV0IG5vIGFjdGl2aXR5IHdpbGwgYXBwbHkgYXQgdGhlIG9yaWdpbmF0aW5nIGxlZy4NCj4g PiBCZWNhdXNlIGl0IGlzIG5vdCBzdXJlIHdoaWNoIG9mIHRoZSBlYXJseSBkaWFsb2dzIHdpbGwg YmUgaW4gZmluYWwNCj4gPiBzdGF0ZSBsYXRlciBvbi4NCj4gDQo+IFRoZSBCMkJVQSBuZXZlciBr bm93cyB3aGljaCBrbm93bi91bmtub3duIGRpYWxvZyB3aWxsIGdlbmVyYXRlIHRoZSBmaXJzdA0K PiBJTlZJVEUgMnh4IHJlc3BvbnNlLg0KPiANCj4gVGhlIHByb3Bvc2FsIGRlbGF5cyBjb21tdW5p Y2F0aW5nIGEgMTh4IHRvIGNhbGxlci4NCg0KT0suIA0KDQo+IA0KPiA+IFBlciBSRkMgMzI2MSAx ODIgc293cyB0aGF0IHRoZSBjYWxsZWQgcGFydHkgaXMgdGVtcG9yYXJpbHkNCj4gPiB1bmF2YWls YWJsZSwgYnV0IHRoZSBzZXJ2ZXIgaGFzDQo+ID4gICAgZGVjaWRlZCB0byBxdWV1ZSB0aGUgY2Fs bCByYXRoZXIgdGhhbiByZWplY3QgaXQuIFRodXMgbm8gU0RQIHdpbGwNCj4gPiBiZSBpbmNsdWRl ZCBpbnRvIHRoaXMgcHJvdmlzaW9uYWwgcmVzcG9uc2UuDQo+IA0KPiBTaW1pbGFyIHRvIHRoZSBv dGhlciAxOHggcmVzcG9uc2VzLCB0aGUgU0RQIGlzIG9wdGlvbmFsLg0KDQpZZXMuIEl0IGlzIHRo ZSBzYW1lIGFzIGZvciAxODEuDQpTbyBJIHdpbGwgaGF2ZSBzb21lIHdvcmRzIG9uIDE4MSBhbmQg MTgyIA0KPiANCj4gPiBBcyBmb3IgMTgxIGl0IHdpbGwgYmUgYWNrbm93bGVkZ2VkIGJ5IHRoZSBC MkJVQSAoUFJBQ0spIGJ1dCBubw0KPiA+IGFjdGl2aXR5IHdpbGwgYXBwbHkgYXQgdGhlIG9yaWdp bmF0aW5nIGxlZy4NCj4gPiBCZWNhdXNlIGl0IGlzIG5vdCBzdXJlIHdoaWNoIG9mIHRoZSBlYXJs eSBkaWFsb2dzIHdpbGwgYmUgaW4gZmluYWwNCj4gPiBzdGF0ZSBsYXRlciBvbg0KPiA+DQo+ID4g V2hlbiBzdWNjZWVkaW5nIHJlc3BvbnNlcyBjb250YWluaW5nIHdpbGwgYmUgcmVjZWl2ZWQgYnkg dGhlIEIyQlVBIGl0DQo+ID4gc2hvdWxkIGFwcGx5IGFjY29yZGluZ2x5IGFzIGRlc2NyaWJlZCBp biB0aGUgZHJhZnQuDQo+ID4NCj4gPiBJcyB0aGlzIE9LIGZvciB5b3U/DQo+IA0KPiBUaGUgcHJv cG9zYWwgZGVsYXlzIGNvbW11bmljYXRpbmcgYSAxOHggdG8gY2FsbGVyIGFuZCBtYXkgcmVzdWx0 IGluIGNhbGwNCj4gcmVsZWFzZSBzaW5jZSBCMkJVQSBwcmV2ZW50aW5nIGNhbGxlciBmcm9tIHJl Y2VpdmluZyAxOHggcmVzcG9uc2VzDQo+IGR1cmluZyBjYWxsIHNldHVwLg0KDQpZZXMgdGhlbiB0 aGUgQjJCVUEgaGFzIHRvIGFzc3VyZSB0aGF0IHRoZSB0aW1lcnMgd2hpY2ggYXJlIHJ1bm5pbmcg ZG8gbm90IGZpcmUgYW5kIHRlcm1pbmF0ZSB0aGUgY2FsbC4NCkluIHRoZSBub3JtYWwgY2FzZSBJ IHNlZSB0aGF0IHRoZSBCMkJVQSByZWNlaXZpbmcgMTh4IHJlc3BvbnNlcyB0aGF0IGRvIG5vdCBj b250YWluIGFueSBTRFAgDQpkb2VzIG5vdCBuZWVkIHRvIGJlIGZvcndhcmRlZCB0byB0aGUgVUFD Lg0KDQpNeSBleGFtcGxlIGlzIHRoZSAxODEgd2hpY2ggaXMgbm90IGNvbnRhaW5pbmcgYW55IFNE UC4gU28gdGhlIGNhbGwgaXMgZm9yd2FyZGVkIGJ5IGFuIFVBU18yIHRvIGFub3RoZXIgVUFTXzMu DQpVQVNfMiBzZW5kcyBhbiAxODEgd2l0aG91dCBTRFAgb25seSBpbmRpY2F0aW5nIHRoYXQgdGhl IElOVklURSB3YXMgZm9yd2FyZGVkLg0KU2VlbiBmcm9tIGZvcmtpbmcgcGVyc3BlY3RpdmUgdGhl IDE4MSBoYXMgbm8gdmFsdWUgZm9yIHRoZSBVQUMgc2luY2UgaXQgaXMgbm90IGludGVyZXN0aW5n IGFzIGxvbmcgYXMgVUFTXzMgc2VuZHMgdGhlIDIwME9LIGZpcnN0Lg0KDQpTbyBub3cgdGhlIHRy aWNreSBwYXJ0IHN0YXJ0cy4NClRoZXJlIGNvdWxkIGJlIGFsc28gYSByZXF1aXJlbWVudCBmcm9t IHRoZSBjYWxsZXIgdGhhdCBoZSBkb2VzIG5vdCBsaWtlIHRvIGhhdmUgY2FsbHMgZm9yd2FyZGVk Lg0KVGhlbiBoZSBuZWVkcyB0aGUgZm9yd2FyZGluZyBpbmZvcm1hdGlvbi4NCkVpdGhlciB0aGVu IHRoZSBCMkJVQSBoYXMgdG8gc2VudCBmaXJzdCB0aGUgMTgxIGFuZCB0aGVuIHRoZSAyMDBPSyB3 aGljaCB3aWxsIHJlYWxseSBkZWxheSB0aGUgY2FsbCBhcyB5b3Ugc2FpZC4NCk9yIHRoZSBCMkJV QSBzZW5kJ3MgYmFjayB0aGUgMjAwIE9LIHdpdGggdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgaW5k aWNhdGluZyB0aGUgY2FsbCBmb3J3YXJkaW5nLiBCdXQgdGhhdCBhc3N1bWVzIHRoYXQgdGhlIFVB QyBzdXBwb3J0cyBSRkM0MjQ0LzcwNDQuIA0KVGh1cyB0aGUgQ2FsbGVyIGdldHMgdGhlIGluZGlj YXRpb24gdGhhdCB0aGUgY2FsbCB3YXMgZm9yd2FyZGVkIGFuZCB0aGUgY2FsbGVyIGNhbiBkZWNp ZGUgaWYgaGUgd2FudHMgdG8gcmVqZWN0IHRoZSBjYWxsIG9yIG5vdC4gIA0KDQpJIHRoaW5rIEkg aGF2ZSB0byBkbyBzb21lIG1vcmUgZGVzY3JpcHRpb24gb24gc3VjaCBzY2VuYXJpb3MuDQoNCg0K PiANCj4gPiA+IDcpIFNlY3Rpb24gNC4zIGZpZ3VyZSAzIHNob3dzIENBTkNFTC8yMDAvNDg3L0FD SyBiZXR3ZWVuIEIyQlVBIGFuZA0KPiA+ID4gRm9ya2luZyBQcm94eS4gIFRoaXMgc2hvdWxkIG5v dCBiZSBvY2N1cnJpbmcuDQo+ID4gPg0KPiA+ID4gOCkgU2VjdGlvbiA0LjQgZmlndXJlIDQgc2hv d3MgQ0FOQ0VMLzIwMCBiZXR3ZWVuIEIyQlVBIGFuZCBGb3JraW5nDQo+ID4gPiBQcm94eS4NCj4g PiA+IFRoaXMgc2hvdWxkIG5vdCBiZSBvY2N1cnJpbmcuICBJdCBhbHNvIGxvb2tzIGxpa2UgdGhl cmUgaXMgYQ0KPiA+ID4gc3Vic2VxdWVudCBleHRyYSAyMDAgcmVzcG9uc2UuDQo+ID4gPg0KPiA+ IDcrOCkgU28gaW4gdGhlIGNhc2Ugd2hlcmUgYSBwcm92aXNpb25hbCByZXNwb25zZSBpbnMgbWFk ZSByZWxpYWJsZQ0KPiAoaW5jbC4NCj4gPiByZXNlcnZhdGlvbiBvZiByZXNvdXJjZXMpIGl0IGlz IHN0aWxsIHZhbGlkIHRoYXQgdGhlIGZvcmtpbmcgcHJveHkgaXMNCj4gPiByZXNwb25zaWJsZSB0 byByZWxlYXNlIHRoZSBlYXJseSBkaWFsb2dzLg0KPiA+IE1ZIHVuZGVyc3RhbmRpbmcgaXMgdGhh dCBpZiB5b3UgbWFrZSBzb21ldGhpbmcgcmVsaWFibGUgdGhhbiB0aGUgVUENCj4gPiBzdG9yZSBl dmVyeXRoaW5nIHdoYXQgd2FzIHJlY2VpdmVkLg0KPiA+IFNvIG5vdyB3aXRoIHJlY2VpdmluZyB0 aGUgMjAwIE9LIGJ5IHRoZSBCMkJVQSBmb3Igb25lIG9mIHRoZSBkaWFsb2dzDQo+ID4gYWxsIG90 aGVyIGVhcmx5IChhbmQgcmVsaWFibGUgbWFkZSkgZGlhbG9ncyBhcmUgZGVzdHJveWVkLg0KPiA+ IEFuZCBubyBmdXJ0aGVyIGFjdGlvbiBoYXMgdG8gYmUgdGFrZW4gYnkgdGhlIFVBQyAoQjJCVUEp IG9ubHkgdGhlDQo+ID4gZm9ya2luZyBwcm94eS4gUmlnaHQ/DQo+IA0KPiBTZWUgUkZDIDMyNjEg c2VjdGlvbiAxNi43IHN0ZXAgMTAuICBUaGUgZm9ya2luZyBwcm94eSBNVVNUIHNlbmQgQ0FOQ0VM Ow0KPiBob3dldmVyIGEgc3Vic2VxdWVudCAyeHggZm9yIElOVklURSBtYXkgc3RpbGwgYmUgcmVj ZWl2ZWQgYnkgdGhlIGNhbGxlci4NCj4gVGh1cyB5b3UnZCBsaWtlbHkgd2FudCB0aGUgQjJCVUEg dG8gQUNLL0JZRSBsYXRlIElOVklURSAyeHggcmVzcG9uc2VzLg0KDQpJIHdpbGwgYWRkIHNvbWUg d29yZHMgd2l0aCByZWdhcmQgdG8gbGF0ZWx5IHJlY2VpdmVkIDIwMCBPSy4NCg0KVGhhbmsgeW91 IGFuZCBCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQo= From nobody Thu Oct 2 06:26:54 2014 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 4BC581A6FB1 for ; Thu, 2 Oct 2014 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 n8LlLaBZJwe9 for ; Thu, 2 Oct 2014 06:26:49 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF83B1A8028 for ; Thu, 2 Oct 2014 06:26:47 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail31.telekom.de with ESMTP; 02 Oct 2014 15:26:01 +0200 X-IronPort-AV: E=Sophos;i="5.04,638,1406584800"; d="scan'208";a="672894543" Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 02 Oct 2014 15:26:01 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 2 Oct 2014 15:26:01 +0200 From: To: , Date: Thu, 2 Oct 2014 15:26:00 +0200 Thread-Topic: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments Thread-Index: Ac/dmV1ggFn6y9RjTQ+d3Uo6O/a64AAqt5AA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB7A47C0@HE113667.emea1.cds.t-internal.com> References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> <542C3367.2090801@alum.mit.edu> In-Reply-To: <542C3367.2090801@alum.mit.edu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/nNZ8JuFdMCAFpM-1QUylWEfS2Ac Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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, 02 Oct 2014 13:26:51 -0000 Thank you Paul, I will take the sentence using "multiplex". Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: dispatch [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul > Kyzivat > Gesendet: Mittwoch, 1. Oktober 2014 19:01 > An: dispatch@ietf.org > Betreff: Re: [dispatch] draft-jesske-dispatch-forking-answer- > correlation-01: comments >=20 > I generally agree with Brett. (I usually do.) >=20 > One comment: >=20 > On 10/1/14 12:04 PM, Brett Tate wrote: >=20 > > "To improve interoperability with devices which do not support > > forking, a service provider shall have the possibility to use a B2BUA > > to correlate multiple dialogs into a single dialog." >=20 > Instead of "correlate", I suggest "multiplex": >=20 > "To improve interoperability with devices which do not support forking, > a service provider shall have the possibility to use a B2BUA to > multiplex multiple downstream dialogs into a single dialog toward the > caller." >=20 > There is substantially more to do than simply correlate. >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Oct 2 13:59:03 2014 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 AF1D61ACD52 for ; Thu, 2 Oct 2014 13:59:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Rhof5WV9ghGY for ; Thu, 2 Oct 2014 13:58:59 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865B51ACD54 for ; Thu, 2 Oct 2014 13:58:38 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-04v.sys.comcast.net with comcast id yLwY1o0022D5gil01LydrH; Thu, 02 Oct 2014 20:58:37 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-06v.sys.comcast.net with comcast id yLyc1o00R1KKtkw01LydvD; Thu, 02 Oct 2014 20:58:37 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s92KwaR5019428; Thu, 2 Oct 2014 16:58:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s92Kwa3a019427; Thu, 2 Oct 2014 16:58:36 -0400 Date: Thu, 2 Oct 2014 16:58:36 -0400 Message-Id: <201410022058.s92Kwa3a019427@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <542C3367.2090801@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <82a8083a078209c80187a46304ff5532@mail.gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB6EC366@HE113667.emea1.cds.t-internal.com> <542C3367.2090801@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412283517; bh=7hmaCWB/tzeypNlNIJdqdxwWwvO6+rB1dAjja+BIOP0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Ges4ptpPrRXFzbkl36vmXf1hIRl5ujmz/qYTdC15uaJ2HL7qvLiIhP2sxrx/S3Ak4 dUnl7H76RrCALAW+32YZRY+h1xSk8ZLan4fZwybO2HGYttNCLOJpIubLpb7HcM9p94 dlib8jjHK8VQ3trhPu2FX/br19/IuAjkuCnQD+Sqef72pyUOaUFpYiOt6xHGvfVRZz 5obF8yUShpgtjLShkZ94RjMxHmbguzohpxhB57XAl0i+QqBVKIXsS7a1v1We1A/g0U /JJ2LLcgjCaMIhHJaEkY1OeJQ+82xWUlqlb5Rb0/5FBOc9+hMzXsQg0ztO3mLf7KVI /itNyFv1aYx/Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/D9SYgVy9MYrD8Dmg5N61KAcWXaM Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments 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, 02 Oct 2014 20:59:01 -0000 > From: Paul Kyzivat > > "To improve interoperability with devices which do not support forking, a > > service provider shall have the possibility to use a B2BUA to correlate > > multiple dialogs into a single dialog." > > Instead of "correlate", I suggest "multiplex": This is an important change. Normally the term "answer correlation" describes how the UAC determines which RTP streams correspond to which 1xx responses it receives. But if the purpose of this draft is to describe how a B2BUA can multiplex multiple early dialogs so that the UAC does not have to be aware of them, the draft should also describe in detail the considerations which apply to media streams. E.g., if the UAC cannot process multiple early dialogs, would it be able to process multiple early media streams? I expect that in this situation, the B2BUA would be expected to multiplex the media in some manner, and we should describe what the constraints are for doing that. Dale From nobody Fri Oct 3 02:58:39 2014 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 304DA1AD021 for ; Fri, 3 Oct 2014 02:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 Q2KRo4s_gjyj for ; Fri, 3 Oct 2014 02:58:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2D21AD01B for ; Fri, 3 Oct 2014 02:58:37 -0700 (PDT) Received: from 132-177-252-46.ip.sipit.net ([132.177.252.46]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s939wWj6070688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Fri, 3 Oct 2014 04:58:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [132.177.252.46] claimed to be 132-177-252-46.ip.sipit.net Message-ID: <542E734A.4040605@nostrum.com> Date: Fri, 03 Oct 2014 11:58:34 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/uJEbCKOoHN1Zrv8q4EKwGBiGF1c Subject: [dispatch] SIPit 31 Summary 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, 03 Oct 2014 09:58:38 -0000 We had a great event at SIPit 31. The summary is available at RjS From nobody Fri Oct 3 09:19:27 2014 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 145481A0123 for ; Fri, 3 Oct 2014 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, 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 dS6xVcO8OYM7 for ; Fri, 3 Oct 2014 09:19:21 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E041A0379 for ; Fri, 3 Oct 2014 09:19:20 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id q1so1330571lam.22 for ; Fri, 03 Oct 2014 09:19:19 -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:cc:content-type; bh=FGPdxLOIZKtc2s9GYNCwjODcMETHwOYOy8EsOwCk+zA=; b=DdyFm4eb3c1QKEQQJtTyKP4pA3kwQBhNJGnl6vyA7Mqun6RS/8SoowF+mvQkb6P2FH 7rHHaTDqv2jiuVmlTeWWnpVBy/+tv4WQ+Te/xjj9I3YvKOdoJYfRvRHvOfrtMfg+kHA4 S6clYu2dxlz1XWzXe5ZCO9l5wqCP1o/mNGjCQh7WTIQh+MF+0nDff47h04i7nHtCjwSp QB0Y+TjNTsuOHRIyIn3cKH5Ls9YNY+ZmBTW7IYnEsT/Ok+BIVglhdsn8a/+foKhXQMUU wgPgEHDLnnm/QTcChVrQ7bhwhshOtXLldv/21YoAXGFdKTr+m+rODx3O00iK2hFcaog0 gY0Q== MIME-Version: 1.0 X-Received: by 10.112.4.33 with SMTP id h1mr6466314lbh.67.1412353159448; Fri, 03 Oct 2014 09:19:19 -0700 (PDT) Received: by 10.25.42.18 with HTTP; Fri, 3 Oct 2014 09:19:19 -0700 (PDT) Date: Fri, 3 Oct 2014 11:19:19 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=bcaec52be6a75dd06105048718ac Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6uD2lrG6y2I-g_-ddLLFC5jA8no Cc: Cullen Jennings Subject: [dispatch] DISPATCH topics for IETF-91 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, 03 Oct 2014 16:19:23 -0000 --bcaec52be6a75dd06105048718ac Content-Type: text/plain; charset=UTF-8 Hi all, Based on WG discussions and consultation with the ADs, the following topics are proposed for discussion at the DISPATCH WG session at the IETF-91 meeting: 1) http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-00 Mailing list discussion: http://www.ietf.org/mail-archive/web/dispatch/current/msg05625.html 2) http://www.ietf.org/internet-drafts/draft-procter-dispatch-outbound-discovery-00.txt Mailing list discussion: http://www.ietf.org/mail-archive/web/dispatch/current/msg05589.html Continued discussion on these topics prior to the f2f meeting will be helpful in ensuring we can make decisions in the f2f meeting. We'll post an agenda once the IETF agenda is published. Regards, Mary & Cullen --bcaec52be6a75dd06105048718ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Based on =C2=A0WG discussions = and consultation with the ADs, the following topics are proposed for discus= sion at the=C2=A0DISPATCH=C2=A0WG session at the IETF-91 meeti= ng:



2) =C2=A0http://www.ietf.org/internet-drafts/d= raft-procter-dispatch-outbound-discovery-00.txt=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0

Continued discussio= n on these topics prior to the f2f meeting will be helpful in ensuring we c= an make decisions in the f2f meeting.

We'll post an ag= enda once the IETF agenda is published. =C2=A0

Regards,<= /div>
Mary & Cullen
--bcaec52be6a75dd06105048718ac-- From nobody Mon Oct 13 09:55:59 2014 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 D8B5C1A001E; Mon, 13 Oct 2014 09:55:55 -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 Tz449I3GHWGe; Mon, 13 Oct 2014 09:55:53 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A431A1AF1; Mon, 13 Oct 2014 09:55:52 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so6647960lbv.40 for ; Mon, 13 Oct 2014 09:55:50 -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=NGaZcSPFCK8P+o6gDHoU3TWScrVIX5+FkSb0/azPe4A=; b=YvJ8+Bkq2+KwbqKIXAOwRRV9IOBpD9b8OWLwprtaaU8Ok4mB8FugDKRGOiQnjbVDNS a2tsJUXd9yG10OogXXof1TUWQa2L3Zy/T1plAJEY5i/uOlZTMxkvbNkYxOGk9xLN1eNc pgUCmaH8tV5ptxenXMGBXa7nEb06RdVhznFKlUfEechIsOtxn+OhEGv2pcbYsLGp3ZEQ 4sctZu5R6suObgzJekSZ0gfuH6GJ8estB3jib6Jh3w0luXXXnHl521SRI5zjc1PsuBya HRpUvXJk6J+ZhSRbCnxM9y9qF0qWjYAvIcOHqUGO2Tg4Sjja7FE92RjE5zOGPCoQDpJw 5WVw== MIME-Version: 1.0 X-Received: by 10.153.4.11 with SMTP id ca11mr25522847lad.24.1413219350600; Mon, 13 Oct 2014 09:55:50 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Mon, 13 Oct 2014 09:55:50 -0700 (PDT) In-Reply-To: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> References: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 11:55:50 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH Content-Type: multipart/alternative; boundary=001a11342f1661dfee050550c50d Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/rmiqEgrDZ-AWEYf_LIYaWYd0IIE Subject: [dispatch] Fwd: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 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, 13 Oct 2014 16:55:56 -0000 --001a11342f1661dfee050550c50d Content-Type: text/plain; charset=UTF-8 Just in case you haven't seen this elsewhere. They are asking for more nominations for the RAI AD position. Even if you don't nominate someone, it's extremely useful for Nomcom to get feedback on the nominees as well as the area in general. Regards, Mary - as a past Nomcom chair that knows how hard this task is ---------- Forwarded message ---------- From: NomCom Chair 2014 Date: Mon, Oct 13, 2014 at 10:05 AM Subject: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 To: Working Group Chairs Cc: ietf@ietf.org {apologies if you see this multiple times} The 2014-15 Nominating Committee (Nomcom) will still accept nominations from now until October 20, 2014 AT MIDNIGHT EDT for the IESG positions of Area Director for: - RAI - 2 - OAM - 1 - TSV - 1 - INT - 2 - GEN - 1 (IETF Chair) area. While in each case we have an incumbent who is willing to continue, and in two of those areas we have one additional candidate; we would dearly like to be be selecting from a slightly larger field. It is impossible for the NOMCOM to be sure that we have the best candidate if we have only one possible candidate. Even if the you think the incumbent is the best person for the job, it is important, if only for succession planning, to know who else could do the job. At least one of these incumbents have said clearly that this really has become a 50% commitment of a 40 hour week, i.e. it is possible to do significant work on a "day job" For the above five positions there are 9 nominees who have neither accepted nor declined. If you nominated someone and their name does not appear at: https://datatracker.ietf.org/nomcom/2014/private/feedback/ that's because they have either declined, or they have not indicated things one way or other. Perhaps they are still deciding, or perhaps they never got the email, you can help the nomcom by confirming with them. ==== Nominations may be made by selecting the Nominate link at the top of the Nomcom 2014 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2014/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } Nominations may also be made by email to nomcom14@ietf.org. If use email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! NomCom 2014-15 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination, than put one in late. We've set the questionnaire submission deadline for October 25, 2014. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC: Randy Bush IAB: Joel Halpern* Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick* (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) *- known to have decline to run again. PLEASE NOTE THAT IT IS LIKELY THAT APPLICATIONS AREA WILL NOT BE FILLED AT THE IESG REQUEST. Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2014/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom14@ietf.org. Thank you for your help in identifying qualified nominees! Michael Richardson Nomcom Chair 2014-15 nomcom-chair-2014@ietf.org, mcr+nomcom@sandelman.ca --001a11342f1661dfee050550c50d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just in case you haven't seen this elsewhere.=C2=A0 Th= ey are asking for more nominations for the RAI AD position.=C2=A0 Even if y= ou don't nominate someone, it's extremely useful for Nomcom to get = feedback on the nominees as well as the area in general.

Regards,
Mary
- as a past Nomcom chair that knows how = hard this task is

---------- Forwa= rded message ----------
From: NomCom Chair= 2014 <nomcom-chair-2014@ietf.org>
Date: Mon, Oct 13, 2014 at = 10:05 AM
Subject: NOMCOM 2014 - nominations extended for RAI, OAM, TSV a= nd INT - Oct 20
To: Working Group Chairs <wgchairs@ietf.org>
Cc: ietf@ietf.org


{apologies if you see this multiple times}
The 2014-15 Nominating Committee (Nomcom) will still accept nominations
from now until October 20, 2014 AT MIDNIGHT EDT for the IESG positions
of Area Director for:
=C2=A0 =C2=A0- RAI - 2
=C2=A0 =C2=A0- OAM - 1
=C2=A0 =C2=A0- TSV - 1
=C2=A0 =C2=A0- INT - 2
=C2=A0 =C2=A0- GEN - 1=C2=A0 =C2=A0 (IETF Chair)

area.=C2=A0 While in each case we have an incumbent who is willing to conti= nue,
and in two of those areas we have one additional candidate; we would dearly=
like to be be selecting from a slightly larger field.

It is impossible for the NOMCOM to be sure that we have the best candidate<= br> if we have only one possible candidate. Even if the you think the incumbent= is the best
person for the job, it is important, if only for succession planning, to kn= ow who else
could do the job.

At least one of these incumbents have said clearly that this really has
become a 50% commitment of a 40 hour week, i.e. it is possible to do
significant work on a "day job"

For the above five positions there are 9 nominees who have neither
accepted nor declined.=C2=A0 If you nominated someone and their name does n= ot
appear at:
=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/nomco= m/2014/private/feedback/

that's because they have either declined, or they have not indicated things one way or other.=C2=A0 =C2=A0Perhaps they are still deciding, or pe= rhaps
they never got the email, you can help the nomcom by confirming with them.<= br>
=3D=3D=3D=3D

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2014 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2014/nominate/

=C2=A0 {Note that nominations made using the web tool require an ietf.org
=C2=A0 =C2=A0datatracker account. You can create a datatracker ietf.org account
=C2=A0 =C2=A0if you don't have one already by visiting the following UR= L:
=C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/accounts/create/ }
Nominations may also be made by email to nomcom14@ietf.org.

If use email, please include the word "Nominate" in the Subject a= nd
indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you
are making the nomination. If you wish to nominate someone via email
for more than one position, please use separate emails to do so.

Self-nomination is welcome!

NomCom 2014-15 will follow the policy for "Open Disclosure of Willing<= br> Nominees" described in RFC 5680.=C2=A0 As stated in RFC 5680: "Th= e list of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists.=C2=A0 In all other ways, the
confidentiality requirements of RFC 3777/BCP10 remain in effect.=C2=A0 All<= br> feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.

Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission,<= br> as it is easier to decline the nomination, than put one in late.
We've set the questionnaire submission deadline for October 25, 2014.
The Nomcom appoints individuals to fill the open slots on the
IAOC, the IAB, and the IESG. The list of people and posts whose terms
end with the March 2015 IETF meeting, and thus the positions for which
this Nomcom is responsible, follows:

IAOC:
Randy Bush

IAB:
Joel Halpern*
Russ Housley
Eliot Lear
Xing Li
Andrew Sullivan
Dave Thaler

IESG:
Pete Resnick* (Applications)
Ted Lemon (Internet)
Joel Jaeggli (Operations and Management)
Richard Barnes (RAI)
Adrian Farrel* (Routing)
Stephen Farrell (Security)
Spencer Dawkins (Transport)
Jari Arkko (Gen)

*- known to have decline to run again.

PLEASE NOTE THAT IT IS LIKELY THAT APPLICATIONS AREA WILL NOT
BE FILLED AT THE IESG REQUEST.

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF, and also, please consider accepting a nomination.=C2=A0 You'l= l
find extensive information about specific positions, developed by
the IAB, IESG, and IAOC, under individual tabs at:

=C2=A0 https://datatracker.ietf.org/nomcom/2014/requirements/=

In addition to nominations, the Nomcom seeks community input on
the positions themselves.=C2=A0 We need and welcome the community's
views and input on the jobs within each organization. If you
have ideas on the positions' responsibilities (more, less,
different), please let us know.

Please send suggestions and feedback about this to nomcom14@ietf.org.

Thank you for your help in identifying qualified nominees!

Michael Richardson
Nomcom Chair 2014-15
nomcom-chair-2014@ietf.org, mcr+nomcom@sandelman.ca=


--001a11342f1661dfee050550c50d-- From nobody Mon Oct 13 10:57:29 2014 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 C807C1A7000; Mon, 13 Oct 2014 10:57:27 -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 Po143YOrAfBd; Mon, 13 Oct 2014 10:57:26 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA40F1A8546; Mon, 13 Oct 2014 10:56:50 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so6859409lbv.19 for ; Mon, 13 Oct 2014 10:56:49 -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=CiTxjRy6MAjs3IbiNeHyrcdYSS54aw/Wi+nse0KbE+8=; b=p9ilDZwePM6DCnyblWxBzB5mqJjNeeDNV7xcf08pYHgzQTb1WtWGwSuCKrUp652HR0 54GzBTD73cxzryaLDwSsP5eki7YRsQ8qaEeHzZKzpaZbBBPf1cDqDKrPYMmUkeKBRejt yQ1s3HU9aYHJPkDeujNowsphZEOOnOgBa5rUUNnXa/mUyD0QTG/L2a/rg5r0fmi18wx4 pH5Y0F/EWgm13JitrX+DAbq/OyEXYn+GdFIgJQPIAUHDVQIi6QvUtKgLHXocE+/q9flb qnqrVviXAYIibUha3t/HRh/VuCzixCp/NZUknwJEzKscgbq/XB4ObluvkWwQed/DtDr7 zWGQ== MIME-Version: 1.0 X-Received: by 10.112.85.138 with SMTP id h10mr49651lbz.33.1413223008990; Mon, 13 Oct 2014 10:56:48 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Mon, 13 Oct 2014 10:56:48 -0700 (PDT) In-Reply-To: <20443.1413220517@sandelman.ca> References: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> <20443.1413220517@sandelman.ca> Date: Mon, 13 Oct 2014 12:56:48 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH Content-Type: multipart/mixed; boundary=001a11347168708e9c0505519f0b Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/5M3EGmw0mwgU3VxQyY1X1cDCXF8 Subject: [dispatch] Fwd: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 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, 13 Oct 2014 17:57:28 -0000 --001a11347168708e9c0505519f0b Content-Type: multipart/alternative; boundary=001a11347168708e960505519f09 --001a11347168708e960505519f09 Content-Type: text/plain; charset=UTF-8 FYI...there was an error in the link to provide feedback. Here's the correct one. Mary. ---------- Forwarded message ---------- From: Michael Richardson Date: Mon, Oct 13, 2014 at 12:15 PM Subject: Re: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 To: Working Group Chairs , ietf@ietf.org NomCom Chair 2014 wrote: > For the above five positions there are 9 nominees who have neither > accepted nor declined. If you nominated someone and their name does > not appear at: > https://datatracker.ietf.org/nomcom/2014/private/feedback/ This is the correct URL: https://datatracker.ietf.org/nomcom/2014/feedback/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --001a11347168708e960505519f09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...there was an error in the link to provide feedback.= =C2=A0 Here's the correct one.

Mary.

<= div class=3D"gmail_quote">---------- Forwarded message ----------
From: = Michael Richardson <= mcr+ietf@sandelman.ca>
Date: Mon, Oct 13, 2014 at 12:15 PM
Subject: Re: NOMCOM 2014 - n= ominations extended for RAI, OAM, TSV and INT - Oct 20
To: Working Group= Chairs <wgchairs@ietf.org>,= ietf@ietf.org



NomCom Chair 2014 <nomcom-= chair-2014@ietf.org> wrote:
=C2=A0 =C2=A0 > For the above five positions there are 9 nominees who ha= ve neither
=C2=A0 =C2=A0 > accepted nor declined.=C2=A0 If you nominated someone an= d their name does
=C2=A0 =C2=A0 > not appear at:
=C2=A0 =C2=A0 > https://datatracker.ietf.org/nomcom/2014/p= rivate/feedback/

This is the correct URL:
=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/nomcom/2014/feedback= /

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




--001a11347168708e960505519f09-- --001a11347168708e9c0505519f0b Content-Type: application/pgp-signature Content-Disposition: attachment Content-Transfer-Encoding: base64 X-Attachment-Id: c86e1fee02b644a0_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaVFFVkF3VUJWRHdJcElDTGNQdmQwTjFsQVFJendnZjhEV3BzaksyMi9QZXRv ME5QSk1Fb1V2QVdSRWlsbUN2Kw0KWW54TXlTTUpZTlVJZ21hSll2MER0ZStqMW9JWDh4ZXBOSzRt ZmMwNlNhRjNzZHpOelEzOTFrQnhDWDcyNjJWSg0KbklRaSt2cUVRVXdWZmxDT1RXekZYd2xTYm55 cmJxbWd2akplWnl3SFA3NXROTWRtajhDcnVvNW9UYUk2V3RvUw0Kck44dTlPS3Q3MGxnbFpGQXFq Rm1QaXdDUFo2QWtXRVprc1NzTmFqQUlPQnVXT252YXBVSElmRzB3aGRpbWIrUw0KNG1McjUwOFFv RTkzVzRQUHluank0d253b3JTRVJJQnc2T2pRM1BEYjJuRTVOdXNPcFBkUkkwQnBYNlVrZVFQWQ0K Zk1STmJodXAzL2EvMlBNbXdTc21VWERVSHRlZUZlaE1iTCtORFAxenl4VXQ2clNQbDF0blpBPT0N Cj1xWTZ5DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0= --001a11347168708e9c0505519f0b-- From nobody Wed Oct 15 13:13:12 2014 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 19A741A879F for ; Wed, 15 Oct 2014 13:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ_OSDPWYp1j for ; Wed, 15 Oct 2014 13:13:07 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 1DC5C1A88CD for ; Wed, 15 Oct 2014 13:13:07 -0700 (PDT) Received: (qmail 13622 invoked by uid 0); 15 Oct 2014 20:13:06 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 15 Oct 2014 20:13:06 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 3eD11p0091MNPNq01eD4cs; Wed, 15 Oct 2014 20:13:04 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=doUQZJtgAAAA:8 a=9bOKTyGbAAAA:8 a=M0OflfRGAAAA:8 a=ll-iCDY8AAAA:8 a=hea1mOaGJMCzGTMmGbgA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=5eIJMYd8ObsA:10 a=yDlVmugRoooA:10 a=GBsgy2rA9acA:10 a=0CJEY8SJ_7AA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=Yo_weSMKip8A:10 a=vRAbILRZcFsA:10 a=N3zA0ylTc-fSNlXY1MkA:9 a=tg8yzmqARRgiNWYa:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=w19MAODG12V9eUNfJUkkBkZXTEXWUqWvG1+fUBCQau4=; b=QePj9xCN/dZqVBw3zVc2fM0FfLdF5Wng/qulxEamFJrWTANtSb7o2qS61SfYHsO41YCMaSpiQFQZdEwGb2W8cDcr5HFOh4NKs+sFsMH1eSje4SWVa2EH8G6BjNzEBogQ; Received: from [72.66.64.164] (port=54703 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeUwP-0001VT-Kx; Wed, 15 Oct 2014 14:13:01 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 16:12:56 -0400 From: Richard Shockey To: , , Message-ID: Thread-Topic: ATIS and SIP Forum Network to Network Interface work in progress documents Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3496234381_875618" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/j43Gi_M4k2ddPY7YDQRwq7TEf5o Subject: [dispatch] ATIS and SIP Forum Network to Network Interface work in progress documents 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 Oct 2014 20:13:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3496234381_875618 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable As some of you know the SIP Forum and ATIS have been cooperating for the past year on a series of profile documents for SIP to facilitate all IP interconnection among service providers. The Task Force has agreed to make a snapshot of the documents available to the larger carrier and SIP community to invite informed technical comments. These are still a =B3work in progress=B2 . For those of you in the United States this work has taken on a larger significance since it has the attention of the United States Federal Communications Commission as was called out in a recent speech by Commissio= n Chairman Tom Wheeler. https://apps.fcc.gov/edocs_public/attachmatch/DOC-329767A1.pdf ****** The IP-Network to Network Interface (NNI) Joint Task Force , a cooperative effort between the ATIS and the SIP Forum, is seeking public comment on two draft documents: =20 1. IP Interconnection Profile. The IP-NNI Profile Specification defines a reference architectureand specifications for both the protocol an= d media as it appears =B3on-the-wire=B2 at interconnect points. The specifications reference commonly used IETF, 3GPP, and other related industry specifications and identify protocol extensions and capability information needed for all-IP telephony peering. 2. IP Interconnection Routing Report. The IP-NNI Routing Technical Report documents mechanisms for identifying the preferred IP interconnectio= n point for a given TN. This report presents multiple views of current IP interconnection mechanisms based on aggregate PSTN constructs, interim solutions based on all-IP routing using a per-TN registry, and a consideration of hybrid approaches across both mechanisms during the transition to all-IP. =20 Members of the IETF SIP Community may access the document directly here. http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,153/I= t emid,261/ Members of ATIS may also Access the documents at: http://access.atis.org/apps/org/workgroup/ipnni/download.php/18837/latest(f= o r ATIS members) or http://access.atis.org/apps/group_public/document.php?document_id=3D18837&wg_= a bbrev=3Dipnni (public access). =20 Providing Feedback: Written input, technical feedback only, is requested b= y October 29, 2014. However, in light of the short timeframe, input will be accepted until December 1, 2014. Submit comments to the Task Force via its mailing list. To do this, individuals must first be registered as a SIP Forum Participant Member (Free) here:http://www.sipforum.org/component/option,com_advanced_registration/tas= k ,register/.=20 When completed, subscription to the NNI Task Force mailing list can be performed at: http://sipforum.org/mailman/listinfo/nni. =20 For further information on the IP Network to Network Interface (NNI) Joint Task Force and these above-referenced documents, please contact me or Jim McEachern, Senior Technical Consultant, ATIS jmceachern@atis.org or me at the contact information listed below. =20 =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us Www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 --B_3496234381_875618 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable



The Task Fo= rce has agreed to make a snapshot of the documents available to the larger c= arrier and SIP community to invite informed technical comments.  These = are still a “work in progress” .


For those of you in the United States= this work has taken on a larger significance since it has the attention of = the United States Federal Communications Commission as was called out in a r= ecent speech by Commission Chairman Tom Wheeler.




The IP-Network to Ne= twork Interface (NNI) Joint Task Force, a cooperative effort between the= ATIS and the SIP Forum, is seeking public comment on two draft documents:

 

1.      IP Interconnection Profile.  The IP-NNI Profile Specification defines a refere= nce architectureand specifications for both the protocol and media as= it appears “on-the-wire” at interconnect points.  The spec= ifications reference commonly used IETF, 3GPP, and other related industry sp= ecifications and identify protocol extensions and capability information nee= ded for all-IP telephony peering.

2.=   &n= bsp;   IP Interconnection= Routing Report.  The IP-NNI Routing Tech= nical Report documents mechanisms for identifying the preferred IP interconn= ection point for a given TN. This report presents multiple views of current = IP interconnection mechanisms based on aggregate PSTN constructs, interim so= lutions based on all-IP routing using a per-TN registry, and a consideration= of hybrid approaches across both mechanisms during the transition to all-IP= . 



 

Members of the IETF SIP Community may access the document directly here.=



http://www.sipforum.org/component= /option,com_docman/task,cat_view/gid,153/Itemid,261/


Members of ATIS may also Access the documents at: http://access.atis.org/apps/org/workgroup/ipnni/download.ph= p/18837/latest(for ATIS members) or

http://access.atis.org/apps/group_public/document.php?document_id=3D18837&a= mp;wg_abbrev=3Dipnni (public access).

 

Providing Feedback:&nbs= p; Written input, technical feedback only, is requested by = October 29, 2014. However, in light of the short timeframe, input will be ac= cepted until December 1, 2014.  Submit comments to the Task Force via i= ts mailing list. To do this, individuals must first be registered as a SIP F= orum Participant Member (Free) 


here:http://www.sipforum.org/component/option,com_advanced_regi= stration/task,register/. 


&nbs= p;When completed, subscri= ption to the NNI Task Force mailing list can be performed at: http://sipf= orum.org/mailman/listinfo/nni= .

&n= bsp;

For further information on the IP Network to Network Interface (NNI= ) Joint Task Force and these above-referenced documents, please contact me o= r Jim McEachern, Senior Technical Consultant, ATIS jmceachern@atis.org or me a= t the contact information listed below.

 

— 

Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
Www.sipforum.org<= /font>
richard<at&g= t;shockey.us
Sk= ype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

--B_3496234381_875618-- From nobody Sun Oct 26 11:33:06 2014 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 EFACC1A0383 for ; Sun, 26 Oct 2014 11:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EfJnB-G5ECm4 for ; Sun, 26 Oct 2014 11:33:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678A81A037F for ; Sun, 26 Oct 2014 11:33:01 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 8E98C1B8156 for ; Sun, 26 Oct 2014 19:32:59 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 75E77C804F for ; Sun, 26 Oct 2014 19:32:59 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 19:32:58 +0100 From: To: "dispatch@ietf.org" Thread-Topic: New draft-mohali-dispatch-cause-for-service-number-translation-00 Thread-Index: Ac/xPlgteNIAhbPWR8mRQuvaoqH0OA== Date: Sun, 26 Oct 2014 18:32:59 +0000 Message-ID: <6892_1414348379_544D3E5B_6892_12051_1_8B970F90C584EA4E97D5BAAC9172DBB8142A062F@PEXCVZYM12.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.197.38.4] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8142A062FPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.26.113324 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/EtsYFG2hnbBOepTX1Czn75Jyf7c Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-translation-00 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, 26 Oct 2014 18:33:05 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8142A062FPEXCVZYM12corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have submitted a new draft, draft-mohali-dispatch-service-number-translat= ion-00. This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB8142A062FPEXCVZYM12corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have submitted a new draft= , draft-mohali-dispatch-service-number-translation-00.

 

This draft defines a new val= ue for the SIP URI parameter "cause", which can be used to associ= ate a SIP URI to a service access number that has been translated by a spec= ific application.

 

Abstract: =

RFC4458 defines a "caus= e" URI parameter as having predefined values for Redirecting reasons a= s a mapping from ITU-T Q.732.2-5 Redirecting Reasons.  The "cause= " URI parameter is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header defined in RFC7044 that must be a= dded in retargeted requests. This specification creates a new predefined va= lue for cases when the retargeting is caused by a specific service action l= eading to a called number translation. This document updates RFC4458.

 

This draft is needed for 3GP= P, but we’ve tried to write it in a way so that it can also be applie= d to other environments.

 

A first version of the draft= can be seen under:

h= ttp://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service-= number-00.txt

 

This version is a very first= version and for sure needs improvement.

Your comments are welcome.

 

Regards,

Marianne Mohali

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8142A062FPEXCVZYM12corpo_-- From nobody Mon Oct 27 14:39:35 2014 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 6A6FA1A002A for ; Mon, 27 Oct 2014 14:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkCyr4m8Itut for ; Mon, 27 Oct 2014 14:39:26 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E35D1A0010 for ; Mon, 27 Oct 2014 14:39:11 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s9RLdAcA007235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 17:39:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1414445950; bh=IvokfOiy50rCyOF635UjDEzhPZEWl3TjibBZT4T5Sv4=; h=From:To:Subject:Cc:Date:Message-Id:Reply-To:Mime-Version: Content-Type:Content-Transfer-Encoding; b=XzpWWOaNOYj1EN2xqywNGV9uu0UZlcXZMXXVpwgBT2ihA2oDAiCidQ63PToLmwPJu N4XDvD6vyl6L3ICZZqjmWo64A6jFOLXXxuwu/jab8Ghfy+khYoX+3i7K3xqKl6vPXx Vu7iLZqBRrF+yF0WzE6Qd6z9qmwBMHpPtlN460j0= From: "Paul E. Jones" To: "avtcore@ietf.org" Date: Mon, 27 Oct 2014 21:39:13 +0000 Message-Id: User-Agent: eM_Client/6.0.21034.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/E_HumKjSV3sQ8BJNwwTTzQUQD6M Cc: dispatch@ietf.org Subject: [dispatch] draft-jones-avtcore-private-media-reqts-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:39:30 -0000 Folks, Just as an FYI, we prepared (and I just submitted) the subject I-D for=20 discussion in avtcore. Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 10/27/2014 5:33:48 PM Subject: I-D Action: draft-jones-avtcore-private-media-reqts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Requirements for Private Media in a Switched=20 Conferencing Environment Authors : Paul E. Jones Nermeen Ismail David Benham Nathan Buckles John Mattsson Yi Cheng Richard Barnes Filename : draft-jones-avtcore-private-media-reqts-00.txt Pages : 15 Date : 2014-10-27 Abstract: This document specifies the requirements for ensuring the privacy and integrity of real-time media flows between two or more endpoints communicating in a switched conferencing environment. This document also provides a high-level overview of switched conferencing in order to establish a common understanding of the goals and objectives of this work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jones-avtcore-private-media-reqts-00 Please note that it may take a couple of minutes from the time of=20 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 From nobody Mon Oct 27 14:43:01 2014 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 4204D1A001C; Mon, 27 Oct 2014 14:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnCRVdzJ5L3G; Mon, 27 Oct 2014 14:42:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D671A006D; Mon, 27 Oct 2014 14:41:39 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s9RLfcbc007397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 17:41:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1414446098; bh=xqszF8FlUCf+cmThW9pkC0Soosyd7SfON9HU1ahi1gA=; h=From:To:Subject:Cc:Date:Message-Id:Reply-To:Mime-Version: Content-Type:Content-Transfer-Encoding; b=ZmkCPB1+tNzSO2bPpSrp24uRzpQs0DDBjONo8+ZrGF6fLb4baUowoVOZPOJsjjtXJ /WNkYWmCQBE/04JZeB9kTIjWyFZw2CicBR/PCvPdK1fRSsr35ImunS+RRTnGPf8RJe XOKhcImV1+pncGHwNDNKtDaia+j9ACORPje7GxaY= From: "Paul E. Jones" To: "avt@ietf.org WG" Date: Mon, 27 Oct 2014 21:41:41 +0000 Message-Id: User-Agent: eM_Client/6.0.21034.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ei6hIgIIbsOPXp0_qcC5Q5PvAs0 Cc: "dispatch@ietf.org" Subject: [dispatch] draft-jones-avtcore-private-media-reqts-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:42:51 -0000 Folks, Just as an FYI, we prepared (and I just submitted) the subject I-D for=20 discussion in avtcore. Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 10/27/2014 5:33:48 PM Subject: I-D Action: draft-jones-avtcore-private-media-reqts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Requirements for Private Media in a Switched=20 Conferencing Environment Authors : Paul E. Jones Nermeen Ismail David Benham Nathan Buckles John Mattsson Yi Cheng Richard Barnes Filename : draft-jones-avtcore-private-media-reqts-00.txt Pages : 15 Date : 2014-10-27 Abstract: This document specifies the requirements for ensuring the privacy and integrity of real-time media flows between two or more endpoints communicating in a switched conferencing environment. This document also provides a high-level overview of switched conferencing in order to establish a common understanding of the goals and objectives of this work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jones-avtcore-private-media-reqts-00 Please note that it may take a couple of minutes from the time of=20 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 From nobody Mon Oct 27 14:52:03 2014 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 B09F91A0120 for ; Mon, 27 Oct 2014 14:51:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 95WDu-j8afky for ; Mon, 27 Oct 2014 14:51:56 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ED01A007B for ; Mon, 27 Oct 2014 14:51:56 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-08v.sys.comcast.net with comcast id 8MrA1p0082LrikM01MrvTL; Mon, 27 Oct 2014 21:51:55 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-12v.sys.comcast.net with comcast id 8Mru1p00Z1KKtkw01MrvnD; Mon, 27 Oct 2014 21:51:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9RLpsTm006600; Mon, 27 Oct 2014 17:51:54 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9RLpsDY006599; Mon, 27 Oct 2014 17:51:54 -0400 Date: Mon, 27 Oct 2014 17:51:54 -0400 Message-Id: <201410272151.s9RLpsDY006599@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: In-reply-to: <6892_1414348379_544D3E5B_6892_12051_1_8B970F90C584EA4E97D5BAAC9172DBB8142A062F@PEXCVZYM12.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) References: <6892_1414348379_544D3E5B_6892_12051_1_8B970F90C584EA4E97D5BAAC9172DBB8142A062F@PEXCVZYM12.corporate.adroot.infra.ftgroup> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414446715; bh=tCLrQe23zRBkt3T1clZGhCDMKlypB9VFDgR7/CPEQv8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Xmv1UlTF1bAZLGRwv0rp49Ubu2ifaAJAPhzy3O45MZCb9QOiryaBF1uLHHh9kXPui XmEDSiV1DMywWDiQDPz0bx7sxbdESw2oWunEukylOhwGbLP8b2LX6QJ8dtYZH1+8yi qb5DOOUMn5Hsnhhkw0RV78otOmJSApsuxF/pnZYMfg/Z1DseX/4B/Ege9YNGtSDmya DoRhrW6dxkse+caojKDeN2PFh+wQuOV9czTJK8hxvB+iNhNEB6Lz3LKH12i/92+NyD gcs/mTXTm+B+gp2Uc5x3PKFZCDWWoDlLWIejc8gIytbWx5aBzg40UMua1ZwXcxo620 VNgLpuO6fdIsg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/V1Vc3NjWBo-DimryhCsn0xiVVJI Cc: dispatch@ietf.org Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-translation-00 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, 27 Oct 2014 21:51:59 -0000 > From: > > I have submitted a new draft, > draft-mohali-dispatch-service-number-translation-00. I have no idea why, but the actual name in the datatracker is "draft-mohali-dispatch-cause-for-service-number-00". Dale From nobody Mon Oct 27 15:01:49 2014 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 0C8F91A0363 for ; Mon, 27 Oct 2014 15:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qvcI_fvlW6cv for ; Mon, 27 Oct 2014 15:01:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422D21A037A for ; Mon, 27 Oct 2014 15:01:02 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id B23D02AC339; Mon, 27 Oct 2014 23:01:00 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 94BFB384061; Mon, 27 Oct 2014 23:01:00 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 23:00:59 +0100 From: To: "Dale R. Worley" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-translation-00 Thread-Index: Ac/xPlgteNIAhbPWR8mRQuvaoqH0OAA8eKSzAAAoB3A= Date: Mon, 27 Oct 2014 22:01:00 +0000 Message-ID: <16949_1414447260_544EC09C_16949_2137_1_8B970F90C584EA4E97D5BAAC9172DBB8142A0782@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <6892_1414348379_544D3E5B_6892_12051_1_8B970F90C584EA4E97D5BAAC9172DBB8142A062F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <201410272151.s9RLpsDY006599@hobgoblin.ariadne.com> In-Reply-To: <201410272151.s9RLpsDY006599@hobgoblin.ariadne.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.27.203025 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/JvzXvv7Loa3v-flAymnY0PbBIMA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-translation-00 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, 27 Oct 2014 22:01:44 -0000 Hi Dale, Indeed, there is a mistake in the email I sent. I had to change the name of= the draft which was too long. The name of the submitted draft is draft-mohali-dispatch-cause-for-service-= number-00 Sorry for the confusion. Best regards, Marianne -----Message d'origine----- De=A0: Dale R. Worley [mailto:worley@ariadne.com]=20 Envoy=E9=A0: lundi 27 octobre 2014 22:52 =C0=A0: MOHALI Marianne IMT/OLN Cc=A0: dispatch@ietf.org Objet=A0: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number= -translation-00 > From: >=20 > I have submitted a new draft, > draft-mohali-dispatch-service-number-translation-00. I have no idea why, but the actual name in the datatracker is "draft-mohali= -dispatch-cause-for-service-number-00". Dale ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Oct 28 07:36:24 2014 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 F36DD1A8980 for ; Tue, 28 Oct 2014 07:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju_kVcMrcq61 for ; Tue, 28 Oct 2014 07:36:19 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAFC1A899B for ; Tue, 28 Oct 2014 07:36:18 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail31.telekom.de with ESMTP; 28 Oct 2014 15:36:15 +0100 X-IronPort-AV: E=Sophos;i="5.04,802,1406584800"; d="scan'208";a="689271708" Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 28 Oct 2014 15:36:15 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 28 Oct 2014 15:36:15 +0100 From: To: Date: Tue, 28 Oct 2014 15:36:14 +0100 Thread-Topic: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-02.txt Thread-Index: Ac/yBKUlczw/LMw7T7C+BV7QbO3lHwAtsA/w Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FF223A21@HE113667.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/gXIC8WnzV4rVwh5mJwdF-lsibxU Subject: [dispatch] WG: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-02.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, 28 Oct 2014 14:36:22 -0000 RGVhciBhbGwsDQp5ZXN0ZXJkYXkgSSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhl IGRyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi4NCkkgaGF2 ZSB0cmllZCB0byBpbmNsdWRlIGFsbCBjb21tZW50cyBJIHJlY2VpdmVkIHNvIGZhciBhbmQgYWRk ZWQgc29tZSBuZXcgQ2FsbCBmbG93cyBmb3IgZGlzY3Vzc2lvbi4NCg0KVGhlIGRyYWZ0IGlzIGRl c2NyaWJpbmcgd2hlcmUgYSBCMkJVQSBwcm92aWRlcyBhIGNvcnJlbGF0aW9uIG1lY2hhbmlzbSB0 byBtYWludGFpbiBhIHNpbmdsZSBkaWFsb2cgYmV0d2VlbiBVQUMgYW5kIEIyQlVBIHdoaWxlIGJl dHdlZW4gQjJCVUEgYW5kIFVBUzEsIFVBUzIsIFVBUzMgZWN0LiBtdWx0aXBsZSBlYXJseSBkaWFs b2dzIGFyZSBleGlzdGluZy4NCldlIHNlZSB0aGUgbmVlZCBmb3Igc3VjaCBhIHNvbHV0aW9uIGR1 ZSB0byBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbm90IHVuZGVyc3RhbmRpbmcgbXVsdGlwbGVz IGVhcmx5IGRpYWxvZ3Mgb3IgaGFuZGxpbmcgaXQgaW4gYSB3cm9uZyBtYW5uZXIuIE1vcmUgcHJv YmxlbWF0aWMgYXJlIHRoZSBjYXNlcyB3aGVyZSBwcmVjb25kaXRpb25zIGFuZCBlYXJseSBtZWRp YSBpcyB1c2VkLg0KDQpDb21tZW50cyBhbmQgaW1wcm92ZW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpU aGFuayB5b3UgYW5kIEJlc3QgUmVnYXJkcw0KDQpSb2xhbmQNCg0KLS0tLS1VcnNwcsO8bmdsaWNo ZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IE1vbnRhZywgMjcuIE9rdG9iZXIg MjAxNCAxNzozOQ0KQW46IEplc3NrZSwgUm9sYW5kOyBKZXNza2UsIFJvbGFuZA0KQmV0cmVmZjog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qZXNza2UtZGlzcGF0Y2gtZm9ya2lu Zy1hbnN3ZXItY29ycmVsYXRpb24tMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi0wMi50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9sYW5kIEplc3NrZSBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1qZXNza2UtZGlzcGF0Y2gt Zm9ya2luZy1hbnN3ZXItY29ycmVsYXRpb24NClJldmlzaW9uOgkwMg0KVGl0bGU6CQlDb3JyZWxh dGlvbiBvZiBtdWx0aXBsZSByZXNwb25zZXMgb2YgZm9ya2VkIElOVklURVMgaW4gQmFjayB0byBC YWNrIFVzZXIgQWdlbnRzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTEwLTI3DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMw0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFu c3dlci1jb3JyZWxhdGlvbi0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1qZXNza2UtZGlzcGF0Y2gtZm9ya2luZy1hbnN3ZXItY29y cmVsYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJlbGF0aW9uLTAyDQpEaWZmOiAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamVzc2tlLWRp c3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJlbGF0aW9uLTAyDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZSBob3cgYSBjb3JyZWxhdGlvbiBvZiBtdWx0aXBsZSByZXNwb25z ZXMgb2YgYQ0KICAgZm9ya2VkIElOVklURSBpbiBCYWNrIHRvIEJhY2sgVXNlciBBZ2VudHMgY2Fu IGFwcGx5Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Oct 30 09:26:15 2014 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 6F4D71A0072 for ; Thu, 30 Oct 2014 09:26:14 -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 Nnoy_1J1ySgp for ; Thu, 30 Oct 2014 09:26:12 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D381A00F8 for ; Thu, 30 Oct 2014 09:26:04 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-04v.sys.comcast.net with comcast id 9URz1p00B5FMDhs01US4yy; Thu, 30 Oct 2014 16:26:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id 9US31p00M3Ge9ey01US3A1; Thu, 30 Oct 2014 16:26:04 +0000 Message-ID: <5452669B.4050504@alum.mit.edu> Date: Thu, 30 Oct 2014 12:26:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FF223A21@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FF223A21@HE113667.emea1.cds.t-internal.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=1414686364; bh=DczJa3Mk2aaDHjhvUO+djc6HLoSHxVqGP5cR/A+KnaA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=olJgOqd0nfoU5pMdoQJiUDB+4HHQWVbrhrurbTRkmTlQXyu6My6hc7kp1sHpmiSdv Bp4qv76b4yOjLtUKuBjwCx8aj+abnCHRpC0bHxKzcak/U8WOJQwUOKRT+NQY08111V Lmh2jGRw2ieJTsLsxgRxYF4KcIQ4XC883gS4b+lKSWBgQ08kWBrsEuucyVMOgEY4kP 9cAydka8XdMX+4E0mS/NL0OFyxNErKqMhlZy1SQSGgJKrS/Ytq3ao3YuGxWTNMKiNV lgeL/7rBGzy0DzCqAz6IeTreuvqh0pg0WNxsJ4M7bLeuOl79mr54CDyiLZ1F5bqcTX Uj9hiCPzbtfaw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/RCkl80xPzQOd-wuBtbX5To1h-hg Subject: Re: [dispatch] WG: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-02.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: Thu, 30 Oct 2014 16:26:14 -0000 Roland, General comment: I suggest that you label each of the messages in call flows to identify if they contain SDP, and if so which SDP. (That way we can tell which messages contain the same SDP.) Without that it is hard to follow. Section 4.1: I wonder if the example in figure 1 is too "easy". It would be more interesting if it was UAS_3 that returned the 200. (In that case a strategy by the UAC to latch onto the last received SDP in a 1xx, implicitly assuming serial forking, doesn't work.) Section 4.2 In this case you propose hiding many of the 18x responses from the UAC. This assumes there is no important content in them that is of interest to the UAC. But that may not be the case. For instance there are semantic differences between 180, 181, 182, 183. Also, there could be Alert-Info in these that could influence the UAC user interface. What would you do about these? Section 4.3: Each of the updates contains an SDP offer. So the response to each of those updates will contain an answer. One *hopes* that those answers are identical or at least equivalent to the SDP in the initial INVITE. I guess you are assuming that. If that turns out not to be true then things get complicated. I assume your intent is that F22 contains an SDP answer, and that F24 contains equivalent SDP. If so, then update F28 is not needed. (But if the 200 had been received from UAS_3 then it would be.) What SDP, if any, to include in F30 is arguable. Given that an answer has previously been sent in a reliable provisional, whatever it contains should be ignored by the UAC. Technically it should probably contain what was in the first provisional to contain SDP - in this case what was in F8. But that may cause trouble with some implementations. There is no perfect answer. Omitting SDP in the 200 may be the safest alternative. See RFC6337 for more on this. I'm going to stop now. Lets sort this much out before addressing more. Thanks, Paul On 10/28/14 10:36 AM, R.Jesske@telekom.de wrote: > Dear all, > yesterday I have uploaded a new version of the draft-jesske-dispatch-forking-answer-correlation. > I have tried to include all comments I received so far and added some new Call flows for discussion. > > The draft is describing where a B2BUA provides a correlation mechanism to maintain a single dialog between UAC and B2BUA while between B2BUA and UAS1, UAS2, UAS3 ect. multiple early dialogs are existing. > We see the need for such a solution due to existing implementations not understanding multiples early dialogs or handling it in a wrong manner. More problematic are the cases where preconditions and early media is used. > > Comments and improvements are welcome. > > Thank you and Best Regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Montag, 27. Oktober 2014 17:39 > An: Jesske, Roland; Jesske, Roland > Betreff: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-02.txt > > > A new version of I-D, draft-jesske-dispatch-forking-answer-correlation-02.txt > has been successfully submitted by Roland Jesske and posted to the IETF repository. > > Name: draft-jesske-dispatch-forking-answer-correlation > Revision: 02 > Title: Correlation of multiple responses of forked INVITES in Back to Back User Agents > Document date: 2014-10-27 > Group: Individual Submission > Pages: 23 > URL: http://www.ietf.org/internet-drafts/draft-jesske-dispatch-forking-answer-correlation-02.txt > Status: https://datatracker.ietf.org/doc/draft-jesske-dispatch-forking-answer-correlation/ > Htmlized: http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-jesske-dispatch-forking-answer-correlation-02 > > Abstract: > This document describe how a correlation of multiple responses of a > forked INVITE in Back to Back User Agents can apply. > > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >