From nobody Mon Feb 5 22:51:44 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C3126D0C for ; Mon, 5 Feb 2018 22:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 icCAsmXiDUhK for ; Mon, 5 Feb 2018 22:51:39 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 C3725126CD6 for ; Mon, 5 Feb 2018 22:51:38 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E7148D8CE9AB3 for ; Tue, 6 Feb 2018 06:51:34 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 6 Feb 2018 06:51:35 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Tue, 6 Feb 2018 14:51:29 +0800 From: "Roni Even (A)" To: Simon Pietro Romano CC: Adam Roach , "pkyzivat@alum.mit.edu" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: clue protocol Thread-Index: AdOfFsEBaXtikoKvSSi3EmdC/AHtLQ== Date: Tue, 6 Feb 2018 06:51:28 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8621CD@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [clue] clue protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 06:51:43 -0000 SGkgU2ltb24sDQpDYW4geW91IGxvb2sgYXQgdGhlIG9wZW4gY29tbWVudHMgZnJvbSBBZGFtIHNv IHRoYXQgd2UgY2FuIGZpbmlzaCB0aGUgd29yayBpbiBDTFVFDQpSb25pDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwMywgMjAx NyAxMDowNyBQTQ0KVG86IFNpbW9uIFBpZXRybyBSb21hbm8NCkNjOiBjbHVlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2NsdWVdIEFEIFJldmlldzogZHJhZnQtaWV0Zi1jbHVlLXByb3RvY29sLTEz DQoNClRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXNwb25zZSEgSSd2ZSByZW1vdmVkIHRob3Nl IGlzc3VlcyB0aGF0IHlvdSd2ZSBhZGRyZXNzZWQsIGFuZCBpbmNsdWRlZCByZXNwb25zZXMgdG8g dGhlIHJlbWFpbmluZyBpc3N1ZXMgYmVsb3cuDQoNCklNUE9SVEFOVCBOT1RFIFRPIENMVUUgV09S S0lORyBHUk9VUDogVGhlcmUgaXMgYSBkaXNjdXNzaW9uIHJlZ2FyZGluZyByZXRyYW5zbWlzc2lv biB0aW1lcnMgdGhhdCB5b3UgbmVlZCB0byBoYXZlLiBTZWUgdGhlIGNvbW1lbnRzIGJlbG93IGZv ciBkZXRhaWxzLg0KDQoNCk9uIDEwLzYvMTcgMTozNyBQTSwgU2ltb24gUGlldHJvIFJvbWFubyB3 cm90ZToNCj4NCj4+IFRpdGxlOiBUaGUgcnVsZSBvZiB0aHVtYiBpcyB0aGF0IGFsbCBidXQgYSBz bWFsbCBoYW5kZnVsIG9mIA0KPj4gd2VsbC1rbm93biBhY3JvbnltcyBuZWVkIHRvIGJlIGV4cGFu ZGVkIGluIHRpdGxlcyBhbmQgYWJzdHJhY3RzLiBJIA0KPj4gcmVjb2duaXplIHRoYXQgIkNMVUUi IGlzIGEgYml0IHRvcnR1cmVkLCBhcyBhY3JvbnltcyBnbywgYnV0IHRoZSANCj4+IHRpdGxlIG9m IHRoaXMgZG9jdW1lbnQgaXMsIGJyb2FkbHkgc3BlYWtpbmcsIG9wYXF1ZS4gUGxlYXNlIGNoYW5n ZSBpdCANCj4+IHRvIHNvbWV0aGluZyBtZWFuaW5nZnVsLCBzdWNoIGFzICJQcm90b2NvbCBmb3Ig Q29udHJvbGxpbmcgTXVsdGlwbGUgDQo+PiBTdHJlYW1zIGZvciBUZWxlcHJlc2VuY2UgKENMVUUp 4oCdDQo+Pg0KPiBbU1BSXSBEb25lLg0KDQpJIHRoaW5rIHRoaXMgZ290IG1pc3NlZC4gVGhlIGhl YWRlciBvZiB0aGUgY3VycmVudCB2ZXJzaW9uIHN0aWxsIHJlYWRzOg0KDQpDTFVFIFdvcmtpbmcg R3JvdXAgUi4gUHJlc3RhDQpJbnRlcm5ldC1EcmFmdCBTLiBQLiBSb21hbm8NCkludGVuZGVkIHN0 YXR1czogU3RhbmRhcmRzIFRyYWNrIFVuaXZlcnNpdHkgb2YgTmFwb2xpDQpFeHBpcmVzOiBBcHJp bCA5LCAyMDE4IE9jdG9iZXIgNiwgMjAxNw0KDQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ0xVRSBwcm90b2NvbA0KIMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkcmFmdC1pZXRmLWNsdWUtcHJvdG9jb2wt MTQNCg0KPg0KPj4gR2VuZXJhbDogVGhlcmUgYXJlIHRocmVlIGluc3RhbmNlcyBvZiBleGNlc3Np dmVseSBsb25nIGxpbmVzIGluIHRoZSANCj4+IGRvY3VtZW50Lg0KPj4NCj4gW1NQUl0gPz8/DQoN ClRoZSByZWZvcm1hdHRpbmcgb2YgWE1MIGluIC0xNCBoYXMgZml4ZWQgdGhpcyBpc3N1ZS4NCg0K PiBCTE9DS0VSOiBHZW5lcmFsOiBUaGVyZSBhcmUgc2V2ZXJhbCBtZW50aW9ucyBvZiB0aW1lb3V0 cyBhbmQgcmV0cnkgDQo+IHRocmVzaG9sZHMgaW4gdGhlIHRleHQgYW5kIGl0cyBjb3JyZXNwb25k aW5nIHN0YXRlIG1hY2hpbmVzOyBob3dldmVyLCANCj4gdGhlIGRvY3VtZW50IG5laXRoZXIgZGVm aW5lcyBub3IgY2l0ZXMgYSBkb2N1bWVudCBhcyBkZWZpbmluZyB3aGF0IA0KPiB0aGVzZSB0aW1l b3V0IGFuZCByZXRyeSB2YWx1ZXMgYXJlLiBUaGVzZSBuZWVkIHRvIGJlIGRlZmluZWQgYW5kIA0K PiBkZXNjcmliZWQuIElmIHRoZSB0aW1lciBhbmQgcmV0cnkgc2NoZW1lIGFsbG93cyB0aGUgdHdv IGVuZHMgb2YgdGhlIA0KPiBjb25uZWN0aW9uIHRvIGhhdmUgZGlmZmVyZW50IHZhbHVlcyBmb3Ig dGltZW91dHMgYW5kIG51bWJlciBvZiANCj4gcmV0cmllcywgdGhlbiB0aGVyZSBuZWVkIHRvIGJl IGFkZGl0aW9uYWwgZXJyb3IgcHJvY2VkdXJlcyB0aGF0IGFsbG93IA0KPiB0aGUgTUMgYW5kIE1Q IHN0YXRlIG1hY2hpbmVzIHRvIHN0YXkgaW4gc3luYyAoaWYgdGhlIHRpbWVyL3JldHJ5IA0KPiB2 YWx1ZXMgY2FuIGJlIGRpZmZlcmVudCwgaXQncyBwb3NzaWJsZSBmb3Igb25lIHN0YXRlIG1hY2hp bmUgdG8gDQo+IHRyYW5zaXRpb24gdG8gInRlcm1pbmF0ZWQsIiB3aGlsZSB0aGUgb3RoZXIgaXMg c3RpbGwgYWN0aXZlLCBhbmQgeW91IA0KPiBuZWVkIG1lc3NhZ2luZyB0byBjbGVhbiB0aGlzIHVw KS4NCj4NCj4gW1NQUl0gT3VyIGlkZWEgd2FzIHRvIHJlbHkgb24gYSBzaW5nbGUsIGZpeGVkLCBh cHBsaWNhdGlvbi1sZXZlbCANCj4gKGkuZS4sIENMVUUtbGV2ZWwpIHRpbWVvdXQgdmFsdWUsIHJh dGhlciB0aGFuIGxldmVyYWdpbmcgYSBudW1iZXIgb2YgDQo+IHRoZW0gKFQxLCBUMiwgVDQsIHBs dXMgVGltZXIgQSB0aHJvdWdoIFRpbWVyIEspIGFzIGluIFNJUC4gVGhlIHZhbHVlIA0KPiBvZiB0 aGUgb25lIGFuZCBvbmx5IHRpbWVyIHdvdWxkIGJlIHRoZSB1c3VhbCBSVFQgZXN0aW1hdGUgKH41 MDBtcykuDQo+IERpZmZlcmVudGx5IGZyb20gcHJvdG9jb2xzIGxpa2UgU0lQLCB3ZSBhcmUgYWxz byBsZXZlcmFnaW5nIHJldHJhbnNtaXQgDQo+IGNvdW50cyB0byBnZXQgb3V0IG9mIGEgdGltZW91 dC1kcml2ZW4gcmV0cmFuc21pc3Npb24gbG9vcC4gV2XigJlyZSBub3QgDQo+IGFkZGluZyBzdWNo IGluZm9ybWF0aW9uIHRvIHRoZSByZXZpc2VkIHZlcnNpb24gb2YgdGhlIGRyYWZ0LCBiZWNhdXNl IA0KPiB3ZeKAmWQgZmlyc3QgbGlrZSB0byBnZXQgeW91ciBmZWVkYmFjayBvbiB0aGUgYXBwcm9h Y2guIElmIHlvdSAoYW5kIHRoZSANCj4gcmVzdCBvZiB0aGUgZ3JvdXApIGJlbGlldmUgdGhpcyBp cyBhIGZlYXNpYmxlIGFwcHJvYWNoLCB3ZSBjYW4gZXhwYW5kIA0KPiBvbiB0aGF0IGluIGEgZnVy dGhlciB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KSW4gdGhpbmtpbmcgdGhyb3VnaCB3aGF0 IHRoaXMgc2NoZW1lIHNob3VsZCBsb29rIGxpa2UsIGl0IG9jY3VycyB0byBtZSB0aGF0IHRoZSBD TFVFIG1lc3NhZ2VzIGFyZSBkZWZpbmVkIHRvIGJlIHNlbnQgb3ZlciBhIHJlbGlhYmxlIHRyYW5z cG9ydCAoU0NUUCksIHdoaWNoIGhhcyBpdHMgb3duIHJldHJhbnNtaXNzaW9uIHRpbWVycyBhbmQg ZXZlbnR1YWwgdGltZW91dHMuIA0KSW1wbGVtZW50aW5nIGEgcmV0cmFuc21pc3Npb24gc2NoZW1l IG9uIHRvcCBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCAtLSBlc3BlY2lhbGx5IG9uZSBhcyBhZ2dy ZXNzaXZlIGFzIHlvdSBzdWdnZXN0IGFib3ZlIC0tIHdpbGwgcHV0IG1vcmUgdHJhZmZpYyBvbiB0 aGUgbmV0d29yayB3aGVuIGNvbmdlc3Rpb24gb2NjdXJzIHJhdGhlciB0aGFuIGxlc3MuDQoNClNv LCBpbiB0aGUgZmluYWwgYW5hbHlzaXMsIEkgdGhpbmsgdGhlIGFjdGlvbiBoZXJlIGlzIHRvIHJl bW92ZSByZXRyYW5zbWlzc2lvbiB0aW1lcnMgYW5kIHJldHJ5IGNvdW50cyBhbHRvZ2V0aGVyLiBJ ZiB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgdGFrZXMgbG9uZ2VyIHRvIGRldGVjdCBhIGZhaWx1 cmUgdGhhbiBpcyBzZW5zaWJsZSBmb3IgQ0xVRSAoYW5kIGl0IGxpa2VseSBkb2VzKSwgdGhlbiBh IHN1cGVydmlzb3J5IHRpbWVyIHRoYXQgZGVjbGFyZXMgdGhlIHNlc3Npb24gZmFpbGVkIG1pZ2h0 IG1ha2Ugc2Vuc2UuDQoNCj4NCj4+IFNlY3Rpb24gNTogVGhlIFhNTCBkZWZpbml0aW9uIGFsbG93 cyB6ZXJvIG9yIG1vcmUgPGNsdWVJZD4gZWxlbWVudHMgDQo+PiB0byBhcHBlYXIgaW4gYSBtZXNz YWdlLiBJZiBtb3JlIHRoYW4gb25lIGlzIGFsbG93ZWQsIHRoZSBkb2N1bWVudCANCj4+IHNob3Vs ZCBleHBsYWluIGhvdyBtdWx0aXBsZSBJRHMgYXJlIGhhbmRsZWQuIElmIHRoZXkgYXJlIG5vdCwg dGhlbiANCj4+IHRoZSBzY2hlbWEgYW5kL29yIHRleHQgbmVlZHMgdG8gcHJvaGliaXQgaGF2aW5n IG1vcmUgdGhhbiBvbmUuDQo+Pg0KPiBbU1BSXSBBY3R1YWxseSwgdGhlIHNjaGVtYSBzdGF0ZXM6 DQo+DQo+IDx4czplbGVtZW50IG5hbWU9ImNsdWVJZCIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1 cnM9IjDigJ0vPg0KPg0KPiBUaGlzIHNob3VsZCBpbmRpY2F0ZSB0aGF0IGNsdWVJZCBjYW4gYXBw ZWFyIGVpdGhlciAwIG9yIDEgdGltZXMgaW4gYSANCj4gdmFsaWQgWE1MIGRvY3VtZW50LiBUaGUg ZGVmYXVsdCB2YWx1ZSBmb3IgbWF4T2NjdXJzIGlzIGluIGZhY3QgMS4NCj4gRG9u4oCZdCB5b3Ug YWdyZWUgb24gdGhhdD8NCg0KQWgsIHlvdSdyZSBjb3JyZWN0LiBJJ20gbm90IHVzZWQgdG8gc2Vl aW5nIG1pbk9jY3VycyB3aXRob3V0IG1heE9jY3VycywgYnV0IHRoaXMgaXMgZW50aXJlbHkgZmlu ZSBhcyBpdCdzIGN1cnJlbnRseSB3cml0dGVuLg0KDQo+DQo+PiBCTE9DS0VSOiBTZWN0aW9uIDUu MTogVGhlIGRlc2NyaXB0aW9uIG9mIDxzdXBwb3J0ZWRWZXJzaW9ucz4gDQo+PiBkZXNjcmliZXMg YSBzY2hlbWUgaW4gd2hpY2ggbXVsdGlwbGUgc3VwcG9ydGVkIHZlcnNpb25zIGNhbiBiZSANCj4+ IGxpc3RlZDsgYW5kLCBpZiB0aGUgbGlzdCBpcyBvbWl0dGVkLCBpdCBpbXBsaWVzIHRoYXQgb25s eSB0aGUgdmVyc2lvbiANCj4+IGRlc2NyaWJlZCBpbiA8dj4gaXMgc3VwcG9ydGVkLiBUaGlzIHRl eHQgZG9lcyBub3QgZGVmaW5lIChub3IgZG9lcyANCj4+IGFueSBvdGhlciB0ZXh0IHRoYXQgSSBj YW4gZmluZCkgd2hhdCA8dj4gc2hvdWxkIGJlIHNldCB0byB3aGVuIA0KPj4gPHN1cHBvcnRlZFZl cnNpb25zPiBpcyB1c2VkLiBJbnR1aXRpdmVseSwgaXQgc2VlbXMgdGhhdCA8dj4gc2hvdWxkIGJl IA0KPj4gc2V0IHRvIHRoZSBsYXJnZXN0IG1pbm9yIHZlcnNpb24gb2YgdGhlIHNtYWxsZXN0IG1h am9yIHZlcnNpb24gDQo+PiBhZHZlcnRpc2VkIGluIDxzdXBwb3J0ZWRWZXJzaW9ucz4sIGJ1dCB0 aGF0IChvciB3aGF0ZXZlciB0aGUgY29ycmVjdCANCj4+IGFuc3dlciBpcykgbmVlZHMgdG8gYmUg Y2xlYXJseSBzcGVsbGVkIG91dC4NCj4+DQo+IFtTUFJdIEkgYmVsaWV2ZSB3ZSB3ZXJlIGdpdmlu ZyBmb3IgZ3JhbnRlZCB0aGF0IOKAnHbigJ0gc2hvdWxkIGJlLCBpbiBzdWNoIA0KPiBjYXNlLCB0 aGUgaGlnaGVzdCBzdXBwb3J0ZWQgdmVyc2lvbiAoaS5lLiwgbGFyZ2VzdCBtYWpvciBhbmQgbGFy Z2VyIA0KPiBtaW5vciBudW1iZXJzKS4gTm93IHRoYXQgeW91IG1ha2UgbWUgdGhpbmsgYXJvdW5k IHRoYXQsIEkgd291bGQgc2ltcGx5IA0KPiBzYXkgdGhhdCB0aGUg4oCcduKAnSBhdHRyaWJ1dGUg TVVTVCBiZSBzZXQgdG8gb25lIG9mIHRoZSB2ZXJzaW9ucyB0aGF0IHRoZSANCj4gZW50aXR5IGlu IHF1ZXN0aW9uIHN1cHBvcnRzLCBhcyBwZXIgdGhlIDxzdXBwb3J0ZWRWZXJzaW9ucz4gbGlzdC4g SSANCj4gY2FuLCBlLmcuLCBkZWNpZGUgdGhhdCBJIHNlbmQgYW4g4oCYb3B0aW9uc+KAmSB3aXRo IOKAnHY9MTIuMjPigJ0gaWYgdGhlIA0KPiA8c3VwcG9ydGVkVmVyc2lvbnM+IGxpc3QgaXMgbGlr ZSBpbiB0aGUgZm9sbG93aW5nOg0KPg0KPiA8dmVyc2lvbj4zMy40NDwvdmVyc2lvbj4NCj4gPHZl cnNpb24+MjcuMDwvdmVyc2lvbj4NCj4gPHZlcnNpb24+MTIuMzQ1PC92ZXJzaW9uPg0KPiA8dmVy c2lvbj4xLjQ0PC92ZXJzaW9uPg0KDQpJIHRoaW5rIHRoaXMgZm9ybXVsYXRpb24gaXMgYSBwcm9i bGVtLiBJIGFzc3VtZSB0aGUgaW50ZW50aW9uIGJlaGluZCB0aGUgInYiIGZpZWxkIGlzIHRoYXQg c29tZSBpbXBsZW1lbnRhdGlvbiB0aGF0IHJlY2VpdmVzIGEgdmVyc2lvbiBudW1iZXIgaW4gdGhl ICJ2IiBmaWVsZCB3aXRoIGEgbWFqb3IgbnVtYmVyIGhpZ2hlciB0aGFuIGl0IHVuZGVyc3RhbmRz IGlzIHN1cHBvc2VkIHRvIGNsb3NlIHRoZSBjb25uZWN0aW9uLCBzaW5jZSBpdCBydW5zIGEgcmlz ayBvZiBtaXNpbnRlcnByZXRpbmcgdGhlIGNvbnRlbnRzIG9mIG1lc3NhZ2VzLiBTbywgaW4geW91 ciBleGFtcGxlLCBpZiB5b3Ugc2VudCAidj0xMi4yMyIgdG8gbXkgaW1wbGVtZW50YXRpb24gdGhh dCBvbmx5IHNwb2tlIG1ham9yIHZlcnNpb24gMSwgSSB3b3VsZCByZWplY3QgaXQsIGV2ZW4gdGhv dWdoIHlvdSBhbHNvIHN1cHBvcnQgbWFqb3IgdmVyc2lvbiAxLiBUaGF0J3Mgd2h5IEkgd2FzIHRo aW5raW5nIGl0IHNob3VsZCBjb250YWluIHRoZSBzbWFsbGVzdCBtYWpvciB2ZXJzaW9uIGJlaW5n IGFkdmVydGlzZWQuDQoNClRoZSBtaW5vciB2ZXJzaW9uIGlzIG9idmlvdXNseSBsZXNzIHVzZWZ1 bCBpbiB0aGlzIGNvbnRleHQsIHNpbmNlIHRoZXkncmUgZGVmaW5lZCB0byBiZSBiYWNrd2FyZHMg YW5kIGZvcndhcmRzIGNvbXBhdGlibGUsIGJ1dCBpdCdzIG1vcmUgdXNlZnVsIHRvIGtub3cgdGhl IGhpZ2hlc3QgbWlub3IgdmVyc2lvbiBzdXBwb3J0ZWQgdGhhbiBzb21lIHJhbmRvbSBtaW5vciB2 ZXJzaW9uLCBhcyBpdCBpbmRpY2F0ZXMgdGhlIGZ1bGwgZmVhdHVyZSBzZXQgdGhhdCBpcyBzdXBw b3J0ZWQuIA0KVGhlIHJlYXNvbiBpdCdzIGxlc3MgdXNlZnVsIGlzIHRoYXQgdGhlIHZhbHVlIGNh biBiZSBwYXJzZWQgb3V0IG9mIHRoZSA8dmVyc2lvbj4gbGlzdC4NCg0KPj4gQkxPQ0tJTkc6IFRo ZSBzdGF0ZSBtYWNoaW5lcyBpbiBzZWN0aW9uIDYgYW5kIGl0cyBzdWJzZWN0aW9ucyBkb24ndCAN Cj4+IGhhdmUgdHJhbnNpdGlvbnMgZm9yIGFsbCBwb3NzaWJsZSBtZXNzYWdlcyB0aGF0IGNvdWxk IGFycml2ZSBpbiBhIA0KPj4gc3RhdGUuIFRoaXMgY2FuIGNhdXNlIGludGVyb3AgaXNzdWVzLiBQ bGVhc2UgYWRkIHRleHQgdGhhdCBjbGVhcmx5IA0KPj4gaW5kaWNhdGVzIHdoZXRoZXIgc3VjaCBt ZXNzYWdlcyBkbyBvciBkbyBub3QgY2F1c2UgYSB0cmFuc2l0aW9uLg0KPj4gKFRoaXMgbWlnaHQg YmUgYXMgc2ltcGxlIGFzICJtZXNzYWdlcyBub3Qgc2hvd24gZm9yIGEgc3RhdGUgZG8gbm90IA0K Pj4gY2F1c2UgdGhlIHN0YXRlIHRvIGNoYW5nZSwiIGJ1dCBvbmx5IGlmIHlvdSBjYXJlZnVsbHkg Y2hlY2sgdGhhdCB0aGlzIA0KPj4gaXMgdHJ1ZSAtLSBmb3IgZXhhbXBsZSwgd2hhdCBzaG91bGQg YW4gTVAgc3RhdGUgbWFjaGluZSBkbyBkbyBpZiBpdCANCj4+IGdldHMgYSAiQ09ORiArIEFDSyIg aW4gdGhlIHN0YXRlICJXQUlUIEZPUiBDT05GIj8pDQo+Pg0KPiBbU1BSXSBJbiB0aGUgc3BlY2lm aWMgY2FzZSB5b3UgbWVudGlvbiwgSSB3b3VsZCBleHBlY3QgdGhhdCBhIDMwMiBpcyANCj4gZ2Vu ZXJhdGVkIChJbnZhbGlkIFBhcmFtZXRlciksIHNpbmNlIHRoZSBpbmNvbWluZyBDT05GIHNob3Vs ZCBub3QgDQo+IGNvbnRhaW4gdGhlIDxhY2s+IGVsZW1lbnQuIFRoaXMgc2FpZCwgSSBzZWUgeW91 ciBwb2ludCByZWxhdGVkIHRvIHRoZSANCj4gcG90ZW50aWFsIGxhY2sgb2Ygc29tZSBlZGdlcyBp biB0aGUgc3RhdGUgbWFjaGluZSBncmFwaC4gVGhpcyBwb2ludCBpcyANCj4gb2J2aW91c2x5IGFs c28gcmVsYXRlZCB0byB0aGUg4oCcdGltZW91dOKAnSBpc3N1ZSB5b3UgcmFpc2VkIGJlZm9yZS4N Cj4gRGlmZmVyZW50IHdheXMgb2YgbWFuYWdpbmcgdGltZW91dHMgd2lsbCBkZWZpbml0ZWx5IGhh dmUgZGlmZmVyZW50IA0KPiBpbXBhY3RzIG9uIHRoZSBjdXJyZW50IHN0YXRlIG1hY2hpbmVzLg0K PiBXZSB3aWxsIGRlZmVyIHRoZSBtb2RpZmljYXRpb24gb2YgdGhlIGRpYWdyYW1zIGluIHF1ZXN0 aW9uIHRvIHRoZSBuZXh0IA0KPiByZXZpc2lvbiByb3VuZC4gSW4gdGhlIG1lYW53aGlsZSwgd2Xi gJlsbCBnaXZlIGEgdGhvdWdodCB0byBwb3RlbnRpYWwgDQo+IGZ1cnRoZXIgdW5leHBlY3RlZCB0 cmFuc2FjdGlvbnMgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50Lg0KDQpCYXNlZCBvbiBteSBhbmFs eXNpcyBhYm92ZSwgSSB0aGluayB0aGUgc3RhdGUgbWFjaGluZXMgd2lsbCBnZXQgYSBiaXQgc2lt cGxlciwgYXMgdGhleSB3b24ndCBoYXZlIHJldHJhbnNtaXNzaW9uIGNvdW50cyBhbnkgbG9uZ2Vy Lg0KDQo+DQo+PiBTZWN0aW9uIDYuMiBkZXNjcmliZXMgYSBzdGF0ZSBtYWNoaW5lIHRoYXQgc3Rh cnRzIGluIGEgc3RhdGUgY2FsbGVkIA0KPj4gIldBSVQgRk9SIEFEVi4iIFRoaXMgc3RhdGUgZG9l cyBub3QgYXBwZWFyIHRvIGJlIHRpbWVyLXN1cGVydmlzZWQsIA0KPj4gbWVhbmluZyB0aGF0IGlt cGxlbWVudGF0aW9ucyBvZiB0aGlzIHN0YXRlIG1hY2hpbmUgY2FuIHN0YXkgaW4gdGhpcyANCj4+ IHN0YXRlIGxpdGVyYWxseSBmb3JldmVyLiBJcyB0aGF0IHRoZSBpbnRlbnRpb24/DQo+Pg0KPiBb U1BSXSBUaGUgaWRlYSB3b3VsZCBiZSB0byBvcGVuIGEgc29ja2V0IGFuZCBzdGFydCBsaXN0ZW5p bmcgZm9yIA0KPiBpbmNvbWluZyBhZHZlcnRpc2VtZW50cy4gSXNu4oCZdCB0aGF0IE9LPw0KDQpB dCBzb21lIHBvaW50LCBJIHRoaW5rIHlvdSdyZSBnb2luZyB0byB3YW50IHRvIGNvbmNsdWRlIHRo YXQgdGhlIENMVUUgZGF0YSBjaGFubmVsIGlzbid0IGdvaW5nIHRvIGdldCBzZXQgdXAgY29ycmVj dGx5LCBhbmQgc2lnbmFsIHRoYXQgdG8gdGhlIGFwcGxpY2F0aW9uIGluIHNvbWUgd2F5LiBUaGlz IGlzIHByb2JhYmx5IG9uIHRoZSBvcmRlciBvZiBhIG1pbnV0ZSBvciBzby4NCg0KPj4gU2VjdGlv biA4IGluZGljYXRlcyB0aGF0IGV4dGVuc2lvbnMgbmVlZCB0byBpbmRpY2F0ZSAidGhlIHN0YW5k YXJkIA0KPj4gdmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wgdGhlIGV4dGVuc2lvbiByZWZlcnMgdG8u IiBHaXZlbiB0aGF0IHRoZXJlIGlzIA0KPj4gY29tcGF0aWJpbGl0eSB3aXRoaW4gYSBtYWpvciB2 ZXJzaW9uIG9mIGEgcHJvdG9jb2wsIEkgdGhpbmsgdGhpcyANCj4+IG1lYW5zIHRvIHNheSAidGhl IG1ham9yIHN0YW5kYXJkIHZlcnNpb24gb2YgdGhlIHByb3RvY29sIHRoYXQgdGhlIA0KPj4gZXh0 ZW5zaW9uIHJlZmVycyB0by7igJ0NCj4+DQo+IFtTUFJdIE15IGV4dGVuc2lvbiBtaWdodCBiZSBh c3NvY2lhdGVkIHdpdGggdmVyc2lvbiAzLjYgb2YgdGhlIA0KPiBwcm90b2NvbC4gVGhpcyBtZWFu cyB0aGF0IGl0IHdpbGwgbmVlZCB0byBiZSBzdXBwb3J0ZWQgYnkgYWxsIHZlcnNpb25zIA0KPiBo aWdoZXIgdGhhbiB0aGF0ICgzLjcgb253YXJkcykuIFRob3VnaCwgdGhpcyBkb2VzIG5vdCBlbnRh aWwgdGhhdCANCj4gdmVyc2lvbnMgMy41IGFuZCBsb3dlciBzaG91bGQgdW5kZXJzdGFuZCBpdC4g UmlnaHQ/DQoNCkknbSBhIGJpdCBjb25mdXNlZC4gSXMgdGhlIG5vdGlvbiBoZXJlIHRoYXQgZXh0 ZW5zaW9ucywgb25jZSBpbnRyb2R1Y2VkLCBhbHdheXMgYmVjb21lIGEgbWFuZGF0b3J5LXRvLWlt cGxlbWVudCBwYXJ0IG9mIHRoZSBwcm90b2NvbD8gSWYgdGhhdCdzIHRoZSBjYXNlLCBpdCdzIG5v dCBjbGVhciB3aHkgeW91IHdvdWxkIG5lZWQgdG8gYWR2ZXJ0aXNlIHRoZW0gZXhwbGljaXRseSwg c2luY2Ugc3VwcG9ydCB3b3VsZCBiZSBpbXBsaWVkIGJ5IHRoZSB2ZXJzaW9uIG51bWJlciBpdHNl bGYuIA0KKFRoaXMgaXNuJ3QgdW5oZWFyZCBvZjogaXQncyBob3cgTkZTIGhhcyBoaXN0b3JpY2Fs bHkgaGFuZGxlZCB2ZXJzaW9uIG51bWJlcnMsIGZvciBleGFtcGxlLikgSG93ZXZlciwgSSBkaWRu J3QgZ2V0IHRoZSBpbXByZXNzaW9uIHRoYXQgQ0xVRSBwcm90b2NvbCBleHRlbnNpb25zIHdlcmUg aGFuZGxlZCBpbiBzdWNoIGEgd2F5LiBJZiB0aGlzIGlzIHRoZSBpbnRlbnRpb24sIHRoZXJlIG5l ZWRzIHRvIGJlIGEgbG90IG1vcmUgdGV4dCB0aGF0IG1ha2VzIHRoaXMgTVRJIGFzcGVjdCBvZiBl eHRlbnNpb25zIGNsZWFyLCBhbmQgYSByZWNvbnNpZGVyYXRpb24gb2Ygd2h5IHlvdSdyZSBzaWdu YWxpbmcgdGhlbSBpbmRpdmlkdWFsbHkgcmF0aGVyIHRoYW4gaW5mZXJyaW5nIHRoZW0gZnJvbSB0 aGUgdmVyc2lvbiBudW1iZXIuDQoNCj4+IFNlY3Rpb24gOCBjb250YWlucyBzY2hlbWEgdGhhdCBj b250YWlucyBhIDx2ZXJzaW9uPiBlbGVtZW50LiBJdCANCj4+IHNob3VsZCBiZSBjbGFyaWZpZWQg dGhhdCB0aGlzIGlzIHRoZSAqcHJvdG9jb2wqIHZlcnNpb24sIG5vdCB0aGUNCj4+ICpleHRlbnNp b24qIHZlcnNpb24gKG9yLCBpZiBpdCdzIHRoZSBleHRlbnNpb24gdmVyc2lvbiwgdGhhdCBuZWVk cyB0byANCj4+IGJlIHNwZWxsZWQgb3V0IHRvbywgYnV0IEkgdGhpbmsgeW91J2xsIG5lZWQgYSBu ZXcgbmFtZXNwYWNlIGZvciANCj4+IHRoYXQuLi4/KQ0KPj4NCj4gW1NQUl0gSSB0aG91Z2h0IHRo aXMgd2FzIGNsZWFyIGZyb20gdGhlIHRoaXJkIGJ1bGxldCBwb2ludCBpbiB0aGUgbGlzdDoNCj4N Cj4gLcKgdGhlIHN0YW5kYXJkIHZlcnNpb24gb2YgdGhlIHByb3RvY29sIHRoZSBleHRlbnNpb24g cmVmZXJzIHRvLg0KPg0KPiBJc27igJl0IHRoaXMgZW5vdWdoPyBJbiBzdWNoIGEgY2FzZSwgd2hh dCB3b3VsZCB5b3Ugc3VnZ2VzdCB0byBhZGQ/DQoNCkFoLCBJIHNlZS4gSXQgd2Fzbid0IGNsZWFy IHRoYXQgdGhlc2UgdGhyZWUgYnVsbGV0cyBjb3JyZXNwb25kZWQgdG8gdGhlIGVsZW1lbnRzIGlu IHRoZSBYTUwuIFBlcmhhcHMgbWFrZSB0aGlzIGNsZWFyZXIgd2l0aCBzb21ldGhpbmcgbGlrZSAi VGhlIHZhbHVlcyBvZiB0aGUgZmllbGRzIG9mIHRoZSA8ZXh0ZW5zaW9uPiBlbGVtZW50IHRha2Ug dGhlIGZvbGxvd2luZyB2YWx1ZXM6IiAoYW5kIG1heWJlIG1vdmUgaXQgY2xvc2VyIHRvIHRoZSBh Y3R1YWwgWE1MKS4NCg0KPg0KPj4gVGhlIHJlbWFpbmRlciBvZiB0aGlzIGNvbW1lbnQgaXMgbm9u LWJsb2NraW5nOiBJIGFsc28gZmluZCB0aGUgDQo+PiAiU0hPVUxEIiBpbiB0aGlzIHNlY3Rpb24g dG8gYmUgaGlnaGx5IHBlcnBsZXhpbmcuIENhbiB5b3UgZXhwbGFpbiB0aGUgDQo+PiByYXRpb25h bGUgYmVoaW5kIHJlcXVpcmluZyBzY2hlbWEsIGJ1dCBub3QgcmVxdWlyaW5nIGFueSBkZXNjcmlw dGlvbiANCj4+IG9mIHdoYXQgdGhlIHNjaGVtYSAqbWVhbnM/KQ0KPj4NCj4gW1NQUl0gSXQgaXMg bGlrZSBjb2Rpbmcgd2l0aG91dCBhZGRpbmcgY29tbWVudHMvZG9jdW1lbnRhdGlvbi4gDQo+IERv Y3VtZW50YXRpb24gaXMgbW9zdCB3ZWxjb21lLCBidXQgbm90IG1hbmRhdG9yeS4gRG9u4oCZdCB5 b3UgYWdyZWU/DQoNCkkgZG9uJ3QuIEl0IHNlZW1zIG1vcmUgbGlrZSBjb21taXR0aW5nIGEgaGVh ZGVyIGZpbGUgd2l0aG91dCB0aGUgY29ycmVzcG9uZGluZyBpbXBsZW1lbnRhdGlvbiBmaWxlLiBK dXN0IGJlY2F1c2UgcGVvcGxlIGtub3cgd2hhdCB0aGluZ3MgYXJlIGNhbGxlZCBkb2Vzbid0IG1l YW4gdGhhdCB0aGV5IGNhbiBoYW5kbGUgdGhlbS4gRm9yIGludGVyb3AsIHlvdSdyZSBnb2luZyB0 byBuZWVkIHNvbWUgZGVzY3JpcHRpb24gb2Ygd2hhdCB0aGUgZmllbGRzIG1lYW4gYW5kIGhvdyB0 aGUgbWVzc2FnZXMgYXJlIGhhbmRsZWQuDQoNCj4+DQo+PiBUaGUgc2NoZW1hIGluIHNlY3Rpb24g OSBjb250YWluczoNCj4+DQo+PiA8eHM6aW1wb3J0IG5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1z OnhtbDpuczpjbHVlLWluZm8iDQo+PiBzY2hlbWFMb2NhdGlvbj0iZGF0YS1tb2RlbC1zY2hlbWEt MTcueHNkIi8+DQo+Pg0KPj4gSWYgeW91IGRvIG5vdCBpbnRlbmQgdG8gYmFrZSB0aGlzICItMTci IGludG8gdGhlIGRvY3VtZW50IChhbmQgSSANCj4+IGNhbid0IGltYWdpbmUgeW91IGRvKSwgcGxl YXNlIGFkZCBhbiBSRkMgZWRpdG9yIG5vdGUgdG8gY2hhbmdlIGl0IHRvIA0KPj4gc29tZXRoaW5n IGVsc2UgdXBvbiBwdWJsaWNhdGlvbi4NCj4+DQo+IFtTUFJdIERvbmUuIEkgYW0gbm90IHZlcnkg ZmFtaWxpYXIgd2l0aCBSRkMgZWRpdG9yIG5vdGVzLCBpbmRlZWQuIEhlcmUgDQo+IGlzIHdoYXQg d2UgYWRkZWQgYXQgdGhlIGJlZ2lubmluZyBvZiBzZWN0aW9uIDk6DQo+DQo+ICJOT1RFIFRPIFRI RSBSRkMtRWRpdG9yOiBQbGVhc2UgcmVwbGFjZSAiZGF0YS1tb2RlbC1zY2hlbWEtMTcueHNkIiAN Cj4gd2l0aCB0aGUgcmlnaHQgc2NoZW1hIGxvY2F0aW9uIGZvciB0aGUgQ0xVRSBkYXRhIG1vZGVs IHNjaGVtYSBkb2N1bWVudCANCj4gKHdoaWNoIGlzIHN0aWxsIHRvIGJlIGRlZmluZWQgYXQgdGhl IHRpbWUgb2YgdGhpcyB3cml0aW5nKSBpbiB0aGlzIA0KPiBzZWN0aW9uIHByaW9yIHRvIHB1Ymxp Y2F0aW9uIGFzIGFuIFJGQy7igJ0NCj4NCj4gRG9lcyB0aGlzIHdvcmsgZm9yIHlvdT8NCg0KVGhh dCdzIHBlcmZlY3QuIFRoYW5rcyENCg0KPj4gU2VjdGlvbiAxMCBpbiBnZW5lcmFsOiBXaGlsZSBp dCBkb2VzIGNvbnN1bWUgYSBsb3Qgb2Ygc3BhY2UsIEkgZG9uJ3QgDQo+PiB0aGluayB0aGF0IGRl ZmluaW5nIHNpeCByYXRoZXIgZGlmZmVyZW50IG1lc3NhZ2UgdHlwZXMgYW5kIHRoZW4gDQo+PiBz aG93aW5nIG9ubHkgKm9uZSogdHlwZSBpbiB0aGUgZXhhbXBsZXMgaXMgdmVyeSBpbGx1c3RyYXRp dmUgb2YgdGhlIA0KPj4gcHJvdG9jb2wuIEkgd291bGQgKlNUUk9OR0xZKiBzdWdnZXN0IGFkZGlu ZyBhdCBsZWFzdCBhIHJlc3BvbnNlIA0KPj4gbWVzc2FnZSwgYW5kIGlkZWFsbHkgdGhlIGV4YW1w bGUgc2VjdGlvbiBzaG91bGQgY29udGFpbiBhdCBsZWFzdCBvbmUgDQo+PiBleGFtcGxlIGZvciBl YWNoIG9mIHRoZSBzaXggbWVzc2FnZSB0eXBlcy4NCj4+DQo+IFtTUFJdIFdpbGwgZG8gaW4gdGhl IChob3BlZnVsbHkgZmluYWwpIHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudC4gTGV04oCZcyANCj4g Zmlyc3QgZG91YmxlIGNoZWNrIHRoYXQgdGhlIHByb3Bvc2VkIG1vZGlmaWNhdGlvbnMgYXJlIE9L Lg0KDQpTb3VuZHMgZ29vZC4NCg0KPg0KPj4gU2VjdGlvbiAxMi4xIGhhcyBhIHN0cmFuZ2UgZG91 YmxlLWRvdWJsZSBxdW90ZSBhcm91bmQgdGhlIFVSTiBuYW1lLCANCj4+IGFuZCBzZWN0aW9uIDEy LjMgcmVwZWF0cyB0aGlzIGZvciB0aGUgTUlNRSB0eXBlLg0KPj4NCj4gW1NQUl0gSSBkb27igJl0 IHVuZGVyc3RhbmQgdGhpcy4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeT8NCj4NCg0KUmVwbGFjZQ0K DQogICAgIiJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmNsdWUtcHJvdG9jb2wiIi4NCg0Kd2l0aA0K DQogICAgInVybjppZXRmOnBhcmFtczp4bWw6bnM6Y2x1ZS1wcm90b2NvbCIuDQoNCg0KQW5kIHRo ZW4gcmVwbGFjZQ0KDQogICAgVGhpcyBzZWN0aW9uIHJlZ2lzdGVycyB0aGUgIiJhcHBsaWNhdGlv bi9jbHVlK3htbCIiIE1JTUUgdHlwZS4NCg0Kd2l0aA0KDQogICAgVGhpcyBzZWN0aW9uIHJlZ2lz dGVycyB0aGUgImFwcGxpY2F0aW9uL2NsdWUreG1sIiBNSU1FIHR5cGUuDQoNCg0KVGhhbmtzIQ0K DQovYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Y2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2x1ZQ0K From nobody Tue Feb 6 01:04:28 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0B8126BF6 for ; Tue, 6 Feb 2018 01:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fRr4nds7SgHm for ; Tue, 6 Feb 2018 01:04:04 -0800 (PST) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3432A120727 for ; Tue, 6 Feb 2018 01:04:04 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id w1693ii8009870-w1693iiA009870 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Feb 2018 10:03:44 +0100 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id w1693hVH030567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Feb 2018 10:03:43 +0100 From: Simon Pietro Romano Message-Id: <0D0F98C3-D9BC-4F39-BC59-DD192CE9F8D1@unina.it> Content-Type: multipart/alternative; boundary="Apple-Mail=_B7558A76-E69B-4D04-86F0-75EEE1B3D127" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 6 Feb 2018 10:03:42 +0100 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8621CD@DGGEMM506-MBX.china.huawei.com> Cc: Adam Roach , "pkyzivat@alum.mit.edu" , Paul Kyzivat , "clue@ietf.org" To: "Roni Even (A)" References: <6E58094ECC8D8344914996DAD28F1CCD8621CD@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [clue] clue protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 09:04:10 -0000 --Apple-Mail=_B7558A76-E69B-4D04-86F0-75EEE1B3D127 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yep! I=E2=80=99ll come back with a revised version asap. BTW, Adam was = asking for some general feedback from the WG... Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 6 Feb 2018, at 07:51, Roni Even (A) wrote: >=20 > Hi Simon, > Can you look at the open comments from Adam so that we can finish the = work in CLUE > Roni >=20 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, November 03, 2017 10:07 PM > To: Simon Pietro Romano > Cc: clue@ietf.org > Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 >=20 > Thanks for your thorough response! I've removed those issues that = you've addressed, and included responses to the remaining issues below. >=20 > IMPORTANT NOTE TO CLUE WORKING GROUP: There is a discussion regarding = retransmission timers that you need to have. See the comments below for = details. >=20 >=20 > On 10/6/17 1:37 PM, Simon Pietro Romano wrote: >>=20 >>> Title: The rule of thumb is that all but a small handful of=20 >>> well-known acronyms need to be expanded in titles and abstracts. I=20= >>> recognize that "CLUE" is a bit tortured, as acronyms go, but the=20 >>> title of this document is, broadly speaking, opaque. Please change = it=20 >>> to something meaningful, such as "Protocol for Controlling Multiple=20= >>> Streams for Telepresence (CLUE)=E2=80=9D >>>=20 >> [SPR] Done. >=20 > I think this got missed. The header of the current version still = reads: >=20 > CLUE Working Group R. Presta > Internet-Draft S. P. Romano > Intended status: Standards Track University of Napoli > Expires: April 9, 2018 October 6, 2017 >=20 > CLUE protocol > draft-ietf-clue-protocol-14 >=20 >>=20 >>> General: There are three instances of excessively long lines in the=20= >>> document. >>>=20 >> [SPR] ??? >=20 > The reformatting of XML in -14 has fixed this issue. >=20 >> BLOCKER: General: There are several mentions of timeouts and retry=20 >> thresholds in the text and its corresponding state machines; however,=20= >> the document neither defines nor cites a document as defining what=20 >> these timeout and retry values are. These need to be defined and=20 >> described. If the timer and retry scheme allows the two ends of the=20= >> connection to have different values for timeouts and number of=20 >> retries, then there need to be additional error procedures that allow=20= >> the MC and MP state machines to stay in sync (if the timer/retry=20 >> values can be different, it's possible for one state machine to=20 >> transition to "terminated," while the other is still active, and you=20= >> need messaging to clean this up). >>=20 >> [SPR] Our idea was to rely on a single, fixed, application-level=20 >> (i.e., CLUE-level) timeout value, rather than leveraging a number of=20= >> them (T1, T2, T4, plus Timer A through Timer K) as in SIP. The value=20= >> of the one and only timer would be the usual RTT estimate (~500ms). >> Differently from protocols like SIP, we are also leveraging = retransmit=20 >> counts to get out of a timeout-driven retransmission loop. We=E2=80=99r= e not=20 >> adding such information to the revised version of the draft, because=20= >> we=E2=80=99d first like to get your feedback on the approach. If you = (and the=20 >> rest of the group) believe this is a feasible approach, we can expand=20= >> on that in a further version of the document. >=20 > In thinking through what this scheme should look like, it occurs to me = that the CLUE messages are defined to be sent over a reliable transport = (SCTP), which has its own retransmission timers and eventual timeouts.=20= > Implementing a retransmission scheme on top of a reliable transport -- = especially one as aggressive as you suggest above -- will put more = traffic on the network when congestion occurs rather than less. >=20 > So, in the final analysis, I think the action here is to remove = retransmission timers and retry counts altogether. If the underlying = transport takes longer to detect a failure than is sensible for CLUE = (and it likely does), then a supervisory timer that declares the session = failed might make sense. >=20 >>=20 >>> Section 5: The XML definition allows zero or more elements=20= >>> to appear in a message. If more than one is allowed, the document=20 >>> should explain how multiple IDs are handled. If they are not, then=20= >>> the schema and/or text needs to prohibit having more than one. >>>=20 >> [SPR] Actually, the schema states: >>=20 >> >>=20 >> This should indicate that clueId can appear either 0 or 1 times in a=20= >> valid XML document. The default value for maxOccurs is in fact 1. >> Don=E2=80=99t you agree on that? >=20 > Ah, you're correct. I'm not used to seeing minOccurs without = maxOccurs, but this is entirely fine as it's currently written. >=20 >>=20 >>> BLOCKER: Section 5.1: The description of =20 >>> describes a scheme in which multiple supported versions can be=20 >>> listed; and, if the list is omitted, it implies that only the = version=20 >>> described in is supported. This text does not define (nor does=20= >>> any other text that I can find) what should be set to when=20 >>> is used. Intuitively, it seems that should = be=20 >>> set to the largest minor version of the smallest major version=20 >>> advertised in , but that (or whatever the correct=20= >>> answer is) needs to be clearly spelled out. >>>=20 >> [SPR] I believe we were giving for granted that =E2=80=9Cv=E2=80=9D = should be, in such=20 >> case, the highest supported version (i.e., largest major and larger=20= >> minor numbers). Now that you make me think around that, I would = simply=20 >> say that the =E2=80=9Cv=E2=80=9D attribute MUST be set to one of the = versions that the=20 >> entity in question supports, as per the list. I=20= >> can, e.g., decide that I send an =E2=80=98options=E2=80=99 with = =E2=80=9Cv=3D12.23=E2=80=9D if the=20 >> list is like in the following: >>=20 >> 33.44 >> 27.0 >> 12.345 >> 1.44 >=20 > I think this formulation is a problem. I assume the intention behind = the "v" field is that some implementation that receives a version number = in the "v" field with a major number higher than it understands is = supposed to close the connection, since it runs a risk of = misinterpreting the contents of messages. So, in your example, if you = sent "v=3D12.23" to my implementation that only spoke major version 1, I = would reject it, even though you also support major version 1. That's = why I was thinking it should contain the smallest major version being = advertised. >=20 > The minor version is obviously less useful in this context, since = they're defined to be backwards and forwards compatible, but it's more = useful to know the highest minor version supported than some random = minor version, as it indicates the full feature set that is supported.=20= > The reason it's less useful is that the value can be parsed out of the = list. >=20 >>> BLOCKING: The state machines in section 6 and its subsections don't=20= >>> have transitions for all possible messages that could arrive in a=20 >>> state. This can cause interop issues. Please add text that clearly=20= >>> indicates whether such messages do or do not cause a transition. >>> (This might be as simple as "messages not shown for a state do not=20= >>> cause the state to change," but only if you carefully check that = this=20 >>> is true -- for example, what should an MP state machine do do if it=20= >>> gets a "CONF + ACK" in the state "WAIT FOR CONF"?) >>>=20 >> [SPR] In the specific case you mention, I would expect that a 302 is=20= >> generated (Invalid Parameter), since the incoming CONF should not=20 >> contain the element. This said, I see your point related to the=20= >> potential lack of some edges in the state machine graph. This point = is=20 >> obviously also related to the =E2=80=9Ctimeout=E2=80=9D issue you = raised before. >> Different ways of managing timeouts will definitely have different=20 >> impacts on the current state machines. >> We will defer the modification of the diagrams in question to the = next=20 >> revision round. In the meanwhile, we=E2=80=99ll give a thought to = potential=20 >> further unexpected transactions to be taken into account. >=20 > Based on my analysis above, I think the state machines will get a bit = simpler, as they won't have retransmission counts any longer. >=20 >>=20 >>> Section 6.2 describes a state machine that starts in a state called=20= >>> "WAIT FOR ADV." This state does not appear to be timer-supervised,=20= >>> meaning that implementations of this state machine can stay in this=20= >>> state literally forever. Is that the intention? >>>=20 >> [SPR] The idea would be to open a socket and start listening for=20 >> incoming advertisements. Isn=E2=80=99t that OK? >=20 > At some point, I think you're going to want to conclude that the CLUE = data channel isn't going to get set up correctly, and signal that to the = application in some way. This is probably on the order of a minute or = so. >=20 >>> Section 8 indicates that extensions need to indicate "the standard=20= >>> version of the protocol the extension refers to." Given that there = is=20 >>> compatibility within a major version of a protocol, I think this=20 >>> means to say "the major standard version of the protocol that the=20 >>> extension refers to.=E2=80=9D >>>=20 >> [SPR] My extension might be associated with version 3.6 of the=20 >> protocol. This means that it will need to be supported by all = versions=20 >> higher than that (3.7 onwards). Though, this does not entail that=20 >> versions 3.5 and lower should understand it. Right? >=20 > I'm a bit confused. Is the notion here that extensions, once = introduced, always become a mandatory-to-implement part of the protocol? = If that's the case, it's not clear why you would need to advertise them = explicitly, since support would be implied by the version number itself.=20= > (This isn't unheard of: it's how NFS has historically handled version = numbers, for example.) However, I didn't get the impression that CLUE = protocol extensions were handled in such a way. If this is the = intention, there needs to be a lot more text that makes this MTI aspect = of extensions clear, and a reconsideration of why you're signaling them = individually rather than inferring them from the version number. >=20 >>> Section 8 contains schema that contains a element. It=20 >>> should be clarified that this is the *protocol* version, not the >>> *extension* version (or, if it's the extension version, that needs = to=20 >>> be spelled out too, but I think you'll need a new namespace for=20 >>> that...?) >>>=20 >> [SPR] I thought this was clear from the third bullet point in the = list: >>=20 >> - the standard version of the protocol the extension refers to. >>=20 >> Isn=E2=80=99t this enough? In such a case, what would you suggest to = add? >=20 > Ah, I see. It wasn't clear that these three bullets corresponded to = the elements in the XML. Perhaps make this clearer with something like = "The values of the fields of the element take the following = values:" (and maybe move it closer to the actual XML). >=20 >>=20 >>> The remainder of this comment is non-blocking: I also find the=20 >>> "SHOULD" in this section to be highly perplexing. Can you explain = the=20 >>> rationale behind requiring schema, but not requiring any description=20= >>> of what the schema *means?) >>>=20 >> [SPR] It is like coding without adding comments/documentation.=20 >> Documentation is most welcome, but not mandatory. Don=E2=80=99t you = agree? >=20 > I don't. It seems more like committing a header file without the = corresponding implementation file. Just because people know what things = are called doesn't mean that they can handle them. For interop, you're = going to need some description of what the fields mean and how the = messages are handled. >=20 >>>=20 >>> The schema in section 9 contains: >>>=20 >>> >> schemaLocation=3D"data-model-schema-17.xsd"/> >>>=20 >>> If you do not intend to bake this "-17" into the document (and I=20 >>> can't imagine you do), please add an RFC editor note to change it to=20= >>> something else upon publication. >>>=20 >> [SPR] Done. I am not very familiar with RFC editor notes, indeed. = Here=20 >> is what we added at the beginning of section 9: >>=20 >> "NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd"=20 >> with the right schema location for the CLUE data model schema = document=20 >> (which is still to be defined at the time of this writing) in this=20 >> section prior to publication as an RFC.=E2=80=9D >>=20 >> Does this work for you? >=20 > That's perfect. Thanks! >=20 >>> Section 10 in general: While it does consume a lot of space, I don't=20= >>> think that defining six rather different message types and then=20 >>> showing only *one* type in the examples is very illustrative of the=20= >>> protocol. I would *STRONGLY* suggest adding at least a response=20 >>> message, and ideally the example section should contain at least one=20= >>> example for each of the six message types. >>>=20 >> [SPR] Will do in the (hopefully final) revision of the document. = Let=E2=80=99s=20 >> first double check that the proposed modifications are OK. >=20 > Sounds good. >=20 >>=20 >>> Section 12.1 has a strange double-double quote around the URN name,=20= >>> and section 12.3 repeats this for the MIME type. >>>=20 >> [SPR] I don=E2=80=99t understand this. Can you please clarify? >>=20 >=20 > Replace >=20 > ""urn:ietf:params:xml:ns:clue-protocol"". >=20 > with >=20 > "urn:ietf:params:xml:ns:clue-protocol". >=20 >=20 > And then replace >=20 > This section registers the ""application/clue+xml"" MIME type. >=20 > with >=20 > This section registers the "application/clue+xml" MIME type. >=20 >=20 > Thanks! >=20 > /a >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail=_B7558A76-E69B-4D04-86F0-75EEE1B3D127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yep! = I=E2=80=99ll come back with a revised version asap. BTW, Adam was asking = for some general feedback from the WG...

Cheers,

Simon
          =             =   _\\|//_
      =                     =   = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 6 Feb 2018, at 07:51, Roni Even (A) <roni.even@huawei.com> wrote:

Hi = Simon,
Can you look at the open comments from Adam so that = we can finish the work in CLUE
Roni

-----Original Message-----
From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Friday, November 03, 2017 10:07 PM
To: = Simon Pietro Romano
Cc: clue@ietf.org
Subject: Re: [clue] AD = Review: draft-ietf-clue-protocol-13

Thanks = for your thorough response! I've removed those issues that you've = addressed, and included responses to the remaining issues below.

IMPORTANT NOTE TO CLUE WORKING GROUP: There is = a discussion regarding retransmission timers that you need to have. See = the comments below for details.


On 10/6/17 1:37 PM, Simon Pietro Romano wrote:

Title: The rule of thumb is that all but a = small handful of
well-known acronyms need to be expanded = in titles and abstracts. I
recognize that "CLUE" is a bit = tortured, as acronyms go, but the
title of this document = is, broadly speaking, opaque. Please change it
to = something meaningful, such as "Protocol for Controlling Multiple
Streams for Telepresence (CLUE)=E2=80=9D

[SPR] Done.

I think this got missed. The header of the current version = still reads:

CLUE Working Group R. = Presta
Internet-Draft S. P. Romano
Intended = status: Standards Track University of Napoli
Expires: = April 9, 2018 October 6, 2017

=             &n= bsp;           &nbs= p;    CLUE protocol
=             &n= bsp;         = draft-ietf-clue-protocol-14


General: There are three instances of excessively long lines = in the
document.

[SPR] ???

The reformatting of XML in -14 has fixed this issue.

BLOCKER: = General: There are several mentions of timeouts and retry
thresholds in the text and its corresponding state machines; = however,
the document neither defines nor cites a = document as defining what
these timeout and retry values = are. These need to be defined and
described. If the timer = and retry scheme allows the two ends of the
connection to = have different values for timeouts and number of
retries, = then there need to be additional error procedures that allow
the MC and MP state machines to stay in sync (if the = timer/retry
values can be different, it's possible for = one state machine to
transition to "terminated," while = the other is still active, and you
need messaging to = clean this up).

[SPR] Our idea was to rely = on a single, fixed, application-level
(i.e., CLUE-level) = timeout value, rather than leveraging a number of
them = (T1, T2, T4, plus Timer A through Timer K) as in SIP. The value
of the one and only timer would be the usual RTT estimate = (~500ms).
Differently from protocols like SIP, we are also = leveraging retransmit
counts to get out of a = timeout-driven retransmission loop. We=E2=80=99re not
adding such information to the revised version of the draft, = because
we=E2=80=99d first like to get your feedback on = the approach. If you (and the
rest of the group) believe = this is a feasible approach, we can expand
on that in a = further version of the document.

In thinking through what this scheme should look like, it = occurs to me that the CLUE messages are defined to be sent over a = reliable transport (SCTP), which has its own retransmission timers and = eventual timeouts.
Implementing a retransmission scheme = on top of a reliable transport -- especially one as aggressive as you = suggest above -- will put more traffic on the network when congestion = occurs rather than less.

So, in the final = analysis, I think the action here is to remove retransmission timers and = retry counts altogether. If the underlying transport takes longer to = detect a failure than is sensible for CLUE (and it likely does), then a = supervisory timer that declares the session failed might make sense.


Section 5: The XML = definition allows zero or more <clueId> elements
to = appear in a message. If more than one is allowed, the document
should explain how multiple IDs are handled. If they are not, = then
the schema and/or text needs to prohibit having more = than one.

[SPR] Actually, the = schema states:

<xs:element name=3D"clueId"= type=3D"xs:string" minOccurs=3D"0=E2=80=9D/>

This should indicate that clueId can appear either 0 or 1 = times in a
valid XML document. The default value for = maxOccurs is in fact 1.
Don=E2=80=99t you agree on = that?

Ah, you're correct. I'm = not used to seeing minOccurs without maxOccurs, but this is entirely = fine as it's currently written.


BLOCKER: Section 5.1: The description of = <supportedVersions>
describes a scheme in which = multiple supported versions can be
listed; and, if the = list is omitted, it implies that only the version
described= in <v> is supported. This text does not define (nor does
any other text that I can find) what <v> should be set = to when
<supportedVersions> is used. Intuitively, = it seems that <v> should be
set to the largest = minor version of the smallest major version
advertised in = <supportedVersions>, but that (or whatever the correct
answer is) needs to be clearly spelled out.

[SPR] I believe we were giving for granted that = =E2=80=9Cv=E2=80=9D should be, in such
case, the highest = supported version (i.e., largest major and larger
minor = numbers). Now that you make me think around that, I would simply
say that the =E2=80=9Cv=E2=80=9D attribute MUST be set to one = of the versions that the
entity in question supports, as = per the <supportedVersions> list. I
can, e.g., = decide that I send an =E2=80=98options=E2=80=99 with =E2=80=9Cv=3D12.23=E2= =80=9D if the
<supportedVersions> list is like in = the following:

<version>33.44</version>
<version>27.0</version>
<version>12.345</version>
<version>1.44</version>

I think this formulation is a = problem. I assume the intention behind the "v" field is that some = implementation that receives a version number in the "v" field with a = major number higher than it understands is supposed to close the = connection, since it runs a risk of misinterpreting the contents of = messages. So, in your example, if you sent "v=3D12.23" to my = implementation that only spoke major version 1, I would reject it, even = though you also support major version 1. That's why I was thinking it = should contain the smallest major version being advertised.

The minor version is obviously less useful in = this context, since they're defined to be backwards and forwards = compatible, but it's more useful to know the highest minor version = supported than some random minor version, as it indicates the full = feature set that is supported.
The reason it's less = useful is that the value can be parsed out of the <version> = list.

BLOCKING: The state = machines in section 6 and its subsections don't
have = transitions for all possible messages that could arrive in a
state. This can cause interop issues. Please add text that = clearly
indicates whether such messages do or do not = cause a transition.
(This might be as simple as "messages = not shown for a state do not
cause the state to change," = but only if you carefully check that this
is true -- for = example, what should an MP state machine do do if it
gets = a "CONF + ACK" in the state "WAIT FOR CONF"?)

[SPR] In the specific case you mention, I would = expect that a 302 is
generated (Invalid Parameter), since = the incoming CONF should not
contain the <ack> = element. This said, I see your point related to the
potential lack of some edges in the state machine graph. This = point is
obviously also related to the =E2=80=9Ctimeout=E2=80= =9D issue you raised before.
Different ways of managing = timeouts will definitely have different
impacts on the = current state machines.
We will defer the modification of = the diagrams in question to the next
revision round. In = the meanwhile, we=E2=80=99ll give a thought to potential
further unexpected transactions to be taken into account.

Based on my analysis above, I = think the state machines will get a bit simpler, as they won't have = retransmission counts any longer.


Section 6.2 describes a state machine that starts in a state = called
"WAIT FOR ADV." This state does not appear to be = timer-supervised,
meaning that implementations of this = state machine can stay in this
state literally forever. = Is that the intention?

[SPR] = The idea would be to open a socket and start listening for
incoming advertisements. Isn=E2=80=99t that OK?

At some point, I think you're = going to want to conclude that the CLUE data channel isn't going to get = set up correctly, and signal that to the application in some way. This = is probably on the order of a minute or so.

Section 8 indicates that extensions need to indicate "the = standard
version of the protocol the extension refers = to." Given that there is
compatibility within a major = version of a protocol, I think this
means to say "the = major standard version of the protocol that the
extension = refers to.=E2=80=9D

[SPR] My = extension might be associated with version 3.6 of the
protocol. This means that it will need to be supported by all = versions
higher than that (3.7 onwards). Though, this = does not entail that
versions 3.5 and lower should = understand it. Right?

I'm a = bit confused. Is the notion here that extensions, once introduced, = always become a mandatory-to-implement part of the protocol? If that's = the case, it's not clear why you would need to advertise them = explicitly, since support would be implied by the version number itself. =
(This isn't unheard of: it's how NFS has historically = handled version numbers, for example.) However, I didn't get the = impression that CLUE protocol extensions were handled in such a way. If = this is the intention, there needs to be a lot more text that makes this = MTI aspect of extensions clear, and a reconsideration of why you're = signaling them individually rather than inferring them from the version = number.

Section 8 contains = schema that contains a <version> element. It
should = be clarified that this is the *protocol* version, not the
*extension* version (or, if it's the extension version, that = needs to
be spelled out too, but I think you'll need a = new namespace for
that...?)

[SPR] I thought this was clear from the third = bullet point in the list:

- the = standard version of the protocol the extension refers to.

Isn=E2=80=99t this enough? In such a case, = what would you suggest to add?

Ah, I see. It wasn't clear that these three bullets = corresponded to the elements in the XML. Perhaps make this clearer with = something like "The values of the fields of the <extension> = element take the following values:" (and maybe move it closer to the = actual XML).


The = remainder of this comment is non-blocking: I also find the
"SHOULD" in this section to be highly perplexing. Can you = explain the
rationale behind requiring schema, but not = requiring any description
of what the schema *means?)

[SPR] It is like coding without = adding comments/documentation.
Documentation is most = welcome, but not mandatory. Don=E2=80=99t you agree?

I don't. It seems more like = committing a header file without the corresponding implementation file. = Just because people know what things are called doesn't mean that they = can handle them. For interop, you're going to need some description of = what the fields mean and how the messages are handled.


The schema in section 9 contains:

<xs:import = namespace=3D"urn:ietf:params:xml:ns:clue-info"
schemaLocation=3D"data-model-schema-17.xsd"/>

If you do not intend to bake this "-17" into = the document (and I
can't imagine you do), please add an = RFC editor note to change it to
something else upon = publication.

[SPR] Done. I am = not very familiar with RFC editor notes, indeed. Here
is = what we added at the beginning of section 9:

"NOTE TO THE RFC-Editor: Please replace = "data-model-schema-17.xsd"
with the right schema location = for the CLUE data model schema document
(which is still = to be defined at the time of this writing) in this
section = prior to publication as an RFC.=E2=80=9D

Does= this work for you?

That's = perfect. Thanks!

Section 10 in general: = While it does consume a lot of space, I don't
think that = defining six rather different message types and then
showing only *one* type in the examples is very illustrative = of the
protocol. I would *STRONGLY* suggest adding at = least a response
message, and ideally the example section = should contain at least one
example for each of the six = message types.

[SPR] Will do = in the (hopefully final) revision of the document. Let=E2=80=99s
first double check that the proposed modifications are OK.

Sounds good.


Section 12.1 has a strange double-double quote = around the URN name,
and section 12.3 repeats this for = the MIME type.

[SPR] I don=E2=80= =99t understand this. Can you please clarify?


Replace

=    ""urn:ietf:params:xml:ns:clue-protocol"".

with

=    "urn:ietf:params:xml:ns:clue-protocol".


And then replace

   This section registers the = ""application/clue+xml"" MIME type.

with

   This section registers the = "application/clue+xml" MIME type.


Thanks!

/a

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

= --Apple-Mail=_B7558A76-E69B-4D04-86F0-75EEE1B3D127-- From nobody Mon Feb 12 00:10:14 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BDE120725 for ; Mon, 12 Feb 2018 00:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 lvV-5g76poGG for ; Mon, 12 Feb 2018 00:10:09 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 2A65F126E64 for ; Mon, 12 Feb 2018 00:10:09 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3A9189D403991 for ; Mon, 12 Feb 2018 08:10:05 +0000 (GMT) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 12 Feb 2018 08:10:06 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Mon, 12 Feb 2018 16:09:58 +0800 From: "Roni Even (A)" To: "clue@ietf.org" Thread-Topic: Question about timers (retry and timeouts) in draft-ietf-clue-protocol Thread-Index: AdOj2NoMzin0OvqsR8qbld+eN+ClsA== Date: Mon, 12 Feb 2018 08:09:58 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD863A56@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD863A56DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [clue] Question about timers (retry and timeouts) in draft-ietf-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 08:10:12 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD863A56DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, An important issue that was made by Adam during his AD review has to do wit= h timeout and retry thresholds, please provide feedback This is the comment: BLOCKER: General: There are several mentions of timeouts and retry threshol= ds in the text and its corresponding state machines; however, the document = neither defines nor cites a document as defining what these timeout and ret= ry values are. These need to be defined and described. If the timer and ret= ry scheme allows the two ends of the connection to have different values fo= r timeouts and number of retries, then there need to be additional error pr= ocedures that allow the MC and MP state machines to stay in sync (if the ti= mer/retry values can be different, it's possible for one state machine to t= ransition to "terminated," while the other is still active, and you need me= ssaging to clean this up). The remainder of this comment is non-blocking: R= elated to this, the document frequently refers to retries as "expiring" (e.= g., "retry expired" on the state diagrams). That doesn't really make sense = unless "retry" is the name of a timer rather than a counter; I think you me= an to say "exhausted" or something similar. My view as individual: The CLUE protocol is delivered using SCTP "CLUE entities are required to us= e ordered SCTP message delivery, with full reliability" so there is no prob= lem with timeout for retry for the data channel (https://tools.ietf.org/htm= l/draft-ietf-clue-datachannel-14#section-3.3.2 ) So the retry and timeout are for the application level and not for the sctp= transport. >From the discussion on the mailing list during the WGLC "The idea here is that the MC avoids entering a loop where the MP keeps on = sending an erroneous ADV hence forcing the MC to respond with a NACK. If th= is situation iterates for a while (# of retries), the MC terminates the ong= oing CLUE "session". I noticed that the discussion started even earlier and the conclusion was t= hat retry and timeout are needed but we also need default values which were= never listed My understanding is that when a receiver of a protocol message sends a nega= tive ack as response he allows for reties of fixed message and will allow i= t n times or quit after x time if no new message arrives. I think that for retries any number is good but I think that 2 is OK since = is the message sender cannot send a valid message we should abandon the cal= l. As for timeout this can be a short one that will still allow for a round= trip so my view that 1 second is enough Other thoughs? One side comment in section 6.2 there are two instances of "number of timeo= uts" ? Roni Even Clue co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD863A56DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

An important issue that was made by Adam during his = AD review has to do with timeout and retry thresholds, please provide feedb= ack

 

This is the comment:

BLOCKER: General: There are several mentions of timeouts and retry thres= holds in the text and its corresponding state machines; however, the docume= nt neither defines nor cites a document as defining what these timeout and = retry values are. These need to be defined and described. If the timer and retry scheme allows the two end= s of the connection to have different values for timeouts and number of ret= ries, then there need to be additional error procedures that allow the MC a= nd MP state machines to stay in sync (if the timer/retry values can be different, it's possible for one st= ate machine to transition to "terminated," while the other is sti= ll active, and you need messaging to clean this up). The remainder of this = comment is non-blocking: Related to this, the document frequently refers to retries as "expiring" (e.g., &= quot;retry expired" on the state diagrams). That doesn't really make s= ense unless "retry" is the name of a timer rather than a counter;= I think you mean to say "exhausted" or something similar.

 

My view as individual:

 

The CLUE protocol is delivered using SCTP “CLUE entities are required to use ordered SCTP mes= sage delivery, with full reliability” so there is no problem with tim= eout for retry for the data channel (https://tools.ietf.org/html/= draft-ietf-clue-datachannel-14#section-3.3.2 )

 =

So the retry and timeout= are for the application level and not for the sctp transport.

 =

From the discussion on t= he mailing list during the WGLC

 = 

The idea here is that the MC avo=
ids entering a loop where the MP keeps on sending an erroneous ADV hence fo=
rcing the MC to respond with a NACK. If this situation iterates for a while=
 (# of retries), the MC terminates the ongoing CLUE “session”. =

I noticed that the discussion started even earlier and the conclusion w=
as that retry and timeout are needed but we also need default values which =
were never listed
My understanding is that when a receiver of a protocol message sends a =
negative ack as response he allows for reties of fixed message and will all=
ow it n times or quit after x time if no new message arrives.
I think that for retries any number is good but I think that 2 is OK si=
nce is the message sender cannot send a valid message we should abandon the=
 call. As for timeout this can be a short one that will still allow for a r=
ound trip so my view that 1 second is enough
Other thoughs?
 
One side comment in section 6.2 there are t=
wo instances of “number of timeouts” ?

 =

 

 

Roni Even

Clue co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD863A56DGGEMM506MBXchina_-- From nobody Mon Feb 26 06:19:28 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5C1242F5 for ; Mon, 26 Feb 2018 06:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 O-p3-JRj-1qX for ; Mon, 26 Feb 2018 06:19:22 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 8F26F120725 for ; Mon, 26 Feb 2018 06:19:21 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1EB35A2E161A1 for ; Mon, 26 Feb 2018 14:19:17 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 26 Feb 2018 14:19:19 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Mon, 26 Feb 2018 22:19:09 +0800 From: "Roni Even (A)" To: "clue@ietf.org" Thread-Topic: Question about timers (retry and timeouts) in draft-ietf-clue-protocol Thread-Index: AdOj2NoMzin0OvqsR8qbld+eN+ClsA== Date: Mon, 26 Feb 2018 14:19:09 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86763B@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.90] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86763BDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [clue] Question about timers (retry and timeouts) in draft-ietf-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:19:26 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86763BDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, An important issue that was made by Adam during his AD review has to do wit= h timeout and retry thresholds, please provide feedback This is the comment: BLOCKER: General: There are several mentions of timeouts and retry threshol= ds in the text and its corresponding state machines; however, the document = neither defines nor cites a document as defining what these timeout and ret= ry values are. These need to be defined and described. If the timer and ret= ry scheme allows the two ends of the connection to have different values fo= r timeouts and number of retries, then there need to be additional error pr= ocedures that allow the MC and MP state machines to stay in sync (if the ti= mer/retry values can be different, it's possible for one state machine to t= ransition to "terminated," while the other is still active, and you need me= ssaging to clean this up). The remainder of this comment is non-blocking: R= elated to this, the document frequently refers to retries as "expiring" (e.= g., "retry expired" on the state diagrams). That doesn't really make sense = unless "retry" is the name of a timer rather than a counter; I think you me= an to say "exhausted" or something similar. My view as individual: The CLUE protocol is delivered using SCTP "CLUE entities are required to us= e ordered SCTP message delivery, with full reliability" so there is no prob= lem with timeout for retry for the data channel (https://tools.ietf.org/htm= l/draft-ietf-clue-datachannel-14#section-3.3.2 ) So the retry and timeout are for the application level and not for the sctp= transport. >From the discussion on the mailing list during the WGLC "The idea here is that the MC avoids entering a loop where the MP keeps on = sending an erroneous ADV hence forcing the MC to respond with a NACK. If th= is situation iterates for a while (# of retries), the MC terminates the ong= oing CLUE "session". I noticed that the discussion started even earlier and the conclusion was t= hat retry and timeout are needed but we also need default values which were= never listed My understanding is that when a receiver of a protocol message sends a nega= tive ack as response he allows for reties of fixed message and will allow i= t n times or quit after x time if no new message arrives. I think that for retries any number is good but I think that 2 is OK since = is the message sender cannot send a valid message we should abandon the cal= l. As for timeout this can be a short one that will still allow for a round= trip so my view that 1 second is enough Other thoughs? One side comment in section 6.2 there are two instances of "number of timeo= uts" ? Roni Even Clue co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86763BDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

An important issue that was made by Adam during his = AD review has to do with timeout and retry thresholds, please provide feedb= ack

 

This is the comment:

BLOCKER: General: There are several mentions of timeouts and retry thres= holds in the text and its corresponding state machines; however, the docume= nt neither defines nor cites a document as defining what these timeout and = retry values are. These need to be defined and described. If the timer and retry scheme allows the two end= s of the connection to have different values for timeouts and number of ret= ries, then there need to be additional error procedures that allow the MC a= nd MP state machines to stay in sync (if the timer/retry values can be different, it's possible for one st= ate machine to transition to "terminated," while the other is sti= ll active, and you need messaging to clean this up). The remainder of this = comment is non-blocking: Related to this, the document frequently refers to retries as "expiring" (e.g., &= quot;retry expired" on the state diagrams). That doesn't really make s= ense unless "retry" is the name of a timer rather than a counter;= I think you mean to say "exhausted" or something similar.

 

My view as individual:

 

The CLUE protocol is delivered using SCTP “CLUE entities are required to use ordered SCTP mes= sage delivery, with full reliability” so there is no problem with tim= eout for retry for the data channel (https://tools.ietf.org/html/= draft-ietf-clue-datachannel-14#section-3.3.2 )

 =

So the retry and timeout= are for the application level and not for the sctp transport.

 =

From the discussion on t= he mailing list during the WGLC

 = 

The idea here is that the MC avo=
ids entering a loop where the MP keeps on sending an erroneous ADV hence fo=
rcing the MC to respond with a NACK. If this situation iterates for a while=
 (# of retries), the MC terminates the ongoing CLUE “session”. =

I noticed that the discussion started even earlier and the conclusion w=
as that retry and timeout are needed but we also need default values which =
were never listed
My understanding is that when a receiver of a protocol message sends a =
negative ack as response he allows for reties of fixed message and will all=
ow it n times or quit after x time if no new message arrives.
I think that for retries any number is good but I think that 2 is OK si=
nce is the message sender cannot send a valid message we should abandon the=
 call. As for timeout this can be a short one that will still allow for a r=
ound trip so my view that 1 second is enough
Other thoughs?
 
One side comment in section 6.2 there are t=
wo instances of “number of timeouts” ?

 =

 

 

Roni Even

Clue co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD86763BDGGEMM506MBXchina_--