From nobody Wed Apr 8 16:00:38 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DF61A9144 for ; Wed, 8 Apr 2015 16:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJdnDig-cDyn for ; Wed, 8 Apr 2015 16:00:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489F71A9142 for ; Wed, 8 Apr 2015 16:00:31 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3903020A45 for ; Wed, 8 Apr 2015 19:00:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 08 Apr 2015 19:00:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=zrmBh k32DfWzJV3IFfovwNzOgtY=; b=TabwmdRGS9NPh5bspuKeu5IzPbQBDk16OZg6n xvf+JlmjhfEaLiwAN7500faj7e1lv7KOaxkGVmn6l6zVS3DNVi4FXNyiF7/lwcAj WX8iIOaCxXkE2vOGp8bBJ8xEuLhGDM9oLANeD71JPu9F3vjaaaikcwSEE5wfb9So EGYIo0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=zrmBhk32DfWzJV3IFfovwNzOgtY=; b=uEQIu hJzhqMDh0Mj3tukPiF07RVhCczDzFglbsDwt07DYnQMFxgcwxXXgAHKFEr2jwxvj lixokJ+OD/jU4xUvV+sv52I7qi8mFQa296tBjlPg5TU00eS2/xH44PWXY2YZLz2w 0UToKDc54tLL5Bvhz/hfKcVYUpv88eyl4m2Q1I= X-Sasl-enc: IIBZZPMIuKPTzCZwLYP5SbHlOhGc3t2kWtPR7gMcLHIl 1428534029 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 8EF84680125; Wed, 8 Apr 2015 19:00:28 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EC4E9440-F9DB-464C-8B5B-F537593E4532" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54C8C1EA.1060809@acm.org> Date: Wed, 8 Apr 2015 16:00:26 -0700 Message-Id: References: <1422384846.2887.44.camel@it.uc3m.es> <54C8C1EA.1060809@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:00:36 -0000 --Apple-Mail=_EC4E9440-F9DB-464C-8B5B-F537593E4532 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Marc was the only person who responded to this WGLC. Please send mail to = the list by April 20 if you have read this document and support its = publication. Otherwise the document will be abandoned. Alissa On Jan 28, 2015, at 3:03 AM, Marc Petit-Huguenin = wrote: > Signed PGP part > I reviewed this document multiple times and I believe that it is ready = to be submitted to the IESG. >=20 > Thanks. >=20 > On 01/27/2015 11:54 AM, Carlos Jes=FAs Bernardos Cano wrote: > > Hi, > > > > Hereby we are issuing a WGLC for draft-ietf-p2psip-share-04. > > > > The WGLC will be open till the 16th of February. We kindly ask the = WG to > > review the document and provide comments. We did one last year and = we > > didn't get any comments, which is not acceptable if we want to = progress > > the document. 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. > > Note that if we don't get some responses to this WGLC showing enough > > energy & interest to progress this document, we would abandon it. > > > > Additional information about the document is below: > > > > Title : A Usage for Shared Resources in RELOAD = (ShaRe) > > Authors : Alexander Knauf > > Thomas C. Schmidt > > Gabriel Hege > > Matthias Waehlisch > > Filename : draft-ietf-p2psip-share-04.txt > > Pages : 20 > > Date : 2014-08-29 > > > > Abstract: > > This document defines a RELOAD Usage for managing shared write = access > > to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a = basic > > primitive for enabling various coordination and notification = schemes > > among distributed peers. Access in ShaRe is controlled by a > > hierarchical trust delegation scheme maintained within an access > > list. A new USER-CHAIN-ACL access policy allows authorized peers = to > > write a Shared Resource without owning its corresponding = certificate. > > This specification also adds mechanisms to store Resources with a > > variable name which is useful whenever peer-independent = rendezvous > > processes are required. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-p2psip-share-04 > > >=20 > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail=_EC4E9440-F9DB-464C-8B5B-F537593E4532 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Marc was the only person who responded to this = WGLC. Please send mail to the list by April 20 if you have read this = document and support its publication. Otherwise the document will be = abandoned.

Alissa

On Jan 28, = 2015, at 3:03 AM, Marc Petit-Huguenin <petithug@acm.org> = wrote:

Signed PGP part
I reviewed this document multiple times and = I believe that it is ready to be submitted to the = IESG.

Thanks.

On 01/27/2015 11:54 AM, Carlos Jes=FAs = Bernardos Cano wrote:
> Hi,
>
> Hereby we are issuing = a WGLC for draft-ietf-p2psip-share-04.
>
> The WGLC will be = open till the 16th of February. We kindly ask the WG to
> review = the document and provide comments. We did one last year and we
> = didn't get any comments, which is not acceptable if we want to = progress
> the document. 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.
> Note that if we don't get some = responses to this WGLC showing enough
> energy & interest to = progress this document, we would abandon it.
>
> Additional = information about the document is below:
>
>         Title           : A Usage for Shared = Resources in RELOAD (ShaRe)
>         Authors         : Alexander = Knauf
>                           Thomas C. = Schmidt
>                           Gabriel = Hege
>                           Matthias = Waehlisch
>  =        Filename        : = draft-ietf-p2psip-share-04.txt
>         Pages           : 20
>         Date            : = 2014-08-29
>
> Abstract:
>    This document defines a = RELOAD Usage for managing shared write access
>    to RELOAD Resources.  Shared Resources in RELOAD = (ShaRe) form a basic
>    primitive for enabling = various coordination and notification schemes
>    among distributed = peers.  Access in = ShaRe is controlled by a
>    hierarchical trust = delegation scheme maintained within an access
>    list.  A new USER-CHAIN-ACL = access policy allows authorized peers to
>    write a Shared Resource = without owning its corresponding certificate.
>    This specification also = adds mechanisms to store Resources with a
>    variable name which is = useful whenever peer-independent rendezvous
>    processes are = required.
>
>
> The IETF datatracker status page for = this draft is:
> https:/= /datatracker.ietf.org/doc/draft-ietf-p2psip-share/
>
> = There's also a htmlized version available at:
> http://tool= s.ietf.org/html/draft-ietf-p2psip-share-04
>

--
Marc = Petit-Huguenin
Email: marc@petit-huguenin.org
Blo= g: http://blog.marc.petit-huguen= in.org
Profile: http://www.linkedin.com/in/pe= tithug


_______________________________________= ________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail=_EC4E9440-F9DB-464C-8B5B-F537593E4532-- From nobody Mon Apr 13 01:13:38 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E671B2E9A for ; Mon, 13 Apr 2015 01:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.501 X-Spam-Level: X-Spam-Status: No, score=-101.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm_Xxqnd3MVH for ; Mon, 13 Apr 2015 01:13:35 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43451B2E99 for ; Mon, 13 Apr 2015 01:13:34 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-f7-552b7aac7660 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.93.28347.CAA7B255; Mon, 13 Apr 2015 10:13:32 +0200 (CEST) Received: from [131.160.126.136] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Mon, 13 Apr 2015 10:13:26 +0200 Message-ID: <552B7AA6.2090409@ericsson.com> Date: Mon, 13 Apr 2015 11:13:26 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dean Willis , David Bryan References: <54D088CA.2060104@ericsson.com> <54D0DCBE.4040005@ericsson.com> <54D37C57.1050802@ericsson.com> In-Reply-To: <54D37C57.1050802@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje6aKu1Qg5arBhbTTl5mtpj09zO7 xa4rWhZLbp5hdGDxePztD7PHkiU/mTx2NDxn9ri45BtjAEsUl01Kak5mWWqRvl0CV8afb04F 980rvqz9zNTAuEWpi5GTQ0LARKJh5zQWCFtM4sK99WxdjFwcQgJHGSX27t/ADpIQEljLKPHx m0cXIwcHr4C2xI4lLiBhFgFViSO/z7OC2GwCFhJbbt0HmyMqECUx8eshMJtXQFDi5MwnYLaI gJ/EgxsrWUDGMAvYS/TfEgQJCwuoSGw5/ZwdYu0mZonJnS+ZQBKcAjoSH07tZYKo15RYv0sf JMwsIC/RvHU2M8Rl2hLLn7WwTGAUnIVk2yyEjllIOhYwMq9iFC1OLU7KTTcy0kstykwuLs7P 08tLLdnECAzmg1t+G+xgfPnc8RCjAAejEg/vg1daoUKsiWXFlbmHGKU5WJTEee2MD4UICaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYGxtLZq/SHdXuGYId/zJxdMC1n+/rnXje0Pzozn81ZLr br2Y8Pdau8u3ezea+w/1rJU5o7smZaue3s4kOdcr0/qc2B4uO/srqu+A5guBr+X7GSKLH5/s 6heSX/nFbuaSVRn3/Geuu6uavrtdT4adN1G2a7XoBi5jabPbyxaHm0frnPy5+vFegz4lluKM REMt5qLiRACZpb6zRwIAAA== Archived-At: Cc: "Rosen, Brian" , p2psip@ietf.org Subject: Re: [P2PSIP] Concepts Draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 08:13:37 -0000 Hi David, what is the status of this effort? Cheers, Gonzalo On 05/02/2015 4:21 PM, Gonzalo Camarillo wrote: > Hi, > >> David is my hero. > > s/my/our/ :-) > >> I can iterate next week or week after, and yes, agree it is very >> close to ready for WGLC. > > If you could revise the draft in that time frame, that would be really > great. Also, if you could discuss on the list what remains to be > resolved in order to get the draft to be ready for WGLC, that would give > us a way forward. > > Thanks! > > Gonzalo > > >> >> On Feb 3, 2015 8:35 AM, "Gonzalo Camarillo" >> > > wrote: >> >> Hi David, >> >> thanks for the quick response! Given the status, I think you can >> just >> revise the draft and get the chairs to WGLC it. Do you have an >> ETA for >> such a revision? >> >> Thanks, >> >> Gonzalo >> >> On 03/02/2015 3:43 PM, David Bryan wrote: >> > I am indeed. It needs one small pass to conform to 6940 >> language but >> > should otherwise be good to go. I have in my notes that I was >> waiting >> > for any further comments, but the list has been very quiet. >> > >> > On Feb 3, 2015 2:37 AM, "Gonzalo Camarillo" >> > > >> > >> >> > wrote: >> > >> > Hi, >> > >> > what is the status of this draft? Are its authors actively >> working >> > on it? >> > >> > Thanks, >> > >> > Gonzalo >> > >> > On 17/06/2014 8:33 PM, Rosen, Brian wrote: >> > > >> > > On Jun 13, 2014, at 4:40 PM, David Bryan >> >> > >> >> wrote: >> > > >> > >> I was recently asked to update the concepts draft and >> discuss the >> > important issues. The pass that has been made is largely >> around >> > normalizing the text to be compliant with the terminology >> of RFC >> > 6940, but it certainly will need an additional pass after >> a few >> > questions to the group: >> > >> >> > >> To move this draft forward, there are a few open >> issues/questions: >> > >> >> > >> MAJOR OPEN ISSUE: The initial wording in the high-level >> > description >> > >> about proving AoR to contact mapping reflects a very >> long and >> > >> contentious debate about the role of the protocol, >> and reflected a >> > >> pretense that this was an overlay only for P2PSIP. >> That is not >> > >> really true in base anymore (see last paragraph of >> > introduction) and >> > >> the language has been very much genericized in >> base. Should >> > we make >> > >> this text more abstract and then use AoR->contact >> mapping as an >> > >> example of the (original) use? On a related note, >> see the last >> > >> paragraph of the Background section -- do we want to >> reword this? >> > >> >> > >> (my thought would be to make the text more generic, and >> mention >> > that the AoR->contact mapping is the most popular usage…) >> > > Agree >> > > >> > >> >> > >> OPEN ISSUE: Should we include a section that >> documents previous >> > >> decisions made, to preserve the historical debate >> and prevent past >> > >> issues from being raised in the future, or simply >> rely on the >> > mailing >> > >> list to address these concerns? >> > >> >> > >> (I don't think we want to do this. Huge (and largely >> unneeded) >> > can of worms, but it has been in the open issues section >> for some >> > time and should be at least asked of the list) >> > > No, we don’t need to do this >> > > >> > >> >> > >> OPEN ISSUE: Should we include the use cases from >> > >> draft-bryan-p2psip-app-scenarios-00 (now long >> expired)? There was >> > >> some interest in doing so in previous versions, but no >> > conclusion was >> > >> reached. >> > >> >> > >> (given the current stage of the group, I would say >> these aren't >> > likely to be useful anymore, but again, as it is currently >> listed as >> > an open issue in the draft, need to check) >> > > Nah, I don’t think it is necessary, or even that useful >> at this point >> > > >> > >> >> > >> The final open issue is do we want to advance the draft? In >> > discussion with the chairs and some folks, it seems the >> answer is >> > yes, there is useful material and we should push the draft >> out, but >> > I wanted to discuss. Assuming there is still interest, I'd >> also >> > welcome any comments on the draft...I'm sure I missed a >> few spots >> > where it no longer aligns with 6940. >> > > I would like to see this finished. >> > > >> > >> >> > >> David >> > >> _______________________________________________ >> > >> P2PSIP mailing list >> > >> P2PSIP@ietf.org >> > >> > >> https://www.ietf.org/mailman/listinfo/p2psip >> > > >> > > _______________________________________________ >> > > P2PSIP mailing list >> > > P2PSIP@ietf.org >> > >> > > https://www.ietf.org/mailman/listinfo/p2psip >> > > >> > >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From nobody Tue Apr 21 01:40:58 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F721B37B5 for ; Tue, 21 Apr 2015 01:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tghjz9kEXBGS for ; Tue, 21 Apr 2015 01:40:55 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FBA1B37B3 for ; Tue, 21 Apr 2015 01:40:55 -0700 (PDT) Received: by oift201 with SMTP id t201so148515368oif.3 for ; Tue, 21 Apr 2015 01:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=JLsJ1t7QukFvYc3rsrwmWYoo2+kZaao09VionlKZ4hU=; b=zzHvJWNAMBn+RsrAiGg04p3BZUNW/H5R5R4GCxaSijqCFvmZsAdFRhwJDqe8C4BYCQ zM/YR8TB9+K34SauR5HCmf2el1gfOfthElhjdTUjT7cY5N/eqePBMVBbIMp6KyMogz0H qoLmvTCEqu5ydrOlk8n8z80plLovgETZzaqL9uzQNxDcKzCKN0iTCY7Df5xLkNj98uoc wvCv7ttqbmRMZ93uaKQN/PpndVhI4YCuXd4yylKU8yEv7uEklwP1ZROjuv4EwYMzAaE5 Mo/UzbuKifNwboxL30c/LhjhUkhaA3fqYuzQQc3rKHacwIGlKIM213MXwaJgBtiU6AVt Z5hQ== X-Received: by 10.202.64.195 with SMTP id n186mr16935175oia.53.1429605655042; Tue, 21 Apr 2015 01:40:55 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.90.165 with HTTP; Tue, 21 Apr 2015 01:40:34 -0700 (PDT) From: Emmanuel Baccelli Date: Tue, 21 Apr 2015 10:40:34 +0200 X-Google-Sender-Auth: u9QreEtKfm9BPNyKsjlRl4f6Bcg Message-ID: To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=001a113dd1e63cdfd50514380116 Archived-At: Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 08:40:56 -0000 --001a113dd1e63cdfd50514380116 Content-Type: text/plain; charset=UTF-8 Hi Alissa, if it is not too late: I am currently reviewing the document. ETA early next week. Sorry for the delay. Is that alright with you? Best, Emmanuel --001a113dd1e63cdfd50514380116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Alissa,

if it is not = too late: I am currently reviewing the document. ETA early next week.
=
Sorry for the delay. Is that alright with you?

Best,

Emmanuel





--001a113dd1e63cdfd50514380116-- From nobody Tue Apr 21 12:08:24 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FBF1B2A25 for ; Tue, 21 Apr 2015 12:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG28exuVPr2K for ; Tue, 21 Apr 2015 12:08:22 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35ECC1B2A1E for ; Tue, 21 Apr 2015 12:08:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 816882072F for ; Tue, 21 Apr 2015 15:08:20 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 21 Apr 2015 15:08:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Wp6duTLK+KaFa1q+1fk1ZRPf65k=; b=Et+fKq KSd+cv/E9mGLZ15NTRyfzuVVkBPhOKqFGWYImxh2p3SJIyl/Z2FFu8Pw8h9faRgl iHkKSL92zRPBzQ8KwKxgk4R/H3PXJ9O/yqZ3RqhxZVcSP7FzSoiXVK7yc5tq37uE d2dVrb5a43rLynFeYQTRwduCMLashforPvSrY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Wp6duTLK+KaFa1q +1fk1ZRPf65k=; b=cxHBcIkl/Qls22k3DLbh81L5v5yFUDaCpfq3FnpxrYJOXar t/Es8+bpD/NI9j1F8aHRG5P0uENlW7awDKQDAO1LaEhrco3rXc++a9EFrBjQ05IN Nju5KX9VOcDDGHxMMCRH+j/zLiq0dyhOY3RMpFpn4bkiOu74Q7haCg0fZUoI= X-Sasl-enc: A3w0apzpI6ivxYz42irAFCRZWHY0fDOjmcwdIOePacmg 1429643300 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.180]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C9FC6801A2; Tue, 21 Apr 2015 15:08:19 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Tue, 21 Apr 2015 12:08:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:08:23 -0000 Yes, that=92s fine, thanks. Alissa On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli = wrote: >=20 > Hi Alissa, >=20 > if it is not too late: I am currently reviewing the document. ETA = early next week. > Sorry for the delay. Is that alright with you? >=20 > Best, >=20 > Emmanuel >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Thu Apr 23 03:03:49 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0B1A90BD for ; Thu, 23 Apr 2015 03:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XFVRMiYP9l0 for ; Thu, 23 Apr 2015 03:03:46 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A501A90C6 for ; Thu, 23 Apr 2015 03:03:32 -0700 (PDT) Received: by oica37 with SMTP id a37so10256269oic.0 for ; Thu, 23 Apr 2015 03:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2FJo6cJuODmp2uBiBSgM7JhbDiUxDD4U9WISo/51DXw=; b=vUciDMZ70ljUylc4t3NRajCKs6qbru85gRYZ9gtVhJBrdWx6lJeshKk2axrdmvPyvx 23SfMneRD9+y9CduYQ4T/aJ7j2j5mIJsgP7uKjAy6LXQBHtM7RgVpOyOFouq2TFmYrwe XY50id7uin5aqpwIO/3WCAuATTKE8OQ+Wb8LV8YjTP7Es7X2QGbBoxoqItY7iLCsTQTB OVumUsY0brlLy8ElBDLhUb9ES1LxhFkvmFEisgaodj3wb6EBTuLgzRDQ0c8TPd4M/5wf mhscPHJDKXLIN2V83kGhCPRtOGYRLyO8FjiEV/OfSHTHcbaoeTeZ5peR1Z60/XpSMcOU DS2Q== X-Received: by 10.60.103.70 with SMTP id fu6mr1741687oeb.27.1429783411531; Thu, 23 Apr 2015 03:03:31 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.90.165 with HTTP; Thu, 23 Apr 2015 03:03:11 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Thu, 23 Apr 2015 12:03:11 +0200 X-Google-Sender-Auth: QRwOPiYNCQAs5WRhyoeX7aFnE7c Message-ID: To: p2psip Content-Type: multipart/alternative; boundary=089e0112c0a059a5910514616458 Archived-At: Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 10:03:47 -0000 --089e0112c0a059a5910514616458 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alissa, Hi WG, I have reviewed draft-ietf-p2psip-share-05, and here are my comments. General comments: in my opinion the draft is in good shape and reads well. I have a few nits and editorial suggestions detailed below. I believe these can be addressed quite easily with a quick resubmission and my impression is the doc is ready to go. Detailed comments: in Section 1: refer to RFC6940 (and which section, if applicable) the first time specific terms are used such as "RELOAD Usage" or "RELOAD security model". Spoiler: I will have a lot of such comments below ;) in Section 2: for reader convenience, I suggest listing the key terms (without recalling their definitions) imported from RFC6940, and the p2psip-concepts draft in the paragraph right after the 2119 boilerplate. in Section 3.1: in step 3, I suggest being explicit that the 8bit part is a suffix (least significant bits) in Section 4.1: - "...Alice is also granted (limited) write access..." Either explain what "limited" means here, or remove this adjective. - "Note that overwriting existing items in an Access Control List that reference a different Kind-ID..." Clarify: different from what? I suppose you mean that the overwrite results in changing the Kind-ID - "The Resource Owner is allowed to overwrite any existing ACL item, but should be aware of its consequences." Either quickly explain / give examples of consequences or remove this sentence. in Section 5.1: "The specifications in this document scheme adhere to this paradigm...". add reference to RFC6940 (and the exact section). It will help readers grasp quicker what draft-ietf-p2psip-share specification adds here. in Section 6.1: - first sentence "Write access ... solely be issued by the Resource Owner." rephrase needed (confusing as readers already know that delegation is possible). - "... stored in the numerical order... starting with the index of the root item...". I have a (stupid) question: What if the Node-ID of the an authorized peer with ad=3D1 has a node-ID that is numerically smaller that that of the owne= r? I suggest rephrasing in order to clarify this corner case, just to make sure no one is confused? in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y." in Section 6.6: Because it is possible here, I would have preferred to see the last 2 paragraphs written in steps + pseudo-code style if...else..else. But that's a matter of taste. Best, Emmanuel On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper wrote: > Yes, that=E2=80=99s fine, thanks. > Alissa > > On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli > wrote: > > > > > Hi Alissa, > > > > if it is not too late: I am currently reviewing the document. ETA early > next week. > > Sorry for the delay. Is that alright with you? > > > > Best, > > > > Emmanuel > > > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > --089e0112c0a059a5910514616458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa, Hi WG,

I have reviewed draft-ietf-p2psip-share-05, and here = are my comments.


General comments:= =C2=A0
in my opinion the draft is in goo= d shape and reads well. I have a few nits and editorial suggestions detaile= d below. I believe these can be addressed quite easily with a quick resubmi= ssion and my impression is the doc is ready to go.


Detailed comments:

<= /div>
in Section 1: refer to RFC6940 (and whic= h section, if applicable) the first time specific terms are used such as &q= uot;RELOAD Usage" or "RELOAD security model". Spoiler: I wil= l have a lot of such comments below ;)
<= br>
in Section 2: for reader convenience= , I suggest listing the key terms (without recalling their definitions) imp= orted from RFC6940, and the=C2=A0p2psip-concepts draft in the = paragraph right after the 2119 boilerplate.

in Section 3.1: in step 3, I su= ggest being explicit that the 8bit part is a suffix (least significant bits= )

in Section 4.1:=C2=A0
- "...Alice= is also granted (limited) write access..."
Either explain what "limited" means here, or remove this= adjective.

- "Note that overwriting existing items in an Access Contr= ol List that reference a =C2=A0 =C2=A0different Kind-ID..."
Clarify: different from what? I suppose you mean t= hat the overwrite results in changing the Kind-ID

- "The Resource Owne= r is allowed to overwrite any existing ACL item, but should be aware of its= consequences."
Either quickly expl= ain / give examples of consequences or remove this sentence.

in Section 5.1= : =C2=A0"The specifications in this document scheme adhere to this par= adigm...".
add reference to RFC6940= (and the exact section). It will help readers grasp quicker what draft-iet= f-p2psip-share specification adds here.=C2=A0

in Section 6.1:= =C2=A0
- first sentence "Write acce= ss ... solely be issued by the Resource Owner."
rephrase needed (confusing as readers already know that delega= tion is possible).

- "... stored in the numerical order... starting w= ith the index of the root item...".
I have a (stupid) question: What if the Node-ID of the an authorized peer = with ad=3D1 has a node-ID that is numerically smaller that that of the owne= r?
I suggest rephrasing in order to clar= ify this corner case, just to make sure no one is confused?

in Section 6.5:= Step 1. reference "as per RFC 6940 Section X.Y."

in Section 6.6:= Because it is possible here, I would have preferred to see the last 2 para= graphs written in steps + pseudo-code style if...else..else. But that's= a matter of taste.


Best,

Emm= anuel




On Tue, Apr 21, 2015 at 9:08 PM, Ali= ssa Cooper <alissa@cooperw.in> wrote:
Yes, that=E2=80=99s fine, thanks.
Alissa

On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> = wrote:

>
> Hi Alissa,
>
> if it is not too late: I am currently reviewing the document. ETA earl= y next week.
> Sorry for the delay. Is that alright with you?
>
> Best,
>
> Emmanuel
>
>
>
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip


--089e0112c0a059a5910514616458-- From nobody Thu Apr 23 03:10:06 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6A61A90D8 for ; Thu, 23 Apr 2015 03:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0OMASstJ20j for ; Thu, 23 Apr 2015 03:10:02 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A8A1A90C7 for ; Thu, 23 Apr 2015 03:09:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,630,1422918000"; d="scan'208";a="26378064" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES128-SHA; 23 Apr 2015 12:09:37 +0200 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 23 Apr 2015 12:09:36 +0200 Received: from [10.82.81.172] (141.22.200.55) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 23 Apr 2015 12:09:36 +0200 Message-ID: <5538C4D6.1030007@haw-hamburg.de> Date: Thu, 23 Apr 2015 12:09:26 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Emmanuel Baccelli , p2psip References: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> In-Reply-To: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 10:10:05 -0000 Hi Emmanuel, many thanks! We'll fix the issues and resubmit during the next few days. Best wishes, thomas On 23.04.2015 12:03, Emmanuel Baccelli wrote: > Hi Alissa, Hi WG, > > I have reviewed draft-ietf-p2psip-share-05, and here are my comments. > > > General comments: > in my opinion the draft is in good shape and reads well. I have a few > nits and editorial suggestions detailed below. I believe these can be > addressed quite easily with a quick resubmission and my impression is > the doc is ready to go. > > > Detailed comments: > > in Section 1: refer to RFC6940 (and which section, if applicable) the > first time specific terms are used such as "RELOAD Usage" or "RELOAD > security model". Spoiler: I will have a lot of such comments below ;) > > in Section 2: for reader convenience, I suggest listing the key terms > (without recalling their definitions) imported from RFC6940, and the > p2psip-concepts draft in the paragraph right after the 2119 boilerplate. > > in Section 3.1: in step 3, I suggest being explicit that the 8bit part > is a suffix (least significant bits) > > in Section 4.1: > - "...Alice is also granted (limited) write access..." > Either explain what "limited" means here, or remove this adjective. > > - "Note that overwriting existing items in an Access Control List that > reference a different Kind-ID..." > Clarify: different from what? I suppose you mean that the overwrite > results in changing the Kind-ID > > - "The Resource Owner is allowed to overwrite any existing ACL item, but > should be aware of its consequences." > Either quickly explain / give examples of consequences or remove this > sentence. > > in Section 5.1: "The specifications in this document scheme adhere to > this paradigm...". > add reference to RFC6940 (and the exact section). It will help readers > grasp quicker what draft-ietf-p2psip-share specification adds here. > > in Section 6.1: > - first sentence "Write access ... solely be issued by the Resource Owner." > rephrase needed (confusing as readers already know that delegation is > possible). > > - "... stored in the numerical order... starting with the index of the > root item...". > I have a (stupid) question: What if the Node-ID of the an authorized > peer with ad=1 has a node-ID that is numerically smaller that that of > the owner? > I suggest rephrasing in order to clarify this corner case, just to make > sure no one is confused? > > in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y." > > in Section 6.6: Because it is possible here, I would have preferred to > see the last 2 paragraphs written in steps + pseudo-code style > if...else..else. But that's a matter of taste. > > > Best, > > Emmanuel > > > > > On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper > wrote: > > Yes, that’s fine, thanks. > Alissa > > On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli > > wrote: > > > > > Hi Alissa, > > > > if it is not too late: I am currently reviewing the document. ETA early next week. > > Sorry for the delay. Is that alright with you? > > > > Best, > > > > Emmanuel > > > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > >P2PSIP@ietf.org > >https://www.ietf.org/mailman/listinfo/p2psip > > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °