From nobody Wed Jan 6 00:28:12 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76E1ACCEC; Wed, 6 Jan 2016 00:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ-uDe3C7MjI; Wed, 6 Jan 2016 00:27:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE6C1ACD4C; Wed, 6 Jan 2016 00:27:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGK23886; Wed, 06 Jan 2016 08:27:48 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 08:27:46 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 08:27:46 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 16:26:57 +0800 From: "Songhaibin (A)" To: Jari Arkko , The IESG Thread-Topic: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) Thread-Index: AQHROJttgUybDgveaES+arOUwnCmH57uQIYw Date: Wed, 6 Jan 2016 08:26:56 +0000 Message-ID: References: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> In-Reply-To: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.568CD004.0115, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fff2b817d006db24d974353cd93ffeea Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , "p2psip@ietf.org" , "alexey.melnikov@isode.com" Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 08:27:58 -0000 Dear Jari, Thank you. Please see my reply in line. > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Thursday, December 17, 2015 3:20 PM > To: The IESG > Cc: p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf.org; > p2psip@ietf.org; alexey.melnikov@isode.com > Subject: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-1= 9: (with > DISCUSS) >=20 > Jari Arkko has entered the following ballot position for > draft-ietf-p2psip-diagnostics-19: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Per Alexey's Gen-ART review and my own read, Section 9.1 is inconsistent = with > Section 5.3. The document says earlier that first and last bits are reser= ved. This > is not shown in the table at all. What's perhaps causing the confusion is= that > there are special values (all 0s and all 1s) that convey nothing is reque= sted and > that everything is requested. This does not appear to be the same as havi= ng > two reserved bits. You may want one or the other or both, but as it stand= s 9.1 > or 5.3 do not seem to be saying the same thing. In Section 5.3, it says "The dMFlags field described above is a 64 bit fiel= d that allows initiator nodes to identify up to 62 items of base informatio= n to request in a request message (the first and last flags being reserved)= ." 62 bits can be used to indicate up to 62 diagnostic Kinds, but dMFlags r= eserves all "0"s that means nothing is requested, and all "1"s that means e= verything is requested. But at the same time, the first and last bits canno= t be used for other purposes. >=20 > Also, Section 5.3 uses "delimited" when it probably should have said > "terminated", unless there's more substructure in the SOFTWARE_VERSION > string than is identified by the text. It is the language problem and accepted.=20 BR, -Haibin Song >=20 >=20 >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Wed Jan 6 01:45:07 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6921ACE13; Wed, 6 Jan 2016 01:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFqoHkjIz5f9; Wed, 6 Jan 2016 01:45:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09531ACE10; Wed, 6 Jan 2016 01:45:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCO21981; Wed, 06 Jan 2016 09:44:58 +0000 (GMT) Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 09:44:57 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 09:44:57 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 17:44:51 +0800 From: "Songhaibin (A)" To: Alvaro Retana , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) Thread-Index: AQHROE3xg1hbhCRGu0GftwreM9LEL57uSeMg Date: Wed, 6 Jan 2016 09:44:50 +0000 Message-ID: References: <20151216220546.7663.70255.idtracker@ietfa.amsl.com> In-Reply-To: <20151216220546.7663.70255.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.568CE21B.002D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b57b51ea44527d2a47ed345b83233b60 Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 09:45:06 -0000 RGVhciBBbHZhcm8sDQoNClRoYW5rIHlvdSBhbmQgc2VlIG15IHJlcGx5IGluIGxpbmUuDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWx2YXJvIFJldGFuYSBbbWFpbHRv OmFyZXRhbmFAY2lzY28uY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTcsIDIwMTUg NjowNiBBTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0 aWNzQGlldGYub3JnOyBwMnBzaXAtY2hhaXJzQGlldGYub3JnOw0KPiBjamJjQGl0LnVjM20uZXM7 IHAycHNpcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBBbHZhcm8gUmV0YW5hJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xOTogKHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09N TUVOVCkNCj4gDQo+IEFsdmFybyBSZXRhbmEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzLTE5OiBEaXNj dXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+ IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSSBhbSBiYWxsb3Rpbmcg YSBESVNDVVNTIGJlY2F1c2UgSSBhbSBjb25jZXJuZWQgdGhhdCB0aGlzIGRvY3VtZW50IGRvZXNu J3QNCj4gYWN0dWFsbHkgZG8gd2hhdCBpdCBzZXQgb3V0IHRvIGFjaGlldmUuICBJIHdvdWxkIGxv dmUgaXQgaWYgZHVyaW5nIHRoZSBkaXNjdXNzaW9uIEkNCj4gd2FzIHBvaW50ZWQgdG8gdGhlIHBs YWNlcyB3aGVyZSBSRUxPQUQgYWxyZWFkeSBzb2x2ZXMgdGhlIGlzc3VlcywgYnV0IGZvciBub3cN Cj4gSSB3YXNuJ3QgYWJsZSB0byBmaW5kIHRoZW0uDQo+IA0KPiBBY2NvcmRpbmcgdG8gdGhlIHRl eHQsIGJvdGggZXh0ZW5zaW9ucyBhcmUgaW50ZW5kZWQgdG8gY29sbGVjdCBpbmZvcm1hdGlvbg0K PiAiYWxvbmcgdGhlIHBhdGgiLCBhbmQgdGhlIEZpZ3VyZXMgY2xlYXJseSBkZXBpY3Qgd2hhdCBp cyBpbnRlbmRlZCB0byBoYXBwZW4uDQo+IEhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhhdCBhcyBz cGVjaWZpZWQgKG9yIGF0IGxlYXN0IGFzIGV4cGxhaW5lZCkgdGhlIGJlaGF2aW9yIGlzDQo+IGd1 YXJhbnRlZWQuICBTcGVjaWZpYyBwb2ludHM6DQo+IA0KPiAxLiBSRkM2OTQwIHNheXMgKGluIFNl Y3Rpb24gNi4yLiAoU3ltbWV0cmljIFJlY3Vyc2l2ZSBSb3V0aW5nKSkgdGhhdCBhbg0KPiAib3Zl cmxheSBNQVkgYmUgY29uZmlndXJlZCB0byB1c2UgYWx0ZXJuYXRpdmUgcm91dGluZyBhbGdvcml0 aG1z4oCmW29yXeKApk1BWSBiZQ0KPiBzZWxlY3RlZCBvbiBhIHBlci1tZXNzYWdlIGJhc2lzIi4g SG93IGlzIHRoZSBzeW1tZXRyeSBlbmZvcmNlZCBpZiBvdGhlcg0KPiByb3V0aW5nIGFsZ29yaXRo bXMgYXJlIHVzZWQ/ICBFbmZvcmNpbmcgdGhhdCB0aGUgcGluZy90cmFjZSBtZXNzYWdlcyB1c2UN Cj4gc3ltbWV0cmljIHJvdXRpbmcgd2hlbiBvdGhlciBhbGdvcml0aG1zIGFyZSBpbiB1c2Ugd29u J3QgbmVjZXNzYXJpbHkgaGVscA0KPiBiZWNhdXNlIHRoZSBwYXRocyBtYXkgYmUgZGlmZmVyZW50 Lg0KDQpJIHRoaW5rIG9uZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCwgdGhlIGRyYWZ0IGRvZXMg bm90IGd1YXJhbnRlZSB3aGF0IGl0IGNvbnZleXMgbXVzdCBiZSB0aGUgaW5mb3JtYXRpb24gdGhh dCBjYXVzZWQgdGhlIHByZXZpb3VzIGZhaWx1cmVzLCBidXQgd2l0aCB0aGUgcmV0cmlldmVkIGlu Zm9ybWF0aW9uIGZyb20gdGhlIHByZXZpb3VzIHRyYXZlcnNlZCBub2RlcyAod2l0aCBoaWdoIHBy b2JhYmlsaXR5LCBhcyBpdCBjYW5ub3QgZ3VhcmFudGVlIHRoZSBleGFjdCBzYW1lIHBhdGgpLCBh IHVzZXIgb3IgbWFjaGluZSBjYW4gYW5hbHl6ZSBhbmQgaW5mZXIgd2hhdCBpcyB0aGUgcHJvYmxl bS4gU3ltbWV0cmljIHJvdXRpbmcgaXMgYWNoaWV2ZWQgYnkgdGhlIHZpYSBsaXN0ICh3aGF0ZXZl ciBESFQgcm91dGluZyBhbGdvcml0aG1zIGFyZSB1c2VkKSwgYnV0IHJlc3BvbnNlIG1lc3NhZ2Ug Y291bGQgZ28gdGhyb3VnaCBub3QgZXhhY3RseSB0aGUgc2FtZSBwYXRoIGFzIHRoZXJlIHN0aWxs IGNhbiBiZSBmYWlsdXJlcyBkdXJpbmcgdGhhdCBzaG9ydCBwZXJpb2QuDQoNCj4gDQo+IDIuIFJG QzY5NDAgYWxzbyAoaW4gNi4yLjIuIChSZXNwb25zZSBPcmlnaW5hdGlvbikpIHJlYWRzOiAidGhl IHJlc3BvbnNlDQo+IHRyYXZlcnNlcyB0aGUgc2FtZSBwZWVycyBhcyB0aGUgcmVxdWVzdCB0cmF2 ZXJzZWQsIGV4Y2VwdCBpbiByZXZlcnNlIG9yZGVyDQo+IChzeW1tZXRyaWMgcm91dGluZykgYW5k IHBvc3NpYmx5IHdpdGggZXh0cmEgbm9kZXMgKGxvb3NlIHJvdXRpbmcpLiINCj4gSW4gb3RoZXIg d29yZHMsIGV2ZW4gaWYgc3ltbWV0cmljIHJvdXRpbmcgaXMgdXNlZCwgdGhlcmUgaXMgbm8gZ3Vh cmFudGVlIHRoYXQNCj4gdGhlIHNhbWUgcGF0aCB3aWxsIGJlIGZvbGxvd2VkIGJ5IHRoZSByZXNw b25zZSwgdW5sZXNzIHRoZSBvcmlnaW5hdG9yIGJ1aWxkcyB0aGUNCj4gVmlhIExpc3Qgd2l0aCBz dHJpY3QgZGV0YWlscyBvZiBhbGwgdGhlIG5vZGVzIGluIHRoZSBwYXRoIC0tIG1heWJlIHRoaXMg aXMgd2hhdCBpcw0KPiBpbnRlbmRlZCwgYnV0IG5vIGV4cGxpY2l0IG1lbnRpb24gb2NjdXJzIGlu IHRoZSBkb2N1bWVudC4NCg0KSSBhZ3JlZSB0aGlzIHNob3VsZCBiZSBtZW50aW9uZWQgaW4gdGhl IGRvY3VtZW50Lg0KDQo+IA0KPiAzLiBJbiA0LjMsIHdoYXQgZG9lcyAiZGlyZWN0bHkgb3Igdmlh IHN5bW1ldHJpYyByb3V0aW5nIiBtZWFuPyBJcyBpdCBkaXJlY3RseQ0KPiBjb25uZWN0ZWQ/IElm IHNvLCB0aGVuIChmb3IgdGhlIHRleHQgaW4gNC4zKSB0aGF0IHdvdWxkIG1lYW4gdGhhdCBDIGlz IGFkamFjZW50DQo+IHRvIEEsIGFuZCBldmVuIHRob3VnaCBpdCBpcyB0aGUgbmV4dCBob3AgYWZ0 ZXIgQiwgdGhlIHBhdGggdGFrZW4gdG8gcmVhY2ggQyB3aXRoDQo+IHRoZSBQYXRoVHJhY2sgcmVx dWVzdCBkb2Vzbid0IGluY2x1ZGUgQiDigJQgdGhlIHJlc3VsdCBpcyB0aGF0IHRoZSBkaWFnbm9z dGljDQo+IGluZm9ybWF0aW9uIHJlY2VpdmVkIGZyb20gQyBtYXkgbm90IGJlIHJlbGV2YW50IHJl bGF0aXZlIHRvIGRlc3RpbmF0aW9uIEQuDQoNCkFzIGVhY2ggUGF0aFRyYWNrIHJlcXVlc3Qgd2ls bCBjb250YWluIHRoZSBkZXN0aW5hdGlvbiBJRCwgd2hpY2ggd2FzIHRoZSBzYW1lIGRlc3RpbmF0 aW9uIElEIGFzIHRoZSBwcmV2aW91c2x5IGZhaWxlZCBtZXNzYWdlLiBTbyBubyBtYXR0ZXIgaG93 IHRoZSBQYXRoVHJhY2sgcmVxdWVzdCBhcnJpdmVzIHRvIEMsIEMgd2lsbCBoYXZlIGEgbG9vayBh dCB0aGF0IGRlc3RpbmF0aW9uIElEIGZvciB0aGUgbmV4dCBzdGVwLiANCg0KPiANCj4gQXJlIHRo ZXJlIGltcGxlbWVudGF0aW9ucyBhdmFpbGFibGU/ICBXaGF0IGhhcyBiZWVuIHRoZSBleHBlcmll bmNlPyBUaGUNCj4gU2hlcGhlcmQncyB3cml0ZS11cCBkaWRuJ3QgbWVudGlvbiBhbnksIGFuZCB0 aGUgVEJEIGNvZGVzIG1ha2UgbWUgdGhpbmsgdGhhdA0KPiBtYXliZSBFeHBlcmltZW50YWwgbWln aHQgYmUgYSBiZXR0ZXIgc3RhdHVzIGZvciB0aGlzIGRvY3VtZW50Lg0KDQpJbiBteSBtZW1vcnks IHRoZXJlIHdhcyBvbmUgc2V2ZXJhbCB5ZWFycyBhZ28sIGJ1dCBub3QgYmFzZWQgb24gUkVMT0FE LiANCg0KDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IEluIGdlbmVyYWwsIGFzIG90aGVycyBoYXZlIG1lbnRpb25lZCwgSSB0aGluayB0aGUg dGV4dCBjb3VsZCBiZSBhIGxvdCBjbGVhcmVyIGFuZA0KPiBub3QgbGVhdmUgc29tZSBjb25jZXB0 cyB0byBpbnRlcnByZXRhdGlvbi4NCj4gDQo+IDEuIEluIDQuMi4xLCB0aGUgTWVzc2FnZUV4dGVu c2lvbiBpcyBkZWZpbmVkIHdpdGggYSBCb29sZWFuIG9mICJjcml0aWNhbCIsIGJ1dA0KPiB0aGUg dGV4dCAoYSBwYXJhZ3JhcGggbGF0ZXIpIHNheXMgdGhhdCB0aGlzICJleHRlbnNpb24gaXMgbm90 IGNyaXRpY2FsIi4gSSBtYXkgYmUNCj4gbWlzc2luZyBzb21lIG9mIHRoZSBzZW1hbnRpY3MsIG9y IHRoZXJlJ3MgYW4gZXJyb3Igc29tZXdoZXJlLg0KDQpNeSB1bmRlcnN0YW5kaW5nIHdpdGggUkVM T0FELCBpZiB2YWx1ZSBvZiAiY3JpdGljYWwiIGNhbiBiZSB0cnVlIG9yIGZhbHNlLCBpZiBpdCBp cyBjcml0aWNhbCwgdGhlbiBldmVyeSBub2RlIG11c3Qgc3VwcG9ydCB0aGUgZXh0ZW5zaW9uLCBp ZiBpdCBpcyBub3QgY3JpdGljYWwsIHRoZW4gaXQgaXMgb3B0aW9uYWwgdG8gc3VwcG9ydCBpdC4g QXMgaXQgZXhwbGFpbnMgaW4gdGhhdCBzZWN0aW9uLCAiSWYgYSBwZWVyIGRvZXMgbm90IHN1cHBv cnQgdGhlIGV4dGVuc2lvbiwgdGhleSB3aWxsIHNpbXBseSBpZ25vcmUgdGhlIGRpYWdub3N0aWMg cG9ydGlvbiBvZiB0aGUgbWVzc2FnZS4uLiINCg0KPiANCj4gMi4gSW4gNC4zLi50aGUgbGFzdCBw YXJhZ3JhcGggcmVhZHM6IGlmICIuLi5zdWNjZXNpdmUgY2FsbHMgdG8gUGF0aFRyYWNrIHJldHVy bg0KPiBkaWZmZXJlbnQgcGF0aHMsIHRoZSByZXN1bHRzIHNob3VsZCBiZSBkaXNjYXJkZWQgYW5k IHRoZSByZXF1ZXN0IHJlc2VudCwNCj4gZW5zdXJpbmcgdGhhdCB0aGUgc2Vjb25kIHJlcXVlc3Qg dHJhdmVyc2VzIHRoZSBhcHByb3ByaWF0ZSBwYXRoIi4NCj4gUGF0aCBjaGFuZ2VzIGFyZSBhIGZh Y3Qgb2YgbGlmZSDigJQgdGhlIHNlY29uZCByZXF1ZXN0IG1heSBqdXN0IGJlIHJlZmxlY3Rpbmcg dGhlDQo+IG5ldyBwYXRoLCBzbyByZXNlbmRpbmcgaXQgaW4gYW4gYXR0ZW1wdCB0byBmaW5kIHRo ZSAiYXBwcm9wcmlhdGUgcGF0aCIgbWF5IGJlDQo+IGZ1dGlsZS4NCg0KQXQgbGVhc3QgaW4gdGhl IHByZXZpb3VzIHR3byBhdHRlbXB0cywgdGhlIHBhdGggd2FzICJzdGFibGUiLiANCg0KPiAzLiBX aGF0IGlzIGEgInJvdXRpbmcgbW9kZSI/ICBTZWN0aW9uIDQuMy4xLiAoTmV3IFJFTE9BRCBSZXF1 ZXN0Og0KPiBQYXRoVHJhY2spIHRhbGtzIGFib3V0IGl0IHdoZW4gc2F5aW5nIHRoYXQgdGhlICJQ YXRoVHJhY2sgcmVxdWVzdCBjYW4gYmUNCj4gcm91dGVkIGRpcmVjdGx5IG9yIHRocm91Z2ggdGhl IG92ZXJsYXkgYmFzZWQgb24gdGhlIHJvdXRpbmcgbW9kZSIuICBMYXRlcg0KPiBTZWN0aW9uIDYu Mi4gKE1lc3NhZ2UgUHJvY2Vzc2luZzogSW50ZXJtZWRpYXRlIFBlZXJzKSBzYXlzIHRoYXQgInBy b2Nlc3NpbmcNCj4gdGhpcyByZXF1ZXN0IGFjY29yZGluZyB0byB0aGUgb3ZlcmxheSBzcGVjaWZp ZWQgcm91dGluZyBtb2RlIGZyb20gUkVMT0FEDQo+IHByb3RvY29sIiAtLSBJIGxvb2tlZCBpbiBS RkM2OTQwIGZvciAicm91dGluZyBtb2RlIiwgYnV0IGRpZG4ndCBmaW5kIGFueXRoaW5nLg0KPiBO b3RlIHRoYXQgaXQgYWxzbyBsb29rcyB0byBtZSBsaWtlIHRoZXJlJ3Mgbm8gcGxhY2UgaW4gdGhl IERpYWdub3N0aWNzUmVxdWVzdCB0bw0KPiBpbmRpY2F0ZSBhIG1vZGUuLg0KDQpUaGlzIGRyYWZ0 IHNob3VsZCBhZGQgYSByZWZlcmVuY2UgdG8gUkZDIDcyNjMgZm9yIHRoZSByb3V0aW5nIG1vZGUu DQoNCj4gNC4gU2VjdGlvbiA1LjMuIChkTUZsYWdzIGFuZCBEaWFnbm9zdGljIEtpbmQgSUQgVHlw ZXMpIGRlZmluZXMgYW4NCj4gIlVOREVSTEFZX0hPUCAoOCBiaXRzKTogSW5kaWNhdGVzIHRoZSBJ UCBsYXllciBob3BzIGZyb20gdGhlIGludGVybWVkaWF0ZQ0KPiBwZWVyIHdoaWNoIHJlY2VpdmVz IHRoZSBkaWFnbm9zdGljcyBtZXNzYWdlIHRvIHRoZSBuZXh0IGhvcCBwZWVyIGZvciB0aGlzDQo+ IG1lc3NhZ2UuIiAgSG93IGlzIHRoYXQgaW5mb3JtYXRpb24gZGVyaXZlZD8NCg0KSXQgY2FuIHVz ZSB0aGUgdHJhY2Vyb3V0ZSB0b29sLg0KDQo+IDUuIEkgdGhpbmsgdGhhdCB0aGUgUmVmZXJlbmNl IHRvIFJGQzUyMjYgc2hvdWxkIGJlIE5vcm1hdGl2ZS4NCj4gDQoNCkFjY2VwdGVkLg0KDQo+IA0K PiBJIGFsc28gYWdyZWUgd2l0aCBvdGhlcnMgdGhhdCB0aGUgdGl0bGUgc2hvdWxkIHByb2JhYmx5 IGJlIHNvbWV0aGluZyBhcm91bmQNCj4gUkVMT0FEIERpYWdub3N0aWNzLCBhbmQgdGhhdCB0aGlz IHdvcmsgZG9lc24ndCByZWFsbHkgdXBkYXRlIFJGQzY5NDAsIGl0DQo+IGV4dGVuZHMgaXQgaW4g aW5kZXBlbmRlbnQgd2F5cy4NCg0KSXQgc2VlbXMgd2UgY2FuIGFjaGlldmUgYSBjb25zZW5zdXMg aGVyZSB0aGF0IGl0IGV4dGVuZHMgUkVMT0FELiBXaGF0IGFib3V0IHRoZSB0aXRsZSAiUkVMT0FE IEV4dGVuc2lvbiBmb3IgUDJQIE92ZXJsYXkgRGlhZ25vc3RpY3MiPw0KDQoNClRoYW5rcyBhZ2Fp biwNCg0KLUhhaWJpbiBTb25nDQoNCg0K From nobody Wed Jan 6 16:34:45 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6CD1A1A28; Wed, 6 Jan 2016 16:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqtub7AO8kQr; Wed, 6 Jan 2016 16:34:38 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 092EB1A1A00; Wed, 6 Jan 2016 16:34:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 14C572CCE5; Thu, 7 Jan 2016 02:34:36 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo-6Rx0vDSP3; Thu, 7 Jan 2016 02:34:35 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4637D2CCAE; Thu, 7 Jan 2016 02:34:35 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0CEAF76B-59FE-47BD-8F23-ADDB6B019503"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Jari Arkko In-Reply-To: Date: Thu, 7 Jan 2016 02:34:31 +0200 Message-Id: <11E81FFA-7187-43B4-BA99-40859D835FDD@piuha.net> References: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> To: "Songhaibin (A)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "alexey.melnikov@isode.com" , "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 00:34:41 -0000 --Apple-Mail=_0CEAF76B-59FE-47BD-8F23-ADDB6B019503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > In Section 5.3, it says "The dMFlags field described above is a 64 bit = field that allows initiator nodes to identify up to 62 items of base = information to request in a request message (the first and last flags = being reserved)." 62 bits can be used to indicate up to 62 diagnostic = Kinds, but dMFlags reserves all "0"s that means nothing is requested, = and all "1"s that means everything is requested. But at the same time, = the first and last bits cannot be used for other purposes. Right. Can that be explained somewhere, and can Section 9.1 show the two = aspects? That is, the all 0s/1s *and* first and last bits being = reserved? The current text does not reserve the first and last bits. It = only reserves the all 0s and all 1s=85 = +-------------------------+------------------------------+----------+ | diagnostic information |diagnostic flag in dMFlags | RFC = | = |-------------------------+------------------------------+----------| |Reserved | 0x 0000 0000 0000 0000 = |RFC-[TBDX]| |STATUS_INFO | 0x 0000 0000 0000 0001 = |RFC-[TBDX]| |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 = |RFC-[TBDX]| |PROCESS_POWER | 0x 0000 0000 0000 0004 = |RFC-[TBDX]| |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 = |RFC-[TBDX]| |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 = |RFC-[TBDX]| |SOFTWARE_VERSION | 0x 0000 0000 0000 0020 = |RFC-[TBDX]| |MACHINE_UPTIME | 0x 0000 0000 0000 0040 = |RFC-[TBDX]| |APP_UPTIME | 0x 0000 0000 0000 0080 = |RFC-[TBDX]| |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 = |RFC-[TBDX]| |DATASIZE_STORED | 0x 0000 0000 0000 0200 = |RFC-[TBDX]| |INSTANCES_STORED | 0x 0000 0000 0000 0400 = |RFC-[TBDX]| |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 = |RFC-[TBDX]| |EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 = |RFC-[TBDX]| |EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 = |RFC-[TBDX]| |UNDERLAY_HOP | 0x 0000 0000 0000 4000 = |RFC-[TBDX]| |BATTERY_STATUS | 0x 0000 0000 0000 8000 = |RFC-[TBDX]| |Reserved | 0x FFFF FFFF FFFF FFFF = |RFC-[TBDX]| +-------------------------+------------------------------+=97=97=97=97= + But maybe I=92m missing something. I thought the text above should be something like this instead: = +-------------------------+------------------------------+----------+ | diagnostic information |diagnostic flag in dMFlags | RFC = | = |-------------------------+------------------------------+----------| |Reserved All 0s value | 0x 0000 0000 0000 0000 |RFC-[TBDX]| |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| |STATUS_INFO | 0x 0000 0000 0000 0002 = |RFC-[TBDX]| |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 = |RFC-[TBDX]| |PROCESS_POWER | 0x 0000 0000 0000 0008 = |RFC-[TBDX]| |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 = |RFC-[TBDX]| |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 = |RFC-[TBDX]| |SOFTWARE_VERSION | 0x 0000 0000 0000 0040 = |RFC-[TBDX]| |MACHINE_UPTIME | 0x 0000 0000 0000 0080 = |RFC-[TBDX]| |APP_UPTIME | 0x 0000 0000 0000 0100 = |RFC-[TBDX]| |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 = |RFC-[TBDX]| |DATASIZE_STORED | 0x 0000 0000 0000 0400 = |RFC-[TBDX]| |INSTANCES_STORED | 0x 0000 0000 0000 0800 = |RFC-[TBDX]| |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 = |RFC-[TBDX]| |EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 = |RFC-[TBDX]| |EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 = |RFC-[TBDX]| |UNDERLAY_HOP | 0x 0000 0000 0000 8000 = |RFC-[TBDX]| |BATTERY_STATUS | 0x 0000 0000 0001 0000 = |RFC-[TBDX]| |Reserved Last Bit | 0x 8000 0000 0000 0000 = |RFC-[TBDX]| |Reserved All 1s Value | 0x FFFF FFFF FFFF FFFF = |RFC-[TBDX]| +-------------------------+------------------------------+=97=97=97=97= + >=20 >>=20 >> Also, Section 5.3 uses "delimited" when it probably should have said >> "terminated", unless there's more substructure in the = SOFTWARE_VERSION >> string than is identified by the text. >=20 > It is the language problem and accepted. Thanks! Jari --Apple-Mail=_0CEAF76B-59FE-47BD-8F23-ADDB6B019503 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWjbKXAAoJEM80gCTQU46qi1sP/2o+fGoTI5GTrctQCAruC1Fi iiVTfFCbpLyWnrixSmJybwQuyoGfkySNjkDnVgmPrtYPwfvGWy59HXuVsT4k0UTP qBDYjBTSUlrVYdjmn0QcD6V++Q2MbEhFzYVs29uORQMFKFo53Yf3UlQ8+/IbeItD Mm2FidD8Jf5cmFXTv6d8txssIUi1Y90UTTqbZf1gDXXObZRcmN7PdMq88eXjZ6tk bybRw32xbHGV1fgQSS+VplE2VwGuncrN0oZLOoyh7cO5l80JrNcYG1fu4OTYnwCK Dj1/iAWcXdzL0EvstJfXN9Oe89D7dOZHGR3AiFAGFDmjoVPOIJL6q70W9FvIgGeq TtCXwIAFjZX7D/8i5NlRvwiNYRiVhaYAGlWnhXQVDg+vxOnFT54qb8v0EtUkCma7 sAgMIhsZDWD7mXFt5Npn8ReF7KnDV5oe3clJ1fQrEqKEieZqLqBxM3xKhV2ARm9e LBXQbcKa30U9xMsnQ3Fk1qjii1j38QL7414+ZgtItVKtxrwtHNN1Cs+ufxx6Btzj h02RXD4cer5kYiHIpgWuoJmQIp+pOR2ITA0JHLFwnm4pYKU9m7FC6+3SQS6kF2tU PNr46IeWCbCfgb1B0ltdOoMOnVd43smko+TS5FsU9Kk0wke+zJHBCmaw6QvdwjiP zbLjz4IwjjAsUuEtNZqn =1HHX -----END PGP SIGNATURE----- --Apple-Mail=_0CEAF76B-59FE-47BD-8F23-ADDB6B019503-- From nobody Wed Jan 6 23:51:13 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE231A872C; Wed, 6 Jan 2016 23:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2CUQm2Jd2-t; Wed, 6 Jan 2016 23:51:10 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FCE1A8738; Wed, 6 Jan 2016 23:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2323; q=dns/txt; s=iport; t=1452153070; x=1453362670; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oqfX6ilC8PI0/DWCpjohadhoT8hHLNQflZ6Pty1vMC8=; b=Ze885Lpbmf6um4PPt0Tp0pqrNqDzLmgh1hjtnsjAT1CsRxyimP98XAny 7yMRRxa0khFCP4pXolQ8+9/W+9Y4YjHGDkL/Uuo67FEQtzEKpT79c72SF hfPPFlc9+MRM2Emfl6DaI/l9eGh33sZB+335ErHT009l00/9mHQFEqgf+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBAABGI5W/xbLJq1ehAxtiFm1QxgKh?= =?us-ascii?q?SNKAoFtAQEBAQEBgQuENAEBAQQBAQE1NgoBDAQLEQQBAQoWCAcJAwIBAgEVHwk?= =?us-ascii?q?IBgEMBgIBAYgrDsE4AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVoR/hCYRAYUEA?= =?us-ascii?q?QSHXo8thUKIE4FchEODB4VUjktkgkqBQT00AYQegUIBAQE?= X-IronPort-AV: E=Sophos;i="5.20,532,1444694400"; d="scan'208";a="624326830" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2016 07:51:07 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u077p5mT029644; Thu, 7 Jan 2016 07:51:06 GMT To: "Songhaibin (A)" , The IESG References: <20151216200640.15772.16745.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <568E18E8.7020408@cisco.com> Date: Thu, 7 Jan 2016 08:51:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , "Mehmet \(NSN - DE/Munich\)" , "draft-ietf-p2psip-diagnostics@ietf.org" , "Ersue@ietfa.amsl.com" Subject: Re: [P2PSIP] Benoit Claise's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 07:51:12 -0000 Dear Songhaibin, Thanks. I'll review the diffs with the next version. Regards, B. > Dear Benoit, > > Please see my reply in line. > >> -----Original Message----- >> From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Benoit Claise >> Sent: Thursday, December 17, 2015 4:07 AM >> To: The IESG >> Cc: p2psip-chairs@ietf.org; p2psip@ietf.org; Mehmet (NSN - DE/Munich); >> draft-ietf-p2psip-diagnostics@ietf.org; Ersue@ietfa.amsl.com >> Subject: [P2PSIP] Benoit Claise's No Objection on >> draft-ietf-p2psip-diagnostics-19: (with COMMENT) >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-p2psip-diagnostics-19: No Objection >> >> When responding, please keep the subject line intact and reply to all email >> addresses included in the To and CC lines. (Feel free to cut this introductory >> paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I agree with Ben, Joel & Mehmet (OPS DIR), and Barry. >> >> On top of that, >> - This document looks to me as a specific implementation, written in a draft >> format. > It was to make it clearer to document both the messages and message processing after getting some feedback from the p2psip WG. > >> - While reading the document, I was wondering: Is this P2P specific or P2PSIP >> specific? > It is P2P specific. The next revision will eliminate that confusion in total. > >> Maybe a missed opportunity to have generic OAM principles for P2P, with >> RELOAD extension. >> - Finally, any connection with LIME, at least on the presentation aspects. >> > Maybe there is opportunity in the near future to have OAM for RELOAD with YANG model :) > > > Wish you happy new year, > -Haibin Song > > >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > . > From nobody Thu Jan 14 08:11:32 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21271A0BE8 for ; Thu, 14 Jan 2016 08:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hS4Yj2AZlm0k for ; Thu, 14 Jan 2016 08:11:30 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A1A1A19FA for ; Thu, 14 Jan 2016 08:11:29 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4319B2085A for ; Thu, 14 Jan 2016 11:11:29 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 14 Jan 2016 11:11:29 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=+CiLT 5PIiLKXY0XMGrFa3nyJGrA=; b=ofW4j+UHvZ9ITBC5801iwQ6x3urHv0gghRhKZ GpQMkqu1+GDoiZOmPqBIFoUz541Dj3bSNMGOrDqz1P1UYFrXojqou9zx3z2JdJid pBNJeoy1W6VXenQVagjkWox3p4bKCbJSxuJOqpHtj+F/kbqk+fGM2XP6lteBI/KN GFjXbA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=+CiLT5PIiLKXY0XMGrFa3nyJGrA=; b=ZlEpO zd4E6iPHJloXpcqqkRSPQ+ce6EmJ3UD/A5eS42fhpkWQ+pY/YHSKWW6PcW1LcPqr 42KyJQaHwpOUv17Zt1882NwqcaRhlJfaZxDWt31yaKoebJ7GCHPcLdKcR5noxD7/ r3+D2QFkCMjfJYv2gv+U+5xX/q3pmAjXeZd6R0= X-Sasl-enc: Vvt503gbkktEYtTqsAwTDYOjwxNn5UrSE58HixlULMXM 1452787888 Received: from sjc-alcoop-88112.cisco.com (unknown [128.107.241.166]) by mail.messagingengine.com (Postfix) with ESMTPA id 99A5EC016F0; Thu, 14 Jan 2016 11:11:28 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_854882C6-D7B1-41E8-BC39-F21BCA034AC9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Thu, 14 Jan 2016 08:11:27 -0800 Message-Id: <9064B979-3241-41CB-A3C2-0FFCDB2AB089@cooperw.in> References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> To: David Bryan X-Mailer: Apple Mail (2.2104) Archived-At: Cc: P2PSIP WG Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-concepts-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 16:11:32 -0000 --Apple-Mail=_854882C6-D7B1-41E8-BC39-F21BCA034AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, Do you have an estimate for when this will be completed? Thanks, Alissa > On Nov 25, 2015, at 7:55 PM, David Bryan wrote: >=20 > Thank you very much for the review and comments. >=20 > I will look over the comments, and revise shortly. >=20 > On Nov 25, 2015 4:58 PM, "Alissa Cooper" > wrote: > I have reviewed this document in preparation for IETF last call. There = are a few edits that need to be made before this document can be = last-called: >=20 > 1) The document needs a security considerations section. It is = perfectly fine if this section mostly points to the security = considerations of the other p2psip documents, but it needs to be there. >=20 > 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN = ISSUE.=E2=80=9D These need to be resolved. >=20 > 3) Section 1 should be deleted. >=20 >=20 > While you=E2=80=99re making changes, please address the following: >=20 > 4) Fix the ID nits. >=20 > 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour. >=20 > 6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really = seem appropriate and don=E2=80=99t add much value, so I would suggest = deleting them. >=20 > 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not = call it a draft and should reference the RFC. >=20 >=20 > Thanks, > Alissa > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip = --Apple-Mail=_854882C6-D7B1-41E8-BC39-F21BCA034AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi David,

Do you have an estimate for when this = will be completed?

Thanks,
Alissa

On = Nov 25, 2015, at 7:55 PM, David Bryan <dbryan@ethernot.org>= wrote:

Thank you very much for the review and = comments.

I will look over the comments, = and revise shortly.

On Nov 25, 2015 4:58 PM, "Alissa Cooper" = <alissa@cooperw.in> wrote:
I have reviewed this = document in preparation for IETF last call. There are a few edits that = need to be made before this document can be last-called:

1) The document needs a security considerations section. It is perfectly = fine if this section mostly points to the security considerations of the = other p2psip documents, but it needs to be there.

2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

3) Section 1 should be deleted.


While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour.

6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem = appropriate and don=E2=80=99t add much value, so I would suggest = deleting them.

7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call = it a draft and should reference the RFC.


Thanks,
Alissa
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
=

= --Apple-Mail=_854882C6-D7B1-41E8-BC39-F21BCA034AC9-- From nobody Thu Jan 14 10:39:19 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CCD1A8A86 for ; Thu, 14 Jan 2016 10:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 P9ccOn86_p5p for ; Thu, 14 Jan 2016 10:39:15 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666FA1A8A7A for ; Thu, 14 Jan 2016 10:39:15 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id ik10so203030374igb.1 for ; Thu, 14 Jan 2016 10:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ethernot-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SeS3imxWDXyBzkYpOKQfkmOEkLoybaiCwLlosb4eBQE=; b=S1N/bvQcm+dH+O+VTOTvjOj1C13ermOLyrEMtQ6zqwonYOidrIakMBHmM4ykDfSjHc mkzVXugtZaFavdgg3DsLDYMMNCeo7Meys8Bz0uVVIqxdbpJbM4JjLxrsyT1YSPIIFOW1 oJdJiS9yzrUe/e1wlDZnj2OQFBlrrJbuw7qPPCqQx/ssLUguGkn4fGQfDCDYRwbqFcii l24syEY6Ys4IO8h/bBYMAaBuWfInnMwCqQWLnniqDkFR1TzW10EqeaSJ286cah8isZm9 k7aw8Kyn5j+m1NOpf4x/vB5SSBNGHtqMg8vCuOO27EvF0kNU13ITFa98GsNimNrPVig1 8yEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SeS3imxWDXyBzkYpOKQfkmOEkLoybaiCwLlosb4eBQE=; b=EOkspMB59FNQ/2NjXumlpcK1UO0GUrv+jiHE+yrJMv+6FZJGdxpKijhE1fwj/Tsr20 tUKyx2LBCN/3RBJI4UdU866rWTUF6Y8BJpNOUDS7htMHwA9WamkqDE1Byguc966rQx8n QQFsAHwHg5fwFrYb3YOmlX9EBnOLUz+cc5RTbx3GPiQinsBMZ6EQSbhkLptCe+6cO32c 6GlUR5sFBjTnBmHwYbDwEmvCTJKgCH/JLWji9NkAo6HkF5qQSGuKgU+92jkiDEd+KvuZ Kp9SZTdlIk0nqmppjDzOPf5PqrkHF97RrQcD2FFhJ6vSO6g74rsorlNz2qaHBjOU9qUR X5xg== X-Gm-Message-State: ALoCoQkB47EjpZdkZlV3g8nOFvim2bzLPXozFGb0xlDyaHgt5UxU7lTruo0h4BoT1O5DpA4HaJComeY/rYdj/uqK2WJEkxcimw== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr6730937igt.94.1452796754664; Thu, 14 Jan 2016 10:39:14 -0800 (PST) Received: by 10.107.143.75 with HTTP; Thu, 14 Jan 2016 10:39:14 -0800 (PST) In-Reply-To: <9064B979-3241-41CB-A3C2-0FFCDB2AB089@cooperw.in> References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> <9064B979-3241-41CB-A3C2-0FFCDB2AB089@cooperw.in> Date: Thu, 14 Jan 2016 12:39:14 -0600 Message-ID: From: David Bryan To: Alissa Cooper Content-Type: multipart/alternative; boundary=047d7bdc15b27e438005294f9a9f Archived-At: Cc: P2PSIP WG Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-concepts-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 18:39:17 -0000 --047d7bdc15b27e438005294f9a9f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the note -- quite soon. Between end of semester, holiday travel, and now start of the semester there was no time, but things have cleared up and it is back on my list. David On Thu, Jan 14, 2016 at 10:11 AM, Alissa Cooper wrote: > Hi David, > > Do you have an estimate for when this will be completed? > > Thanks, > Alissa > > On Nov 25, 2015, at 7:55 PM, David Bryan wrote: > > Thank you very much for the review and comments. > > I will look over the comments, and revise shortly. > On Nov 25, 2015 4:58 PM, "Alissa Cooper" wrote: > >> I have reviewed this document in preparation for IETF last call. There >> are a few edits that need to be made before this document can be >> last-called: >> >> 1) The document needs a security considerations section. It is perfectly >> fine if this section mostly points to the security considerations of the >> other p2psip documents, but it needs to be there. >> >> 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2= =80=9D These need >> to be resolved. >> >> 3) Section 1 should be deleted. >> >> >> While you=E2=80=99re making changes, please address the following: >> >> 4) Fix the ID nits. >> >> 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than >> Bonjour. >> >> 6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem >> appropriate and don=E2=80=99t add much value, so I would suggest deletin= g them. >> >> 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call= it a draft and >> should reference the RFC. >> >> >> Thanks, >> Alissa >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > > --047d7bdc15b27e438005294f9a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the note -- quite soon. Between end of semester= , holiday travel, and now start of the semester there was no time, but thin= gs have cleared up and it is back on my list.=C2=A0

Davi= d

On T= hu, Jan 14, 2016 at 10:11 AM, Alissa Cooper <alissa@cooperw.in> wrote:
Hi David,

Do you have an estimate for= when this will be completed?

Thanks,
Al= issa

On= Nov 25, 2015, at 7:55 PM, David Bryan <dbryan@ethernot.org> wrote:

<= p dir=3D"ltr">Thank you very much for the review and comments.

I will look over the comments, and revise shortly.

On Nov 25, 2015 4:58 PM, "Alissa Cooper&quo= t; <alissa@cooper= w.in> wrote:
= I have reviewed this document in preparation for IETF last call. There are = a few edits that need to be made before this document can be last-called:
1) The document needs a security considerations section. It is perfectly fi= ne if this section mostly points to the security considerations of the othe= r p2psip documents, but it needs to be there.

2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

3) Section 1 should be deleted.


While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

5) I think Section 3.5 should reference RFC 6762 and 6763 rather than Bonjo= ur.

6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem ap= propriate and don=E2=80=99t add much value, so I would suggest deleting the= m.

7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call it= a draft and should reference the RFC.


Thanks,
Alissa
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip


--047d7bdc15b27e438005294f9a9f-- From nobody Thu Jan 14 11:06:56 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5FD1A92B7 for ; Thu, 14 Jan 2016 11:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 O25r8LdnKTk2 for ; Thu, 14 Jan 2016 11:06:53 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216001A92B6 for ; Thu, 14 Jan 2016 11:06:52 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 217D522852 for ; Thu, 14 Jan 2016 14:06:51 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 14 Jan 2016 14:06:51 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=qXL2t SVbrWAeZcDOOYKhXEm3KgE=; b=MDlU0TSa1rbqmDhrxYKkQ2Brz7d3ab0dVhkhK XDSNrKMDlp+MXQWf+MQxfhZWtDXoOoDp07GPriN2z3h9Or1od3e8AVz+vZyjl3/J zInpBcBA8lWkirxz50clxIC9JiWkksvaKX9kiQlGY7DQfW9i7u5vOtS00QRUScTA gRTAHE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=qXL2tSVbrWAeZcDOOYKhXEm3KgE=; b=eADp9 sDI0JqS8Yac234sqOiVdg7Typ99Reyap9lVK86Omw9HDDQrtgsPIVEG+HS8hkfcT 3lA/LG570dDRZmToXhExG1hSnJCq/otykY3H2MIe52ZOxHPncFrpBeDVZxGivjal mweCrGbyvR2YMRFk/FERQrAM5m4O07Hw88shHg= X-Sasl-enc: tOqgMz+Gr14uROB/9UVx/QnJckD8c4a+2MJOwcJ8eyc5 1452798410 Received: from dhcp-171-68-21-31.cisco.com (dhcp-171-68-21-31.cisco.com [171.68.21.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 86637680141; Thu, 14 Jan 2016 14:06:50 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3F29370-A142-4545-B451-B43D71505B73" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Thu, 14 Jan 2016 11:05:58 -0800 Message-Id: References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> <9064B979-3241-41CB-A3C2-0FFCDB2AB089@cooperw.in> To: David Bryan X-Mailer: Apple Mail (2.2104) Archived-At: Cc: P2PSIP WG Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-concepts-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 19:06:55 -0000 --Apple-Mail=_E3F29370-A142-4545-B451-B43D71505B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great, thank you. > On Jan 14, 2016, at 10:39 AM, David Bryan wrote: >=20 > Thanks for the note -- quite soon. Between end of semester, holiday = travel, and now start of the semester there was no time, but things have = cleared up and it is back on my list.=20 >=20 > David >=20 > On Thu, Jan 14, 2016 at 10:11 AM, Alissa Cooper > wrote: > Hi David, >=20 > Do you have an estimate for when this will be completed? >=20 > Thanks, > Alissa >=20 >> On Nov 25, 2015, at 7:55 PM, David Bryan > wrote: >>=20 >> Thank you very much for the review and comments. >>=20 >> I will look over the comments, and revise shortly. >>=20 >> On Nov 25, 2015 4:58 PM, "Alissa Cooper" > wrote: >> I have reviewed this document in preparation for IETF last call. = There are a few edits that need to be made before this document can be = last-called: >>=20 >> 1) The document needs a security considerations section. It is = perfectly fine if this section mostly points to the security = considerations of the other p2psip documents, but it needs to be there. >>=20 >> 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN = ISSUE.=E2=80=9D These need to be resolved. >>=20 >> 3) Section 1 should be deleted. >>=20 >>=20 >> While you=E2=80=99re making changes, please address the following: >>=20 >> 4) Fix the ID nits. >>=20 >> 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour. >>=20 >> 6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really = seem appropriate and don=E2=80=99t add much value, so I would suggest = deleting them. >>=20 >> 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not = call it a draft and should reference the RFC. >>=20 >>=20 >> Thanks, >> Alissa >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip = >=20 >=20 --Apple-Mail=_E3F29370-A142-4545-B451-B43D71505B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Great, thank you.

On Jan = 14, 2016, at 10:39 AM, David Bryan <dbryan@ethernot.org>= wrote:

Thanks for the note -- quite soon. Between end of = semester, holiday travel, and now start of the semester there was no = time, but things have cleared up and it is back on my list. 

David

On Thu, = Jan 14, 2016 at 10:11 AM, Alissa Cooper <alissa@cooperw.in> wrote:
Hi = David,

Do you = have an estimate for when this will be completed?
Thanks,
Alissa

On Nov 25, 2015, at 7:55 PM, David Bryan <dbryan@ethernot.org> wrote:

Thank you very much for the review = and comments.

I will look over the = comments, and revise shortly.

On Nov 25, 2015 4:58 PM, "Alissa Cooper" = <alissa@cooperw.in> wrote:
I have reviewed this = document in preparation for IETF last call. There are a few edits that = need to be made before this document can be last-called:

1) The document needs a security considerations section. It is perfectly = fine if this section mostly points to the security considerations of the = other p2psip documents, but it needs to be there.

2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

3) Section 1 should be deleted.


While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour.

6) The Wikipedia references in Section 5 and 6 don=E2=80=99t really seem = appropriate and don=E2=80=99t add much value, so I would suggest = deleting them.

7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call = it a draft and should reference the RFC.


Thanks,
Alissa
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
=



= --Apple-Mail=_E3F29370-A142-4545-B451-B43D71505B73-- From nobody Thu Jan 14 15:03:36 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499491A0218 for ; Thu, 14 Jan 2016 15:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 S2mIWxNLAtCl for ; Thu, 14 Jan 2016 15:03:31 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9081A020B for ; Thu, 14 Jan 2016 15:03:31 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CA5E120397 for ; Thu, 14 Jan 2016 18:03:30 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 14 Jan 2016 18:03:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=58ErxRxigb9dTM+am/pfeLZVddM =; b=RAiXfoYiWgCWSQpgD0BI/C/+NHHQ9X3LEm1FFe4ZfHJWCfZ1TcZPp6hs1Wd DaK7wOUmIIu+vcCbMFXDyHYa4w4QeqLtYMo8VgfJJ6LzDtUXtCUP3Xu6mrpegsnB Ce0q0HWZnTcNWXtTCfWDLkFI50P9YkmUUGyEGTtQ6WZ98/rE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=58 ErxRxigb9dTM+am/pfeLZVddM=; b=YSbNt/CZhU7Cg8B5IcegSIfTZnUHOCq/oX /o1Mx60GvWPDhe9ZKatxgLugNkJo9/Ny6ME9v5h+Y4QDfvSzf6JF3VLqJ1wTB+gs bblCoiyz+b9jaOdONmsxkJ8b9L+ldQCl8rGefZ2VamyC+/mddbEotS2n4ay6GU1D VeTaoeyNM= X-Sasl-enc: LbaQCeSGuMlxbwwuHiIbeftqhADzHDLZz6bTCh4XWXGL 1452812610 Received: from dhcp-171-68-21-31.cisco.com (dhcp-171-68-21-31.cisco.com [171.68.21.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 390BF68011F for ; Thu, 14 Jan 2016 18:03:30 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_C0E23919-072B-436E-A178-F55A9C698888" Message-Id: <33F4951F-E5B9-4BB5-8B2C-F65366B3C728@cooperw.in> Date: Thu, 14 Jan 2016 15:03:29 -0800 To: P2PSIP WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 23:03:35 -0000 --Apple-Mail=_C0E23919-072B-436E-A178-F55A9C698888 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document in preparation for IETF last call. I have = a number of comments and questions that need to be resolved before last = call can be initiated. I=E2=80=99ve also included some nits below that = should be resolved together with last call comments. Given the nature of this document, I=E2=80=99d like for the shepherd to = request an early SECDIR review after the comments below have been = resolved so that the authors and WG can receive security feedback before = the document progresses to IESG evaluation. =3D=3D Substantive comments and questions =3D=3D =3D Section 3.1 =3D I think this section requires clarification.=20 How is the index value supposed to be initialized? Is it supposed to be = chosen at random or set to 0 (or 1, as in the figure)? I don=E2=80=99t understand how this mechanism relates to how SSRCs are = chosen. In fact RFC 3550 doesn=E2=80=99t specify a particular algorithm = to use, but merely provides one example. Furthermore, I don=E2=80=99t = see how the collision probably for the array index value, which selects = the least significant three bytes from a cryptographically random = Node-Id that must be 16 bytes or longer, would be the same as for a = randomly chosen 32-bit integer. Could you explain? =3D Section 5 =3D Are variable resource names expected to be UTF-8 strings? I think = somewhere in this section the internationalization expectations for = these strings need to be specified. =3D Section 5.3 =3D (1) I think this section needs to specify normative requirements on the = pattern construction to avoid duplicative or substring names as = described in 5.1 (2) "Configurations in this overlay document MUST adhere in syntax and = semantic of names as defined by the context of use. For example, syntax = restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], while a more = general naming is feasible in plain RELOAD." I don=E2=80=99t understand what the normative requirement is here or why = it is needed. How is =E2=80=9Cthe context of use=E2=80=9D defined? = Shouldn=E2=80=99t it be up to the specific protocol documents to define = the required syntax and semantics for specific usages (e.g., the way = draft-ietf-p2psip-sip does)? (3) "In the absence of a element for a Kind using = the USER-CHAIN-ACL access policy (see Section 6.6 = ), = implementors SHOULD assume this default value." Why is this SHOULD and not MUST? Shouldn=E2=80=99t implementations = conservatively assume that variable names are not allowed unless = explicitly specified? (4) "If no pattern is defined for a Kind or the "enable" attribute is false, = allowable Resource Names are restricted to the username of the signer = for Shared Resource.=E2=80=9D I think this needs to account for an error condition where the pattern = does not meet the pattern construction requirements, e.g.: ""If no pattern is defined for a Kind, if the "enable" attribute is = false, or if the regular expression does not meet the requirements = specified in this section, the allowable Resource Names are restricted = to the username of the signer for Shared Resource.=E2=80=9D =3D Section 6.2 =3D For privacy reasons, wouldn=E2=80=99t it be better to overwrite every = entry in a subtree when the root of the subtree gets overwritten? = Otherwise the list of users who were given write access may remain long = after their access has been revoked. =3D Section 6.3 =3D How strings are to be compared (e.g., as binary objects or whatever it = is) needs to be normatively specified. It is confusing to use normative language only in step 5 here. I would = suggest either normatively defining each action or not using SHALL here. =3D Section 6.6 =3D "Otherwise, the value MUST be written if the certificate of the signer = contains a username that matches to one of the variable resource name = pattern (c.f. Section 5 = ) = specified in the configuration document" It seems to me that matching the pattern is not sufficient =E2=80=94 = isn=E2=80=99t it the case that both the user and domain portions of the = user name in the certificate need to match the user and domain name = portions present in the resource name? In general, the document seems to = be missing discussion of the implications of having the user name and = the resource name diverge. I think this affects every operation that = involves comparing the two (or the Resource-Id, right?). I=E2=80=99m also unclear about why policy for allowing access to shared = resources is being strictly coupled with policy for allowing variable = resource names. Might there be cases where it makes sense to authorize = one but not the other?=20 =3D Section 8.2 =3D This section misses the threat of a misbehaving peer who is delegated = write access =E2=80=94 that seems like an important case to cover. =3D Section 8.3 =3D By =E2=80=9Cpublicly readable=E2=80=9D do you mean =E2=80=9Creadable by = any node in the overlay=E2=80=9D? Admission to the overlay would still = be access controlled, correct? =3D Section 9.2 =3D What is the significance of 17, other than that it is in the unassigned = range? =3D=3D Nits =3D=3D =3D Section 1 =3D The reference to I-D.ietf-p2psip-disco should be removed given that the = document is several years old and not expected to advance as far as I = know. s/from one authorized to another (previously unauthorized) user/from one = authorized user to another (previously unauthorized) user/ =3D Section 2 =3D s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts = ]/[I-D.ietf-p2psip-concepts = ]/ =3D Section 3.1 =3D s/Append an 8 bit long short individual index value/Append an 8-bit = individual index value/ =3D Section 4.1 =3D s/an Access Control including/an Access Control List including/ =3D Section 5.1 =3D Same comment about I-D.ietf-p2psip-disco = as in Section 1. --Apple-Mail=_C0E23919-072B-436E-A178-F55A9C698888 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have reviewed this document in preparation for IETF last = call. I have a number of comments and questions that need to be resolved = before last call can be initiated. I=E2=80=99ve also included some nits = below that should be resolved together with last call comments.

Given the nature of this = document, I=E2=80=99d like for the shepherd to request an early SECDIR = review after the comments below have been resolved so that the authors = and WG can receive security feedback before the document progresses to = IESG evaluation.


=3D=3D Substantive = comments and questions =3D=3D

=3D Section 3.1 =3D

