From cjbc@it.uc3m.es Mon Jun 3 11:54:23 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849C621F848E for ; Mon, 3 Jun 2013 11:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt6HoLnPJOiN for ; Mon, 3 Jun 2013 11:54:09 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id EDCE121F8E2C for ; Mon, 3 Jun 2013 11:50:24 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 531318A0FCB; Mon, 3 Jun 2013 20:50:23 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 46E0B8A0891; Mon, 3 Jun 2013 20:50:23 +0200 (CEST) Message-ID: <1370285423.4441.123.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Mon, 03 Jun 2013 20:50:23 +0200 In-Reply-To: <1367688214.4458.8.camel@acorde.it.uc3m.es> References: <1367688214.4458.8.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19914.001 X-TM-AS-Result: No--15.569-7.0-31-1 X-imss-scan-details: No--15.569-7.0-31-1 Cc: draft-ietf-p2psip-drr@tools.ietf.org, draft-ietf-p2psip-rpr@tools.ietf.org Subject: Re: [P2PSIP] Review of revised DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 03 Jun 2013 18:54:23 -0000 Hi, One last comment. I've realized while writing the Document Shepherd Write-Up, that current versions of the drafts have some nits (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Please, check and correct them: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-p2psip-drr-06.txt http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-p2psip-rpr-06.txt As soon as a new version is posted and I get all the authors' feedback regarding full conformance with the provisions of BCP 78 and BCP 79 on IPR disclosures, I'll request the IESG the review and approval for publication of both documents. Thanks, Carlos On Sat, 2013-05-04 at 19:23 +0200, Carlos Jesús Bernardos Cano wrote: > Hi, > > I've just gone through the revised documents authors provided after my > first round of comments. I'm happy to see that most of the comments have > been now introduced. I have now only a few minor editorial ones, that > can be dealt with in parallel with the next steps. My reviews are > attached to this e-mail (I added comments to the PDF version of each > draft). Authors, please check the attachments!! :D > > Thanks for the nice job. > > Thanks, > > Carlos > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Sun Jun 9 00:07:47 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9745221F8EB2; Sun, 9 Jun 2013 00:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYp1uZvQr0vm; Sun, 9 Jun 2013 00:07:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8606F21F8EAD; Sun, 9 Jun 2013 00:07:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130609070742.12823.82122.idtracker@ietfa.amsl.com> Date: Sun, 09 Jun 2013 00:07:42 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-drr-07.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Jun 2013 07:07:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : An extension to RELOAD to support Direct Response Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-drr-07.txt Pages : 16 Date : 2013-06-09 Abstract: This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-drr-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-drr-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jun 9 00:09:24 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7821F9642; Sun, 9 Jun 2013 00:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GgkEkWSqlVH; Sun, 9 Jun 2013 00:09:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4F821F8F85; Sun, 9 Jun 2013 00:09:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130609070923.22664.12833.idtracker@ietfa.amsl.com> Date: Sun, 09 Jun 2013 00:09:23 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-rpr-07.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Jun 2013 07:09:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : An extension to RELOAD to support Relay Peer Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-rpr-07.txt Pages : 14 Date : 2013-06-09 Abstract: This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential use cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-rpr-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-rpr-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zongning@huawei.com Sun Jun 9 00:11:56 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB8021F925A for ; Sun, 9 Jun 2013 00:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i13O9XhAas1c for ; Sun, 9 Jun 2013 00:11:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58221F9050 for ; Sun, 9 Jun 2013 00:11:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASF93837; Sun, 09 Jun 2013 07:11:49 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 08:11:43 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 08:11:44 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 15:10:39 +0800 From: Zongning To: "cjbc@it.uc3m.es" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] Review of revised DRR and RPR documents Thread-Index: AQHOSOwwdTr1ZGUzskOBPXxGT5fQW5kj/nOAgAkwU+A= Date: Sun, 9 Jun 2013 07:10:39 +0000 Message-ID: References: <1367688214.4458.8.camel@acorde.it.uc3m.es> <1370285423.4441.123.camel@acorde.it.uc3m.es> In-Reply-To: <1370285423.4441.123.camel@acorde.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.138.41.23] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-p2psip-drr@tools.ietf.org" , "draft-ietf-p2psip-rpr@tools.ietf.org" Subject: Re: [P2PSIP] Review of revised DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Jun 2013 07:11:56 -0000 SGksIENhcmxvcywNCg0KSSBoYXZlIHBvc3RlZCBuZXcgcmV2aXNpb24gb2YgRFJSIGFuZCBSUFIg ZHJhZnRzIHRvIHNvbHZlIHRoZSBuaXRzLg0KVGhhbmtzLg0KDQotTmluZw0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcmxvcyBKZXPDunMgQmVybmFyZG9zIENhbm8g W21haWx0bzpjamJjQGl0LnVjM20uZXNdDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMDQsIDIwMTMg Mjo1MCBBTQ0KPiBUbzogcDJwc2lwQGlldGYub3JnDQo+IENjOiBkcmFmdC1pZXRmLXAycHNpcC1k cnJAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcDJwc2lwLXJwckB0b29scy5pZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW1AyUFNJUF0gUmV2aWV3IG9mIHJldmlzZWQgRFJSIGFuZCBSUFIgZG9j dW1lbnRzDQo+IA0KPiBIaSwNCj4gDQo+IE9uZSBsYXN0IGNvbW1lbnQuIEkndmUgcmVhbGl6ZWQg d2hpbGUgd3JpdGluZyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQNCj4gV3JpdGUtVXAsIHRoYXQgY3Vy cmVudCB2ZXJzaW9ucyBvZiB0aGUgZHJhZnRzIGhhdmUgc29tZSBuaXRzIChTZWUNCj4gaHR0cDov L3d3dy5pZXRmLm9yZy90b29scy9pZG5pdHMvIGFuZCB0aGUgSW50ZXJuZXQtRHJhZnRzIENoZWNr bGlzdCkuDQo+IFBsZWFzZSwgY2hlY2sgYW5kIGNvcnJlY3QgdGhlbToNCj4gDQo+IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9pZG5pdHM/dXJsPWh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLXAycHNpcC1kcnItMDYudA0KPiB4dA0KPiANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2lk bml0cz91cmw9aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcDJwc2lwLXJwci0w Ni50DQo+IHh0DQo+IA0KPiBBcyBzb29uIGFzIGEgbmV3IHZlcnNpb24gaXMgcG9zdGVkIGFuZCBJ IGdldCBhbGwgdGhlIGF1dGhvcnMnIGZlZWRiYWNrDQo+IHJlZ2FyZGluZyBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgb24NCj4gSVBSIGRp c2Nsb3N1cmVzLCBJJ2xsIHJlcXVlc3QgdGhlIElFU0cgdGhlIHJldmlldyBhbmQgYXBwcm92YWwg Zm9yDQo+IHB1YmxpY2F0aW9uIG9mIGJvdGggZG9jdW1lbnRzLg0KPiANCj4gVGhhbmtzLA0KPiAN Cj4gQ2FybG9zDQo+IA0KPiBPbiBTYXQsIDIwMTMtMDUtMDQgYXQgMTk6MjMgKzAyMDAsIENhcmxv cyBKZXPDunMgQmVybmFyZG9zIENhbm8gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBJJ3ZlIGp1 c3QgZ29uZSB0aHJvdWdoIHRoZSByZXZpc2VkIGRvY3VtZW50cyBhdXRob3JzIHByb3ZpZGVkIGFm dGVyIG15DQo+ID4gZmlyc3Qgcm91bmQgb2YgY29tbWVudHMuIEknbSBoYXBweSB0byBzZWUgdGhh dCBtb3N0IG9mIHRoZSBjb21tZW50cyBoYXZlDQo+ID4gYmVlbiBub3cgaW50cm9kdWNlZC4gSSBo YXZlIG5vdyBvbmx5IGEgZmV3IG1pbm9yIGVkaXRvcmlhbCBvbmVzLCB0aGF0DQo+ID4gY2FuIGJl IGRlYWx0IHdpdGggaW4gcGFyYWxsZWwgd2l0aCB0aGUgbmV4dCBzdGVwcy4gTXkgcmV2aWV3cyBh cmUNCj4gPiBhdHRhY2hlZCB0byB0aGlzIGUtbWFpbCAoSSBhZGRlZCBjb21tZW50cyB0byB0aGUg UERGIHZlcnNpb24gb2YgZWFjaA0KPiA+IGRyYWZ0KS4gQXV0aG9ycywgcGxlYXNlIGNoZWNrIHRo ZSBhdHRhY2htZW50cyEhIDpEDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBuaWNlIGpvYi4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IENhcmxvcw0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiA+ IFAyUFNJUEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcDJwc2lwDQo+IA0KDQo= From cjbc@it.uc3m.es Sun Jun 9 01:53:41 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6531821F90FD for ; Sun, 9 Jun 2013 01:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LbGghsK5Mns for ; Sun, 9 Jun 2013 01:53:36 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCD821F8F4D for ; Sun, 9 Jun 2013 01:53:36 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BC6189D2AC1; Sun, 9 Jun 2013 10:53:32 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.203.189] (unknown [163.117.203.189]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id D72B49D2AA9; Sun, 9 Jun 2013 10:53:30 +0200 (CEST) Message-ID: <1370767999.4601.3.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Zongning Date: Sun, 09 Jun 2013 10:53:19 +0200 In-Reply-To: References: <1367688214.4458.8.camel@acorde.it.uc3m.es> <1370285423.4441.123.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19928.000 X-TM-AS-Result: No--29.358-7.0-31-1 X-imss-scan-details: No--29.358-7.0-31-1 Cc: "draft-ietf-p2psip-rpr@tools.ietf.org" , "draft-ietf-p2psip-drr@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of revised DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Jun 2013 08:53:41 -0000 Hi Ning, Thanks for the updates. Carlos On Sun, 2013-06-09 at 07:10 +0000, Zongning wrote: > Hi, Carlos, > > I have posted new revision of DRR and RPR drafts to solve the nits. > Thanks. > > -Ning > > > -----Original Message----- > > From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > > Sent: Tuesday, June 04, 2013 2:50 AM > > To: p2psip@ietf.org > > Cc: draft-ietf-p2psip-drr@tools.ietf.org; draft-ietf-p2psip-rpr@tools.ietf.org > > Subject: Re: [P2PSIP] Review of revised DRR and RPR documents > > > > Hi, > > > > One last comment. I've realized while writing the Document Shepherd > > Write-Up, that current versions of the drafts have some nits (See > > http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). > > Please, check and correct them: > > > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-p2psip-drr-06.t > > xt > > > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-p2psip-rpr-06.t > > xt > > > > As soon as a new version is posted and I get all the authors' feedback > > regarding full conformance with the provisions of BCP 78 and BCP 79 on > > IPR disclosures, I'll request the IESG the review and approval for > > publication of both documents. > > > > Thanks, > > > > Carlos > > > > On Sat, 2013-05-04 at 19:23 +0200, Carlos Jesús Bernardos Cano wrote: > > > Hi, > > > > > > I've just gone through the revised documents authors provided after my > > > first round of comments. I'm happy to see that most of the comments have > > > been now introduced. I have now only a few minor editorial ones, that > > > can be dealt with in parallel with the next steps. My reviews are > > > attached to this e-mail (I added comments to the PDF version of each > > > draft). Authors, please check the attachments!! :D > > > > > > Thanks for the nice job. > > > > > > Thanks, > > > > > > Carlos > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www.ietf.org/mailman/listinfo/p2psip > > > From michaelc@idssoftware.com Sun Jun 9 08:36:44 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A56021F8E37 for ; Sun, 9 Jun 2013 08:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 728piZYZOH5T for ; Sun, 9 Jun 2013 08:36:40 -0700 (PDT) Received: from p3plwbeout03-04.prod.phx3.secureserver.net (p3plsmtp03-04-2.prod.phx3.secureserver.net [72.167.218.216]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17321F89EB for ; Sun, 9 Jun 2013 08:36:39 -0700 (PDT) Received: from localhost ([72.167.218.243]) by p3plwbeout03-04.prod.phx3.secureserver.net with bizsmtp id mFce1l0095FgiYg01FceKr; Sun, 09 Jun 2013 08:36:38 -0700 X-SID: mFce1l0095FgiYg01 Received: (qmail 3640 invoked by uid 99); 9 Jun 2013 15:36:38 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9dd1bc5b874ebaf039c105638216a826" To: "Marc Petit-Huguenin" , cjbc@it.uc3m.es From: "Michael Chen" In-Reply-To: <519A3F1D.3030802@acm.org> Date: Sun, 09 Jun 2013 08:36:38 -0700 Message-Id: <20130609083638.59ca11a9ba9389561a029f06442e67fa.ea0354eabf.mailapi@email03.secureserver.net> X-Originating-IP: 172.249.4.226 User-Agent: MailAPI 24605 X-Sender: michaelc@idssoftware.com Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-09 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 09 Jun 2013 15:36:44 -0000 --=_9dd1bc5b874ebaf039c105638216a826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, =20 Has the issue of keep-alive been addressed? =20 http://www.ietf.org/mail-archive/web/p2psip/current/msg06176.html =20 Thanks =20 --Michael --------- Original Message --------- Subject: Re: [P2PSIP] WGLC for draft-i= etf-p2psip-sip-09 From: "Marc Petit-Huguenin" Date: 5/20/13 8:19 am To: cjbc@it.uc3m.es Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 =20 Sorry for the delay in responding to this. =20 I read again the I-D, and I think that this document is ready to be submit= ted to the IESG. =20 On 05/04/2013 10:33 AM, Carlos Jesús Bernardos Cano wrote: > Hi, >=20 > Hereby we are issuing a WGLC for draft-ietf-p2psip-sip-09. >=20 > The WGLC will be open till the 20th of May. We kindly ask the WG to revi= ew > the document and provide comments. >=20 > If you have no comments and think the document is ready to be submitted = to > IESG, please do send a note stating that to the WG ML. >=20 > Additional information about the document is below: >=20 > Title : A SIP Usage for RELOAD Author(s) : Cullen Jennings=20 > Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thom= as > C. Schmidt Filename : draft-ietf-p2psip-sip-09.txt Pages : > 19 Date : 2013-02-25 >=20 > Abstract: This document defines a SIP Usage for REsource LOcation And > Discovery (RELOAD). The SIP Usage provides the functionality of a SIP > proxy or registrar in a fully-distributed system and includes a lookup > service for Address of Records (AORs) stored in the overlay. It also > defines Globally Routable User Agent Uris (GRUUs) that allow the=20 > registrations to map an AOR to a specific node reachable through the=20 > overlay. After such initial contact of a peer, the AppAttach method is > used to establish a direct connection between nodes through which SIP > messages are exchanged. >=20 > The IETF datatracker status page for this draft is:=20 > https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip >=20 > There's also a htmlized version available at:=20 > http://tools.ietf.org/html/draft-ietf-p2psip-sip-09 >=20 =20 - --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) =20 iQIcBAEBCAAGBQJRmj8bAAoJECnERZXWan7EcJAQAMsY49O8XhTJOLcpbXmIeb0r g2qdOCq+c8/baC1sVG4QqEpoKwM6ELCgem6STh7kEJPMWos0VQGTtoERseN1wUZ0 GA2WuyF0NjQrONcm3dnvzjJm39rcCfcjl/S8oU7rLBI3dfFInyQHJ+cv/O8aml/6 0tDeNOACM6fQEsLKXITb2mCPFb+ybeNGWWq5QBA7t4SBhytkxkG/NVmlBQnDPryi 1X/D/o/xOuvh+6JZNnxTQmNQLe6TwiFF6+FqliFcHAhRhYNB4qU3t+LkgMhZplJt 85JKI+3/b4hN20JftQiyxD21Q8xEQte3i5X5tpnDLc9eUmwEbDJdmxJ0bQdFfCAb ZGYhWWsKpIlL1NoRRICcyG6e+ZmsR/fyzJMzGoEMhsw6fXUZheJTHhxVQrVCkEKr THCrdtKvqm/+1Y9CeEwk0k5UEfuVRTREo4b1Hk6GjIn/vyCOyt9R57LMn/9nGk2a dUyI68AfhmNbIFrSvQTvBKgim+DJ4OnJTDJBYGdHBupVFLuYxUuL8FLwO57YHJEe x3zFRxX1wrpkZB2I5wPgHVAvavYSJcYLBMNAqTDfn5DRzgZnS+cpwj1rYPYgNIFR WcCFdTruSOC36TLjNNDlNF7ClUjqOsZZIKQJAMAw6IEJ4FpXEahhLaOStzsSvx7K hPnzI9mLq9y1VRmZGABA =3DsdAy -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --=_9dd1bc5b874ebaf039c105638216a826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,
 
Has the issue of keep-alive been addressed?
 
  http://www.ietf.org/mail-archive/web/p2psip/current/msg06176.ht= ml
 
Thanks
 
--Michael
--------- Original Message -----= ----
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-09
From: "Ma= rc Petit-Huguenin" <petithug@acm.org>
Date: 5/20/13 8:19 am
To: cjbc@it.uc3m.es
Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org=

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sorry for the delay in responding to this.

I read again th= e I-D, and I think that this document is ready to be submitted
to the= IESG.

On 05/04/2013 10:33 AM, Carlos Jesús Bernardos C= ano wrote:
> Hi,
>
> Hereby we are issuing a WG= LC for draft-ietf-p2psip-sip-09.
>
> The WGLC will be op= en till the 20th of May. We kindly ask the WG to review
> the docu= ment and provide comments.
>
> If you have no comments a= nd think the document is ready to be submitted to
> IESG, please d= o send a note stating that to the WG ML.
>
> Additional = information about the document is below:
>
> Title : A S= IP Usage for RELOAD Author(s) : Cullen Jennings
> Bruce B. Loweka= mp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas
> C. S= chmidt Filename : draft-ietf-p2psip-sip-09.txt Pages :
> 19 Date := 2013-02-25
>
> Abstract: This document defines a SIP Us= age for REsource LOcation And
> Discovery (RELOAD). The SIP Usage = provides the functionality of a SIP
> proxy or registrar in a full= y-distributed system and includes a lookup
> service for Address o= f Records (AORs) stored in the overlay. It also
> defines Globally= Routable User Agent Uris (GRUUs) that allow the
> registrations = to map an AOR to a specific node reachable through the
> overlay= =2E After such initial contact of a peer, the AppAttach method is
>= ; used to establish a direct connection between nodes through which SIP
> messages are exchanged.
>
> The IETF datatracker= status page for this draft is:
> https://datatracker.ietf.org/do= c/draft-ietf-p2psip-sip
>
> There's also a htmlized vers= ion available at:
> http://tools.ietf.org/html/draft-ietf-p2psip-= sip-09
>

- --
Marc Petit-Huguenin
Email= : marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGN= ATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCA= AGBQJRmj8bAAoJECnERZXWan7EcJAQAMsY49O8XhTJOLcpbXmIeb0r
g2qdOCq+c8/baC= 1sVG4QqEpoKwM6ELCgem6STh7kEJPMWos0VQGTtoERseN1wUZ0
GA2WuyF0NjQrONcm3d= nvzjJm39rcCfcjl/S8oU7rLBI3dfFInyQHJ+cv/O8aml/6
0tDeNOACM6fQEsLKXITb2m= CPFb+ybeNGWWq5QBA7t4SBhytkxkG/NVmlBQnDPryi
1X/D/o/xOuvh+6JZNnxTQmNQLe= 6TwiFF6+FqliFcHAhRhYNB4qU3t+LkgMhZplJt
85JKI+3/b4hN20JftQiyxD21Q8xEQt= e3i5X5tpnDLc9eUmwEbDJdmxJ0bQdFfCAb
ZGYhWWsKpIlL1NoRRICcyG6e+ZmsR/fyzJ= MzGoEMhsw6fXUZheJTHhxVQrVCkEKr
THCrdtKvqm/+1Y9CeEwk0k5UEfuVRTREo4b1Hk= 6GjIn/vyCOyt9R57LMn/9nGk2a
dUyI68AfhmNbIFrSvQTvBKgim+DJ4OnJTDJBYGdHBu= pVFLuYxUuL8FLwO57YHJEe
x3zFRxX1wrpkZB2I5wPgHVAvavYSJcYLBMNAqTDfn5DRzg= ZnS+cpwj1rYPYgNIFR
WcCFdTruSOC36TLjNNDlNF7ClUjqOsZZIKQJAMAw6IEJ4FpXEa= hhLaOStzsSvx7K
hPnzI9mLq9y1VRmZGABA
=3DsdAy
-----END PGP = SIGNATURE-----
_______________________________________________
= P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailma= n/listinfo/p2psip
--=_9dd1bc5b874ebaf039c105638216a826-- From cjbc@it.uc3m.es Mon Jun 10 03:03:21 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F17621F8519; Mon, 10 Jun 2013 03:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sntGpVkwZvIF; Mon, 10 Jun 2013 03:03:16 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id E2AE321F84D4; Mon, 10 Jun 2013 03:03:12 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 188F9773B4F; Mon, 10 Jun 2013 12:03:11 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 0B569766A6C; Mon, 10 Jun 2013 12:03:11 +0200 (CEST) Message-ID: <1370858591.4513.32.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: iesg-secretary@ietf.org Date: Mon, 10 Jun 2013 12:03:11 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-pPiPTtMezyfwO/It40iI" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19930.003 X-TM-AS-Result: No--15.497-7.0-31-1 X-imss-scan-details: No--15.497-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org, "draft-ietf-p2psip-drr@tools.ietf.org" , p2psip@ietf.org Subject: [P2PSIP] Request to to progress I-D: draft-ietf-p2psip-drr-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 10 Jun 2013 10:03:21 -0000 --=-pPiPTtMezyfwO/It40iI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Dear Secretariat, The P2PSIP WG has completed working group last call on the I-D: draft-ietf-p2psip-drr-07. The I-D is ready for IESG review and publication. Please find attached the proto writeup for this P2PSIP WG document. Thanks, Carlos --=-pPiPTtMezyfwO/It40iI Content-Disposition: attachment; filename="draft-ietf-p2psip-drr-07_document_shepherd_write-up.txt" Content-Type: text/plain; name="draft-ietf-p2psip-drr-07_document_shepherd_write-up.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit An extension to RELOAD to support Direct Response Routing (draft-ietf-p2psip-drr-07) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed Standard Why is this the proper type of RFC? The document has received significant community review, and appears to enjoy enough community interest to be considered valuable. It defines extensions to draft-ietf-p2psip-base, which also has an intended status of Proposed Standard. Is this type of RFC indicated in the title page header? Yes (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: RELOAD recommends symmetric recursive routing for routing messages. An optional extesion that can be used to provide shorter routes for responses (reducing the overhead on intermediate nodes) consists in supporting a direct response routing mode. This defines the required extension as well as describes potential use cases where it can be used. Working Group Summary: The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noting. Document Quality: The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J. Bernardos. Personnel: Who is the Document Shepherd? Carlos J. Bernardos Who is the Responsible Area Director? Gonzalo Camarillo (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has personally done a thorough review of the document. Some changes (mainly editorial) were requested to the authors and included in the last revision of the draft. The Document Shepherd believes the document is ready for forwarding to IESG for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd has no concerns about the depth or breadth of these reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is WG consensus behind this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits. The automatic nits detection tool detects 2 instances of lines with non-RFC5735-compliant IPv4 addresses, but I could not find them, so I guess it is a detection mistake. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document meets the review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document defines a new RELOAD Forwarding Option type. The IANA registry is defined in [I-D.ietf-p2psip-base], Forwarding Option Registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language segments exist. --=-pPiPTtMezyfwO/It40iI-- From cjbc@it.uc3m.es Mon Jun 10 03:04:49 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7702021F8A85; Mon, 10 Jun 2013 03:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX80R+-bNVce; Mon, 10 Jun 2013 03:04:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB6921F84D8; Mon, 10 Jun 2013 03:04:44 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F357C773B4F; Mon, 10 Jun 2013 12:04:33 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id E6358766A6C; Mon, 10 Jun 2013 12:04:33 +0200 (CEST) Message-ID: <1370858674.4513.34.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: iesg-secretary@ietf.org Date: Mon, 10 Jun 2013 12:04:34 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-VFf3rHBstAE8/CO5esyW" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19930.003 X-TM-AS-Result: No--15.497-7.0-31-1 X-imss-scan-details: No--15.497-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org, "draft-ietf-p2psip-rpr@tools.ietf.org" , p2psip@ietf.org Subject: [P2PSIP] Request to to progress I-D: draft-ietf-p2psip-rpr-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 10 Jun 2013 10:04:49 -0000 --=-VFf3rHBstAE8/CO5esyW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Dear Secretariat, The P2PSIP WG has completed working group last call on the I-D: draft-ietf-p2psip-rpr-07. The I-D is ready for IESG review and publication. Please find attached the proto writeup for this P2PSIP WG document. Thanks, Carlos --=-VFf3rHBstAE8/CO5esyW Content-Disposition: attachment; filename="draft-ietf-p2psip-rpr-07_document_shepherd_write-up.txt" Content-Type: text/plain; name="draft-ietf-p2psip-rpr-07_document_shepherd_write-up.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit An extension to RELOAD to support Relay Peer Routing (draft-ietf-p2psip-rpr-07) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed Standard Why is this the proper type of RFC? The document has received significant community review, and appears to enjoy enough community interest to be considered valuable. It defines extensions to draft-ietf-p2psip-base, which also has an intended status of Proposed Standard. Is this type of RFC indicated in the title page header? Yes (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: RELOAD recommends symmetric recursive routing for routing messages. An optional extesion that can be used to provide shorter routes for responses (reducing the overhead on intermediate nodes) consists in supporting a relay peer routing mode. This defines the required extension as well as describes potential use cases where it can be used. Working Group Summary: The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noting. Document Quality: The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J. Bernardos. Personnel: Who is the Document Shepherd? Carlos J. Bernardos Who is the Responsible Area Director? Gonzalo Camarillo (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has personally done a thorough review of the document. Some changes (mainly editorial) were requested to the authors and included in the last revision of the draft. The Document Shepherd believes the document is ready for forwarding to IESG for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd has no concerns about the depth or breadth of these reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There has been an IPR claim in full conformance with the provisions of BCP 78 and BCP 79. The Working Group was informed of this IPR claim befor version -02 of the draft was published. No WG discussion has happened. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is WG consensus behind this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits. The automatic nits detection tool detects 2 instances of lines with non-RFC5735-compliant IPv4 addresses, but I could not find them, so I guess it is a detection mistake. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document meets the review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there is one (which is actually a downward normative reference) to draft-ietf-p2psip-concepts-04. This document has not been updated since October 2011. The plan is to contact authors to ensure the document is finalized or nominate a new editor to complete the work. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes. There is a normative reference to draft-ietf-p2psip-concepts-04, which intended status is Informational. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not require any IANA considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language segments exist. --=-VFf3rHBstAE8/CO5esyW-- From petithug@acm.org Fri Jun 14 09:38:18 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD5621F9CC3 for ; Fri, 14 Jun 2013 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqEwwwI+GNuP for ; Fri, 14 Jun 2013 09:38:17 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 69D4821F9649 for ; Fri, 14 Jun 2013 09:38:17 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:c4a5:8edd:e022:ca5c] (unknown [IPv6:2601:9:4bc0:1f:c4a5:8edd:e022:ca5c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 10DED2021A; Fri, 14 Jun 2013 18:38:14 +0200 (CEST) Message-ID: <51BB46F3.8040303@acm.org> Date: Fri, 14 Jun 2013 09:38:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Polina Goltsman References: <517581CF.1060705@student.kit.edu> In-Reply-To: <517581CF.1060705@student.kit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Roland Bless , p2psip@ietf.org Subject: Re: [P2PSIP] Certificates with multiple NodeIds X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2013 16:38:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Polina, Please find below my answers to some of your comments. Note that I am not a co-author of the spec, so that will be just my opinion. On 04/22/2013 11:30 AM, Polina Goltsman wrote: > Hi, > > I have several questions regarding certificates with multiple NodeIDs. It > seems that different parts in the draft contradict each other. > > First, section 6.6.1 defines requirements for future overlay link > protocols. I suppose, that current overlay link protocol must meet these > requirements. >> Endpoint authentication When a node forms an association with another >> endpoint, it MUST be possible to cryptographically verify that the >> endpoint has a given Node-ID. > > Certificates with multiple NodeIDs sometimes violate this requirement. > Unless a connection was formed as a result of exchanging Attach messages, > it is impossible to associate an endpoint and its NodeID, which is the case > when new node connects to BootstrapPeer. As a consequence several reload > requirements are hard or even impossible to implement IMHO. > > The first requirement is that ConnectionTable SHOULD use some indexes > instead of mapping NodeIds to (D)TLS Connections. I am not sure where in the spec you found this requirement. > > The second requirement is in section 6.1.2 >> If a node with a certificate with multiple Node-IDs attempts to route a >> message other than a Ping or Attach through a node without performing an >> Attach, the receiving node MUST reject the request with an >> Error_Forbidden error. The node MUST implement support for returning >> responses to a Ping or Attach request made by a joiningnode Attaching to >> its responsible peer. > > The routing decisions must be made based on ForwardingHeader alone, and a > ForwardingHeader does not contain information about type of the message, > being sent. So this is practically NOT implementable. I agree that there is a layer violation here. But this applies only to bootstrap nodes, which anyway require special processing on their public address, as they accept connections without Attach. So the special code that parses the message in addition to the header can be isolated to that special kind of nodes. > > Section 3.2.1 Bullet 2 - about Clients, that connect to peers >> A client connected this way using a certificate with only a single >> Node-ID can proceed to use the connection without performing an Attach >> (Section 6.5.1). A client wishing to connect using this mechanism with a >> certificate with multiple Node-IDs can use a Ping (Section >6.5.3) to >> probe the Node-ID of the node to which it is connected before doing the >> Attach. > > As far as I understand, the procedure is as follows. The peer in the > overlay, that listens on some known port, receives a connection from a > client. This connection is in some unknown state because NodeId of at least > one endpoint is not known. Then, the client must send a PingReq to the > wildcard NodeId. It will be consumed by the peer as the next endpoint. Not sure what you mean by next endpoint. The Ping will be answered by this peer, returning a SecureBlock containing the Certificate of this peer. > Once the client has learned the peer's NodeID, it may send Attach, with, as > I suppose, one static candidate. The peer must somehow find out that this > static candidate is the connection, that is already formed and do not try > to form it again. My understanding is that the Attach creates a new connection and that the first one is closed. But this is underspecified so this will create an interoperability problem. > > (Moreover the Attach section doesn't state what to do if the connection is > already formed. This is also essential for the topology plugin, since some > node may already have an opened connection with its new neighbour (consider > peer-ready update), but in that case NodeIds are known and connection table > can be searched). > > In my opinion, both client and peer could learn each other's NodeIDs from > the Ping. Both PingReq and PingAns are signed and thus uniquely identify > its senders. Since the connection to the client is in some unknown state > and the destination was wildcard NodeID, the peer can assume that the > sender of this message is another endpoint of this connection. The peer can > also compare the client's certificate with the one, used to form TLS > association. > > > > Another question, that I have, is shared-secret admission schemes for TLS. > The TLS-PSK RFC states, that in case of TLS-PSK certificate exchange is > optional. It is unclear from the RFC, that PSK ciphers with certificate > exchange must be selected. I think it is clearly stated in 1.3 that certificate must be used with TLS-PSK in the context of RELOAD: "This feature is used together with certificate-based access control, not as a replacement for it." > It is also unclear, what should be sent in TLS-PSK identity field - > username, NodeID, both or nothing. As of TLS-SRP RFC the client certificate > cannot be requested. The identity field is used to select a specific key, when there is a choice between different keys. In the case of RELOAD I suppose that having multiple keys does not make sense so that field (and so the ServerKeyEchange record) should be omitted. > > > > I also can imagine two possible solutions to the first problem. > > Solution 1(undesirable): Have a specified way of finding out peer's > identity. If one of the certificates had multiple NodeIds, the first > message, that is sent over this connection must identified both peers. This > can be Ping, Attach or some dedicated "HelloReq" and it works as described > above. After this exchange both peers must update their connection tables > with NodeIDs of the endpoints. > > This solution is undesirable, since it increases message load on bootstrap > nodes. AFAIK, this is how things are suppose to work in RELOAD. Note that the increased load is only when joining the overlay, so that seems like normal workload to me. https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html > > Solution 2: Use TLS Extension to exchange not only the certificates, but > also NodeID (in some form, e.g. the cert_hash_node_id form) during the TLS > connection. Yes, I proposed something like this back in 2011: https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html That was not the solution selected by the authors. > > The extension can use SupplementaryData [RFC 4680 > ] to exchange the actual NodeID. For > example: struct { SupplementalDataType supp_data_type; uint16 > supp_data_length; select(SupplementalDataType) { case > reload_signer_identity: SignerIdentity } } SupplementalDataEntry; > > The 2 extensions, that look most suitable are: 1. user-mapping [RFC > 4681]. The information, that is sent, > is exactly what is needed,but the RFC defines only client's authentication, > not the server's. 2. serverautz/clientauthz [RFC 5878 > ]. This RFC is not standard. > > I also want to propose more precise way for configuring TLS connection, by > using a dedicated section and overlay-config for configuring underlay link > layer for reload. For example, for TLS this would be: > normal/PSK/SRP > true/false ... > ... I would suggest to write an I-D about this. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRu0bxAAoJECnERZXWan7ECRcP/jw5CphA7aO4vizign7o7Kdp B9xNUuiDB1sV8Vxv/HftIRJmzbXecJLTOj8BuVwZnsTNeZqz7IGJCgRqkaH4Q2sF HIsHls2OI49T7iIYUu7FNcY1h9PsMO/gtOd2195K4NY16GqluOMisCtwlcopTsBY /fhNokoQ6SjSMtt02NjxZAxqFyrggZc9f02ig+TXEOHRKG1vxNA/7g6q/h3+mR7j RNCw2J1kJSZu9fqWIcLWWUSV8GJQevSVHzja88jCxFMd7FrmvkCJ1HJGC7i+/8Q6 hxyNl/I4v8kBdN/Pn0wK2hBbSPPNIyYvLKGa76nwIeMmSkjmJbbfH4cWLQy2qDqf OsJIibUyMurOyLf8zWpcorj4z4Y3E/pdXVrzlQ78zCxZ8hxh2Nem9q/xcaAeE9yh HETN084rkEC0F/9Ro6T/TT2ZCXR8Xc+PYTPAk76dAS2wdQxwQ6wMXbLTIwtOH+Vf BcbvMXI1qIwJ/Y4l5u7zZ/ype4lcjwZXXr+1iu2k9h2uAOg/REfL7dKRuEmSdOb7 yVEx6ZuxXDacgBn8uZVyrJvvUdgu8+/sMjAAcajXmW1lyA0ekIViTJPnRsWD7Ax4 FLQbFzxAdJ6cPUF3EUQ52JosqMM9hAQBXOSfVzXLLAA+XpqVlpMxvktALl8F3zvW HwUMrudMecpks9f80p0q =pzTn -----END PGP SIGNATURE----- From polina.goltsman@student.kit.edu Sat Jun 15 12:35:29 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13E21F9D4B for ; Sat, 15 Jun 2013 12:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1UBcdhnrF2Q for ; Sat, 15 Jun 2013 12:35:25 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6D22A21F9D17 for ; Sat, 15 Jun 2013 12:35:25 -0700 (PDT) Received: from KIT-MSX-04.kit.edu (kit-msx-04.kit.edu [172.21.117.14]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1UnwFv-0006aO-VD; Sat, 15 Jun 2013 21:35:24 +0200 Received: from [172.20.15.72] (172.21.117.6) by smtp.kit.edu (172.21.117.14) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 15 Jun 2013 21:35:23 +0200 Message-ID: <51BCC1F9.3070902@student.kit.edu> Date: Sat, 15 Jun 2013 21:35:21 +0200 From: Polina Goltsman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <517581CF.1060705@student.kit.edu> <51BB46F3.8040303@acm.org> In-Reply-To: <51BB46F3.8040303@acm.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Certificates with multiple NodeIds X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 19:35:29 -0000 Dear Marc, Thank you very much for your comments. On 14.06.2013 18:38, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi Polina, > > Please find below my answers to some of your comments. Note that I am not a > co-author of the spec, so that will be just my opinion. > > On 04/22/2013 11:30 AM, Polina Goltsman wrote: >> Hi, >> >> I have several questions regarding certificates with multiple NodeIDs. It >> seems that different parts in the draft contradict each other. >> >> First, section 6.6.1 defines requirements for future overlay link >> protocols. I suppose, that current overlay link protocol must meet these >> requirements. >>> Endpoint authentication When a node forms an association with another >>> endpoint, it MUST be possible to cryptographically verify that the >>> endpoint has a given Node-ID. >> Certificates with multiple NodeIDs sometimes violate this requirement. >> Unless a connection was formed as a result of exchanging Attach messages, >> it is impossible to associate an endpoint and its NodeID, which is the case >> when new node connects to BootstrapPeer. As a consequence several reload >> requirements are hard or even impossible to implement IMHO. >> >> The first requirement is that ConnectionTable SHOULD use some indexes >> instead of mapping NodeIds to (D)TLS Connections. > I am not sure where in the spec you found this requirement. A have found this requirement in section 6.3.2.2. at the bottom of page 53 (-26) >One possible encoding of the 16 bit integer version as an opaque >identifier is to encode an index into a Connection Table. and so on. I am not very good at this, but as I understood one must have very good reasons not to implement "SHOULD". >> The second requirement is in section 6.1.2 >>> If a node with a certificate with multiple Node-IDs attempts to route a >>> message other than a Ping or Attach through a node without performing an >>> Attach, the receiving node MUST reject the request with an >>> Error_Forbidden error. The node MUST implement support for returning >>> responses to a Ping or Attach request made by a joiningnode Attaching to >>> its responsible peer. >> The routing decisions must be made based on ForwardingHeader alone, and a >> ForwardingHeader does not contain information about type of the message, >> being sent. So this is practically NOT implementable. > I agree that there is a layer violation here. > > But this applies only to bootstrap nodes, which anyway require special > processing on their public address, as they accept connections without Attach. > So the special code that parses the message in addition to the header can be > isolated to that special kind of nodes. From -base: Section 3.2.1 Client Routing **Clients** may insert themselves in the overlay in two ways: ... (bullet 2)Establish a connection with an arbitrary peer in the overlay ... A **client** connected this way using a certificate with only a single Node-ID can proceed to use the connection without performing an Attach (Section 6.5.1 ). A **client** wishing to connect using this mechanism with a certificate with multiple Node-IDs can use a Ping (Section 6.5.3 ) to probe the Node-ID of the node to which it is connected before doing the Attach. Do I understand this wrong, or any client can connect to any peer it wants, so the issue is not only with BP. Moreover, did I miss a requirement that forbids me to for direct connection (without Attach) if I know IP-Address of the Node I wish to connect to. (This didn't make it to the -base, did it ?https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html) >> Section 3.2.1 Bullet 2 - about Clients, that connect to peers >>> A client connected this way using a certificate with only a single >>> Node-ID can proceed to use the connection without performing an Attach >>> (Section 6.5.1). A client wishing to connect using this mechanism with a >>> certificate with multiple Node-IDs can use a Ping (Section >6.5.3) to >>> probe the Node-ID of the node to which it is connected before doing the >>> Attach. >> As far as I understand, the procedure is as follows. The peer in the >> overlay, that listens on some known port, receives a connection from a >> client. This connection is in some unknown state because NodeId of at least >> one endpoint is not known. Then, the client must send a PingReq to the >> wildcard NodeId. It will be consumed by the peer as the next endpoint. > Not sure what you mean by next endpoint. The Ping will be answered by this > peer, returning a SecureBlock containing the Certificate of this peer. Exactly this. I mean endpoint as in the "endpoint of connection or link" >> Once the client has learned the peer's NodeID, it may send Attach, with, as >> I suppose, one static candidate. The peer must somehow find out that this >> static candidate is the connection, that is already formed and do not try >> to form it again. > My understanding is that the Attach creates a new connection and that the first > one is closed. But this is underspecified so this will create an > interoperability problem. > >> (Moreover the Attach section doesn't state what to do if the connection is >> already formed. This is also essential for the topology plugin, since some >> node may already have an opened connection with its new neighbour (consider >> peer-ready update), but in that case NodeIds are known and connection table >> can be searched). >> >> In my opinion, both client and peer could learn each other's NodeIDs from >> the Ping. Both PingReq and PingAns are signed and thus uniquely identify >> its senders. Since the connection to the client is in some unknown state >> and the destination was wildcard NodeID, the peer can assume that the >> sender of this message is another endpoint of this connection. The peer can >> also compare the client's certificate with the one, used to form TLS >> association. >> >> >> >> Another question, that I have, is shared-secret admission schemes for TLS. >> The TLS-PSK RFC states, that in case of TLS-PSK certificate exchange is >> optional. It is unclear from the RFC, that PSK ciphers with certificate >> exchange must be selected. > I think it is clearly stated in 1.3 that certificate must be used with TLS-PSK > in the context of RELOAD: > > "This feature is used together with certificate-based > access control, not as a replacement for it." The point is that IMHO it(together with 3.2.1) should be specified somewhere after section 5. >> It is also unclear, what should be sent in TLS-PSK identity field - >> username, NodeID, both or nothing. As of TLS-SRP RFC the client certificate >> cannot be requested. > The identity field is used to select a specific key, when there is a choice > between different keys. In the case of RELOAD I suppose that having multiple > keys does not make sense so that field (and so the ServerKeyEchange record) > should be omitted. Thank you very much for the explanation. Do you think it should be specified, that this key SHOULD be omitted? >> I also can imagine two possible solutions to the first problem. >> >> Solution 1(undesirable): Have a specified way of finding out peer's >> identity. If one of the certificates had multiple NodeIds, the first >> message, that is sent over this connection must identified both peers. This >> can be Ping, Attach or some dedicated "HelloReq" and it works as described >> above. After this exchange both peers must update their connection tables >> with NodeIDs of the endpoints. >> >> This solution is undesirable, since it increases message load on bootstrap >> nodes. > AFAIK, this is how things are suppose to work in RELOAD. Note that the > increased load is only when joining the overlay, so that seems like normal > workload to me. > > https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html 1) This would increase load on the Bootstrap Peer, which IMHO is not desirable. 2) From your message: * *>Because there is no Attach, the peer has to spy on the first message sent by the client to extract the Node-ID from the SignerIdentity and "label" the newly created connection in the connection table. Well, it was not that obvious to me. Was there a reason why it didn't make it to the -base? I believe it is relatively hard to spy on the messages, that are routed through, since they can be fragmented. So IMHO the first message should be destined to the connection endpoint. >> Solution 2: Use TLS Extension to exchange not only the certificates, but >> also NodeID (in some form, e.g. the cert_hash_node_id form) during the TLS >> connection. > Yes, I proposed something like this back in 2011: > > https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html > > That was not the solution selected by the authors. > >> The extension can use SupplementaryData [RFC 4680 >> ] to exchange the actual NodeID. For >> example: struct { SupplementalDataType supp_data_type; uint16 >> supp_data_length; select(SupplementalDataType) { case >> reload_signer_identity: SignerIdentity } } SupplementalDataEntry; >> >> The 2 extensions, that look most suitable are: 1. user-mapping [RFC >> 4681]. The information, that is sent, >> is exactly what is needed,but the RFC defines only client's authentication, >> not the server's. 2. serverautz/clientauthz [RFC 5878 >> ]. This RFC is not standard. >> >> I also want to propose more precise way for configuring TLS connection, by >> using a dedicated section and overlay-config for configuring underlay link >> layer for reload. For example, for TLS this would be: >> normal/PSK/SRP >> true/false ... >> ... > I would suggest to write an I-D about this. > > Thanks. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRu0bxAAoJECnERZXWan7ECRcP/jw5CphA7aO4vizign7o7Kdp > B9xNUuiDB1sV8Vxv/HftIRJmzbXecJLTOj8BuVwZnsTNeZqz7IGJCgRqkaH4Q2sF > HIsHls2OI49T7iIYUu7FNcY1h9PsMO/gtOd2195K4NY16GqluOMisCtwlcopTsBY > /fhNokoQ6SjSMtt02NjxZAxqFyrggZc9f02ig+TXEOHRKG1vxNA/7g6q/h3+mR7j > RNCw2J1kJSZu9fqWIcLWWUSV8GJQevSVHzja88jCxFMd7FrmvkCJ1HJGC7i+/8Q6 > hxyNl/I4v8kBdN/Pn0wK2hBbSPPNIyYvLKGa76nwIeMmSkjmJbbfH4cWLQy2qDqf > OsJIibUyMurOyLf8zWpcorj4z4Y3E/pdXVrzlQ78zCxZ8hxh2Nem9q/xcaAeE9yh > HETN084rkEC0F/9Ro6T/TT2ZCXR8Xc+PYTPAk76dAS2wdQxwQ6wMXbLTIwtOH+Vf > BcbvMXI1qIwJ/Y4l5u7zZ/ype4lcjwZXXr+1iu2k9h2uAOg/REfL7dKRuEmSdOb7 > yVEx6ZuxXDacgBn8uZVyrJvvUdgu8+/sMjAAcajXmW1lyA0ekIViTJPnRsWD7Ax4 > FLQbFzxAdJ6cPUF3EUQ52JosqMM9hAQBXOSfVzXLLAA+XpqVlpMxvktALl8F3zvW > HwUMrudMecpks9f80p0q > =pzTn > -----END PGP SIGNATURE----- Thanks. Polina From petithug@acm.org Sun Jun 16 08:29:07 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678EA21F9B12 for ; Sun, 16 Jun 2013 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USO7v730tA8o for ; Sun, 16 Jun 2013 08:29:06 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8BA21F9A85 for ; Sun, 16 Jun 2013 08:29:06 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:a9ba:caa6:ee0e:ee2b] (unknown [IPv6:2601:9:4bc0:1f:a9ba:caa6:ee0e:ee2b]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1D26C2021B; Sun, 16 Jun 2013 17:29:03 +0200 (CEST) Message-ID: <51BDD9BD.3040704@acm.org> Date: Sun, 16 Jun 2013 08:29:01 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Polina Goltsman References: <517581CF.1060705@student.kit.edu> <51BB46F3.8040303@acm.org> <51BCC1F9.3070902@student.kit.edu> In-Reply-To: <51BCC1F9.3070902@student.kit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Certificates with multiple NodeIds X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Jun 2013 15:29:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Polina, On 06/15/2013 12:35 PM, Polina Goltsman wrote: > Dear Marc, > > Thank you very much for your comments. > > On 14.06.2013 18:38, Marc Petit-Huguenin wrote: Hi Polina, > > Please find below my answers to some of your comments. Note that I am not > a co-author of the spec, so that will be just my opinion. > > On 04/22/2013 11:30 AM, Polina Goltsman wrote: >>>> Hi, >>>> >>>> I have several questions regarding certificates with multiple >>>> NodeIDs. It seems that different parts in the draft contradict each >>>> other. >>>> >>>> First, section 6.6.1 defines requirements for future overlay link >>>> protocols. I suppose, that current overlay link protocol must meet >>>> these requirements. >>>>> Endpoint authentication When a node forms an association with >>>>> another endpoint, it MUST be possible to cryptographically verify >>>>> that the endpoint has a given Node-ID. >>>> Certificates with multiple NodeIDs sometimes violate this >>>> requirement. Unless a connection was formed as a result of exchanging >>>> Attach messages, it is impossible to associate an endpoint and its >>>> NodeID, which is the case when new node connects to BootstrapPeer. As >>>> a consequence several reload requirements are hard or even impossible >>>> to implement IMHO. >>>> >>>> The first requirement is that ConnectionTable SHOULD use some >>>> indexes instead of mapping NodeIds to (D)TLS Connections. > I am not sure where in the spec you found this requirement. >> A have found this requirement in section 6.3.2.2. at the bottom of page >> 53 (-26) > >>> One possible encoding of the 16 bit integer version as an opaque >>> identifier is to encode an index into a Connection Table. >> and so on. This is not a requirement for the management of the Connection Table, just a compression algorithm to reference an entry in the Connection Table in the destination_list. > >> I am not very good at this, but as I understood one must have very good >> reasons not to implement "SHOULD". Yes, but because the entity decoding the 16 bit opaque_id is the same that encode it, it does not matter. There is no interoperability problem that can be created by following or not the SHOULD. IMO, as this cannot create any interoperability issue, the whole paragraph should have been moved to an appendix, as this is more an implementation note, than normative stuff. >>>> The second requirement is in section 6.1.2 >>>>> If a node with a certificate with multiple Node-IDs attempts to >>>>> route a message other than a Ping or Attach through a node without >>>>> performing an Attach, the receiving node MUST reject the request >>>>> with an Error_Forbidden error. The node MUST implement support for >>>>> returning responses to a Ping or Attach request made by a >>>>> joiningnode Attaching to its responsible peer. >>>> The routing decisions must be made based on ForwardingHeader alone, >>>> and a ForwardingHeader does not contain information about type of the >>>> message, being sent. So this is practically NOT implementable. > I agree that there is a layer violation here. > > But this applies only to bootstrap nodes, which anyway require special > processing on their public address, as they accept connections without > Attach. So the special code that parses the message in addition to the > header can be isolated to that special kind of nodes. >> From -base: Section 3.2.1 Client Routing > >> **Clients** may insert themselves in the overlay in two ways: > >> ... > >> (bullet 2)Establish a connection with an arbitrary peer in the overlay > >> ... > >> A **client** connected this way using a certificate with only a single >> Node-ID can proceed to use the connection without performing an Attach >> (Section 6.5.1 ). A **client** wishing to connect using this mechanism >> with a certificate with multiple Node-IDs can use a Ping (Section 6.5.3 ) >> to probe the Node-ID of the node to which it is connected before doing >> the Attach. > > >> Do I understand this wrong, or any client can connect to any peer it >> wants, so the issue is not only with BP. My understanding of this is that an Attach is required to do that, so the special processing really applied only to bootstrap nodes. You can Attach to any node and never send an Update, relying on a stored Destination_list to be reached and the via_list to receive responses, but the initial still have to go through a bootstrap node. > >> Moreover, did I miss a requirement that forbids me to for direct >> connection (without Attach) if I know IP-Address of the Node I wish to >> connect to. (This didn't make it to the -base, did it >> ?https://www.ietf.org/mail-archive/web/p2psip/current/msg05853.html) >> My >> understanding is that you cannot directly connect to a random node. You always have to do through a bootstrap node. Note that this understanding seems to contradict 11.4. IMO the whole 11.4 should have been removed, as there is no way to be sure 100% that an IP address can be directly reached. Caching peers to serve as future bootstrap nodes would require to use a TURN server to contact them. And as you said, it increase the load on all node as they all can be bootstrap candidates. >>>> Section 3.2.1 Bullet 2 - about Clients, that connect to peers >>>>> A client connected this way using a certificate with only a single >>>>> Node-ID can proceed to use the connection without performing an >>>>> Attach (Section 6.5.1). A client wishing to connect using this >>>>> mechanism with a certificate with multiple Node-IDs can use a Ping >>>>> (Section >6.5.3) to probe the Node-ID of the node to which it is >>>>> connected before doing the Attach. >>>> As far as I understand, the procedure is as follows. The peer in >>>> the overlay, that listens on some known port, receives a connection >>>> from a client. This connection is in some unknown state because >>>> NodeId of at least one endpoint is not known. Then, the client must >>>> send a PingReq to the wildcard NodeId. It will be consumed by the >>>> peer as the next endpoint. > Not sure what you mean by next endpoint. The Ping will be answered by > this peer, returning a SecureBlock containing the Certificate of this > peer. >> Exactly this. I mean endpoint as in the "endpoint of connection or link" >>>> Once the client has learned the peer's NodeID, it may send Attach, >>>> with, as I suppose, one static candidate. The peer must somehow find >>>> out that this static candidate is the connection, that is already >>>> formed and do not try to form it again. > My understanding is that the Attach creates a new connection and that the > first one is closed. But this is underspecified so this will create an > interoperability problem. > >>>> (Moreover the Attach section doesn't state what to do if the >>>> connection is already formed. This is also essential for the topology >>>> plugin, since some node may already have an opened connection with >>>> its new neighbour (consider peer-ready update), but in that case >>>> NodeIds are known and connection table can be searched). >>>> >>>> In my opinion, both client and peer could learn each other's NodeIDs >>>> from the Ping. Both PingReq and PingAns are signed and thus uniquely >>>> identify its senders. Since the connection to the client is in some >>>> unknown state and the destination was wildcard NodeID, the peer can >>>> assume that the sender of this message is another endpoint of this >>>> connection. The peer can also compare the client's certificate with >>>> the one, used to form TLS association. >>>> >>>> >>>> >>>> Another question, that I have, is shared-secret admission schemes for >>>> TLS. The TLS-PSK RFC states, that in case of TLS-PSK certificate >>>> exchange is optional. It is unclear from the RFC, that PSK ciphers >>>> with certificate exchange must be selected. > I think it is clearly stated in 1.3 that certificate must be used with > TLS-PSK in the context of RELOAD: > > "This feature is used together with certificate-based access control, not > as a replacement for it." > >> The point is that IMHO it(together with 3.2.1) should be specified >> somewhere after section 5. Yes, the whole shared-secret/TLS-PSK/TLS-SRP/self-signed-certificate is underspecified. A good candidate for an Internet-Draft. >>>> It is also unclear, what should be sent in TLS-PSK identity field - >>>> username, NodeID, both or nothing. As of TLS-SRP RFC the client >>>> certificate cannot be requested. > The identity field is used to select a specific key, when there is a > choice between different keys. In the case of RELOAD I suppose that having > multiple keys does not make sense so that field (and so the > ServerKeyEchange record) should be omitted. >> Thank you very much for the explanation. Do you think it should be >> specified, that this key SHOULD be omitted? >>>> I also can imagine two possible solutions to the first problem. >>>> >>>> Solution 1(undesirable): Have a specified way of finding out peer's >>>> identity. If one of the certificates had multiple NodeIds, the first >>>> message, that is sent over this connection must identified both >>>> peers. This can be Ping, Attach or some dedicated "HelloReq" and it >>>> works as described above. After this exchange both peers must update >>>> their connection tables with NodeIDs of the endpoints. >>>> >>>> This solution is undesirable, since it increases message load on >>>> bootstrap nodes. > AFAIK, this is how things are suppose to work in RELOAD. Note that the > increased load is only when joining the overlay, so that seems like normal > workload to me. > > https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html >> 1) This would increase load on the Bootstrap Peer, which IMHO is not >> desirable. 2) From your message: * *>Because there is no Attach, the peer >> has to spy on the first message sent by the > >> client to extract the Node-ID from the SignerIdentity and "label" the >> newly created connection in the connection table. > > >> Well, it was not that obvious to me. Was there a reason why it didn't >> make it to the -base? None that I can think of. Again a good candidate for an Internet-Draft. > >> I believe it is relatively hard to spy on the messages, that are routed >> through, since they can be fragmented. So IMHO the first message should >> be destined to the connection endpoint. >>>> Solution 2: Use TLS Extension to exchange not only the certificates, >>>> but also NodeID (in some form, e.g. the cert_hash_node_id form) >>>> during the TLS connection. > Yes, I proposed something like this back in 2011: > > https://www.ietf.org/mail-archive/web/p2psip/current/msg05856.html > > That was not the solution selected by the authors. > >>>> The extension can use SupplementaryData [RFC 4680 >>>> ] to exchange the actual NodeID. >>>> For example: struct { SupplementalDataType supp_data_type; uint16 >>>> supp_data_length; select(SupplementalDataType) { case >>>> reload_signer_identity: SignerIdentity } } SupplementalDataEntry; >>>> >>>> The 2 extensions, that look most suitable are: 1. user-mapping [RFC >>>> 4681]. The information, that is >>>> sent, is exactly what is needed,but the RFC defines only client's >>>> authentication, not the server's. 2. serverautz/clientauthz [RFC >>>> 5878 ]. This RFC is not >>>> standard. >>>> >>>> I also want to propose more precise way for configuring TLS >>>> connection, by using a dedicated section and overlay-config for >>>> configuring underlay link layer for reload. For example, for TLS this >>>> would be: normal/PSK/SRP >>>> true/false >>>> ... >>>> ... > I would suggest to write an I-D about this. > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRvdm4AAoJECnERZXWan7E2t0P/3oMLqD3lWw6f4gLMN/vf2hI qSTzKHnumRofBEgaYSeo7cqIH2RXEmDpI5b0wXnCPYsorLJp73nZD8esEAq2csom kd0xkXYUVDV7V/xNVB82ZhWhD0PJylJhunnLUcwmOhmaDzP2IqXkunfz+y0dvCBT zEGN53TfOF5sjJ/GdtMKZWoYpyfIEZ6aVDMVyuCmGvvn8Yaz15RjNFnpd8zgqC0P xdP8KVSYUE5FZuPe5nTKnRIT12wjMbauuVw+awuSsBr9bfkwaLHvqGxDv/2TR2YI 2yunV253hmIzdeqQziHsvcoShYjKN0VQ3An2X69BIi3aF7w7DpkvSdEoYVrnP+G1 Dmy/9srdbhDagPAgJ4cTOgNde2jjODMTyL/VlnX+GGH8Ui48DHPK55My5XS7l3wf H/1iO79JSB2XBDbicoXWUl51rdNqPX4v/cbl/A1bofAtUVXVLBSLSgnESBdpuSkI myjGuf2gyFUnBuURlfHy7Ni1ELecscbKZSJz2yfDpwKyJEKHkmsnLBxJmZG4/Alx PLRGUybgGoHguhxMQH886FOsGKQW5CivYKEjvOJEifm+yUuykfArJGc5pbfBBEFh RL0L6huqUkhdvLLzXcYc7bmKyyEkucS0fkpbPcw6WVkrJHtY6b3xvH7jYG2JldTM y1XU3AkmhfTNVQajv1wy =lF1v -----END PGP SIGNATURE----- From prvs=58807390b2=gonzalo.camarillo@ericsson.com Mon Jun 17 04:46:48 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80E821F9A93 for ; Mon, 17 Jun 2013 04:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.71 X-Spam-Level: X-Spam-Status: No, score=-105.71 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvcYec8l3Bis for ; Mon, 17 Jun 2013 04:46:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2B50321F96D9 for ; Mon, 17 Jun 2013 04:46:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-b3-51bef7209782 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EF.D1.09795.027FEB15; Mon, 17 Jun 2013 13:46:40 +0200 (CEST) Received: from [131.160.36.46] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 17 Jun 2013 13:46:40 +0200 Message-ID: <51BEF71F.2090502@ericsson.com> Date: Mon, 17 Jun 2013 14:46:39 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBJMWRmVeSWpSXmKPExsUyM+Jvra7C932BBtvvilosuXmG0YHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BlXZj5lKuhnqfjS/ZqpgXEfcxcjJ4eEgInE0ekHmSBsMYkL 99azdTFycQgJnGKUuDp/OyOEs5pRovPkbLAqXgFticNnZrOD2CwCqhJ996+ygdhsAhYSW27d ZwGxRQWiJOase8AGUS8ocXLmE6A4B4eIgKbEnFuBIGFhgQiJ9uuXWSEWS0psedEONpJZQE9i ytUWRghbXmL72zlghwoBrV3+rIVlAiP/LCRTZyFpmYWkZQEj8ypG9tzEzJz0cvNNjMCAOrjl t8EOxk33xQ4xSnOwKInzfjq1K1BIID2xJDU7NbUgtSi+qDQntfgQIxMHJ4jgkmpgbKsIOrc6 v0Nnv8/Lk521kvax1Ueu8vC5zP76vD2x0+AvwyMxERPLiSc0fatb/B6q3/6nad2ZX8FnInR5 3T3uhPkrTx99esR7O980845b3wrO7w2ZJ7Bt6gcOzvSt1c5/i6cpF3+6qbBM8UBZ4JLpJ5Z9 Nfa/rsR0935hfds7gUWOHy11TkZ9UmIpzkg01GIuKk4EANy0jv37AQAA Subject: [P2PSIP] References to concepts draft in draft-ietf-p2psip-rpr and draft-ietf-p2psip-drr X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 11:46:48 -0000 Hi, both of these drafts (in the publication requested state) have informative references to the concepts draft: http://www.ietf.org/id/draft-ietf-p2psip-rpr-07.txt http://www.ietf.org/id/draft-ietf-p2psip-drr-07.txt Given that both draft state that they use the terminology defined in the concepts draft "extensively", shouldn't those references be normative? That is, downrefs. Also, what is the status of the concepts draft? http://tools.ietf.org/html/draft-ietf-p2psip-concepts-04 Thanks, Gonzalo From prvs=0880fa0e3b=gonzalo.camarillo@ericsson.com Mon Jun 17 05:02:21 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372521F9992 for ; Mon, 17 Jun 2013 05:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.8 X-Spam-Level: X-Spam-Status: No, score=-105.8 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNnoST6lGquw for ; Mon, 17 Jun 2013 05:02:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 391D521F9A97 for ; Mon, 17 Jun 2013 05:02:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-90-51befac413ba Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7A.A2.15700.4CAFEB15; Mon, 17 Jun 2013 14:02:13 +0200 (CEST) Received: from [131.160.36.46] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 17 Jun 2013 14:02:13 +0200 Message-ID: <51BEFAC4.3050302@ericsson.com> Date: Mon, 17 Jun 2013 15:02:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOJMWRmVeSWpSXmKPExsUyM+Jvre7RX/sCDTa9ZbNYcvMMowOjx5Il P5kCGKO4bZISS8qCM9Pz9O0SuDPmXtrHWrCOqaJhahNTA+NPxi5GTg4JAROJJQ1vWSFsMYkL 99azgdhCAqcYJd5Nd+1i5AKyVzNKnJgyH6yIV0Bbomv5fjCbRUBVYsna82ANbAIWEltu3WcB sUUFoiTmrHvABlEvKHFy5hOgOAeHiICmxJxbgSBhYQFziV0/N7JB7JWU2PKinR3EZhbQk5hy tYURwpaX2P52DjPEPdoSy5+1sExg5J+FZOosJC2zkLQsYGRexciem5iZk15uuIkRGE4Ht/zW 3cF46pzIIUZpDhYlcd4Pp3YFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uAEEVxSDYwSFkyN9yKN 8nY+kzEJlFF9+XR/yacNT/ISD1UyeSbyNEjxZnTu1TRdtZHd/Ncmnsvx5T9Kw2pualjGp1m/ WvFLdYPH9tb8CY2VEQtzIyySDMq0TH/9lWDqyP5ZILvuufs3U/8kXTW5/x1XbxdeeXFQ9sDV i9+uLQl/H3hdd+/KCRtrHyR2zFNiKc5INNRiLipOBADvi6ka+gEAAA== Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 12:02:22 -0000 Folks, Appendix A of the following draft describes how a node can obtain IP addresses on which it may be reached: http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A Have you taken into account the UNSAF considerations? http://tools.ietf.org/html/rfc3424 Cheers, Gonzalo From michaelc@idssoftware.com Fri Jun 21 10:08:21 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4021F9F08 for ; Fri, 21 Jun 2013 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1S5EglOqLoJ for ; Fri, 21 Jun 2013 10:08:15 -0700 (PDT) Received: from p3plwbeout03-01.prod.phx3.secureserver.net (p3plsmtp03-01-2.prod.phx3.secureserver.net [72.167.218.213]) by ietfa.amsl.com (Postfix) with ESMTP id 544D921F9F30 for ; Fri, 21 Jun 2013 10:08:15 -0700 (PDT) Received: from localhost ([72.167.218.244]) by p3plwbeout03-01.prod.phx3.secureserver.net with bizsmtp id r58D1l0015GyNsw0158DDe; Fri, 21 Jun 2013 10:08:13 -0700 X-SID: r58D1l0015GyNsw01 Received: (qmail 5152 invoked by uid 99); 21 Jun 2013 17:08:13 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_aa142345cd5e317df2d7fe2a788d0837" To: "Marc Petit-Huguenin" From: "Michael Chen" Date: Fri, 21 Jun 2013 10:08:13 -0700 Message-Id: <20130621100813.59ca11a9ba9389561a029f06442e67fa.e623a2cc5a.mailapi@email03.secureserver.net> X-Originating-IP: 172.249.4.226 User-Agent: MailAPI 24670 X-Sender: michaelc@idssoftware.com Cc: p2psip@ietf.org Subject: [P2PSIP] Enrollment server handling base64 encoded csr parameter X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:08:21 -0000 --=_aa142345cd5e317df2d7fe2a788d0837 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Marc, =20 A bug in my program sent the following multi-part header followed by the pk= cs10 DER binary, but your server ignored the transfer encoding header and p= rocessed the csr: =20 --0xD2454C4F Content-Disposition: form-data; name=3D"csr" Content-Type: application/pkcs10 Content-Transfer-Encoding: base64 =20 =20 --0xD2454C4F RFC2311 (referenced in section 11.3 of p2psip-base) does describe the use o= f base64 encoded application/pkcs10 content type (3.7.2). The p2psip-base d= raft should either endorse or explicitly exclude the base64 encoding stated= in RFC2311. =20 Thanks =20 --Michael --=_aa142345cd5e317df2d7fe2a788d0837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Marc,
 
A bug in my program sent the following multi-part header followed by t= he pkcs10 DER binary, but your server ignored the transfer encoding header = and processed the csr:
 
--0xD2454C4F
Content-Disposition: form-data; name=3D"csr"
Content-Type: applic= ation/pkcs10
Content-Transfer-Encoding: base64
 
<CSR DER binary>
 
--0xD2454C4F

RFC2311 (referenced in section 11.3 of p2psip-base) does describ= e the use of base64 encoded application/pkcs10 content type (3.7.2). The p2= psip-base draft should either endorse or explicitly exclude the base64 enco= ding stated in RFC2311.
 
Thanks
 
--Michael
--=_aa142345cd5e317df2d7fe2a788d0837-- From petithug@acm.org Fri Jun 21 10:51:25 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9344521F9BFA for ; Fri, 21 Jun 2013 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8icX50XSGnN for ; Fri, 21 Jun 2013 10:51:24 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 441A121F9948 for ; Fri, 21 Jun 2013 10:51:23 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:41:cc99:88ae:cf1a:af93] (unknown [IPv6:2601:9:4bc0:41:cc99:88ae:cf1a:af93]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E02E72021A; Fri, 21 Jun 2013 19:51:21 +0200 (CEST) Message-ID: <51C49297.5010407@acm.org> Date: Fri, 21 Jun 2013 10:51:19 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Michael Chen References: <20130621100813.59ca11a9ba9389561a029f06442e67fa.e623a2cc5a.mailapi@email03.secureserver.net> In-Reply-To: <20130621100813.59ca11a9ba9389561a029f06442e67fa.e623a2cc5a.mailapi@email03.secureserver.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Enrollment server handling base64 encoded csr parameter X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:51:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Michael, On 06/21/2013 10:08 AM, Michael Chen wrote: > Hi Marc, > > A bug in my program sent the following multi-part header followed by the > pkcs10 DER binary, but your server ignored the transfer encoding header and > processed the csr: > > --0xD2454C4F Content-Disposition: form-data; name="csr" Content-Type: > application/pkcs10 Content-Transfer-Encoding: base64 > > > > --0xD2454C4F > > RFC2311 (referenced in section 11.3 of p2psip-base) does describe the use > of base64 encoded application/pkcs10 content type (3.7.2). The p2psip-base > draft should either endorse or explicitly exclude the base64 encoding > stated in RFC2311. > Hmm, RFC 2616 states in section 19.4.5: HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client. On the other hand RFC 2388 has an example using CTE: --AaB03x content-disposition: form-data; name="field1" content-type: text/plain;charset=windows-1250 content-transfer-encoding: quoted-printable Joe owes =80100. --AaB03x Perhaps what RFC 2616 meant was that CTE cannot be used as an header, but can be used as a MIME parameter. But as HTTP never had any 7bit/8bit issues, I doubt it. For the sake of interoperability, I filled a bug to add support for CTE in form-data my server. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRxJKPAAoJECnERZXWan7EFHUP/3LFuKBZ/mQZRVfIvlVUR4g0 6ZGrXMmZ0szR/S1LGBtN2Rwp/UdLqGo1EN0rP75ZtGQefJJ3MzMbFi6mE4kgPOLj cthl11+SbbpJKUDL8MJHGWrMsYUPX0DASs7+Si/nqKCigm4INkhkOngnoB4D5x6N DetwUvbsmnmxejwWbiOTQ0YdHSI1F4el8R4T6S3cRgGCHSNKADP0fd7T14mxYPpH 1Lgnr4WI6jczovLl//314S45g7vgSvMUtiRkjURON6lLD1GTb+6/sB9yTZ0lftEe qxRXRf226VHVyVHjgEh+giCSCpDCbql8ny+q43IFZWtoMv4IXo+NiTiMALwIvfwp NmmYObyFrbEjZC582xV2rIZSF/MgWad91p0BChwQ0gP7PaxkMQdZWqK1Uv58aszZ AW+6YGu9yhzmoi9FO3uFLlab+wElD4JiNHj7BdbbghJW2Pkcrubg0uj4OJoqSuYM uj4Ilj9IJtf4BGG1aOBM2SS+feIXhVomAVW9JiW9x3mqAMErSzoYjT7bR5Vgtxbo c20sviT3lYp2bGqPPAUNz+85adsMaz6gIZyzaGsivQnk4zI/uwxkaSj0NUXzoOgv VDLk/yo1KfDx+r6NTP3PIgpLW3nfLvHDw/8rGPeLhLNVMW8HOp5HrBHAeJDbGGIW 2xpEV4fpnTZZ/3zpI0gi =WhEI -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Sun Jun 23 08:30:02 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95C21F9B58 for ; Sun, 23 Jun 2013 08:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmOhUMsPis79 for ; Sun, 23 Jun 2013 08:30:02 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3821F9B8D for ; Sun, 23 Jun 2013 08:30:01 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so7671147wev.28 for ; Sun, 23 Jun 2013 08:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=KeYpp2P2iuuDOYVFUWivzHszJOQKVytHts9LSlyPoAo=; b=i2MRE9/uAt78zLCDBUXBZE+h5Fxd6y7ZFGMnUSiNYWFminS9nNS4E4RbJf/iWUOSkn DuH4DeuEVGcBhoyu0ktPqz1oYk24evmd6QwYJVe7vo4SZwSsssVi0xY5V8Q06R04bbki eyexXEe8EmcPM3x8WSTWG2U/15SwFUsfzMZDzUKulLxuVL8tDaWaG4YCiF3vBwB5m8io PChorX7gC5MypCip8VzjFQnpxIRomBdD7BXJhr8oMjfHGnK9ek7feHMdSotwPmgtfDqQ sR/07cHcc97mCSJIilu0EFroVq/nCj0MpZ/p9KXybnXLD0GmF6r1cGz5FRM7TooWQTKb mZ8w== X-Received: by 10.180.160.165 with SMTP id xl5mr1885309wib.46.1372001400785; Sun, 23 Jun 2013 08:30:00 -0700 (PDT) Received: from RoniE ([109.67.214.161]) by mx.google.com with ESMTPSA id dz8sm10559565wib.11.2013.06.23.08.29.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Jun 2013 08:29:59 -0700 (PDT) From: "Roni Even" To: "'Gonzalo Camarillo'" , "'P2PSIP Mailing List'" References: <51BEFAC4.3050302@ericsson.com> In-Reply-To: <51BEFAC4.3050302@ericsson.com> Date: Sun, 23 Jun 2013 18:28:35 +0300 Message-ID: <004b01ce7026$55930650$00b912f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIYXbTplAIujxtiKDGzj7ujRdtuuJivjTIA Content-Language: en-us Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Jun 2013 15:30:02 -0000 Hi Gonzalo, Thanks for point out to RFC3424. How about adding to the following sentence an informative reference to RFC3424. Note that appendix A is not creating an UNSAF proposal but just mentions some methods for informational purpose. Suggest adding to "Note that there is no foolproof way to determine if a peer is publically reachable, other than via out-of-band mechanisms." to "Note that there is no foolproof way to determine if a peer is publically reachable, other than via out-of-band mechanisms. For discussion about issues with address evaluation also see UNSAF [RFC3424]" I am not sure if it adds much information but it may be good to have this reference Roni Even > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > Sent: 17 June, 2013 3:02 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr > > Folks, > > Appendix A of the following draft describes how a node can obtain IP > addresses on which it may be reached: > > http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A > > Have you taken into account the UNSAF considerations? > > http://tools.ietf.org/html/rfc3424 > > Cheers, > > Gonzalo > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From gonzalo.camarillo@ericsson.com Mon Jun 24 01:13:15 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1539C21F9A70 for ; Mon, 24 Jun 2013 01:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.084 X-Spam-Level: X-Spam-Status: No, score=-106.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sivdORc7xIC for ; Mon, 24 Jun 2013 01:11:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B2DF221F8411 for ; Mon, 24 Jun 2013 01:11:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-dd-51c7ff295344 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 64.CF.09795.92FF7C15; Mon, 24 Jun 2013 10:11:22 +0200 (CEST) Received: from [131.160.36.49] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 24 Jun 2013 10:11:21 +0200 Message-ID: <51C7FF29.9070901@ericsson.com> Date: Mon, 24 Jun 2013 11:11:21 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <51BEFAC4.3050302@ericsson.com> <004b01ce7026$55930650$00b912f0$@gmail.com> In-Reply-To: <004b01ce7026$55930650$00b912f0$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vlfr//FAg/WP2S2W3DzDaPG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyph+4BFzwW3hir7frA2M//i7GDk5JARMJJof PmGEsMUkLtxbz9bFyMUhJHCKUeLijessEM5qRomufx0sIFW8AtoSV5cfZAaxWQRUJT5/OArW zSZgIbHl1n2wGlGBKIk56x6wQdQLSpyc+QQsLiKgJvF67WegOAcHM9CcR599QcLCAi4Sm47+ ARspJBAu0XL+KlgJJ9DI1odKELdJSmx50c4OYjML6ElMudrCCGHLS2x/OweqVVti+bMWlgmM QrOQLJ6FpGUWkpYFjMyrGNlzEzNz0svNNzECg/Tglt8GOxg33Rc7xCjNwaIkzvvp1K5AIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwHa1Zs28DByrkjOFls6hOnJdOLLPZLeHVYiIk/fMbW 33ZSMuG50WIzGY5vs3wyZ/BFvTDNuiL4LeKVvFz5Md7Ljk8Fv8nxeG+827X/lbdc38PO7O7A PGa3EKNPZ0/PCp9kdnuH7Znn3xRMNj+0TVPrU571X+nQz2vP+NtzArpZ1VU3fnH2MFZiKc5I NNRiLipOBAD+1AllIAIAAA== Cc: 'P2PSIP Mailing List' Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 08:13:15 -0000 Hi Roni, I think the draft should discuss in more detail how a node makes the decision of attempting to use DRR and what are the trade-offs. The case of closed or managed networks is clear. The draft can mention that an administrator simply configures nodes to use DRR because the administrator knows, somehow, that it will work fine. In open networks, the draft should discuss the trial and error system being proposed. For example, a node without a public IP address may be able to communicate directly with a node in the same non-public address space. That case is not covered by the discussions about UNSAF mechanisms. The whole point about developing ICE was that UNSAF mechanisms do not work in many situations. In short, this is an important interoperability issue because it relates to when a node should use one mechanism or another. Therefore, the draft should discuss all the implications of the proposed mechanism carefully. Thanks, Gonzalo On 23/06/2013 6:28 PM, Roni Even wrote: > Hi Gonzalo, > Thanks for point out to RFC3424. > How about adding to the following sentence an informative reference to > RFC3424. Note that appendix A is not creating an UNSAF proposal but just > mentions some methods for informational purpose. > > Suggest adding to "Note that there is no foolproof way to determine if a > peer is publically reachable, other than via out-of-band mechanisms." to > > "Note that there is no foolproof way to determine if a peer is publically > reachable, other than via out-of-band mechanisms. For discussion about > issues with address evaluation also see UNSAF [RFC3424]" > > I am not sure if it adds much information but it may be good to have this > reference > > Roni Even > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf >> Of Gonzalo Camarillo >> Sent: 17 June, 2013 3:02 PM >> To: P2PSIP Mailing List >> Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr >> >> Folks, >> >> Appendix A of the following draft describes how a node can obtain IP >> addresses on which it may be reached: >> >> http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A >> >> Have you taken into account the UNSAF considerations? >> >> http://tools.ietf.org/html/rfc3424 >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From ron.even.tlv@gmail.com Mon Jun 24 01:59:54 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E02321E8082 for ; Mon, 24 Jun 2013 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhK78oemUI1G for ; Mon, 24 Jun 2013 01:59:53 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D821F9B5C for ; Mon, 24 Jun 2013 01:59:52 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so8094767wes.1 for ; Mon, 24 Jun 2013 01:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=zdW5uZMfIN5rsd51VfLJ+4LbI6xS3pFoE6jz2Wkedwc=; b=lWVFPn1LqviUsoID6gNr7d5FdL0BOhekq4q2J2U1oIdlij9S0Y1IU7GA3fvS8pT/vY aackNPsnl/QR+8Z6CrveCr573A3KdbuT9HFkh3s+2JrBCZIR74qi1H0AvSVEK28H5FRl AzaX75cNKTOJTeXVMZ/nqaTkwegCDgCMqOzoU4xzPi+6Pf12x2obL3CJj6etXzzDT/ro Sz/KFG24sd60bOQxgnQ1gNrsLQEC952kho/ySV/qfinckp+qrEiZc/IIMYTjuOPx+xf1 ZsJp6RXaRwc+/JcJZKUPWqk+16zqSI9eit0apnwoew8f+sXPl5WH9cVK8o7pi8lIQ6R3 +Weg== X-Received: by 10.194.9.101 with SMTP id y5mr15836857wja.86.1372064390657; Mon, 24 Jun 2013 01:59:50 -0700 (PDT) Received: from RoniE ([109.67.214.161]) by mx.google.com with ESMTPSA id fo10sm14965358wib.8.2013.06.24.01.59.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Jun 2013 01:59:49 -0700 (PDT) From: "Roni Even" To: "'Gonzalo Camarillo'" References: <51BEFAC4.3050302@ericsson.com> <004b01ce7026$55930650$00b912f0$@gmail.com> <51C7FF29.9070901@ericsson.com> In-Reply-To: <51C7FF29.9070901@ericsson.com> Date: Mon, 24 Jun 2013 11:58:23 +0300 Message-ID: <008401ce70b8$fd5ff220$f81fd660$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIYXbTplAIujxtiKDGzj7ujRdtuuAJhEpsoAcEy7MSYj6MH8A== Content-Language: en-us Cc: 'P2PSIP Mailing List' Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 08:59:54 -0000 Hi Gonzalo, During the WG discussion we were asked to have in the main body just the case of manage networks and leave in the informational appendix A some informational text about finding routable addresses since it was clear that there is no guarantee that it will work. I do not think that it is the purpose of this document to discuss the whole topic of finding routable addresses, we are just pointing at available options. The idea is that there is always a fall back to SRR Roni > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 24 June, 2013 11:11 AM > To: Roni Even > Cc: 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr > > Hi Roni, > > I think the draft should discuss in more detail how a node makes the decision > of attempting to use DRR and what are the trade-offs. The case of closed or > managed networks is clear. The draft can mention that an administrator > simply configures nodes to use DRR because the administrator knows, > somehow, that it will work fine. > > In open networks, the draft should discuss the trial and error system being > proposed. For example, a node without a public IP address may be able to > communicate directly with a node in the same non-public address space. > That case is not covered by the discussions about UNSAF mechanisms. The > whole point about developing ICE was that UNSAF mechanisms do not work > in many situations. > > In short, this is an important interoperability issue because it relates to when > a node should use one mechanism or another. Therefore, the draft should > discuss all the implications of the proposed mechanism carefully. > > Thanks, > > Gonzalo > > > > On 23/06/2013 6:28 PM, Roni Even wrote: > > Hi Gonzalo, > > Thanks for point out to RFC3424. > > How about adding to the following sentence an informative reference to > > RFC3424. Note that appendix A is not creating an UNSAF proposal but > > just mentions some methods for informational purpose. > > > > Suggest adding to "Note that there is no foolproof way to determine if > > a peer is publically reachable, other than via out-of-band > > mechanisms." to > > > > "Note that there is no foolproof way to determine if a peer is > > publically reachable, other than via out-of-band mechanisms. For > > discussion about issues with address evaluation also see UNSAF [RFC3424]" > > > > I am not sure if it adds much information but it may be good to have > > this reference > > > > Roni Even > > > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > >> Behalf Of Gonzalo Camarillo > >> Sent: 17 June, 2013 3:02 PM > >> To: P2PSIP Mailing List > >> Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr > >> > >> Folks, > >> > >> Appendix A of the following draft describes how a node can obtain IP > >> addresses on which it may be reached: > >> > >> http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A > >> > >> Have you taken into account the UNSAF considerations? > >> > >> http://tools.ietf.org/html/rfc3424 > >> > >> Cheers, > >> > >> Gonzalo > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > From gonzalo.camarillo@ericsson.com Mon Jun 24 03:08:08 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9A21E80D6 for ; Mon, 24 Jun 2013 03:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.093 X-Spam-Level: X-Spam-Status: No, score=-106.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhxM2pCTPGoD for ; Mon, 24 Jun 2013 03:08:02 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 97DFF21E80D0 for ; Mon, 24 Jun 2013 03:08:01 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-85-51c81a803c7b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D1.D0.09795.08A18C15; Mon, 24 Jun 2013 12:08:00 +0200 (CEST) Received: from [131.160.36.49] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 24 Jun 2013 12:07:57 +0200 Message-ID: <51C81A7C.7030404@ericsson.com> Date: Mon, 24 Jun 2013 13:07:56 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <51BEFAC4.3050302@ericsson.com> <004b01ce7026$55930650$00b912f0$@gmail.com> <51C7FF29.9070901@ericsson.com> <008401ce70b8$fd5ff220$f81fd660$@gmail.com> In-Reply-To: <008401ce70b8$fd5ff220$f81fd660$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+JvrW6D1IlAg82X9SyW3DzDaPG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyvh39DNLwQ35iinnl7A3MF6U7GLk5JAQMJGY /PQPO4QtJnHh3nq2LkYuDiGBU4wSP0+8Z4RwVjNKPN27nBmkildAW+LAnWtgNouAqsTNZRdZ QWw2AQuJLbfus4DYogJREnPWPWCDqBeUODnzCVhcREBN4vXaz0BxDg5moDmPPvuChIUFXCQ2 Hf3DDLFrMaPEzH1rwXo5gWZe/X2YGeI6SYktL9rBLmUW0JOYcrWFEcKWl9j+dg5YjRDQzOXP WlgmMArNQrJ6FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAzVg1t+G+xg3HRf7BCjNAeLkjjvp1O7 AoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwNh/KLWGf+Os837nLt+7VP7/bZi8kf68ss/nt y/q6M8zqpyYmfDp+iYHVX7fzsq6t1p72+NDyx8zcE1u+bFC3dIgqj/z0IlrgbrOMOlu+7nRf xeONrZeW3rJ8dPCgk7rjtOnxUpdzJm4+cHL1lUM7Ty6+ZXjvVIoBU1Z/5cusTaXCDP/X3ppc p8RSnJFoqMVcVJwIAIYf9/AjAgAA Cc: 'P2PSIP Mailing List' Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 10:08:08 -0000 Hi Roni, sure, the purpose of this document is not to create a new ICE type of mechanism, I agree. Nevertheless, the document needs to be clear about the options implementers and administrators have. That is, what is likely to work, what is not likely to work, special cases (e.g., when two nodes are in the same private address space), etc. That is the type of (brief) discussion I would like to see in the draft. When it comes to the definition of the mechanisms themselves, I am OK with them as they are. Thanks, Gonzalo On 24/06/2013 11:58 AM, Roni Even wrote: > Hi Gonzalo, > During the WG discussion we were asked to have in the main body just the > case of manage networks and leave in the informational appendix A some > informational text about finding routable addresses since it was clear that > there is no guarantee that it will work. I do not think that it is the > purpose of this document to discuss the whole topic of finding routable > addresses, we are just pointing at available options. The idea is that there > is always a fall back to SRR > Roni > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: 24 June, 2013 11:11 AM >> To: Roni Even >> Cc: 'P2PSIP Mailing List' >> Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr >> >> Hi Roni, >> >> I think the draft should discuss in more detail how a node makes the > decision >> of attempting to use DRR and what are the trade-offs. The case of closed > or >> managed networks is clear. The draft can mention that an administrator >> simply configures nodes to use DRR because the administrator knows, >> somehow, that it will work fine. >> >> In open networks, the draft should discuss the trial and error system > being >> proposed. For example, a node without a public IP address may be able to >> communicate directly with a node in the same non-public address space. >> That case is not covered by the discussions about UNSAF mechanisms. The >> whole point about developing ICE was that UNSAF mechanisms do not work >> in many situations. >> >> In short, this is an important interoperability issue because it relates > to when >> a node should use one mechanism or another. Therefore, the draft should >> discuss all the implications of the proposed mechanism carefully. >> >> Thanks, >> >> Gonzalo >> >> >> >> On 23/06/2013 6:28 PM, Roni Even wrote: >>> Hi Gonzalo, >>> Thanks for point out to RFC3424. >>> How about adding to the following sentence an informative reference to >>> RFC3424. Note that appendix A is not creating an UNSAF proposal but >>> just mentions some methods for informational purpose. >>> >>> Suggest adding to "Note that there is no foolproof way to determine if >>> a peer is publically reachable, other than via out-of-band >>> mechanisms." to >>> >>> "Note that there is no foolproof way to determine if a peer is >>> publically reachable, other than via out-of-band mechanisms. For >>> discussion about issues with address evaluation also see UNSAF > [RFC3424]" >>> >>> I am not sure if it adds much information but it may be good to have >>> this reference >>> >>> Roni Even >>> >>>> -----Original Message----- >>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: 17 June, 2013 3:02 PM >>>> To: P2PSIP Mailing List >>>> Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr >>>> >>>> Folks, >>>> >>>> Appendix A of the following draft describes how a node can obtain IP >>>> addresses on which it may be reached: >>>> >>>> http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A >>>> >>>> Have you taken into account the UNSAF considerations? >>>> >>>> http://tools.ietf.org/html/rfc3424 >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >