Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Jun 2015 14:46:23 -0700

Hi Thomas,

Checking in on the status of this.

Thanks,
Alissa

On May 11, 2015, at 11:09 AM, Thomas C. Schmidt <[email-masked]> wrote:

> Hi Alissa,
> 
> it's coming ASAP. I was blocked by paper deadlines ...
> 
> Thanks,
> 
> Thomas
> 
> On 11.05.2015 19:36, Alissa Cooper wrote:
>> Hi Thomas,
>> 
>> What is the status of this update?
>> 
>> Thanks,
>> Alissa
>> 
>> On Apr 23, 2015, at 3:09 AM, Thomas C. Schmidt <[email-masked]> wrote:
>> 
>>> 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 <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>> 
>>>>    Yes, that’s fine, thanks.
>>>>    Alissa
>>>> 
>>>>    On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli
>>>>    <[email-masked] <mailto:[email-masked]>> 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
>>>>    >[email-masked] <mailto:[email-masked]>
>>>>    >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 °
>>> 
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/p2psip
> 
> -- 
> 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                   Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 17 Jun 2015 12:16:08 +0100

Hi Emmanuel, all,

> addressed quite easily with a quick resubmission and my impression is

thanks - please find our records below.

> security model". Spoiler: I will have a lot of such comments below ;)

Done: We prepended the statement fixing the relation to RFC6940:

   "[RFC6940] defines the base protocol for REsource LOcation And
    Discovery (RELOAD) that allows for application-specific extensions by
    Usages."

> p2psip-concepts draft in the paragraph right after the 2119 boilerplate.

Done: We named the most prominent terms:

   " This document uses the terminology and definitions from the RELOAD
    base [RFC6940] and the peer-to-peer SIP concepts draft
    [I-D.ietf-p2psip-concepts], in particular the RELOAD Usage, Resource
    and Kind."

> is a suffix (least significant bits)

Oh, thanks for that one. We clarified:

   " 3.  Append an 8 bit long short individual index value to those 24 bit
        of the Node-ID"

> Either explain what "limited" means here, or remove this adjective.

Good point, thanks: The right is actually explained in the following 
sentence, so we removed "(limited)":

    " peer Alice is also granted write access to the ACL as indicated by
    the allow_delegation flag (ad) set to 1.  This configuration
    authorizes Alice to store further trust delegations to the Shared
    Resource, i.e., add items to the ACL."

> results in changing the Kind-ID

Yes, we clarified:

   "Note that
    overwriting existing items in an Access Control List with a change in
    the Kind-ID revokes all trust delegations in the corresponding
    subtree (see Section 6.2)."

> Either quickly explain / give examples of consequences or remove this

O.K., we clarified:

   "The Resource Owner is allowed
    to overwrite any existing ACL item, but should be aware of its
    consequences on the trust delegation chain."

> grasp quicker what draft-ietf-p2psip-share specification adds here.

Done:

   " Each RELOAD node uses a certificate to identify itself using its user
    name (or Node-ID) while storing data under a specific Resource-ID
    (see Section 7.3 in [RFC6940]).  The specifications in this document
    scheme adhere to this paradigm, but.."

> rephrase needed (confusing as readers already know that delegation is

O.k., we clarified:

   " Write access to a Kind that is intended to be shared with other
    RELOAD users can solely be *initiated* by the Resource Owner."

> peer with ad=1 has a node-ID that is numerically smaller that that of

That does not matter. Each node has a unique prefix (up to unlikely 
collisions) and writes in its own index space to avoid race conditions 
(see Sect. 3.1). Here we only describe the node-specific indexing.

> I suggest rephrasing in order to clarify this corner case, just to make

We clarified:

      "For each succeeding ACL item, the Resource Owner
       increments its individual index value by one (see Section 3.1) so
       that items can be stored in the numerical order of the array index
       starting with the index of the root item."

> if...else..else. But that's a matter of taste.

I guess ... ;)

So, we've updated and submit in a second.

Thanks again,

  Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 17 Jun 2015 12:46:18 +0100

Hi Alissa,

so status is o.k..

Maybe, if we get the open Ack from Roland, we can move p2psip-share and 
p2psip-sip jointly forward, which would be good for keeping the 
references intact.

Best,
  Thomas

--

---

From: Emmanuel Baccelli <[email-masked]>
Date: Sun, 21 Jun 2015 12:17:38 +0200

Hi Thomas,

Thanks. I think the new/updated text fixes the comments I had.

Best,

Emmanuel
Le 17 juin 2015 13:16, "Thomas C. Schmidt" <[email-masked]> a
écrit :

> collisions) and writes in its own index space to avoid race conditions (see
> Sect. 3.1). Here we only describe the node-specific indexing.
>