I think this section = requires clarification. 

How is the index value supposed to be = initialized? Is it supposed to be chosen at random or set to 0 (or 1, as = in the figure)?

I don=E2=80=99t understand how this mechanism relates to how = SSRCs are chosen. In fact RFC 3550 doesn=E2=80=99t specify a particular = algorithm to use, but merely provides one example. Furthermore, I = don=E2=80=99t see how the collision probably for the array index value, = which selects the least significant three bytes from a cryptographically = random Node-Id that must be 16 bytes or longer, would be the same as for = a randomly chosen 32-bit integer. Could you explain?

=3D Section 5 = =3D

Are = variable resource names expected to be UTF-8 strings? I think somewhere = in this section the internationalization expectations for these strings = need to be specified.

=3D Section 5.3 =3D

(1)
I think this section needs to specify = normative requirements on the pattern construction to avoid duplicative = or substring names as described in 5.1

(2)
"Configurations in this overlay document = MUST adhere in syntax and semantic of names as defined by the context of use. For = example, syntax restrictions apply when using = P2PSIP[I-D.ietf-p2psip-sip], while a more general naming is = feasible in plain RELOAD."

I= don=E2=80=99t understand what the normative requirement is here or why = it is needed. How is =E2=80=9Cthe context of use=E2=80=9D defined? = Shouldn=E2=80=99t it be up to the specific protocol documents to define = the required syntax and semantics for specific usages (e.g., the way = draft-ietf-p2psip-sip does)?
(3)
"In the absence of a = <variable-resource-names> element for a Kind using the = USER-CHAIN-ACL access policy (see Section 6.6), implementors SHOULD assume this default = value."

Why is = this SHOULD and not MUST? Shouldn=E2=80=99t implementations = conservatively assume that variable names are not allowed unless = explicitly specified?

(4)
"If no pattern is defined for a Kind or = the "enable" attribute = is false, allowable Resource Names are restricted to the username of the signer for Shared = Resource.=E2=80=9D

I think this needs to account for an = error condition where the pattern does not meet the pattern construction = requirements, e.g.:

""If no pattern is defined for a Kind, if the "enable" attribute is false, or if the = regular expression does not meet the requirements specified in this = section, the allowable Resource Names are restricted to the username of the signer for Shared = Resource.=E2=80=9D

=3D Section 6.2 =3D

For privacy reasons, wouldn=E2=80=99t = it be better to overwrite every entry in a subtree when the root of the = subtree gets overwritten? Otherwise the list of users who were given = write access may remain long after their access has been = revoked.

=3D Section 6.3 =3D

How strings are to be compared (e.g., = as binary objects or whatever it is) needs to be normatively = specified.

It = is confusing to use normative language only in step 5 here. I would = suggest either normatively defining each action or not using SHALL = here.

=3D = Section 6.6 =3D

"Otherwise, the value = MUST be written if the certificate of the signer contains a username that matches to one = of the variable resource name pattern (c.f. Section 5) specified in the configuration document"

It seems to me that = matching the pattern is not sufficient =E2=80=94 isn=E2=80=99t it the = case that both the user and domain portions of the user name in the = certificate need to match the user and domain name portions present in = the resource name? In general, the document seems to be missing = discussion of the implications of having the user name and the resource = name diverge. I think this affects every operation that involves = comparing the two (or the Resource-Id, right?).

I=E2=80=99m also unclear about why = policy for allowing access to shared resources is being strictly coupled = with policy for allowing variable resource names. Might there be cases = where it makes sense to authorize one but not the other? 

=3D Section 8.2 = =3D

This = section misses the threat of a misbehaving peer who is delegated write = access =E2=80=94 that seems like an important case to cover.

=3D Section 8.3 = =3D

By = =E2=80=9Cpublicly readable=E2=80=9D do you mean =E2=80=9Creadable by any = node in the overlay=E2=80=9D? Admission to the overlay would still be = access controlled, correct?

=3D Section 9.2 =3D

What is the significance of 17, other = than that it is in the unassigned range?


=3D=3D= Nits =3D=3D

=3D= Section 1 =3D

The reference to I-D.ietf-p2psip-disco should be removed given that the = document is several years old and not expected to advance as far as I = know.

s/from one authorized to another (previously unauthorized) user/from one authorized user = to another (previously = unauthorized) user/

=3D Section 2 =3D

s/the = peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts]/[I-D.ietf-p2psip-concepts]/

=3D Section 3.1 =3D

s/Append an 8 = bit long short individual index value/Append an 8-bit individual index value/

=3D Section 4.1 = =3D

s/an Access Control = including/an Access Control = List including/

=3D Section 5.1 =3D

Same comment about I-D.ietf-p2psip-disco as in Section 1.




= --Apple-Mail=_C0E23919-072B-436E-A178-F55A9C698888-- From nobody Fri Jan 15 00:50:06 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B11A8A07 for ; Fri, 15 Jan 2016 00:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 EZ_5HRZfw58e for ; Fri, 15 Jan 2016 00:50:01 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D101A89B4 for ; Fri, 15 Jan 2016 00:50:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,298,1449529200"; d="scan'208";a="27164624" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 15 Jan 2016 09:49:59 +0100 Received: from CAS03.mailcluster.haw-hamburg.de (2002:8d16:183e::8d16:183e) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 15 Jan 2016 09:49:58 +0100 Received: from [141.22.28.186] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.62) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 15 Jan 2016 09:49:58 +0100 To: Alissa Cooper , P2PSIP WG References: From: "Thomas C. Schmidt" Message-ID: <5698B2AA.7060008@haw-hamburg.de> Date: Fri, 15 Jan 2016 09:49:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 08:50:04 -0000 Dear Alissa, many thanks for your detailed feedback. We'll address the comments shortly and be back. Best, Thomas On 15.01.2016 00:03, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF last call. I have > a number of comments and questions that need to be resolved before last > call can be initiated. I’ve also included some nits below that should be > resolved together with last call comments. > > Given the nature of this document, I’d like for the shepherd to request > an early SECDIR review after the comments below have been resolved so > that the authors and WG can receive security feedback before the > document progresses to IESG evaluation. > > > == Substantive comments and questions == > > = Section 3.1 = > > I think this section requires clarification. > > How is the index value supposed to be initialized? Is it supposed to be > chosen at random or set to 0 (or 1, as in the figure)? > > I don’t understand how this mechanism relates to how SSRCs are chosen. > In fact RFC 3550 doesn’t specify a particular algorithm to use, but > merely provides one example. Furthermore, I don’t see how the collision > probably for the array index value, which selects the least significant > three bytes from a cryptographically random Node-Id that must be 16 > bytes or longer, would be the same as for a randomly chosen 32-bit > integer. Could you explain? > > = Section 5 = > > Are variable resource names expected to be UTF-8 strings? I think > somewhere in this section the internationalization expectations for > these strings need to be specified. > > = Section 5.3 = > > (1) > I think this section needs to specify normative requirements on the > pattern construction to avoid duplicative or substring names as > described in 5.1 > > (2) > "Configurations in this overlay document MUST adhere in syntax and > semantic of names as defined by the context of use. For example, syntax > restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], while a more > general naming is feasible in plain RELOAD." > > I don’t understand what the normative requirement is here or why it is > needed. How is “the context of use” defined? Shouldn’t it be up to the > specific protocol documents to define the required syntax and semantics > for specific usages (e.g., the way draft-ietf-p2psip-sip does)? > > (3) > "In the absence of a element for a Kind using > the USER-CHAIN-ACL access policy (see Section 6.6 > ), > implementors SHOULD assume this default value." > > Why is this SHOULD and not MUST? Shouldn’t implementations > conservatively assume that variable names are not allowed unless > explicitly specified? > > (4) > "If no pattern is defined for a Kind or the "enable" attribute is false, > allowable Resource Names are restricted to the username of the signer > for Shared Resource.” > > I think this needs to account for an error condition where the pattern > does not meet the pattern construction requirements, e.g.: > > ""If no pattern is defined for a Kind, if the "enable" attribute is > false, or if the regular expression does not meet the requirements > specified in this section, the allowable Resource Names are restricted > to the username of the signer for Shared Resource.” > > = Section 6.2 = > > For privacy reasons, wouldn’t it be better to overwrite every entry in a > subtree when the root of the subtree gets overwritten? Otherwise the > list of users who were given write access may remain long after their > access has been revoked. > > = Section 6.3 = > > How strings are to be compared (e.g., as binary objects or whatever it > is) needs to be normatively specified. > > It is confusing to use normative language only in step 5 here. I would > suggest either normatively defining each action or not using SHALL here. > > = Section 6.6 = > > "Otherwise, the value MUST be written if the certificate of the signer > contains a username that matches to one of the variable resource name > pattern (c.f. Section 5 > ) > specified in the configuration document" > > It seems to me that matching the pattern is not sufficient — isn’t it > the case that both the user and domain portions of the user name in the > certificate need to match the user and domain name portions present in > the resource name? In general, the document seems to be missing > discussion of the implications of having the user name and the resource > name diverge. I think this affects every operation that involves > comparing the two (or the Resource-Id, right?). > > I’m also unclear about why policy for allowing access to shared > resources is being strictly coupled with policy for allowing variable > resource names. Might there be cases where it makes sense to authorize > one but not the other? > > = Section 8.2 = > > This section misses the threat of a misbehaving peer who is delegated > write access — that seems like an important case to cover. > > = Section 8.3 = > > By “publicly readable” do you mean “readable by any node in the > overlay”? Admission to the overlay would still be access controlled, > correct? > > = Section 9.2 = > > What is the significance of 17, other than that it is in the unassigned > range? > > > == Nits == > > = Section 1 = > > The reference to I-D.ietf-p2psip-disco should be removed given that the > document is several years old and not expected to advance as far as I know. > > s/from one authorized to another (previously unauthorized) user/from one > authorized user to another (previously unauthorized) user/ > > = Section 2 = > > s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts > ]/[I-D.ietf-p2psip-concepts > ]/ > > = Section 3.1 = > > s/Append an 8 bit long short individual index value/Append an 8-bit > individual index value/ > > = Section 4.1 = > > s/an Access Control including/an Access Control List including/ > > = Section 5.1 = > > Same comment about I-D.ietf-p2psip-disco > as > in Section 1. > > > > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Fri Jan 15 13:58:48 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6DD1B3302 for ; Fri, 15 Jan 2016 13:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 opkvKHQdJyGP for ; Fri, 15 Jan 2016 13:58:45 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDC51B3301 for ; Fri, 15 Jan 2016 13:58:44 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C03BF205FD for ; Fri, 15 Jan 2016 16:58:43 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 15 Jan 2016 16:58:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=93O 5MZdChmWANgdDd1km+C3Y770=; b=sQY93XipSDD+5kbDLKLtLDjJpz3ZeFotihy IncnHwxFbHPo3dA3+4SpT3W90hM89CBCw3WLFkHipQcBZkzSxKthF9MKJ52z+3cc sKupoDeICe9SvlLvkdkEw0LRpXXbk5L8xU/mivwmknkq91dtrDhZY8VrWk//Hkjt ji1iu9+c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=93O5MZdChmWANgdDd1km+C3Y770=; b=InhrZ jcd+f85k3z6oEaRe4qiudOXHzo0SYPTz801dBvLHmoNv40CncHMRmshoaUsE9Ve6 rky0dOLu7KiqVdS6x2zN2YxlMTF9O9h2k1zyniJ1AkxGgKecEZhWR28HOZyOiqIa sqni/NHG/+EaGxiJXw2DEPJSgAxa/n4ySjik70= X-Sasl-enc: 2zD6JXdnPuqdcDi7bxw2JrEAAS/E60iR0pw0D4apEhIB 1452895123 Received: from dhcp-171-68-21-31.cisco.com (dhcp-171-68-21-31.cisco.com [171.68.21.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 4B71C6800B1 for ; Fri, 15 Jan 2016 16:58:43 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 15 Jan 2016 13:58:42 -0800 To: P2PSIP WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 21:58:46 -0000 I have reviewed this document in preparation for IETF last call. I have = a number of comments and questions that need to be resolved before last = call can be initiated. In particular, I have some security concerns = about using this in an overlay that allows registrations for any domain. I=E2=80=99ve also included some nits below that should be resolved = together with last call comments. =3D=3D Substantive comments and questions =3D=3D =3D Section 3.2 =3D This section is underspecified and I=E2=80=99m not sure the references = to RFC 2533 and RFC 2738 are the appropriate ones. I think what you need = to specify here is that the contact_prefs will encode a media feature = set comprised of SIP User Agent capabilities, as defined in RFC 3840 and = registered in the SIP media feature tag registration tree (assuming that = is what is intended). It=E2=80=99s also confusing that you only mention whether sip.schemes is = required or not without mentioning whether specifying any other = capabilities is required or optional. =3D Section 3.3 =3D "Before issuing a Store request to the overlay, any peer SHOULD verify = that the AOR of the request is a valid Resource Name with respect to its = domain name and the namespaces defined in the overlay configuration = document (see Section 3.4)." Why is this SHOULD rather than MUST? =3D Section 3.4 =3D (1) I note that this documents refers to a different version of the IEEE = Posix spec than draft-ietf-p2psip-share. What=E2=80=99s the reason for = the difference? (2) I find the explanation of the expected behavior here hard to follow. = I've suggested a re-write below. There also seems to be one case that is = not specified, which is when the "enable" attribute is set to false. = Text describing what should happen in that case needs to be added. OLD=20 A RELOAD overlay can be configured to accept store requests for any AOR, = or to apply domain name restrictions. For the latter, an enumeration of = admissible domain names including wildcarded name patterns of the = following form MAY be configured. Example of Domain Patterns: dht\.example\.com .*\.my\.name In this example, any AOR will be accepted that is either of the form = @dht.example.com, or ends with the domain "my.name". When = restrictions apply and in the absence of domain patterns, the default = behavior is to accept only AORs that exactly match the domain name of = the overlay. Otherwise, i.e., when restrictions are not configured = (attribute enable not set), the default behavior is to accept any AOR. = In the absence of a element, implementors SHOULD = assume this default value. Encoding of the domain name complies to the = restricted ASCII character set without character escaping as defined in = Section 19.1 of [RFC3261]. The element serves as a container for zero to = multiple sub-elements. A element MAY be present if = the "enable" attribute of its parent element is set to true. Each = element defines a pattern for constructing admissible resource = names. It is of type xsd:string and interpreted as a regular expression = according to "POSIX Extended Regular Expression" (see the specifications = in [IEEE-Posix]). NEW=20 A RELOAD overlay can be configured to accept store requests for any AOR, = or to apply domain name restrictions. To apply restrictions, the = overlay configuration document needs to contain a = element. The element serves as a container for = zero to multiple sub-elements. A element MAY be = present if the "enable" attribute of its parent element is set to true. = Each element defines a pattern for constructing admissible = resource names. It is of type xsd:string and interpreted as a regular = expression according to "POSIX Extended Regular Expression" (see the = specifications in [IEEE-Posix]). Encoding of the domain name complies to = the restricted ASCII character set without character escaping as defined = in Section 19.1 of [RFC3261]. Inclusion of a element in an overlay configuration = document is OPTIONAL. If the element is not included, the default = behavior is to accept any AOR. If the element is included and the = =E2=80=9Cenable=E2=80=9D attribute is not set, the overlay MUST only = accept AORs that match the domain name of the overlay. If the element is = included and the =E2=80=9Cenable=E2=80=9D attribute is set to true, the = overlay MUST only accept AORs that match patterns specified in the = element. Example of Domain Patterns: dht\.example\.com .*\.my\.name In this example, any AOR will be accepted that is either of the form = @dht.example.com, or ends with the domain "my.name". =3D Section 8.2.3 =3D The attack described here seems trivial, and therefore it seems to me = that the way SIP usage of RELOAD has been specified here has a gaping = hole in it. Basically in any overlay that wants to allow registrations = from any domain, the only defense against calls being directed to the = wrong recipient is for users to bypass the overlay and do what they = would normally do when making a SIP call. Thus in this use case the only = thing achieved by using RELOAD is to create a giant vulnerability. Did the WG consider this? What is the value of standardizing this in = this way, given this security issue? If the way that SIP usage was = specified was limited to overlays with domain restrictions, at least = this attack would be limited to bogus registrations of users within the = overlay domain(s). =3D Section 8.2.4 =3D (1) By "public" you mean "visible to all nodes in the overlay," correct? (2) "Methods of providing location and identity privacy are still being studied." Is this true, specifically for P2PSIP? =3D=3D Nits =3D=3D =3D Section 1 =3D s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And = Discovery (RELOAD)/ OLD=20 Two opposite scenarios of deploying P2P SIP services are in the focus of = this document: A highly regulated environment of a "single provider" = that admits parties using AORs with domains from controlled = namespace(s), only, and an open, multi-party infrastructure that = liberally allows a registration and rendezvous for various or any domain = namespace. NEW=20 This RELOAD usage may be relevant in a variety of environments, = including a highly regulated environment of a "single provider" that = admits parties using AORs with domains from controlled namespace(s) = only, or an open, multi-party infrastructure that liberally allows a = registration and rendezvous for various or any domain namespace. =3D Section 3.1 =3D "RELOAD peers MAY store two kinds of SIP mappings=E2=80=9D I don=E2=80=99t think you need the normative MAY there, =E2=80=9Ccan=E2=80= =9D would work. =3D Section 3.4 =3D The second line of the example here needs to use .example as the TLD, = not .name. Please make the corresponding changes in the text. =3D Section 5.1 =3D s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/ =3D Section 6 =3D I don't think you need the normative MAY here. From nobody Thu Jan 28 13:28:05 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6CD1A9071 for ; Thu, 28 Jan 2016 13:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Yl-DflK9UUld for ; Thu, 28 Jan 2016 13:28:01 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C261A9067 for ; Thu, 28 Jan 2016 13:28:01 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id CFD8620361 for ; Thu, 28 Jan 2016 16:28:00 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 28 Jan 2016 16:28:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=h1Y7wJgQ8O+U2WtT4ml3TO871hw=; b=M6ezt0 O/wc+CVrGXfC+Tx+Eer0aVV3o7B+BtSPJBIsB6tqm4pV3zZxN7bVR8ThPqvZub2r wsWQ4V+OJlDR1Bz9Aebxb1BKOc3h0FlYVspxqHQ0tSBeXmhkNEteQ7CO3NDA4pxL NyvnfqFL7I4hlE+CdvfMJSZrliWekabfj13nk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=h1Y7wJgQ8O+U2Wt T4ml3TO871hw=; b=tRQkaGxK5LArhkv9ygubk57ZXgo/Nl28etWFqyl1qNNRMQL He11rWgG0L0ElVLnLcfNFiu+jbpAtBSMECMNnLxmgkaoJl59ABaQIUU2nAtFbizQ nAzIArF1GK7OkiQFoprNRlGjLaYnkyWNRCzvDs+mUam9sxWbdpBOSngETU1g= X-Sasl-enc: mYWSfzoj5KABLhVb4VHWupORq/Nm0WYXbfkeeLhUJyba 1454016480 Received: from dhcp-171-68-20-113.cisco.com (dhcp-171-68-20-113.cisco.com [171.68.20.113]) by mail.messagingengine.com (Postfix) with ESMTPA id CC583680174; Thu, 28 Jan 2016 16:27:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Thu, 28 Jan 2016 13:27:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:28:03 -0000 Barry, Does Haibin=E2=80=99s answer clear up your concern?=20 Thanks, Alissa > On Dec 30, 2015, at 1:20 AM, Songhaibin (A) = wrote: >=20 > Dear Barry, >=20 > See my reply in line. And copy Roni's new email address (as the = author's email address has been updated). >=20 >> -----Original Message----- >> From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Barry = Leiba >> Sent: Wednesday, December 16, 2015 12:18 PM >> To: The IESG >> Cc: p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf.org; >> p2psip@ietf.org >> Subject: [P2PSIP] Barry Leiba's Discuss on = draft-ietf-p2psip-diagnostics-19: >> (with DISCUSS and COMMENT) >>=20 >> Barry Leiba has entered the following ballot position for >> draft-ietf-p2psip-diagnostics-19: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> For Sections 9.1 and 9.2, I would like to see some evidence of = discussion that >> resulted in the decision to make the registry policies Standards = Action. Did >> the working group actually discuss this and make a decision that = Standards >> Action is right? What's the reasoning for not using some softer = policy, such as >> "IETF Review" (which might allow for registrations from Experimental >> documents) or Specification Required (which would allow review by a >> designated expert of a non-RFC specification)? Why is Standards = Action the >> right thing? >>=20 > The thought was that if a new value would be used for experimental = purpose, then there are reserved values accordingly for overlay local = use (0xF000-0xFFFE). And then if people want that value can be used = across different RELOAD overlays, then they'd better need a standard = track document to define it (that's why we assume it would be standard = track). "Specification Required" allows non-RFC specifications, not sure = that would reflect the IETF consensus (certain concerns might exist = about certain kinds of diagnostic information).=20 >=20 >> Important note on the previous comment: Please don't just change = this: >> talk with me. I'm actually asking a question, and it might well be = that >> Standards Action is right. I want to hear the answer and have a = discussion >> about it. >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> In addition to what Ben has already said... >>=20 >>> =46rom the shepherd writeup: >>=20 >> "The normal WG process was followed and the document has been = discussed >> for several years. The document as it is now, reflects WG consensus, = with >> nothing special worth noting." >>=20 >> Is it really the case that with *several years* of discussion there's >> *nothing* worth pointing out as something that generated discussion? >> What were those several years spent on? >>=20 >> "A review of Section 9.6 was requested to the APPS area and the = authors >> considered the received feedback." >>=20 >> Similarly: was there nothing about the feedback that was worth = mentioning? >> I'm glad the authors considered it... it would have been good to say = "the >> feedback was only on minor points," or to say what review brought up. >>=20 >> "The idnits tool returns 5 warnings and 1 comment. They do not seem = to be a >> problem." >>=20 >> Well, one of the things that idnits calls out is this: >> -- The draft header indicates that this document updates RFC6940, = but the >> abstract doesn't seem to mention this, which it should. >>=20 >> I believe it's not a problem that the abstract doesn't mention it, = but one >> *reason* the abstract doesn't mention it is that the rest of the = document >> doesn't mention it either. It's not at all clear WHY this document = updates >> 6940, and that *is* a problem. Why? (This is in support of Ben's = comment, >> as well as being a question to the shepherd.) >=20 > The document says it extends one RFC 6940 message and defines one new = RELOAD message. I'm not clear whether it is an update or not. >=20 >=20 >> The idnits tool also mentions the pre-5378 disclaimer, and the = shepherd >> writeup has no information about why the disclaimer is needed. What = text is >> in this document that is not subject to the IETF Trust terms from BCP = 78, and >> why is it not? I think this needs an explanation. >=20 > This has been resolved in another thread. >=20 >=20 >> I strongly agree with Ben's comment about needing explanations for a = number >> of SHOULDs (and SHOULD NOTs) in the document. RFC 2119 says that for >> SHOULD, "the full implications must be understood and carefully = weighed >> before choosing a different course." Without any explanation, = there's no way >> for implementors to understand the implications and to weigh = anything, and I >> tripped over that quite a number of times during my review. >=20 > It has been replied in another thread w.r.t. Ben's comments. And I = agree that after carefully consideration, it's better to change them to = "MUST"s. >=20 >>=20 >> I agree with Spencer's comment that we don't usually strong-arm IANA = with >> 2119 key words. It's a small point, and I don't think IANA are = easily offended >> [ :-) ], but "IANA is asked to create" is a better approach than = "IANA SHALL >> create", and so on. >=20 > We will revise the section and be carefully with those words in IANA = section in future documents:) >=20 > BR, > -Haibin Song >=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >=20 From nobody Thu Jan 28 13:48:00 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7968E1A910A; Thu, 28 Jan 2016 13:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 4zyLoMumFtns; Thu, 28 Jan 2016 13:47:58 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6256A1A90DB; Thu, 28 Jan 2016 13:47:57 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id f81so69462436iof.0; Thu, 28 Jan 2016 13:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ok48fH2uLvzBQiI+mzKIcaYju9NxTZ2jAK422qG2+KA=; b=KMtpdfHfcgLklVvqP9ikFkAFUlx3bfxu2Bbd6Fqa2b+vg3iKAYhG5Zi2DaM/5+jqoo 1COpeWnM8GQd/34TcraAC3RuW8WzBC0Max+lUJ16Paqv22J4Ee4fSYeEo1cHvS3lCiNU SOombtjIFQebRJPg9L4q5o+W4vV+S0VuNTU7vhhe4BhDha6D/SuR3U+llFx491IMuNdJ JNsFnBb8wzetycXTUEbUMr93tMe5dMH0ajCvb5pLGJ6UpFe3CnPU2fcGJznwVmCM62R2 j4YgN0uW2mqlrTy+we8UXXwkUBcVJ31SGmPA3WcQrhDLNQjsHGYqEGhyqkJyZPyj8cTv TqzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ok48fH2uLvzBQiI+mzKIcaYju9NxTZ2jAK422qG2+KA=; b=lb3fN/l8lKVabVTAL47WaPwOjMkb0r2oxbNB7HUGVxJwoHCvQOnOZI2IuORaMLG5UU 6BTfz6JON3UcbgrC9iyx/6EZJddgDg0Td9io3XL4yvzUQJRX3MJP9qMH2v7fbGh2kAng fBpT7oxCrPMZejjSL5/2B0f7cQF8aF4v7q1w70k6gpVDx3eu03M1TZopr38z/w1mz7Q3 LMZe/eD5ULxM5akHusdPWvKsZNitgJC+6xMTDJduLTR7IuLdpSGMwMsxwSuZoF2edKJK +BabRBcqMXs6A3rr8m2h7B5+xjqA6eLvObjKaBWJVcFb/zI1R94L9y4DPxvQNUBgX/xf lbig== X-Gm-Message-State: AG10YOT9F3vTduur9Go5xMKaa6fFe3wLGDQE11mE/EPVxAZeG2uHFLwHZZLYBCV23J3n+lmLPTsgdmGDc/XXyQ== MIME-Version: 1.0 X-Received: by 10.107.12.22 with SMTP id w22mr7696404ioi.8.1454017676813; Thu, 28 Jan 2016 13:47:56 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.50.129 with HTTP; Thu, 28 Jan 2016 13:47:56 -0800 (PST) In-Reply-To: References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 16:47:56 -0500 X-Google-Sender-Auth: ldttDRTj4hXk0XxAxLwAdquLvu8 Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:47:59 -0000 > Does Haibin=E2=80=99s answer clear up your concern? Sorry, it must have gotten lost in the end-of-year mess. No, it doesn't: Haibin gives his thoughts on the question, but I asked about what discussion the working group had in coming to the decision. Further comment: >> For Sections 9.1 and 9.2, I would like to see some evidence of discussio= n that >> resulted in the decision to make the registry policies Standards Action.= Did >> the working group actually discuss this and make a decision that Standar= ds >> Action is right? What's the reasoning for not using some softer policy,= such as >> "IETF Review" (which might allow for registrations from Experimental >> documents) or Specification Required (which would allow review by a >> designated expert of a non-RFC specification)? Why is Standards Action = the >> right thing? >> > The thought was that if a new value would be used for experimental > purpose, then there are reserved values accordingly for overlay local > use (0xF000-0xFFFE). And then if people want that value can be used > across different RELOAD overlays, then they'd better need a standard > track document to define it (that's why we assume it would be standard > track). "Specification Required" allows non-RFC specifications, not > sure that would reflect the IETF consensus (certain concerns might > exist about certain kinds of diagnostic information). Yes, "Specification Required" allows non-RFC specifications, with a designated expert to review the request and sanity-check it. Why does the working group think this registry needs only Standards Track RFCs to make registrations? Why can't IETF consensus approve a non-Standards-Track RFC (as with "IETF Review")? Why couldn't a designated expert handle the review, consulting with whatever appropriate working group(s) exist at the time (as with "Specification Required")? I'm honest OK with Standards Action if that's really what the working group wants, and they have a reasonable explanation for why that's necessary here. I'm asking because I can't see any evidence that it was actually discussed, and I'm concerned that we consistently use too-strict registration policies because we think they're necessary, and that often bites us later on, when we wish we hadn't been so strict. Can you point me at any messages or minutes that show the working group discussion about the registration policy? Can the working group explain what harm could be caused if registrations were allowed to be made without Standards Track RFCs? Barry From nobody Fri Jan 29 11:12:45 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0AC1B31E7 for ; Fri, 29 Jan 2016 11:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 ULtx_EBzXoQL for ; Fri, 29 Jan 2016 11:12:42 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE49B1B31E2 for ; Fri, 29 Jan 2016 11:12:41 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B951C20995 for ; Fri, 29 Jan 2016 14:12:40 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 29 Jan 2016 14:12:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=wCxHDgU0lciaPc+WobISQ9sIneY=; b=xcR0e2 t5M82+zpCYS2CRMkaBz2n1i2LpbcSsR50gyOgPNI8uPXw+SADxTAc8yv51knQJ/q LyMxXUoyOLqp7YaBC40FaMWMXQAvTakF2oCrgiuRvHQDG2sOs5zZp7JxPoV7FpcY TrclfGBiVrVUvNu+gA/xghjEJpLo1gyLzZ/OQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=wCxHDgU0lciaPc+ WobISQ9sIneY=; b=fO6jjkAOm+b3r5wYJ6qdUie2SPrFwwlG0v0yd7KFrshVVXk 6MQ8kkhh3nQ1sizGpzsMyuZAks0vineyf2gw8fLZBACB5JMZl0Hhg0ZrvWHahPmH itoqdDdRY6zs7GxIz39NS/71YWmT2zhm1CknKedDPkkrW6gGHhAKwEUawkFU= X-Sasl-enc: BGnkBz+3XDZzmvEAWyQQPiSOxwDz8cyJyba7sUVfQAN8 1454094760 Received: from dhcp-171-68-20-130.cisco.com (dhcp-171-68-20-130.cisco.com [171.68.20.130]) by mail.messagingengine.com (Postfix) with ESMTPA id 15419C00018; Fri, 29 Jan 2016 14:12:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Fri, 29 Jan 2016 11:12:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 19:12:44 -0000 I looked through the mailing list archives and the meeting minutes from = the meetings around the time when the registration policy was added to = the document (the -01). I did not see any discussion of the registration = policy.=20 I fully agree with Haibin=E2=80=99s analysis, though, which is that the = potential for introducing sensitive diagnostic types (e.g., location) is = sufficient to make Standards Action or IETF Review a good choice. These = should get IETF-wide security review before being added to the = registries.=20 Alissa > On Jan 28, 2016, at 1:47 PM, Barry Leiba = wrote: >=20 >> Does Haibin=E2=80=99s answer clear up your concern? >=20 > Sorry, it must have gotten lost in the end-of-year mess. >=20 > No, it doesn't: Haibin gives his thoughts on the question, but I asked > about what discussion the working group had in coming to the decision. > Further comment: >=20 >>> For Sections 9.1 and 9.2, I would like to see some evidence of = discussion that >>> resulted in the decision to make the registry policies Standards = Action. Did >>> the working group actually discuss this and make a decision that = Standards >>> Action is right? What's the reasoning for not using some softer = policy, such as >>> "IETF Review" (which might allow for registrations from Experimental >>> documents) or Specification Required (which would allow review by a >>> designated expert of a non-RFC specification)? Why is Standards = Action the >>> right thing? >>>=20 >> The thought was that if a new value would be used for experimental >> purpose, then there are reserved values accordingly for overlay local >> use (0xF000-0xFFFE). And then if people want that value can be used >> across different RELOAD overlays, then they'd better need a standard >> track document to define it (that's why we assume it would be = standard >> track). "Specification Required" allows non-RFC specifications, not >> sure that would reflect the IETF consensus (certain concerns might >> exist about certain kinds of diagnostic information). >=20 > Yes, "Specification Required" allows non-RFC specifications, with a > designated expert to review the request and sanity-check it. Why does > the working group think this registry needs only Standards Track RFCs > to make registrations? Why can't IETF consensus approve a > non-Standards-Track RFC (as with "IETF Review")? Why couldn't a > designated expert handle the review, consulting with whatever > appropriate working group(s) exist at the time (as with "Specification > Required")? >=20 > I'm honest OK with Standards Action if that's really what the working > group wants, and they have a reasonable explanation for why that's > necessary here. I'm asking because I can't see any evidence that it > was actually discussed, and I'm concerned that we consistently use > too-strict registration policies because we think they're necessary, > and that often bites us later on, when we wish we hadn't been so > strict. >=20 > Can you point me at any messages or minutes that show the working > group discussion about the registration policy? Can the working group > explain what harm could be caused if registrations were allowed to be > made without Standards Track RFCs? >=20 > Barry From nobody Fri Jan 29 12:30:36 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D171B3350; Fri, 29 Jan 2016 12:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 QueVogif6zkY; Fri, 29 Jan 2016 12:30:33 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29971B334C; Fri, 29 Jan 2016 12:30:32 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id ik10so44460253igb.1; Fri, 29 Jan 2016 12:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=VIXpRLvjo4ZHUmU7Y69PW441Rk5gMprLKp8fLn3AnRU=; b=h1m7tKP0JMV7kFmPhI3p1xPY56sr9CLJKglSNoKQrhx3FrcHPLP6/fGXq7HBylsglk LLUdgb+ZbnhuTOH7Q1AjBG8/e0ypK0UdRVApX/TlulMhRJIbKS8zZ8gtWuojGgc6oKEF 8PySomKv4/Mk6fNmVBhNqUy18M7twN9P1HEHKzjiJftfzPNcMv88dlSr2Goj64swcKS0 GjPTORM8pCI6LFY9sehl9YTJxP88f4H6faW94BCJqND3sdcyKiumALL0rdPD48UiLJfm CvRk0vprjkTtCLfGMQi+i28o79sM8ErjpI4DGkhZzteJO8V9YxIb/wtjb/82sekks6qL hLFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VIXpRLvjo4ZHUmU7Y69PW441Rk5gMprLKp8fLn3AnRU=; b=HnMpd+ajiEXVMF06pGnVKP9Yf6Xl0sdf6hFKTFtX0npZegYNnCQ+Rt7sllp23a9i/P SesYCF8a4f1Zd9FUtVekLIOrnuiy5Q0fjwxQrqORhkphqS5WT/p01HOx1SpgetyYcZ4h z4U28xMrkN1cVBdz9OjVcMpBYoCr2bNZ1M+DyazJHxtTmyRGqm3NwhUOg+gwkVFpHHJ0 5YgnWjeKNZEBrKkUiywJUBZ1I+4yOPZfAOX6HUmaMA2ytgpQMoPru2CxupSV1iHGuMwO 0NWplNxbzDbcg0/SlUBt3fo1QN+ptJM3a9vswlS6XXMD/tgUiREvsaNKAPlUAmlY5OOh 5Bdw== X-Gm-Message-State: AG10YOSSdsuz1pGSRqCDmTlxBidQZxnlqvYsgwQ/HGITC/rZ4B5kV+UcTNa8YEVy2KzsQ/m7j9yK25oyxRi+5g== MIME-Version: 1.0 X-Received: by 10.50.73.168 with SMTP id m8mr12395240igv.53.1454099432108; Fri, 29 Jan 2016 12:30:32 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.50.129 with HTTP; Fri, 29 Jan 2016 12:30:32 -0800 (PST) In-Reply-To: References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 15:30:32 -0500 X-Google-Sender-Auth: zUjnQsZFGVXuHlQWxdABDBQ-g_k Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , "draft-ietf-p2psip-diagnostics@ietf.org" Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:30:35 -0000 On Fri, Jan 29, 2016 at 2:12 PM, Alissa Cooper wrote: > > I looked through the mailing list archives and the meeting minutes > from the meetings around the time when the registration policy was > added to the document (the -01). I did not see any discussion of the > registration policy. > > I fully agree with Haibin=E2=80=99s analysis, though, which is that the > potential for introducing sensitive diagnostic types (e.g., location) > is sufficient to make Standards Action or IETF Review a good choice. > These should get IETF-wide security review before being added to the > registries. I've also had some off-list discussion with Alissa, in which she adds that new registrations aren't very likely, so the barrier probably won't really matter. So I'm going to accept this as sufficient discussion and will go clear my DISCUSS now. I think it's important that in future cases we urge working groups to have explicit discussion of registration policies, but I agree that it's not really the time to do that with this document. Thanks for the discussion we've had on it. Barry >> On Jan 28, 2016, at 1:47 PM, Barry Leiba wrote= : >> >>> Does Haibin=E2=80=99s answer clear up your concern? >> >> Sorry, it must have gotten lost in the end-of-year mess. >> >> No, it doesn't: Haibin gives his thoughts on the question, but I asked >> about what discussion the working group had in coming to the decision. >> Further comment: >> >>>> For Sections 9.1 and 9.2, I would like to see some evidence of discuss= ion that >>>> resulted in the decision to make the registry policies Standards Actio= n. Did >>>> the working group actually discuss this and make a decision that Stand= ards >>>> Action is right? What's the reasoning for not using some softer polic= y, such as >>>> "IETF Review" (which might allow for registrations from Experimental >>>> documents) or Specification Required (which would allow review by a >>>> designated expert of a non-RFC specification)? Why is Standards Actio= n the >>>> right thing? >>>> >>> The thought was that if a new value would be used for experimental >>> purpose, then there are reserved values accordingly for overlay local >>> use (0xF000-0xFFFE). And then if people want that value can be used >>> across different RELOAD overlays, then they'd better need a standard >>> track document to define it (that's why we assume it would be standard >>> track). "Specification Required" allows non-RFC specifications, not >>> sure that would reflect the IETF consensus (certain concerns might >>> exist about certain kinds of diagnostic information). >> >> Yes, "Specification Required" allows non-RFC specifications, with a >> designated expert to review the request and sanity-check it. Why does >> the working group think this registry needs only Standards Track RFCs >> to make registrations? Why can't IETF consensus approve a >> non-Standards-Track RFC (as with "IETF Review")? Why couldn't a >> designated expert handle the review, consulting with whatever >> appropriate working group(s) exist at the time (as with "Specification >> Required")? >> >> I'm honest OK with Standards Action if that's really what the working >> group wants, and they have a reasonable explanation for why that's >> necessary here. I'm asking because I can't see any evidence that it >> was actually discussed, and I'm concerned that we consistently use >> too-strict registration policies because we think they're necessary, >> and that often bites us later on, when we wish we hadn't been so >> strict. >> >> Can you point me at any messages or minutes that show the working >> group discussion about the registration policy? Can the working group >> explain what harm could be caused if registrations were allowed to be >> made without Standards Track RFCs? >> >> Barry > From nobody Fri Jan 29 12:39:50 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 616331A92DC; Fri, 29 Jan 2016 12:39:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129203946.14671.39449.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 12:39:46 -0800 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-diagnostics@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Barry Leiba's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:39:46 -0000 Barry Leiba has entered the following ballot position for draft-ietf-p2psip-diagnostics-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- For Sections 9.1 and 9.2, I wish there had been some working group discussion that resulted in the decision to make the registry policies Standards Action. It seems that some softer policy, such as "IETF Review" (which might allow for registrations from Experimental documents) or Specification Required (which would allow review by a designated expert of a non-RFC specification) would work OK for this registry, and I would have liked the working group to have actively considered that. But that ship has sailed for this document and this working group, and it's not likely to box us in for this case, so this is now a non-blocking comment. Thanks for the discussion we've had on this point. In addition to what Ben has already said... One of the things that idnits calls out is this: -- The draft header indicates that this document updates RFC6940, but the abstract doesn't seem to mention this, which it should. I believe it's not a problem that the abstract doesn't mention it, but one *reason* the abstract doesn't mention it is that the rest of the document doesn't mention it either. It's not at all clear WHY this document updates 6940. Why? (This is in support of Ben's comment, as well as being a question to the shepherd.) The idnits tool also mentions the pre-5378 disclaimer, and this has been resolved, so the disclaimer should be removed when the draft is updated. I strongly agree with Ben's comment about needing explanations for a number of SHOULDs (and SHOULD NOTs) in the document. RFC 2119 says that for SHOULD, "the full implications must be understood and carefully weighed before choosing a different course." Without any explanation, there's no way for implementors to understand the implications and to weigh anything, and I tripped over that quite a number of times during my review. I agree with Spencer's comment that we don't usually strong-arm IANA with 2119 key words. It's a small point, and I don't think IANA are easily offended [ :-) ], but "IANA is asked to create" is a better approach than "IANA SHALL create", and so on. From nobody Fri Jan 29 22:47:17 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5021B3012; Fri, 29 Jan 2016 22:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 oykDmM-v2dJ2; Fri, 29 Jan 2016 22:47:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C4A1B3010; Fri, 29 Jan 2016 22:47:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHR36722; Sat, 30 Jan 2016 06:47:07 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 30 Jan 2016 06:47:06 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 30 Jan 2016 14:46:59 +0800 From: "Songhaibin (A)" To: Alexey Melnikov , Jari Arkko Thread-Topic: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) Thread-Index: AQHRSTbRdacASYAuakGMpQDKz6bJNp8TwUYg Date: Sat, 30 Jan 2016 06:46:58 +0000 Message-ID: References: <20151217072025.29734.77582.idtracker@ietfa.amsl.com> <11E81FFA-7187-43B4-BA99-40859D835FDD@piuha.net> <78ECC973-EF0E-40F1-8C26-F060F033563E@isode.com> In-Reply-To: <78ECC973-EF0E-40F1-8C26-F060F033563E@isode.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56AC5C6C.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 99c68bdb8ca737a48f4d56189c9b31fc Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 06:47:15 -0000 Dear Alexey and Jari, Accept the text what Jari suggested. And now it is clear. BR, -Haibin Song > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Thursday, January 07, 2016 6:36 PM > To: Jari Arkko; Songhaibin (A) > Cc: The IESG; p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf.= org; > p2psip@ietf.org > Subject: Re: [P2PSIP] Jari Arkko's Discuss on draft-ietf-p2psip-diagnosti= cs-19: > (with DISCUSS) >=20 > Hi, >=20 > > On 7 Jan 2016, at 00:34, Jari Arkko wrote: > > > > > >> In Section 5.3, it says "The dMFlags field described above is a 64 bit= field > that allows initiator nodes to identify up to 62 items of base informatio= n to > request in a request message (the first and last flags being reserved)." = 62 bits > can be used to indicate up to 62 diagnostic Kinds, but dMFlags reserves a= ll "0"s > that means nothing is requested, and all "1"s that means everything is > requested. But at the same time, the first and last bits cannot be used f= or > other purposes. > > > > Right. Can that be explained somewhere, and can Section 9.1 show the > > two aspects? That is, the all 0s/1s *and* first and last bits being > > reserved? The current text does not reserve the first and last bits. > > It only reserves the all 0s and all 1s... >=20 > I thought the same. > > > > +-------------------------+------------------------------+----------= + > > | diagnostic information |diagnostic flag in dMFlags | RFC = | > > |-------------------------+------------------------------+----------= | > > |Reserved | 0x 0000 0000 0000 0000 > |RFC-[TBDX]| > > |STATUS_INFO | 0x 0000 0000 0000 0001 > |RFC-[TBDX]| > > |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 > |RFC-[TBDX]| > > |PROCESS_POWER | 0x 0000 0000 0000 0004 > |RFC-[TBDX]| > > |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 > |RFC-[TBDX]| > > |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 > |RFC-[TBDX]| > > |SOFTWARE_VERSION | 0x 0000 0000 0000 0020 > |RFC-[TBDX]| > > |MACHINE_UPTIME | 0x 0000 0000 0000 0040 > |RFC-[TBDX]| > > |APP_UPTIME | 0x 0000 0000 0000 0080 > |RFC-[TBDX]| > > |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 > |RFC-[TBDX]| > > |DATASIZE_STORED | 0x 0000 0000 0000 0200 > |RFC-[TBDX]| > > |INSTANCES_STORED | 0x 0000 0000 0000 0400 > |RFC-[TBDX]| > > |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 > |RFC-[TBDX]| > > |EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 > |RFC-[TBDX]| > > |EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 > |RFC-[TBDX]| > > |UNDERLAY_HOP | 0x 0000 0000 0000 4000 > |RFC-[TBDX]| > > |BATTERY_STATUS | 0x 0000 0000 0000 8000 > |RFC-[TBDX]| > > |Reserved | 0x FFFF FFFF FFFF FFFF > |RFC-[TBDX]| > > +-------------------------+------------------------------+----+ > > > > But maybe I'm missing something. > > > > I thought the text above should be something like this instead: >=20 > Exactly my point. If what Jari suggests is not true, then the text needs = even > more work. > > > > +-------------------------+------------------------------+----------= + > > | diagnostic information |diagnostic flag in dMFlags | RFC = | > > |-------------------------+------------------------------+----------= | > > |Reserved All 0s value | 0x 0000 0000 0000 0000 > |RFC-[TBDX]| > > |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| > > |STATUS_INFO | 0x 0000 0000 0000 0002 > |RFC-[TBDX]| > > |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 > |RFC-[TBDX]| > > |PROCESS_POWER | 0x 0000 0000 0000 0008 > |RFC-[TBDX]| > > |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 > |RFC-[TBDX]| > > |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 > |RFC-[TBDX]| > > |SOFTWARE_VERSION | 0x 0000 0000 0000 0040 > |RFC-[TBDX]| > > |MACHINE_UPTIME | 0x 0000 0000 0000 0080 > |RFC-[TBDX]| > > |APP_UPTIME | 0x 0000 0000 0000 0100 > |RFC-[TBDX]| > > |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 > |RFC-[TBDX]| > > |DATASIZE_STORED | 0x 0000 0000 0000 0400 > |RFC-[TBDX]| > > |INSTANCES_STORED | 0x 0000 0000 0000 0800 > |RFC-[TBDX]| > > |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 > |RFC-[TBDX]| > > |EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 > |RFC-[TBDX]| > > |EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 > |RFC-[TBDX]| > > |UNDERLAY_HOP | 0x 0000 0000 0000 8000 > |RFC-[TBDX]| > > |BATTERY_STATUS | 0x 0000 0000 0001 0000 > |RFC-[TBDX]| > > |Reserved Last Bit | 0x 8000 0000 0000 0000 > |RFC-[TBDX]| > > |Reserved All 1s Value | 0x FFFF FFFF FFFF FFFF > |RFC-[TBDX]| > > +-------------------------+------------------------------+----+ > > > >> > >>> > >>> Also, Section 5.3 uses "delimited" when it probably should have said > >>> "terminated", unless there's more substructure in the > >>> SOFTWARE_VERSION string than is identified by the text. > >> > >> It is the language problem and accepted. > > > > Thanks! > > > > Jari > > From nobody Sat Jan 30 00:53:27 2016 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC31B36C0; Sat, 30 Jan 2016 00:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 i_4FIwNgSZGU; Sat, 30 Jan 2016 00:53:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3B31B36BF; Sat, 30 Jan 2016 00:53:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDR01288; Sat, 30 Jan 2016 08:53:16 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 30 Jan 2016 08:53:15 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Sat, 30 Jan 2016 16:53:12 +0800 From: "Songhaibin (A)" To: "Alvaro Retana (aretana)" , The IESG Thread-Topic: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) Thread-Index: AQHROE3xg1hbhCRGu0GftwreM9LEL57uSeMggAJp5wCAIz/kMA== Date: Sat, 30 Jan 2016 08:53:12 +0000 Message-ID: References: <20151216220546.7663.70255.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.145] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56AC79FD.0079, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b57b51ea44527d2a47ed345b83233b60 Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 08:53:23 -0000 Hi Alvaro, > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > Sent: Friday, January 08, 2016 4:28 AM > To: Songhaibin (A); The IESG > Cc: draft-ietf-p2psip-diagnostics@ietf.org; p2psip-chairs@ietf.org; > cjbc@it.uc3m.es; p2psip@ietf.org; Roni Even > Subject: Re: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19:= (with > DISCUSS and COMMENT) >=20 > On 1/6/16, 4:44 AM, "Songhaibin (A)" wrote: >=20 > Haibin: >=20 > Hi! >=20 > ... > >> > >> > >> > >> --------------------------------------------------------------------- > >> - > >> DISCUSS: > >> --------------------------------------------------------------------- > >> - > >> > >> I am balloting a DISCUSS because I am concerned that this document > >>doesn't actually do what it set out to achieve. I would love it if > >>during the discussion I was pointed to the places where RELOAD > >>already solves the issues, but for now I wasn't able to find them. > >> > >> According to the text, both extensions are intended to collect > >>information "along the path", and the Figures clearly depict what is > >>intended to happen. > >> However, I don't think that as specified (or at least as explained) > >>the behavior is guaranteed. Specific points: > >> > >> 1. RFC6940 says (in Section 6.2. (Symmetric Recursive Routing)) that > >>an "overlay MAY be configured to use alternative routing > >>algorithms=A9[or]=A9MAY be selected on a per-message basis". How is th= e > >>symmetry enforced if other routing algorithms are used? Enforcing > >>that the ping/trace messages use symmetric routing when other > >>algorithms are in use won't necessarily help because the paths may be > >>different. > > > >I think one important thing is that, the draft does not guarantee what > >it conveys must be the information that caused the previous failures, > >but with the retrieved information from the previous traversed nodes > >(with high probability, as it cannot guarantee the exact same path), a > >user or machine can analyze and infer what is the problem. Symmetric > >routing is achieved by the via list (whatever DHT routing algorithms > >are used), but response message could go through not exactly the same > >path as there still can be failures during that short period. > > > >> > >> 2. RFC6940 also (in 6.2.2. (Response Origination)) reads: "the > >>response traverses the same peers as the request traversed, except in > >>reverse order (symmetric routing) and possibly with extra nodes > >>(loose routing)." > >> In other words, even if symmetric routing is used, there is no > >>guarantee that the same path will be followed by the response, unless > >>the originator builds the Via List with strict details of all the > >>nodes in the path -- maybe this is what is intended, but no explicit > >>mention occurs in the document. > > > >I agree this should be mentioned in the document. >=20 > Clarifying the caveats (like what we're discussing above, for example) is= one of > the ways to move forward with resolving my DISCUSS. >=20 > However, I have to say that the clarifications, which basically point at = no > guarantees about the path (or its relevance), leave me very dissatisfied = with a > technical solution that is unreliable. :-( >=20 Unless there is path information from the previous RELOAD message, it canno= t guarantee the same path for the diagnostics message. It is similar to the= routing packets in a large network.=20 > > > >> > >> 3. In 4.3, what does "directly or via symmetric routing" mean? Is it > >>directly connected? If so, then (for the text in 4.3) that would mean > >>that C is adjacent to A, and even though it is the next hop after B, > >>the path taken to reach C with the PathTrack request doesn't include > >>B < the result is that the diagnostic information received from C may > >>not be relevant relative to destination D. > > > >As each PathTrack request will contain the destination ID, which was > >the same destination ID as the previously failed message. So no matter > >how the PathTrack request arrives to C, C will have a look at that > >destination ID for the next step. >=20 > My point above was the the path *to* C (from A) may not actually even go > through B. In other words, even if the rest of the path (all the way to > D) is congruent, the overall information is still not completely relevant= . >=20 > > It is determined by the routing table in the P2P overlay network. If the ov= erlay is stable, then the path to the destination is stable. The "directly = or via symmetric routing" only mean how the initiator node talk with each p= eer in the path. Symmetric routing means the use of via list. And directly = routing (I will change it to direct response routing) can refer to RFC 7263= . So in this case you mentioned, A asks B first, and then asks C (via DRR or = symmetric routing). I hope the clarification helps. > > > >> > >> Are there implementations available? What has been the experience? > >>The Shepherd's write-up didn't mention any, and the TBD codes make me > >>think that maybe Experimental might be a better status for this > >>document. > > > >In my memory, there was one several years ago, but not based on RELOAD. >=20 > Given the clear inconsistency and the lack of experience, I want to sugge= st that > Experimental status be considered. If we get an consensus somewhere on the status, I will follow it to do the = editing work. Thank you very much, -Haibin Song > > > > > > > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> In general, as others have mentioned, I think the text could be a lot > >>clearer and not leave some concepts to interpretation. > >> > >> 1. In 4.2.1, the MessageExtension is defined with a Boolean of > >>"critical", but the text (a paragraph later) says that this > >>"extension is not critical". I may be missing some of the semantics, > >>or there's an error somewhere. > > > >My understanding with RELOAD, if value of "critical" can be true or > >false, if it is critical, then every node must support the extension, > >if it is not critical, then it is optional to support it. As it > >explains in that section, "If a peer does not support the extension, > >they will simply ignore the diagnostic portion of the message..." >=20 > I looked at the text again -- it is still confusing to me, but I noticed = that Section > 6.1. (Message Creation and Transmission) does say that "the sender > MUST...[set] the value of critical to FALSE". Maybe using "Critical" (ca= pital C) > to describe the state (vs the use of the word as an > adjective) would help. >=20 > > > >> > >> 2. In 4.3..the last paragraph reads: if "...succesive calls to > >>PathTrack return different paths, the results should be discarded and > >>the request resent, ensuring that the second request traverses the > >>appropriate path". > >> Path changes are a fact of life < the second request may just be > >>reflecting the new path, so resending it in an attempt to find the > >>"appropriate path" > >>may be > >> futile. > > > >At least in the previous two attempts, the path was "stable". > > > >> 3. What is a "routing mode"? Section 4.3.1. (New RELOAD Request: > >> PathTrack) talks about it when saying that the "PathTrack request can > >>be routed directly or through the overlay based on the routing mode". > >>Later > >> Section 6.2. (Message Processing: Intermediate Peers) says that > >>"processing this request according to the overlay specified routing > >>mode from RELOAD protocol" -- I looked in RFC6940 for "routing mode", > >>but didn't find anything. > >> Note that it also looks to me like there's no place in the > >>DiagnosticsRequest to indicate a mode.. > > > >This draft should add a reference to RFC 7263 for the routing mode. >=20 > Ok. >=20 > > > >> 4. Section 5.3. (dMFlags and Diagnostic Kind ID Types) defines an > >>"UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the > >>intermediate peer which receives the diagnostics message to the next > >>hop peer for this message." How is that information derived? > > > >It can use the traceroute tool. > > > >> 5. I think that the Reference to RFC5226 should be Normative. > >> > > > >Accepted. > > > >> > >> I also agree with others that the title should probably be something > >>around RELOAD Diagnostics, and that this work doesn't really update > >>RFC6940, it extends it in independent ways. > > > >It seems we can achieve a consensus here that it extends RELOAD. What > >about the title "RELOAD Extension for P2P Overlay Diagnostics"? >=20 > I am not opposed to that. >=20 > Thanks! >=20 > Alvaro.