From nobody Tue Feb 2 05:46:30 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 A778B1ACE1F for ; Tue, 2 Feb 2016 05:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] 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 KtGua1wFzWca for ; Tue, 2 Feb 2016 05:46:26 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BEB21B2AF1 for ; Tue, 2 Feb 2016 05:46:23 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id r129so118633958wmr.0 for ; Tue, 02 Feb 2016 05:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:content-type:mime-version:content-transfer-encoding; bh=S3sLdRxVk1+ZoOTi2JMu8+4RlwiQ/+2qJYVT+/g9IIc=; b=WaVA3MVvVdiHN6ihnjtVKv73rwESqPmvyIQC/f1kdTyqgL/9u5GperNIvTKqA8HjSp qpkTFKYWB3vZpPTrrhrC2Stz/qGKrWuoZYh+kmx5cMEi+HVS+Er7h320t95JwKHGP63P yznNlCmKbeMzMGKsYYdNG69NGxXljQwMWScgj+3GYc9Z8GiZHrbUpuoRuOq+t3ZmgkPP ptJyaCL7/C/cl5FkEC+fzDky0R+jxmgR8YnfjZFljtIdgoh5zMWfWQSVxhKwz4I6wC6O 6KqM9EuXK2qUPXPU69NwSVGiE9oRo+HeDCP3tvgc1DpGhtEDLMFNljgMPTGz63zu7K/Y SZJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:content-type:mime-version :content-transfer-encoding; bh=S3sLdRxVk1+ZoOTi2JMu8+4RlwiQ/+2qJYVT+/g9IIc=; b=YDp6Hoqg3SQvWzOtUz36Ygr3RO28iQAVxHzqFtCrMsGCweGI7iF9Dp6MXm7/IE7CBi ld17x113WjjEv8O+Vm4E/8ALAbPOxGdnGRLyywRYIxc3/IG0Yu46/KEgRTARH121/B2a B3i16UVpyoF/mbq7zZYdgMoq9BlUIGAI1hlLyJjuwLdwJTdGFnHtn+GOY5DVwy4T9WSi 59xwKQt0znt2aDrx/gWbnY5lWpzSVVYAJA3G6WlbusLsV/EIdicyZqJ88JGFvbrjyeh7 L/dgSlS2DfZyUhuUlC9IGZSrxRGMHivPLq1w1tPqHm7AzAy6kDyW9hjxB4NEz2PPU2Z/ WCTg== X-Gm-Message-State: AG10YOReNfEfpgvjkDiU6iwGnC6CgBtWnue9M0xOPDz3oUXxKq0GVOvUbfoEwAF/Ry23cHOK X-Received: by 10.28.96.198 with SMTP id u189mr16009088wmb.55.1454420782289; Tue, 02 Feb 2016 05:46:22 -0800 (PST) Received: from ?IPv6:2001:720:410:1010:2247:47ff:fedb:3d7e? ([2001:720:410:1010:2247:47ff:fedb:3d7e]) by smtp.gmail.com with ESMTPSA id e77sm16574039wma.18.2016.02.02.05.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 05:46:21 -0800 (PST) Message-ID: <1454420780.3763.9.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Barry Leiba , The IESG Date: Tue, 02 Feb 2016 14:46:20 +0100 In-Reply-To: <20160129203946.14671.39449.idtracker@ietfa.amsl.com> References: <20160129203946.14671.39449.idtracker@ietfa.amsl.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-diagnostics@ietf.org, p2psip@ietf.org Subject: Re: [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 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:46:27 -0000 Hi Barry, As document shepherd, I think I have to apologize because now that you brought up the issue of "Updates RFC6940", I agree with you that there is no reason for that. @Authors: can you remove that or comment why this is required? Thanks, Carlos On Fri, 2016-01-29 at 12:39 -0800, Barry Leiba wrote: > 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 Tue Feb 2 17:11:25 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 D39C21ACF56; Tue, 2 Feb 2016 17:11:21 -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 Vnx_KnSX7Nak; Tue, 2 Feb 2016 17:11:18 -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 1EA451ACF1C; Tue, 2 Feb 2016 17:11:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHW43716; Wed, 03 Feb 2016 01:11:14 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Feb 2016 01:11:13 +0000 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Feb 2016 01:11:12 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 3 Feb 2016 09:11:07 +0800 From: "Songhaibin (A)" To: "cjbc@it.uc3m.es" , Barry Leiba , The IESG Thread-Topic: [P2PSIP] Barry Leiba's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT) Thread-Index: AQHRWtU1cO/XfcRTn0Og15JpAgPJo58YRGoAgAFFTUA= Date: Wed, 3 Feb 2016 01:11:06 +0000 Message-ID: References: <20160129203946.14671.39449.idtracker@ietfa.amsl.com> <1454420780.3763.9.camel@it.uc3m.es> In-Reply-To: <1454420780.3763.9.camel@it.uc3m.es> 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.0A020201.56B153B2.0192, 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: d6200e6cd607cc7c157461d7f9054005 Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , "p2psip@ietf.org" Subject: Re: [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 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, 03 Feb 2016 01:11:22 -0000 SSB0aGluayB3ZSBjYW4gcmVtb3ZlIHRoYXQuDQoNCkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQMlBTSVAgW21haWx0bzpwMnBz aXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcmxvcyBKZXPDunMNCj4gQmVybmFy ZG9zIENhbm8NCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDIsIDIwMTYgOTo0NiBQTQ0KPiBU bzogQmFycnkgTGVpYmE7IFRoZSBJRVNHDQo+IENjOiBwMnBzaXAtY2hhaXJzQGlldGYub3JnOyBk cmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljc0BpZXRmLm9yZzsNCj4gcDJwc2lwQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbUDJQU0lQXSBCYXJyeSBMZWliYSdzIE5vIE9iamVjdGlvbiBvbg0K PiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xOTogKHdpdGggQ09NTUVOVCkNCj4gDQo+ IEhpIEJhcnJ5LA0KPiANCj4gQXMgZG9jdW1lbnQgc2hlcGhlcmQsIEkgdGhpbmsgSSBoYXZlIHRv IGFwb2xvZ2l6ZSBiZWNhdXNlIG5vdyB0aGF0IHlvdQ0KPiBicm91Z2h0IHVwIHRoZSBpc3N1ZSBv ZiAiVXBkYXRlcyBSRkM2OTQwIiwgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZXJlIGlzIG5vDQo+ IHJlYXNvbiBmb3IgdGhhdC4gQEF1dGhvcnM6IGNhbiB5b3UgcmVtb3ZlIHRoYXQgb3IgY29tbWVu dCB3aHkgdGhpcyBpcw0KPiByZXF1aXJlZD8NCj4gDQo+IFRoYW5rcywNCj4gDQo+IENhcmxvcw0K PiANCj4gT24gRnJpLCAyMDE2LTAxLTI5IGF0IDEyOjM5IC0wODAwLCBCYXJyeSBMZWliYSB3cm90 ZToNCj4gPiBCYXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gPiBkcmFmdC1pZXRmLXAycHNpcC1kaWFnbm9zdGljcy0xOTogTm8gT2JqZWN0 aW9uDQo+ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCj4gPiB0aGlzIGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS4N Cj4gPiBodG1sDQo+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNz Lw0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLS0NCj4gPiBDT01NRU5UOg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiAtLS0NCj4gPg0KPiA+IEZvciBTZWN0aW9ucyA5LjEgYW5kIDku MiwgSSB3aXNoIHRoZXJlIGhhZCBiZWVuIHNvbWUgd29ya2luZyBncm91cA0KPiA+IGRpc2N1c3Np b24gdGhhdCByZXN1bHRlZCBpbiB0aGUgZGVjaXNpb24gdG8gbWFrZSB0aGUgcmVnaXN0cnkgcG9s aWNpZXMNCj4gPiBTdGFuZGFyZHMgQWN0aW9uLsKgwqBJdCBzZWVtcyB0aGF0IHNvbWUgc29mdGVy IHBvbGljeSwgc3VjaCBhcyAiSUVURg0KPiA+IFJldmlldyIgKHdoaWNoIG1pZ2h0IGFsbG93IGZv ciByZWdpc3RyYXRpb25zIGZyb20gRXhwZXJpbWVudGFsDQo+ID4gZG9jdW1lbnRzKQ0KPiA+IG9y IFNwZWNpZmljYXRpb24gUmVxdWlyZWQgKHdoaWNoIHdvdWxkIGFsbG93IHJldmlldyBieSBhIGRl c2lnbmF0ZWQNCj4gPiBleHBlcnQgb2YgYSBub24tUkZDIHNwZWNpZmljYXRpb24pIHdvdWxkIHdv cmsgT0sgZm9yIHRoaXMgcmVnaXN0cnksDQo+ID4gYW5kIEkgd291bGQgaGF2ZSBsaWtlZCB0aGUg d29ya2luZyBncm91cCB0byBoYXZlIGFjdGl2ZWx5IGNvbnNpZGVyZWQNCj4gPiB0aGF0LsKgwqBC dXQgdGhhdCBzaGlwIGhhcyBzYWlsZWQgZm9yIHRoaXMgZG9jdW1lbnQgYW5kIHRoaXMgd29ya2lu Zw0KPiA+IGdyb3VwLCBhbmQgaXQncyBub3QgbGlrZWx5IHRvIGJveCB1cyBpbiBmb3IgdGhpcyBj YXNlLCBzbyB0aGlzIGlzIG5vdw0KPiA+IGEgbm9uLWJsb2NraW5nIGNvbW1lbnQuwqDCoFRoYW5r cyBmb3IgdGhlIGRpc2N1c3Npb24gd2UndmUgaGFkIG9uIHRoaXMNCj4gPiBwb2ludC4NCj4gPg0K PiA+IEluIGFkZGl0aW9uIHRvIHdoYXQgQmVuIGhhcyBhbHJlYWR5IHNhaWQuLi4NCj4gPg0KPiA+ IE9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgaWRuaXRzIGNhbGxzIG91dCBpcyB0aGlzOg0KPiA+IMKg IC0tIFRoZSBkcmFmdCBoZWFkZXIgaW5kaWNhdGVzIHRoYXQgdGhpcyBkb2N1bWVudCB1cGRhdGVz IFJGQzY5NDAsDQo+ID4gYnV0IHRoZQ0KPiA+IMKgwqDCoMKgwqBhYnN0cmFjdCBkb2Vzbid0IHNl ZW0gdG8gbWVudGlvbiB0aGlzLCB3aGljaCBpdCBzaG91bGQuDQo+ID4NCj4gPiBJIGJlbGlldmUg aXQncyBub3QgYSBwcm9ibGVtIHRoYXQgdGhlIGFic3RyYWN0IGRvZXNuJ3QgbWVudGlvbiBpdCwg YnV0DQo+ID4gb25lICpyZWFzb24qIHRoZSBhYnN0cmFjdCBkb2Vzbid0IG1lbnRpb24gaXQgaXMg dGhhdCB0aGUgcmVzdCBvZiB0aGUNCj4gPiBkb2N1bWVudCBkb2Vzbid0IG1lbnRpb24gaXQgZWl0 aGVyLsKgwqBJdCdzIG5vdCBhdCBhbGwgY2xlYXIgV0hZIHRoaXMNCj4gPiBkb2N1bWVudCB1cGRh dGVzIDY5NDAuwqDCoFdoeT/CoMKgKFRoaXMgaXMgaW4gc3VwcG9ydCBvZiBCZW4ncyBjb21tZW50 LCBhcw0KPiA+IHdlbGwgYXMgYmVpbmcgYSBxdWVzdGlvbiB0byB0aGUgc2hlcGhlcmQuKQ0KPiA+ DQo+ID4gVGhlIGlkbml0cyB0b29sIGFsc28gbWVudGlvbnMgdGhlIHByZS01Mzc4IGRpc2NsYWlt ZXIsIGFuZCB0aGlzIGhhcw0KPiA+IGJlZW4gcmVzb2x2ZWQsIHNvIHRoZSBkaXNjbGFpbWVyIHNo b3VsZCBiZSByZW1vdmVkIHdoZW4gdGhlIGRyYWZ0IGlzDQo+ID4gdXBkYXRlZC4NCj4gPg0KPiA+ IEkgc3Ryb25nbHkgYWdyZWUgd2l0aCBCZW4ncyBjb21tZW50IGFib3V0IG5lZWRpbmcgZXhwbGFu YXRpb25zIGZvciBhDQo+ID4gbnVtYmVyIG9mIFNIT1VMRHMgKGFuZCBTSE9VTEQgTk9UcykgaW4g dGhlIGRvY3VtZW50LsKgwqBSRkMgMjExOSBzYXlzDQo+ID4gdGhhdCBmb3IgU0hPVUxELCAidGhl IGZ1bGwgaW1wbGljYXRpb25zIG11c3QgYmUgdW5kZXJzdG9vZCBhbmQNCj4gPiBjYXJlZnVsbHkg d2VpZ2hlZCBiZWZvcmUgY2hvb3NpbmcgYSBkaWZmZXJlbnQgY291cnNlLiLCoMKgV2l0aG91dCBh bnkNCj4gPiBleHBsYW5hdGlvbiwgdGhlcmUncyBubyB3YXkgZm9yIGltcGxlbWVudG9ycyB0byB1 bmRlcnN0YW5kIHRoZQ0KPiA+IGltcGxpY2F0aW9ucyBhbmQgdG8gd2VpZ2ggYW55dGhpbmcsIGFu ZCBJIHRyaXBwZWQgb3ZlciB0aGF0IHF1aXRlIGENCj4gPiBudW1iZXIgb2YgdGltZXMgZHVyaW5n IG15IHJldmlldy4NCj4gPg0KPiA+IEkgYWdyZWUgd2l0aCBTcGVuY2VyJ3MgY29tbWVudCB0aGF0 IHdlIGRvbid0IHVzdWFsbHkgc3Ryb25nLWFybSBJQU5BDQo+ID4gd2l0aA0KPiA+IDIxMTkga2V5 IHdvcmRzLsKgwqBJdCdzIGEgc21hbGwgcG9pbnQsIGFuZCBJIGRvbid0IHRoaW5rIElBTkEgYXJl IGVhc2lseQ0KPiA+IG9mZmVuZGVkIFsgOi0pIF0sIGJ1dCAiSUFOQSBpcyBhc2tlZCB0byBjcmVh dGUiIGlzIGEgYmV0dGVyIGFwcHJvYWNoDQo+ID4gdGhhbiAiSUFOQSBTSEFMTCBjcmVhdGUiLCBh bmQgc28gb24uDQo+ID4NCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg== From nobody Mon Feb 8 14:33:29 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 E9B221B342A for ; Mon, 8 Feb 2016 14:33:27 -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 B9Bem_hnnk9t for ; Mon, 8 Feb 2016 14:33:24 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDBA1B3428 for ; Mon, 8 Feb 2016 14:33:24 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 29C0B20794 for ; Mon, 8 Feb 2016 17:33:24 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 08 Feb 2016 17:33:24 -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=Yy6WuR5sMjwnJuU+zLS1QVAOu7s=; b=VT+H2z D+Ic+y7iThY7NihjvHZD2PixS6KMzKpB2q0E3dnMUqU+DefawW2B0V/vntKArXJP jPJdzo5z6HlTatTSy+W/Rv67lpCd+GR4VqacxqDoZ3CApB0UmmrOZeFRYbCS3MC6 vYnJl9YeETxgPnXfrElGpbdb9MIVYxKrTLPEE= 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=Yy6WuR5sMjwnJuU +zLS1QVAOu7s=; b=u9KUdP8zgfGrIZX+ur+ZwIMzjH3NnFCMlqkXMI9+ixqDQhS QanOxzzMsN4Dfs9N3Djozxna+LIpNbk5MV2oUAK3l8iZr5CEUAH+ptTDKpe4sU7t j8yOm/w6gj2MeMyKLh0Car5Puopzb+JCbFKRtfga8FFVN3QWx34yFpMF0Bn0= X-Sasl-enc: Kti8pD0gOzIy7vP0PqaXEuafnoMqOCqQm08VgfdAWBbD 1454970803 Received: from dhcp-171-68-20-80.cisco.com (dhcp-171-68-20-80.cisco.com [171.68.20.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 9996368010F; Mon, 8 Feb 2016 17:33:23 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <5698B2AA.7060008@haw-hamburg.de> Date: Mon, 8 Feb 2016 14:33:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E80FB83-1586-44D9-B8F3-17567B1F1F1C@cooperw.in> References: <5698B2AA.7060008@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: P2PSIP WG 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: Mon, 08 Feb 2016 22:33:28 -0000 Hi Thomas, What is the status of this? Thanks, Alissa > On Jan 15, 2016, at 12:49 AM, Thomas C. Schmidt = wrote: >=20 > Dear Alissa, >=20 > many thanks for your detailed feedback. We'll address the comments = shortly and be back. >=20 > Best, > Thomas >=20 > 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=92ve also included some nits below that = should be >> resolved together with last call comments. >>=20 >> Given the nature of this document, I=92d 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. >>=20 >>=20 >> =3D=3D Substantive comments and questions =3D=3D >>=20 >> =3D Section 3.1 =3D >>=20 >> 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)? >>=20 >> I don=92t understand how this mechanism relates to how SSRCs are = chosen. >> In fact RFC 3550 doesn=92t specify a particular algorithm to use, but >> merely provides one example. Furthermore, I don=92t 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? >>=20 >> =3D Section 5 =3D >>=20 >> 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. >>=20 >> =3D Section 5.3 =3D >>=20 >> (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 >>=20 >> (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." >>=20 >> I don=92t understand what the normative requirement is here or why it = is >> needed. How is =93the context of use=94 defined? Shouldn=92t 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)? >>=20 >> (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." >>=20 >> Why is this SHOULD and not MUST? Shouldn=92t implementations >> conservatively assume that variable names are not allowed unless >> explicitly specified? >>=20 >> (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.=94 >>=20 >> I think this needs to account for an error condition where the = pattern >> does not meet the pattern construction requirements, e.g.: >>=20 >> ""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.=94 >>=20 >> =3D Section 6.2 =3D >>=20 >> For privacy reasons, wouldn=92t 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. >>=20 >> =3D Section 6.3 =3D >>=20 >> How strings are to be compared (e.g., as binary objects or whatever = it >> is) needs to be normatively specified. >>=20 >> 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. >>=20 >> =3D Section 6.6 =3D >>=20 >> "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" >>=20 >> It seems to me that matching the pattern is not sufficient =97 isn=92t = 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?). >>=20 >> I=92m 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 >>=20 >> This section misses the threat of a misbehaving peer who is delegated >> write access =97 that seems like an important case to cover. >>=20 >> =3D Section 8.3 =3D >>=20 >> By =93publicly readable=94 do you mean =93readable by any node in the >> overlay=94? Admission to the overlay would still be access = controlled, >> correct? >>=20 >> =3D Section 9.2 =3D >>=20 >> What is the significance of 17, other than that it is in the = unassigned >> range? >>=20 >>=20 >> =3D=3D Nits =3D=3D >>=20 >> =3D Section 1 =3D >>=20 >> 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. >>=20 >> s/from one authorized to another (previously unauthorized) user/from = one >> authorized user to another (previously unauthorized) user/ >>=20 >> =3D Section 2 =3D >>=20 >> s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts >> = ]/[I-D.ietf-p2psip-concepts >> = ]/ >>=20 >> =3D Section 3.1 =3D >>=20 >> s/Append an 8 bit long short individual index value/Append an 8-bit >> individual index value/ >>=20 >> =3D Section 4.1 =3D >>=20 >> s/an Access Control including/an Access Control List including/ >>=20 >> =3D Section 5.1 =3D >>=20 >> Same comment about I-D.ietf-p2psip-disco >> = as >> in Section 1. >>=20 >>=20 >>=20 >>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From nobody Mon Feb 8 14:34:54 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 256501B343B for ; Mon, 8 Feb 2016 14:34:53 -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 LVJDCRoPPbKx for ; Mon, 8 Feb 2016 14:34:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CB81B3432 for ; Mon, 8 Feb 2016 14:34:51 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C2682212D6 for ; Mon, 8 Feb 2016 17:34:50 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 08 Feb 2016 17:34:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= 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=eOx65HBwSv3nura5L+EQP4Uo1/Q=; b=akr7yO m+v1xwXGN/kZ/wd3SjackQ0Am0dr3EDu7aHA9TaqciEWq2LGrP7kKUMIEC7VQZKY IFGwlns8asWqfCIkvqiveQnGdvl7IROy5E3LPCzuCx/5MM7mdUAwfv3PbkAta9Mc Ja+8HW1swT5dx9gQwe5WYsNo2hmk6sBdxvSFE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=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=eOx65HBwSv3nura 5L+EQP4Uo1/Q=; b=H/X0yk/+vLFbYyFrqNLtWA8B95aNA8lZgyz1yoS7fzVk2xs UOkXRFwaBc/2STtStlH+EpaMBHiyeaQgKx8GODcmRqZUEBon81Q3QwOg3tS8uAan usHdDs9XoZx/NFUUFexDfP1Z97TpDiishJBnRGzV5sW8XqTd9/T08zaDkrCE= X-Sasl-enc: KVpuliMK2pTmjeeHj3c3hDspFjW8Sk5H76yrKQ6N7KJh 1454970890 Received: from dhcp-171-68-20-80.cisco.com (dhcp-171-68-20-80.cisco.com [171.68.20.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 514E568010F for ; Mon, 8 Feb 2016 17:34:50 -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: Mon, 8 Feb 2016 14:34:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5596511D-5D26-4792-B5AE-69DF327D5BAF@cooperw.in> References: To: P2PSIP WG X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [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: Mon, 08 Feb 2016 22:34:53 -0000 Is anyone in the WG able to respond to these comments and questions? Thanks, Alissa > On Jan 15, 2016, at 1:58 PM, Alissa Cooper wrote: >=20 > 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. >=20 > I=E2=80=99ve also included some nits below that should be resolved = together with last call comments. >=20 >=20 > =3D=3D Substantive comments and questions =3D=3D >=20 > =3D Section 3.2 =3D >=20 > 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). >=20 > 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. >=20 > =3D Section 3.3 =3D >=20 > "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)." >=20 > Why is this SHOULD rather than MUST? >=20 > =3D Section 3.4 =3D >=20 > (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? >=20 > (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. >=20 > 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. >=20 > Example of Domain Patterns: dht\.example\.com .*\.my\.name >=20 > 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]. >=20 > 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]). >=20 > 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]. >=20 > 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. >=20 > Example of Domain Patterns: dht\.example\.com .*\.my\.name >=20 > In this example, any AOR will be accepted that is either of the form = @dht.example.com, or ends with the domain "my.name". >=20 > =3D Section 8.2.3 =3D >=20 > 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. >=20 > 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). >=20 > =3D Section 8.2.4 =3D >=20 > (1) > By "public" you mean "visible to all nodes in the overlay," correct? >=20 > (2) > "Methods of providing > location and identity privacy are still being studied." >=20 > Is this true, specifically for P2PSIP? >=20 >=20 > =3D=3D Nits =3D=3D >=20 > =3D Section 1 =3D >=20 > s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And = Discovery (RELOAD)/ >=20 > 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. >=20 > 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. >=20 > =3D Section 3.1 =3D >=20 > "RELOAD peers MAY store two kinds of SIP mappings=E2=80=9D >=20 > I don=E2=80=99t think you need the normative MAY there, =E2=80=9Ccan=E2=80= =9D would work. >=20 > =3D Section 3.4 =3D >=20 > The second line of the example here needs to use .example as the TLD, = not .name. Please make the corresponding changes in the text. >=20 > =3D Section 5.1 =3D >=20 > s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/ >=20 > =3D Section 6 =3D >=20 > I don't think you need the normative MAY here. >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Mon Feb 8 14:35:28 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 CBBCE1B3435 for ; Mon, 8 Feb 2016 14:35:25 -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 TeorYSFG2owY for ; Mon, 8 Feb 2016 14:35:22 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3335C1B3437 for ; Mon, 8 Feb 2016 14:35:21 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8D479215BC for ; Mon, 8 Feb 2016 17:35:20 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 08 Feb 2016 17:35:20 -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=3Ls4f gIHFkhdqh0L5Y/MghWE+g0=; b=DwXgZ+UB0eyheVpkKCoDddWY6azwm+AlXU5GH kDhwJNjHF5efazRgdIJRl2rEJCr3JqZojLNkRQkVELaxCM8plTQoSIp9rFmw728J ztwKdi8Y7kAFGd6a9PmyhPVIeC+d41YJM+KH4+LNz23p2CFIpNO+hWB6zoDZBUpe +20/K4= 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=3Ls4fgIHFkhdqh0L5Y/MghWE+g0=; b=DkISw uzvFhGuqVSFMS2X0P99glgOC1uVPW84euD6MtpMESDXhyTc5N4xv4JrPthzLEySO 2qRogsPVseTKUbG007pBitBNH4GQtEWnjp8QEL2vrGbxAZ9L3LSi/ltDwQRU84qV KFk7AfOVsbKwT9NjL/EOyziRz8h+3AhQcWKv2A= X-Sasl-enc: TFzHxRoSgE9OApBy3KZa3t7FiU6fA/JW9dAN6u5lWxrg 1454970920 Received: from dhcp-171-68-20-80.cisco.com (dhcp-171-68-20-80.cisco.com [171.68.20.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 03244680145; Mon, 8 Feb 2016 17:35:19 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_643872C7-FB5E-4F6B-B41F-D777DAB68AD3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Mon, 8 Feb 2016 14:35:19 -0800 Message-Id: <5546C870-1B73-4CA1-BABA-842E6A95A388@cooperw.in> 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: Mon, 08 Feb 2016 22:35:26 -0000 --Apple-Mail=_643872C7-FB5E-4F6B-B41F-D777DAB68AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, What is the status of this? Thanks, Alissa > On Jan 14, 2016, at 11:05 AM, Alissa Cooper wrote: >=20 > Great, thank you. >=20 >> 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 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail=_643872C7-FB5E-4F6B-B41F-D777DAB68AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi David,

What is the status of this?

Thanks,
Alissa

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

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
=



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

= --Apple-Mail=_643872C7-FB5E-4F6B-B41F-D777DAB68AD3-- From nobody Mon Feb 8 14:37: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 7B9491B344F for ; Mon, 8 Feb 2016 14:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 wvvs6M19PvEt for ; Mon, 8 Feb 2016 14:37:03 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C39C1B3449 for ; Mon, 8 Feb 2016 14:37:03 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aSuQW-001w9o-IG>; Mon, 08 Feb 2016 23:37:00 +0100 Received: from x55b23e3d.dyn.telefonica.de ([85.178.62.61] helo=[192.168.178.90]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1aSuQW-0030NS-49>; Mon, 08 Feb 2016 23:37:00 +0100 To: Alissa Cooper References: <5698B2AA.7060008@haw-hamburg.de> <4fd3df9ac9bc49f6a2ac571a3e6b2dcd@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <56B91887.8010908@haw-hamburg.de> Date: Mon, 8 Feb 2016 23:36:55 +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: <4fd3df9ac9bc49f6a2ac571a3e6b2dcd@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.62.61 Archived-At: Cc: P2PSIP WG 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: Mon, 08 Feb 2016 22:37:06 -0000 Hi Alissa, I'll be back with ShaRe in a few days. Best, Thomas On 08.02.2016 23:33, Alissa Cooper wrote: > Hi Thomas, > > What is the status of this? > > Thanks, > Alissa > >> On Jan 15, 2016, at 12:49 AM, Thomas C. Schmidt wrote: >> >> 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 ° -- 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 Mon Feb 8 14:52:31 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 8303F1B3457 for ; Mon, 8 Feb 2016 14:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 vNfAqTaduQda for ; Mon, 8 Feb 2016 14:52:27 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1201B3469 for ; Mon, 8 Feb 2016 14:52:27 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for p2psip@ietf.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aSufR-001ylk-SI>; Mon, 08 Feb 2016 23:52:25 +0100 Received: from x55b23e3d.dyn.telefonica.de ([85.178.62.61] helo=[192.168.178.90]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for p2psip@ietf.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1aSufR-0031TY-Fo>; Mon, 08 Feb 2016 23:52:25 +0100 From: "Thomas C. Schmidt" To: p2psip@ietf.org References: <412972789d024091baeda005b8500e47@HUB02.mailcluster.haw-hamburg.de> Message-ID: <56B91C25.2020308@haw-hamburg.de> Date: Mon, 8 Feb 2016 23:52:21 +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: <412972789d024091baeda005b8500e47@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.62.61 Archived-At: Subject: Re: [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: Mon, 08 Feb 2016 22:52:30 -0000 Yes, I'll catch up on this asap. Cheers, Thomas On 08.02.2016 23:34, Alissa Cooper wrote: > Is anyone in the WG able to respond to these comments and questions? > > Thanks, > Alissa > >> On Jan 15, 2016, at 1:58 PM, 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. In particular, I have some security concerns about using this in an overlay that allows registrations for any domain. >> >> I’ve also included some nits below that should be resolved together with last call comments. >> >> >> == Substantive comments and questions == >> >> = Section 3.2 = >> >> This section is underspecified and I’m 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’s also confusing that you only mention whether sip.schemes is required or not without mentioning whether specifying any other capabilities is required or optional. >> >> = Section 3.3 = >> >> "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? >> >> = Section 3.4 = >> >> (1) I note that this documents refers to a different version of the IEEE Posix spec than draft-ietf-p2psip-share. What’s 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 >> 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 >> 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 “enable” 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 “enable” 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". >> >> = Section 8.2.3 = >> >> 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). >> >> = Section 8.2.4 = >> >> (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? >> >> >> == Nits == >> >> = Section 1 = >> >> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery (RELOAD)/ >> >> OLD >> 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 >> 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. >> >> = Section 3.1 = >> >> "RELOAD peers MAY store two kinds of SIP mappings” >> >> I don’t think you need the normative MAY there, “can” would work. >> >> = Section 3.4 = >> >> The second line of the example here needs to use .example as the TLD, not .name. Please make the corresponding changes in the text. >> >> = Section 5.1 = >> >> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/ >> >> = Section 6 = >> >> I don't think you need the normative MAY here. >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > -- 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 Thu Feb 11 08:40:47 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 3613F1B3452; Thu, 11 Feb 2016 08:40:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160211164046.9449.65656.idtracker@ietfa.amsl.com> Date: Thu, 11 Feb 2016 08:40:46 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-concepts-08.txt 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: Thu, 11 Feb 2016 16:40:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol of the IETF. Title : Concepts and Terminology for Peer to Peer SIP Authors : David A. Bryan Philip Matthews Eunsoo Shim Dean Willis Spencer Dawkins Filename : draft-ietf-p2psip-concepts-08.txt Pages : 19 Date : 2016-02-11 Abstract: This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol and SIP usage document defined by the working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-concepts-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-concepts-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 11 08:47:52 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 89CCD1B3463 for ; Thu, 11 Feb 2016 08:47:50 -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 dwv-wpb6H3pD for ; Thu, 11 Feb 2016 08:47:48 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A940C1B2C3F for ; Thu, 11 Feb 2016 08:47:48 -0800 (PST) Received: by mail-ob0-x234.google.com with SMTP id is5so81586814obc.0 for ; Thu, 11 Feb 2016 08:47:48 -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=Y+W8RU4HdEzfkU4KIuDU+aOd65wCCVqtGvthXHLJLdY=; b=RNL7U5Sx5AM6xI7FNt0C3ecvMt8IcA39Yc+icX73CaWSr7P18yx94hjql/uHa5iqgy aYB+uXVowpR/nlPje7atP3ncn15c3xvyMP4kttE8cITwGZ+IJT6CK0Tvb0Pgu3p9m6+s WrVkhIC8uOcjkb9u6AaITHOkIr3kqIeu9yUvfimp43Bo9mbUprxxHEZjdC7+oTQn4de2 r7lZhO2ZsoYn5/VTLv1fFTRbrI8czoKOoh+BzgUR4Fd+n0aRPdSvEzjrHkoKZMe3VTl4 mNh76hQVyiOqWPyeSJr9WU6YCU6ik/WXAPkPr4PFRmz4oRwR9w216eO4aRNtMdGTwVz0 Ou7A== 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=Y+W8RU4HdEzfkU4KIuDU+aOd65wCCVqtGvthXHLJLdY=; b=bknS1Rn45CZwDrGfoHCqa+DNrmvJNmj63suAWMeg6NAoRiwom30VORXZ1sdZUAzEny kH3d4TFjFG+RdGOWp6T50dSOyS8i2FqRw59sNfqZkzB9T+e2hLODg3zH61Gd/vH9XPjA 7WO6FnAkjHrVD4bloUDiZAHiRjkaJCbe3hCBUdCixsbRDVuoBzJrwrW2OQj3SLhXjQ33 SXOUSOyUBcejg5OmpeHzkfiBvTrzWQvFO7/21D68zUlHrbK0R4EB/s4pWd5xxs83MSA6 Gw/pw1ZopGoMBM2Ax8kER8cRiRCapattSD35yh57+5WXErh9J4rJ88TR0RVb/YF8y8lR TGfg== X-Gm-Message-State: AG10YOS3eLBo96SBG6KNhtT2bPCl3oGyJxpr05+6RLZRKFBSKZfllRwQS5M29HmDlSIJ8JbuUp5v4L2A2fj6IA== MIME-Version: 1.0 X-Received: by 10.60.80.70 with SMTP id p6mr48078239oex.75.1455209267910; Thu, 11 Feb 2016 08:47:47 -0800 (PST) Received: by 10.157.15.104 with HTTP; Thu, 11 Feb 2016 08:47:47 -0800 (PST) In-Reply-To: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> Date: Thu, 11 Feb 2016 10:47:47 -0600 Message-ID: From: David Bryan To: Alissa Cooper Content-Type: multipart/alternative; boundary=089e011828a07cf6a0052b814fe6 Archived-At: Cc: p2psip 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, 11 Feb 2016 16:47:50 -0000 --089e011828a07cf6a0052b814fe6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, A new version of the draft has been submitted. Alissa, thanks for your close review, I have addressed the issues you mention (see below), and don't believe there are actually any current open issues, except possibly changing this away from the language around pre-5378 contributions. I am fine with moving it to the newer disclaimer (conforms to 5378), and will attempt to ask each author to comment on this thread that they also are fine with it using the new trust language. Other specifics inline: On Wed, Nov 25, 2015 at 4:58 PM, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF last call. There ar= e > 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. > Added, along with an IANA considerations (there are no considerations) > 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2= =80=9D These need > to be resolved. > After review, I believe these have all been resolved. They have been removed. 3) Section 1 should be deleted. > Section 1 (editors comments) has been deleted. > While you=E2=80=99re making changes, please address the following: > > 4) Fix the ID nits. > The only nits now are the pre-5378 contributions and the fact that it somehow believes one of the figures contains code comments (it doesn't). There are no other outstanding 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. > Agreed and corrected. > 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call = it a draft and > should reference the RFC. > Fixed. In addition, RFCs 7363 and 7374 have issued since the last revision. I have corrected them as well. -sip and -diagnostics are still drafts, and are still referenced (current version) as such. Again, thank you for the review and sorry for the delay in iteration. > > Thanks, > Alissa > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --089e011828a07cf6a0052b814fe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

A new version of the draft has = been submitted. Alissa, thanks for your close review, I have addressed the = issues you mention (see below), and don't believe there are actually an= y current open issues, except possibly changing this away from the language= around pre-5378 contributions. I am fine with moving it to the newer discl= aimer (conforms to 5378), and will attempt to ask each author to comment on= this thread that they also are fine with it using the new trust language. = Other specifics inline:

On Wed, Nov 25, 2015 at 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 tha= t 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.

Added, along with an IANA considerations (there are no consideration= s)
=C2=A0
2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

After re= view, I believe these have all been resolved. They have been removed.
=

3) Section 1 should be deleted.

Section= 1 (editors comments) has been deleted.
=C2=A0
While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

The only nits now a= re the pre-5378 contributions and the fact that it somehow believes one of = the figures contains code comments (it doesn't). There are no other out= standing nits.
=C2=A0
5) I think Section 3.5 should reference RFC 6762 and 6763 rather than Bonjo= ur.=C2=A0

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.

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

= Fixed. In addition, RFCs 7363 and 7374 have issued since the last revision.= I have corrected them as well. -sip and -diagnostics are still drafts, and= are still referenced (current version) as such.

A= gain, thank you for the review and sorry for the delay in iteration.
<= div>=C2=A0

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

--089e011828a07cf6a0052b814fe6-- From nobody Thu Feb 11 16:38:15 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 395D41B396C for ; Thu, 11 Feb 2016 16:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyyFswz9M-Yk for ; Thu, 11 Feb 2016 16:38:02 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 3E4F71A6F9B for ; Thu, 11 Feb 2016 16:38:01 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id xk3so99216016obc.2 for ; Thu, 11 Feb 2016 16:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wOJ4i+RCVGfTLqtroFIJRVW+lRfkFAsHp2H0RmoIRFQ=; b=NzAT409YQPy+sHMl7vWh/sl3R6mMjGjYM4DxtSeiItWVzrQKbi1lPpEPqUjHEnvK/G inDi1ywWsKdII1LpahsHLm10HMH/ADQ4YPEU9FlBxKj9xNqhz8J9tw8TErP5U+HYxAew HMsJdNiosdpwng9zyFntzN0AcnVtelRnDKUxU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wOJ4i+RCVGfTLqtroFIJRVW+lRfkFAsHp2H0RmoIRFQ=; b=RXJ2l0gvv2VCyTZw3y1dPEui+NhCNCKgdF9h0EQSuMVM+RRRZMOQ3ZQqAe0BcL6JR0 D673Qb4+PlsFx0IjB34Emc+CkvTH87pVjAa1HZgQT/FfW4IhC7RCvbBV95gq10WUOXBk gF/FmRqWaLxxSER1GNEDih384lXQxu4bkX+B1IamrMWNTaUntH+8PSznkcTu2NPoWWrh VHx0GG7o46lFvQfckQZwG3XjuC9vNx9qeo1CFy9VfWVJctQ6jNiwMPXxn3u6al9GtlwS BQ1uEi7Sr8kbgEHCxMwJgw+Vas2ybEgh1U56JJzvFm9DpgPZ4ldvLvXAoC/xX2IURu2Z 878g== X-Gm-Message-State: AG10YORAr6fwIzaVluFIWaujHOZOSfAKES0R7exCuGMuSYp52JckUi+tv1Q3T06ZkQvPcA== X-Received: by 10.60.162.102 with SMTP id xz6mr38014316oeb.62.1455237481219; Thu, 11 Feb 2016 16:38:01 -0800 (PST) Received: from [192.168.1.129] ([216.243.244.98]) by smtp.gmail.com with ESMTPSA id q10sm7188062obg.1.2016.02.11.16.37.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Feb 2016 16:38:00 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D8CE48F-A01C-43EA-A61A-A5BD3BBCDF9E" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Willis In-Reply-To: Date: Thu, 11 Feb 2016 18:36:59 -0600 Message-Id: References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> To: David Bryan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: p2psip 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: Fri, 12 Feb 2016 00:38:12 -0000 --Apple-Mail=_0D8CE48F-A01C-43EA-A61A-A5BD3BBCDF9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed on all counts. > On Feb 11, 2016, at 10:47, David Bryan wrote: >=20 > Hi all, >=20 > A new version of the draft has been submitted. Alissa, thanks for your = close review, I have addressed the issues you mention (see below), and = don't believe there are actually any current open issues, except = possibly changing this away from the language around pre-5378 = contributions. I am fine with moving it to the newer disclaimer = (conforms to 5378), and will attempt to ask each author to comment on = this thread that they also are fine with it using the new trust = language. Other specifics inline: >=20 > On Wed, Nov 25, 2015 at 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 > Added, along with an IANA considerations (there are no considerations) > =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 > After review, I believe these have all been resolved. They have been = removed. >=20 > 3) Section 1 should be deleted. >=20 > Section 1 (editors comments) has been deleted. > =20 > While you=E2=80=99re making changes, please address the following: >=20 > 4) Fix the ID nits. >=20 > The only nits now are the pre-5378 contributions and the fact that it = somehow believes one of the figures contains code comments (it doesn't). = There are no other outstanding nits. > =20 > 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour.=20 >=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 > Agreed and corrected. > =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 > Fixed. In addition, RFCs 7363 and 7374 have issued since the last = revision. I have corrected them as well. -sip and -diagnostics are still = drafts, and are still referenced (current version) as such. >=20 > Again, thank you for the review and sorry for the delay in iteration. > =20 >=20 > Thanks, > Alissa > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip = >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail=_0D8CE48F-A01C-43EA-A61A-A5BD3BBCDF9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed on all counts.

On = Feb 11, 2016, at 10:47, David Bryan <dbryan@ethernot.org>= wrote:

Hi all,

A new version of the draft has been submitted. Alissa, thanks = for your close review, I have addressed the issues you mention (see = below), and don't believe there are actually any current open issues, = except possibly changing this away from the language around pre-5378 = contributions. I am fine with moving it to the newer disclaimer = (conforms to 5378), and will attempt to ask each author to comment on = this thread that they also are fine with it using the new trust = language. Other specifics inline:

On Wed, Nov 25, 2015 at 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.

Added, along with an IANA considerations (there are no = considerations)
 
2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

After review, I believe = these have all been resolved. They have been removed.

3) Section 1 should be deleted.

Section 1 (editors = comments) has been deleted.
 
While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

The only nits now are the pre-5378 = contributions and the fact that it somehow believes one of the figures = contains code comments (it doesn't). There are no other outstanding = 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.

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

Fixed. In addition, RFCs = 7363 and 7374 have issued since the last revision. I have corrected them = as well. -sip and -diagnostics are still drafts, and are still = referenced (current version) as such.

Again, thank you for the review and = sorry for the delay in iteration.
 

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

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

= --Apple-Mail=_0D8CE48F-A01C-43EA-A61A-A5BD3BBCDF9E-- From nobody Fri Feb 12 22:22:15 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 2EA331B2D19 for ; Fri, 12 Feb 2016 22:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZg5aO7zr_E5 for ; Fri, 12 Feb 2016 22:22:14 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080FA1B2D1A for ; Fri, 12 Feb 2016 22:22:14 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id g203so87063820iof.2 for ; Fri, 12 Feb 2016 22:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=R2Nk1zv5K/FP2B9Es8kKIkIFQ8aJ/LFoS4Vz8p5y8vA=; b=Daryw+/TpXEBDcjUNjhmhpL2DKyl68F+SYcqAbSeeaj0GKJkn3YCnvwZ/e8VdpN6dX MbmI5rZ5HFbrumJEacmuC5LAAbS6AFa3EN6Y4DLJvhA8RkBLLV4kr9l7L1mfBNsTxnhu RBS70ECPzXpBZbl/8SQjzmtgtokETgOiEPK7fiIYunHUROk8XCW+/MV3+DNSIobubS4w 0tJ+poe3AiWWGGDS4tnJtQUTAHIKyvhXZ4BZSur5NXK2wd0lqGeS6wLaN+hsE3Mz0W2u AXpzmSf1EiwZTHOYUWsf2WeVsQ7DEfYQlrtQAMsPoOPBs7OpplqFsTVOPxCpyZuDz3Hw TXpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=R2Nk1zv5K/FP2B9Es8kKIkIFQ8aJ/LFoS4Vz8p5y8vA=; b=Tm1PWdipW7cg1DuRtLOkMheQEnMbLjJZZddx1ZSJBnSqrTL7pqCiM0JHKOuispIipP PflDa7aoLOp3E7sRYRbzQhhg7ii1WdFpIrUh6SdvEoZzINEQkGeD4vJXRwFNsa9MbcDP 9gqUsueSpJTSWRknluqTI7EWhX9gni6K1F6tvhoSXW5Fn/OrNFDM2VPnudS+ScNpXcd2 2eL7oA9r0ypw09WGL/pwg3lVzZIz/NMuxiJ0Az0CYrWateneXFIzoZ3Wu+j+Hofj3Z8I uBd2crFV1DAJ3V/tWTGKtn2+kDID8xTalnPXuBKZSYPH4qIemnZLRPwBx8Ve5MzRYvxs ltlw== X-Gm-Message-State: AG10YORRMPcd7tyWOFm8GtLvXwU1PTEq4hG7XfFMnT2NnwPK1npmXicbjjOmuUYgKXOUbiWw2QRMX86N9K4xDA== MIME-Version: 1.0 X-Received: by 10.107.135.20 with SMTP id j20mr7954902iod.56.1455344533367; Fri, 12 Feb 2016 22:22:13 -0800 (PST) Received: by 10.107.157.17 with HTTP; Fri, 12 Feb 2016 22:22:13 -0800 (PST) Received: by 10.107.157.17 with HTTP; Fri, 12 Feb 2016 22:22:13 -0800 (PST) Date: Sat, 13 Feb 2016 15:22:13 +0900 Message-ID: From: Eunsoo Shim To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=001a113f8e7af019d5052ba0cd28 Archived-At: Cc: Spencer Dawkins at IETF , Dean Willis Subject: Re: [P2PSIP] AD evaluation: draft-ietf-sip-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: Sat, 13 Feb 2016 06:22:15 -0000 --001a113f8e7af019d5052ba0cd28 Content-Type: text/plain; charset=UTF-8 I agree with David's proposals and consent to the changes of terms. Regards, Eunsoo --001a113f8e7af019d5052ba0cd28 Content-Type: text/html; charset=UTF-8

I agree with David's proposals and consent to the changes of terms.

Regards,

Eunsoo

--001a113f8e7af019d5052ba0cd28-- From nobody Thu Feb 18 14:50:10 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 D40B01B3640 for ; Thu, 18 Feb 2016 14:50:09 -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 I30ITrhyhevP for ; Thu, 18 Feb 2016 14:50:05 -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 38FFF1B3612 for ; Thu, 18 Feb 2016 14:50:05 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A1F4720C4B for ; Thu, 18 Feb 2016 17:50:02 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 18 Feb 2016 17:50:02 -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=aPvWz SB+8nMRlB373akLQ0s2HTU=; b=D2L7WHQccfpL3Z2n8HXEstt5Y9VmXj9eTGCee iMOUDmzmOSG00B5eh1Y4dy7lMl2JNNYr+ZHMiR3YlLlb7F/IPRAYxBsI/GAXvPiw HgzkugEbIzSSIyMNKP2LWNgPS0Pv9GEo32P8jNzlEGEwq2+eHFhA+4eTrUzhfn56 JNsXYk= 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=aPvWzSB+8nMRlB373akLQ0s2HTU=; b=pJ3mV CVA9Mj0cejBj+E9FdCzk9xmbc+J2wML5Mg8dL3QuCu3uT/zkfkM8EUNwFcA7TpVm ivUzVvuIW2bPhJ7OeVwP1bssZlrKPkQfCMgJ3f0ADXui//vU8Lry+G86e3iAJM2A GXRVbHCBf1veziogfmF5xhwn7FADqWXMxVPV94= X-Sasl-enc: MWhs/WTyFcG22foSzWNKOBf93gDP1Xv2IVaZtvMVaAZv 1455835802 Received: from dhcp-171-68-20-91.cisco.com (dhcp-171-68-20-91.cisco.com [171.68.20.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 1246FC0001E; Thu, 18 Feb 2016 17:50:01 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A1AB20A2-0368-421F-A29F-A4B9B5D9762B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Thu, 18 Feb 2016 14:50:01 -0800 Message-Id: <4E9F7F5E-3A23-4EE3-BFFC-A3C5301781FA@cooperw.in> References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> To: David Bryan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: p2psip 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, 18 Feb 2016 22:50:10 -0000 --Apple-Mail=_A1AB20A2-0368-421F-A29F-A4B9B5D9762B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 David, The changes look good to me, thanks. I can request IETF LC while we wait = for Spencer and Philip to respond about pre-5378, if you=E2=80=99d like, = or I can wait. Let me know your preference. Alissa > On Feb 11, 2016, at 8:47 AM, David Bryan wrote: >=20 > Hi all, >=20 > A new version of the draft has been submitted. Alissa, thanks for your = close review, I have addressed the issues you mention (see below), and = don't believe there are actually any current open issues, except = possibly changing this away from the language around pre-5378 = contributions. I am fine with moving it to the newer disclaimer = (conforms to 5378), and will attempt to ask each author to comment on = this thread that they also are fine with it using the new trust = language. Other specifics inline: >=20 > On Wed, Nov 25, 2015 at 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 > Added, along with an IANA considerations (there are no considerations) > =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 > After review, I believe these have all been resolved. They have been = removed. >=20 > 3) Section 1 should be deleted. >=20 > Section 1 (editors comments) has been deleted. > =20 > While you=E2=80=99re making changes, please address the following: >=20 > 4) Fix the ID nits. >=20 > The only nits now are the pre-5378 contributions and the fact that it = somehow believes one of the figures contains code comments (it doesn't). = There are no other outstanding nits. > =20 > 5) I think Section 3.5 should reference RFC 6762 and 6763 rather than = Bonjour.=20 >=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 > Agreed and corrected. > =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 > Fixed. In addition, RFCs 7363 and 7374 have issued since the last = revision. I have corrected them as well. -sip and -diagnostics are still = drafts, and are still referenced (current version) as such. >=20 > Again, thank you for the review and sorry for the delay in iteration. > =20 >=20 > Thanks, > Alissa > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip = >=20 --Apple-Mail=_A1AB20A2-0368-421F-A29F-A4B9B5D9762B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
David,

The changes look good to me, thanks. I = can request IETF LC while we wait for Spencer and Philip to respond = about pre-5378, if you=E2=80=99d like, or I can wait. Let me know your = preference.

Alissa

On Feb 11, 2016, at 8:47 AM, David Bryan = <dbryan@ethernot.org> wrote:

Hi all,

A = new version of the draft has been submitted. Alissa, thanks for your = close review, I have addressed the issues you mention (see below), and = don't believe there are actually any current open issues, except = possibly changing this away from the language around pre-5378 = contributions. I am fine with moving it to the newer disclaimer = (conforms to 5378), and will attempt to ask each author to comment on = this thread that they also are fine with it using the new trust = language. Other specifics inline:

On Wed, Nov 25, 2015 at 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.

Added, along with an IANA considerations (there are no = considerations)
 
2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

After review, I believe = these have all been resolved. They have been removed.

3) Section 1 should be deleted.

Section 1 (editors = comments) has been deleted.
 
While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

The only nits now are the pre-5378 = contributions and the fact that it somehow believes one of the figures = contains code comments (it doesn't). There are no other outstanding = 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.

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

Fixed. In addition, RFCs = 7363 and 7374 have issued since the last revision. I have corrected them = as well. -sip and -diagnostics are still drafts, and are still = referenced (current version) as such.

Again, thank you for the review and = sorry for the delay in iteration.
 

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


= --Apple-Mail=_A1AB20A2-0368-421F-A29F-A4B9B5D9762B-- From nobody Thu Feb 18 15:41:41 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 2140E1A8AA1 for ; Thu, 18 Feb 2016 15:41:39 -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 wkCyJY7aHJDJ for ; Thu, 18 Feb 2016 15:41:37 -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 136D51A888F for ; Thu, 18 Feb 2016 15:41:37 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 00658219D0 for ; Thu, 18 Feb 2016 18:40:10 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 18 Feb 2016 18:40:10 -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=qPT2xiPV7uCBrH3VbMfK55S6afQ=; b=r2EVZO 8Tw14PSJuonKwFrOUa2Xo3WI8Q23RFYGWDQn7NktYhV/N73R6CjsHVvIb2BppRYJ 2FK9ThO5kRfYbFTonmm99bcAPhnQ+4awZVpOxP4KxVXvh0YAkLI6OwP1+gQovoDf EBzSz5QqzOVs4oH7ZpTsxEWsllV8vclZfZJPI= 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=qPT2xiPV7uCBrH3 VbMfK55S6afQ=; b=goZKx+Kjmc0qZeFTS3OafNnWSXi6Kk7NnQalXcVsEikjjz3 nLjPBxNpZLjyAXl3axbJDnQwblluJa7ERDLT7HwEK4OrX5jQ0FOU6FbgXIXd14XP vnUwY/fGSyaZiinY3ZfPC1UNmlkH7KZTzdxUqPv/ESmGVFn0WdQAgvO0SNKw= X-Sasl-enc: rKcE+x/3EW1SJG+Pvpykc+L4HRDuozlILeEAysUd5wl1 1455838810 Received: from dhcp-171-68-20-91.cisco.com (dhcp-171-68-20-91.cisco.com [171.68.20.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ABDFC00012; Thu, 18 Feb 2016 18:40:09 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <56B91C25.2020308@haw-hamburg.de> Date: Thu, 18 Feb 2016 15:40:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <412972789d024091baeda005b8500e47@HUB02.mailcluster.haw-hamburg.de> <56B91C25.2020308@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: p2psip@ietf.org Subject: Re: [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: Thu, 18 Feb 2016 23:41:39 -0000 Hi Thomas, Checking in on this and the -share doc. When do you expect to respond? Thanks, Alissa > On Feb 8, 2016, at 2:52 PM, Thomas C. Schmidt = wrote: >=20 > Yes, I'll catch up on this asap. >=20 > Cheers, > Thomas >=20 > On 08.02.2016 23:34, Alissa Cooper wrote: >> Is anyone in the WG able to respond to these comments and questions? >>=20 >> Thanks, >> Alissa >>=20 >>> On Jan 15, 2016, at 1:58 PM, Alissa Cooper = wrote: >>>=20 >>> 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. >>>=20 >>> I=92ve also included some nits below that should be resolved = together with last call comments. >>>=20 >>>=20 >>> =3D=3D Substantive comments and questions =3D=3D >>>=20 >>> =3D Section 3.2 =3D >>>=20 >>> This section is underspecified and I=92m 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). >>>=20 >>> It=92s also confusing that you only mention whether sip.schemes is = required or not without mentioning whether specifying any other = capabilities is required or optional. >>>=20 >>> =3D Section 3.3 =3D >>>=20 >>> "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)." >>>=20 >>> Why is this SHOULD rather than MUST? >>>=20 >>> =3D Section 3.4 =3D >>>=20 >>> (1) I note that this documents refers to a different version of the = IEEE Posix spec than draft-ietf-p2psip-share. What=92s the reason for = the difference? >>>=20 >>> (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. >>>=20 >>> OLD >>> 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. >>>=20 >>> Example of Domain Patterns: dht\.example\.com .*\.my\.name >>>=20 >>> 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]. >>>=20 >>> 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]). >>>=20 >>> NEW >>> 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]. >>>=20 >>> 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 =93enable=94 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 =93enable=94 attribute is set to true, the overlay MUST only = accept AORs that match patterns specified in the = element. >>>=20 >>> Example of Domain Patterns: dht\.example\.com .*\.my\.name >>>=20 >>> In this example, any AOR will be accepted that is either of the form = @dht.example.com, or ends with the domain "my.name". >>>=20 >>> =3D Section 8.2.3 =3D >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> =3D Section 8.2.4 =3D >>>=20 >>> (1) >>> By "public" you mean "visible to all nodes in the overlay," correct? >>>=20 >>> (2) >>> "Methods of providing >>> location and identity privacy are still being studied." >>>=20 >>> Is this true, specifically for P2PSIP? >>>=20 >>>=20 >>> =3D=3D Nits =3D=3D >>>=20 >>> =3D Section 1 =3D >>>=20 >>> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And = Discovery (RELOAD)/ >>>=20 >>> OLD >>> 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. >>>=20 >>> NEW >>> 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. >>>=20 >>> =3D Section 3.1 =3D >>>=20 >>> "RELOAD peers MAY store two kinds of SIP mappings=94 >>>=20 >>> I don=92t think you need the normative MAY there, =93can=94 would = work. >>>=20 >>> =3D Section 3.4 =3D >>>=20 >>> The second line of the example here needs to use .example as the = TLD, not .name. Please make the corresponding changes in the text. >>>=20 >>> =3D Section 5.1 =3D >>>=20 >>> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/ >>>=20 >>> =3D Section 6 =3D >>>=20 >>> I don't think you need the normative MAY here. >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Thu Feb 18 15:54:53 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 405C71B383F for ; Thu, 18 Feb 2016 15:54:51 -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 EtJJeSA9jsLx for ; Thu, 18 Feb 2016 15:54:49 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468171B383C for ; Thu, 18 Feb 2016 15:54:49 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id xk3so93804441obc.2 for ; Thu, 18 Feb 2016 15:54:49 -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=PySdPS20HNUSZ9xK24u03j+zUHkpzPgJDN5LVFt0Wrk=; b=mcfsVN7jvF91BWOhZw6jT6wvCS1cn6/zGXmfOhVNI2zMTDbSTRY1pNN7fm3ZNxkL1B upz8HzokTIxEE/GpxcMDG0QGg92Kg4/26frlSaiHINnrRtGFftxgUNr0Kk8UdG52JDXJ cEjyw2qdMi9q6aY02EKOryuPg5DkQS6+e/s+z3DpzzCaGeDYnAl9YHlpub+tyP6H6bqw lFNwoeclr5iEfcjqTZ3BCiIPhVG4ZKSWSG3blYo/kRQlB7yVRBi9yi5OPXP9n6L90stq /BqX5KyZRAZNuUxU9RAqDQFFdzPyt9SXyn5onr09SQc/Ch0Y/PI7F+Nln+Hq+FXvpQHI QGyQ== 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=PySdPS20HNUSZ9xK24u03j+zUHkpzPgJDN5LVFt0Wrk=; b=mGVAjN5j0Dsw9+xF+E7C5cHvBSoS6gPswtmdoQkzsFKZ6/ucuid1VajaNF8N/LdPIM P/TE5NB6i81HesaXPvaYJgWT7ao//z76CEqiRrC+nwz/oFHxgI4e+b6djT/M+9GpmuxJ vwmv058ffs/Yjs8jYiYo7h1CYSF2EiGz61QLfDq45o11QlwsgVN5oiYEDlK1PE5tJQ9W zhGspDWVGbpLMOzzyTZA5P37/tUEl7johod5cz/c2eE4rvBiShyUGRdBLja9NsY5NRgp waWfZpH4VAPHiJNJ24+KRG4T58SLLe0sa1cYt2TiWs1GFD7hlW/AJHRMyZvUVfcHO+31 YHiQ== X-Gm-Message-State: AG10YOSqGQWEvkvq2HtVyL6R22swHjRTOgszH2HfcBIIdh6i7qDF4/594dBpzhT/RQj5PCpd9QPcHbxnwlrzWQ== MIME-Version: 1.0 X-Received: by 10.60.67.34 with SMTP id k2mr8959378oet.67.1455839688652; Thu, 18 Feb 2016 15:54:48 -0800 (PST) Received: by 10.157.15.104 with HTTP; Thu, 18 Feb 2016 15:54:48 -0800 (PST) Received: by 10.157.15.104 with HTTP; Thu, 18 Feb 2016 15:54:48 -0800 (PST) In-Reply-To: <4E9F7F5E-3A23-4EE3-BFFC-A3C5301781FA@cooperw.in> References: <338712AE-3E19-4AEF-B40C-AE4C3A5B7F5A@cooperw.in> <4E9F7F5E-3A23-4EE3-BFFC-A3C5301781FA@cooperw.in> Date: Thu, 18 Feb 2016 17:54:48 -0600 Message-ID: From: David Bryan To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11c2e2987e118f052c141758 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, 18 Feb 2016 23:54:51 -0000 --001a11c2e2987e118f052c141758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Spencer actually responded to me directly (he's no longer on the list directly) - I will forward the response and continue to try to reach Phillip. I'm fine with moving to LC while I try to reach Phillip. Thank you very much, On Feb 18, 2016 4:50 PM, "Alissa Cooper" wrote: > David, > > The changes look good to me, thanks. I can request IETF LC while we wait > for Spencer and Philip to respond about pre-5378, if you=E2=80=99d like, = or I can > wait. Let me know your preference. > > Alissa > > On Feb 11, 2016, at 8:47 AM, David Bryan wrote: > > Hi all, > > A new version of the draft has been submitted. Alissa, thanks for your > close review, I have addressed the issues you mention (see below), and > don't believe there are actually any current open issues, except possibly > changing this away from the language around pre-5378 contributions. I am > fine with moving it to the newer disclaimer (conforms to 5378), and will > attempt to ask each author to comment on this thread that they also are > fine with it using the new trust language. Other specifics inline: > > On Wed, Nov 25, 2015 at 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. >> > > Added, along with an IANA considerations (there are no considerations) > > >> 2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2= =80=9D These need >> to be resolved. >> > > After review, I believe these have all been resolved. They have been > removed. > > 3) Section 1 should be deleted. >> > > Section 1 (editors comments) has been deleted. > > >> While you=E2=80=99re making changes, please address the following: >> >> 4) Fix the ID nits. >> > > The only nits now are the pre-5378 contributions and the fact that it > somehow believes one of the figures contains code comments (it doesn't). > There are no other outstanding 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. >> > > Agreed and corrected. > > >> 7) References to =E2=80=9Cthe RELOAD base draft=E2=80=9D should not call= it a draft and >> should reference the RFC. >> > > Fixed. In addition, RFCs 7363 and 7374 have issued since the last > revision. I have corrected them as well. -sip and -diagnostics are still > drafts, and are still referenced (current version) as such. > > Again, thank you for the review and sorry for the delay in iteration. > > >> >> Thanks, >> Alissa >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > > > --001a11c2e2987e118f052c141758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Spencer actually responded to me directly (he's no longe= r on the list directly) - I will forward the response and continue to try t= o reach Phillip.

I'm fine with moving to LC while I try to reach Phillip.=

Thank you very much,

On Feb 18, 2016 4:50 PM, "Alissa Cooper&quo= t; <alissa@cooperw.in> wrote= :
David,

The changes look goo= d to me, thanks. I can request IETF LC while we wait for Spencer and Philip= to respond about pre-5378, if you=E2=80=99d like, or I can wait. Let me kn= ow your preference.

Alissa

On Feb 11, 2016, at 8:47 AM, David Bryan <dbryan@ethernot.org&g= t; wrote:

Hi all,

A new v= ersion of the draft has been submitted. Alissa, thanks for your close revie= w, I have addressed the issues you mention (see below), and don't belie= ve there are actually any current open issues, except possibly changing thi= s away from the language around pre-5378 contributions. I am fine with movi= ng it to the newer disclaimer (conforms to 5378), and will attempt to ask e= ach author to comment on this thread that they also are fine with it using = the new trust language. Other specifics inline:

On Wed, Nov 25, 2015 at 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 las= t-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.

Added, along with an IANA considerations (there are no consideration= s)
=C2=A0
2) Section 3.5 and Section 7 have text marked as =E2=80=9COPEN ISSUE.=E2=80= =9D These need to be resolved.

After re= view, I believe these have all been resolved. They have been removed.
=

3) Section 1 should be deleted.

Section= 1 (editors comments) has been deleted.
=C2=A0
While you=E2=80=99re making changes, please address the following:

4) Fix the ID nits.

The only nits now a= re the pre-5378 contributions and the fact that it somehow believes one of = the figures contains code comments (it doesn't). There are no other out= standing nits.
=C2=A0
5) I think Section 3.5 should reference RFC 6762 and 6763 rather than Bonjo= ur.=C2=A0

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.

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

= Fixed. In addition, RFCs 7363 and 7374 have issued since the last revision.= I have corrected them as well. -sip and -diagnostics are still drafts, and= are still referenced (current version) as such.

A= gain, thank you for the review and sorry for the delay in iteration.
<= div>=C2=A0

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


--001a11c2e2987e118f052c141758-- From nobody Fri Feb 19 11:47:38 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 DDC4C1B32F5; Fri, 19 Feb 2016 11:47:34 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160219194734.14022.63508.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 11:47:34 -0800 Archived-At: Cc: alcoop@cisco.com, draft-ietf-p2psip-concepts@ietf.org, p2psip@ietf.org, p2psip-chairs@ietf.org Subject: [P2PSIP] Last Call: (Concepts and Terminology for Peer to Peer SIP) to Informational RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 19 Feb 2016 19:47:35 -0000 The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'Concepts and Terminology for Peer to Peer SIP' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol and SIP usage document defined by the working group. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 18:46:17 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 6929D1A00DB; Wed, 24 Feb 2016 18:46:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160225024613.15590.16615.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 18:46:13 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-20.txt 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: Thu, 25 Feb 2016 02:46:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-20.txt Pages : 31 Date : 2016-02-24 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 24 19:10:41 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 C12161B2ECA; Wed, 24 Feb 2016 19:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 9kx4d-NGdFn0; Wed, 24 Feb 2016 19:10:33 -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 09C331B2EC1; Wed, 24 Feb 2016 19:10:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJD04337; Thu, 25 Feb 2016 03:10:28 +0000 (GMT) Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 03:10:27 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 03:10:26 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 11:10:19 +0800 From: "Songhaibin (A)" To: Alissa Cooper , Barry Leiba Thread-Topic: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) Thread-Index: AQHRN7jZcW5g6EknVEW+vQa5IqGiDp7jRewwgC3qCQCAAAWVAIABZu+AgCniSUA= Date: Thu, 25 Feb 2016 03:10:19 +0000 Message-ID: References: <20151216041827.16193.95293.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="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.0A0B0205.56CE70A4.0129, 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: 27ef7e6dff8ec0cfd0f8b69d31f84b64 Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-diagnostics@ietf.org" , IESG , "p2psip@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, 25 Feb 2016 03:10:37 -0000 RGVhciBBbGlzc2EgYW5kIGFsbCwNCg0KSSBkaWQgdGhlIGVkaXRpbmcgam9iIGFuZCBoYXZlIHN1 Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBhY2NvcmRpbmcgdG8gdGhlIGNv bW1lbnRzIHJlY2VpdmVkIGFuZCB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgbGlzdC4gSSBhbHNvIGFk ZCBzb21lIHRleHQgaW4gdGhlIGNoYW5nZSBoaXN0b3J5IGFwcGVuZGl4IGZvciBpdC4gUGxlYXNl IGNoZWNrIGlmIHRoZSB1cGRhdGVkIHZlcnNpb24gaGFzIGFkZHJlc3NlZCB5b3VyIGNvbW1lbnRz Lg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25v c3RpY3MtMjANCg0KSSBrZWVwIHRoZSBpbnRlbmRlZCBzdGF0dXMgb2YgdGhlIGRvY3VtZW50IGFz IGl0IGlzLiBBbHZhcm8gdGhvdWdodCBFeHBlcmltZW50YWwgbWlnaHQgYmUgYSBiZXR0ZXIgc3Rh dHVzLCB3aGVuIEkgY2hlY2sgdGhlIGNoYW5nZSBoaXN0b3J5IGluIHRoZSBkb2N1bWVudCwgYXMg aXQgaXMgZGVmaW5lZCBhcyBhIG1hbmRhdG9yeSBSRUxPQUQgZXh0ZW5zaW9uLCB0aGUgY3VycmVu dCBpbnRlbmRlZCBzdGF0dXMgc2VlbXMgc3VpdGFibGUuIE90aGVyd2lzZSB3ZSBuZWVkIGdvIHRo cm91Z2ggYW5vdGhlciBXR0xDIHRvIGNoYW5nZSB0aGUgaW50ZW5kZWQgc3RhdHVzLg0KDQoiQy43 LiAgQ2hhbmdlcyBpbiB2ZXJzaW9uIC0xMA0KDQogICBSZXNvbHZlIHRoZSBhdXRob3JpemF0aW9u IGlzc3VlIGFuZCBvdGhlciBjb21tZW50cyAoZS5nLiBkZWZpbmUNCiAgIGRpYWdub3N0aWNzIGFz IGEgbWFuZGF0b3J5IGV4dGVuc2lvbikgZnJvbSBXR0xDLiAgQW5kIGNoZWNrIGZvciB0aGUNCiAg IGxhbmd1YWdlcy4NCiINCkJlc3QgUmVnYXJkcyENCi1IYWliaW4NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNvb3Bl cncuaW5dDQo+IFNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDMwLCAyMDE2IDM6MTMgQU0NCj4gVG86 IEJhcnJ5IExlaWJhDQo+IENjOiBJRVNHOyBSb25pIEV2ZW47IHAycHNpcC1jaGFpcnNAaWV0Zi5v cmc7DQo+IGRyYWZ0LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzQGlldGYub3JnOyBwMnBzaXBAaWV0 Zi5vcmc7IFNvbmdoYWliaW4gKEEpDQo+IFN1YmplY3Q6IFJlOiBbUDJQU0lQXSBCYXJyeSBMZWli YSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTk6DQo+ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBJIGxvb2tlZCB0aHJvdWdoIHRoZSBtYWlsaW5n IGxpc3QgYXJjaGl2ZXMgYW5kIHRoZSBtZWV0aW5nIG1pbnV0ZXMgZnJvbSB0aGUNCj4gbWVldGlu Z3MgYXJvdW5kIHRoZSB0aW1lIHdoZW4gdGhlIHJlZ2lzdHJhdGlvbiBwb2xpY3kgd2FzIGFkZGVk IHRvIHRoZQ0KPiBkb2N1bWVudCAodGhlIC0wMSkuIEkgZGlkIG5vdCBzZWUgYW55IGRpc2N1c3Np b24gb2YgdGhlIHJlZ2lzdHJhdGlvbiBwb2xpY3kuDQo+IA0KPiBJIGZ1bGx5IGFncmVlIHdpdGgg SGFpYmlu4oCZcyBhbmFseXNpcywgdGhvdWdoLCB3aGljaCBpcyB0aGF0IHRoZSBwb3RlbnRpYWwg Zm9yDQo+IGludHJvZHVjaW5nIHNlbnNpdGl2ZSBkaWFnbm9zdGljIHR5cGVzIChlLmcuLCBsb2Nh dGlvbikgaXMgc3VmZmljaWVudCB0byBtYWtlDQo+IFN0YW5kYXJkcyBBY3Rpb24gb3IgSUVURiBS ZXZpZXcgYSBnb29kIGNob2ljZS4gVGhlc2Ugc2hvdWxkIGdldCBJRVRGLXdpZGUNCj4gc2VjdXJp dHkgcmV2aWV3IGJlZm9yZSBiZWluZyBhZGRlZCB0byB0aGUgcmVnaXN0cmllcy4NCj4gDQo+IEFs aXNzYQ0KPiANCj4gPiBPbiBKYW4gMjgsIDIwMTYsIGF0IDE6NDcgUE0sIEJhcnJ5IExlaWJhIDxi YXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gd3JvdGU6DQo+ID4NCj4gPj4gRG9lcyBIYWliaW7igJlz IGFuc3dlciBjbGVhciB1cCB5b3VyIGNvbmNlcm4/DQo+ID4NCj4gPiBTb3JyeSwgaXQgbXVzdCBo YXZlIGdvdHRlbiBsb3N0IGluIHRoZSBlbmQtb2YteWVhciBtZXNzLg0KPiA+DQo+ID4gTm8sIGl0 IGRvZXNuJ3Q6IEhhaWJpbiBnaXZlcyBoaXMgdGhvdWdodHMgb24gdGhlIHF1ZXN0aW9uLCBidXQg SSBhc2tlZA0KPiA+IGFib3V0IHdoYXQgZGlzY3Vzc2lvbiB0aGUgd29ya2luZyBncm91cCBoYWQg aW4gY29taW5nIHRvIHRoZSBkZWNpc2lvbi4NCj4gPiBGdXJ0aGVyIGNvbW1lbnQ6DQo+ID4NCj4g Pj4+IEZvciBTZWN0aW9ucyA5LjEgYW5kIDkuMiwgSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGV2 aWRlbmNlIG9mDQo+ID4+PiBkaXNjdXNzaW9uIHRoYXQgcmVzdWx0ZWQgaW4gdGhlIGRlY2lzaW9u IHRvIG1ha2UgdGhlIHJlZ2lzdHJ5DQo+ID4+PiBwb2xpY2llcyBTdGFuZGFyZHMgQWN0aW9uLiAg RGlkIHRoZSB3b3JraW5nIGdyb3VwIGFjdHVhbGx5IGRpc2N1c3MNCj4gPj4+IHRoaXMgYW5kIG1h a2UgYSBkZWNpc2lvbiB0aGF0IFN0YW5kYXJkcyBBY3Rpb24gaXMgcmlnaHQ/ICBXaGF0J3MgdGhl DQo+ID4+PiByZWFzb25pbmcgZm9yIG5vdCB1c2luZyBzb21lIHNvZnRlciBwb2xpY3ksIHN1Y2gg YXMgIklFVEYgUmV2aWV3Ig0KPiA+Pj4gKHdoaWNoIG1pZ2h0IGFsbG93IGZvciByZWdpc3RyYXRp b25zIGZyb20gRXhwZXJpbWVudGFsDQo+ID4+PiBkb2N1bWVudHMpIG9yIFNwZWNpZmljYXRpb24g UmVxdWlyZWQgKHdoaWNoIHdvdWxkIGFsbG93IHJldmlldyBieSBhDQo+ID4+PiBkZXNpZ25hdGVk IGV4cGVydCBvZiBhIG5vbi1SRkMgc3BlY2lmaWNhdGlvbik/ICBXaHkgaXMgU3RhbmRhcmRzDQo+ ID4+PiBBY3Rpb24gdGhlIHJpZ2h0IHRoaW5nPw0KPiA+Pj4NCj4gPj4gVGhlIHRob3VnaHQgd2Fz IHRoYXQgaWYgYSBuZXcgdmFsdWUgd291bGQgYmUgdXNlZCBmb3IgZXhwZXJpbWVudGFsDQo+ID4+ IHB1cnBvc2UsIHRoZW4gdGhlcmUgYXJlIHJlc2VydmVkIHZhbHVlcyBhY2NvcmRpbmdseSBmb3Ig b3ZlcmxheSBsb2NhbA0KPiA+PiB1c2UgKDB4RjAwMC0weEZGRkUpLiBBbmQgdGhlbiBpZiBwZW9w bGUgd2FudCB0aGF0IHZhbHVlIGNhbiBiZSB1c2VkDQo+ID4+IGFjcm9zcyBkaWZmZXJlbnQgUkVM T0FEIG92ZXJsYXlzLCB0aGVuIHRoZXknZCBiZXR0ZXIgbmVlZCBhIHN0YW5kYXJkDQo+ID4+IHRy YWNrIGRvY3VtZW50IHRvIGRlZmluZSBpdCAodGhhdCdzIHdoeSB3ZSBhc3N1bWUgaXQgd291bGQg YmUNCj4gPj4gc3RhbmRhcmQgdHJhY2spLiAiU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIgYWxsb3dz IG5vbi1SRkMNCj4gPj4gc3BlY2lmaWNhdGlvbnMsIG5vdCBzdXJlIHRoYXQgd291bGQgcmVmbGVj dCB0aGUgSUVURiBjb25zZW5zdXMNCj4gPj4gKGNlcnRhaW4gY29uY2VybnMgbWlnaHQgZXhpc3Qg YWJvdXQgY2VydGFpbiBraW5kcyBvZiBkaWFnbm9zdGljIGluZm9ybWF0aW9uKS4NCj4gPg0KPiA+ IFllcywgIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIGFsbG93cyBub24tUkZDIHNwZWNpZmljYXRp b25zLCB3aXRoIGENCj4gPiBkZXNpZ25hdGVkIGV4cGVydCB0byByZXZpZXcgdGhlIHJlcXVlc3Qg YW5kIHNhbml0eS1jaGVjayBpdC4gIFdoeSBkb2VzDQo+ID4gdGhlIHdvcmtpbmcgZ3JvdXAgdGhp bmsgdGhpcyByZWdpc3RyeSBuZWVkcyBvbmx5IFN0YW5kYXJkcyBUcmFjayBSRkNzDQo+ID4gdG8g bWFrZSByZWdpc3RyYXRpb25zPyAgV2h5IGNhbid0IElFVEYgY29uc2Vuc3VzIGFwcHJvdmUgYQ0K PiA+IG5vbi1TdGFuZGFyZHMtVHJhY2sgUkZDIChhcyB3aXRoICJJRVRGIFJldmlldyIpPyAgV2h5 IGNvdWxkbid0IGENCj4gPiBkZXNpZ25hdGVkIGV4cGVydCBoYW5kbGUgdGhlIHJldmlldywgY29u c3VsdGluZyB3aXRoIHdoYXRldmVyDQo+ID4gYXBwcm9wcmlhdGUgd29ya2luZyBncm91cChzKSBl eGlzdCBhdCB0aGUgdGltZSAoYXMgd2l0aCAiU3BlY2lmaWNhdGlvbg0KPiA+IFJlcXVpcmVkIik/ DQo+ID4NCj4gPiBJJ20gaG9uZXN0IE9LIHdpdGggU3RhbmRhcmRzIEFjdGlvbiBpZiB0aGF0J3Mg cmVhbGx5IHdoYXQgdGhlIHdvcmtpbmcNCj4gPiBncm91cCB3YW50cywgYW5kIHRoZXkgaGF2ZSBh IHJlYXNvbmFibGUgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGF0J3MNCj4gPiBuZWNlc3NhcnkgaGVy ZS4gIEknbSBhc2tpbmcgYmVjYXVzZSBJIGNhbid0IHNlZSBhbnkgZXZpZGVuY2UgdGhhdCBpdA0K PiA+IHdhcyBhY3R1YWxseSBkaXNjdXNzZWQsIGFuZCBJJ20gY29uY2VybmVkIHRoYXQgd2UgY29u c2lzdGVudGx5IHVzZQ0KPiA+IHRvby1zdHJpY3QgcmVnaXN0cmF0aW9uIHBvbGljaWVzIGJlY2F1 c2Ugd2UgdGhpbmsgdGhleSdyZSBuZWNlc3NhcnksDQo+ID4gYW5kIHRoYXQgb2Z0ZW4gYml0ZXMg dXMgbGF0ZXIgb24sIHdoZW4gd2Ugd2lzaCB3ZSBoYWRuJ3QgYmVlbiBzbw0KPiA+IHN0cmljdC4N Cj4gPg0KPiA+IENhbiB5b3UgcG9pbnQgbWUgYXQgYW55IG1lc3NhZ2VzIG9yIG1pbnV0ZXMgdGhh dCBzaG93IHRoZSB3b3JraW5nDQo+ID4gZ3JvdXAgZGlzY3Vzc2lvbiBhYm91dCB0aGUgcmVnaXN0 cmF0aW9uIHBvbGljeT8gIENhbiB0aGUgd29ya2luZyBncm91cA0KPiA+IGV4cGxhaW4gd2hhdCBo YXJtIGNvdWxkIGJlIGNhdXNlZCBpZiByZWdpc3RyYXRpb25zIHdlcmUgYWxsb3dlZCB0byBiZQ0K PiA+IG1hZGUgd2l0aG91dCBTdGFuZGFyZHMgVHJhY2sgUkZDcz8NCj4gPg0KPiA+IEJhcnJ5DQoN Cg== From nobody Thu Feb 25 17:21:15 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 D8E0D1A1A38; Thu, 25 Feb 2016 17:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 lAjdGcfLvb_2; Thu, 25 Feb 2016 17:21:11 -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 BA92B1A1A4D; Thu, 25 Feb 2016 17:21:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJE34310; Fri, 26 Feb 2016 01:21:07 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 01:21:04 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 09:20:57 +0800 From: "Songhaibin (A)" To: "Alvaro Retana (aretana)" , Alissa Cooper Thread-Topic: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) Thread-Index: AQHRN7jZcW5g6EknVEW+vQa5IqGiDp7jRewwgC3qCQCAAAWVAIABZu+AgCniSUCAAFpUAIABHupw Date: Fri, 26 Feb 2016 01:20:56 +0000 Message-ID: References: <20151216041827.16193.95293.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="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.0A090204.56CFA883.013C, 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: 27ef7e6dff8ec0cfd0f8b69d31f84b64 Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , IESG , Barry Leiba , "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, 26 Feb 2016 01:21:14 -0000 Hi Alvaro, Thanks. And agree with the suggested text and place for it. Best Regards! -Haibin > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > Sent: Friday, February 26, 2016 12:12 AM > To: Songhaibin (A); Alissa Cooper > Cc: Roni Even; p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf= .org; > IESG; p2psip@ietf.org; Barry Leiba > Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnost= ics-19: > (with DISCUSS and COMMENT) >=20 > On 2/24/16, 10:10 PM, "iesg on behalf of Songhaibin (A)" > wrote: >=20 > Haibin: >=20 >=20 > Hi! >=20 > >I did the editing job and have submitted a new version of the document > >according to the comments received and the discussion in the list. I > >also add some text in the change history appendix for it. Please check > >if the updated version has addressed your comments. > > > >https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20 >=20 > I think that the text added in 4.3 maybe needs a little word-smithing (se= e below > for a suggestion), and I think it should be in a more prominent place (I = suggest > 4.1) because the issue is not specific to Path_Track. > Otherwise I think it's ok. >=20 > >I keep the intended status of the document as it is. Alvaro thought > >Experimental might be a better status, when I check the change history > >in the document, as it is defined as a mandatory RELOAD extension, the > >current intended status seems suitable. Otherwise we need go through > >another WGLC to change the intended status. >=20 > I don't think a new WGLC would be needed (or IETF LC for that matter) sin= ce it > was already approved at a "higher" maturity level. I also don't think we= need > to belabor this point much longer. >=20 > I will clear my DISCUSS. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 > Suggested text update: >=20 > OLD> > One important thing is that, this document 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 they are, 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 as defined in > [RFC6940] (whatever DHT routing algorithms are used), but response > message could go through not exactly the same path as there still can > be node failures during that very short period. And there can also > be lack of accurate path informaiton of the previously failed > message. >=20 >=20 > NEW> > It is important to note that the mechanisms described in this document > do not guarantee that the information collected is in fact related to > the previous failures. However, using the information from previous > traversed nodes, the user (or management system) may be able to infer > the problem. Symmetric routing can be achieved by using the Via List > [RFC6940] (or an alternate DHT routing algorithm), but the response > path is not guaranteed to be the same. From nobody Fri Feb 26 17:12:20 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 6FF0D1B368A; Fri, 26 Feb 2016 17:12:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160227011219.23289.69824.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 17:12:19 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-21.txt 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: Sat, 27 Feb 2016 01:12:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-21.txt Pages : 31 Date : 2016-02-26 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 26 17:14:51 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 3FF201B36DA; Fri, 26 Feb 2016 17:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 4E5jAz6E-4VC; Fri, 26 Feb 2016 17:14:45 -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 235571B36D9; Fri, 26 Feb 2016 17:14:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFB00779; Sat, 27 Feb 2016 01:14:42 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 27 Feb 2016 01:14:41 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 27 Feb 2016 09:14:30 +0800 From: "Songhaibin (A)" To: "Songhaibin (A)" , "Alvaro Retana (aretana)" , Alissa Cooper Thread-Topic: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT) Thread-Index: AQHRN7jZcW5g6EknVEW+vQa5IqGiDp7jRewwgC3qCQCAAAWVAIABZu+AgCniSUCAAFpUAIABHupwgAGQnaA= Date: Sat, 27 Feb 2016 01:14:30 +0000 Message-ID: References: <20151216041827.16193.95293.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="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.0A020201.56D0F882.00A4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 52bea3f1f0ff1467495177818fdeaedb Archived-At: Cc: "p2psip-chairs@ietf.org" , Barry Leiba , "draft-ietf-p2psip-diagnostics@ietf.org" , "p2psip@ietf.org" , IESG 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: Sat, 27 Feb 2016 01:14:48 -0000 Hi Alvaro, I just submitted a new version, and this comment has been solved. https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21 Best Regards! -Haibin > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Songhaibin (A) > Sent: Friday, February 26, 2016 9:21 AM > To: Alvaro Retana (aretana); Alissa Cooper > Cc: p2psip-chairs@ietf.org; p2psip@ietf.org; IESG; Barry Leiba; > draft-ietf-p2psip-diagnostics@ietf.org > Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnost= ics-19: > (with DISCUSS and COMMENT) >=20 > Hi Alvaro, >=20 > Thanks. And agree with the suggested text and place for it. >=20 > Best Regards! > -Haibin >=20 > > -----Original Message----- > > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > > Sent: Friday, February 26, 2016 12:12 AM > > To: Songhaibin (A); Alissa Cooper > > Cc: Roni Even; p2psip-chairs@ietf.org; > > draft-ietf-p2psip-diagnostics@ietf.org; > > IESG; p2psip@ietf.org; Barry Leiba > > Subject: Re: [P2PSIP] Barry Leiba's Discuss on > draft-ietf-p2psip-diagnostics-19: > > (with DISCUSS and COMMENT) > > > > On 2/24/16, 10:10 PM, "iesg on behalf of Songhaibin (A)" > > wrote: > > > > Haibin: > > > > > > Hi! > > > > >I did the editing job and have submitted a new version of the > > >document according to the comments received and the discussion in the > > >list. I also add some text in the change history appendix for it. > > >Please check if the updated version has addressed your comments. > > > > > >https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20 > > > > I think that the text added in 4.3 maybe needs a little word-smithing > > (see below for a suggestion), and I think it should be in a more > > prominent place (I suggest > > 4.1) because the issue is not specific to Path_Track. > > Otherwise I think it's ok. > > > > >I keep the intended status of the document as it is. Alvaro thought > > >Experimental might be a better status, when I check the change > > >history in the document, as it is defined as a mandatory RELOAD > > >extension, the current intended status seems suitable. Otherwise we > > >need go through another WGLC to change the intended status. > > > > I don't think a new WGLC would be needed (or IETF LC for that matter) > > since it was already approved at a "higher" maturity level. I also > > don't think we need to belabor this point much longer. > > > > I will clear my DISCUSS. > > > > Thanks! > > > > Alvaro. > > > > > > Suggested text update: > > > > OLD> > > One important thing is that, this document does not guarantee what i= t > > conveys must be the information that caused the previous failures, > > but with the retrieved information from the previous traversed nodes > > (with high probability they are, 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 as defined i= n > > [RFC6940] (whatever DHT routing algorithms are used), but response > > message could go through not exactly the same path as there still ca= n > > be node failures during that very short period. And there can also > > be lack of accurate path informaiton of the previously failed > > message. > > > > > > NEW> > > It is important to note that the mechanisms described in this docume= nt > > do not guarantee that the information collected is in fact related t= o > > the previous failures. However, using the information from previous > > traversed nodes, the user (or management system) may be able to infe= r > > the problem. Symmetric routing can be achieved by using the Via List > > [RFC6940] (or an alternate DHT routing algorithm), but the response > > path is not guaranteed to be the same. >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip