Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT)

["Ben Campbell" <[e-mail]>]

On 4 Nov 2016, at 16:30, Thomas C. Schmidt wrote:

> Hi Ben,
>
> please see inline.
>
> On 03.11.2016 22:42, Ben Campbell wrote:
>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> I have a one set of substantive comments/questions, and some
>>>> editorial
>>>> comments:
>>>>
>>>> Substantive:
>>>>
>>>> - I'm confused about the validation procedure. In step one, is this
>>>> the
>>>> user name of the user attempting to write the resource? In step 5, 
>>>> I
>>>> do
>>>> not understand how this terminates. Which ACL item is the 
>>>> "previously
>>>> selected" one. If that refers to the one selected in the last
>>>> iteration
>>>> of steps 3 and 4, how do you know there are not more ACL items to
>>>> iterate
>>>> through?
>>>>
>>>
>>> You are referring to 6.3 "validating writ access"?
>>>
>>> In this case, you receive a store request along with a certificate. 
>>> In
>>> step 1, you resolve the user name of the requester, i.e., the user
>>> name that corresponds to the certificate in the request.
>>
>> Adding something to the effect of "This is the user requesting the 
>> write
>> operation" would be helpful.
>>
>
> O.K., done.
>
>>
>>>
>>>  ... then you identify the user in the ACL and walk up the 
>>> delegation
>>> chain.
>>>
>>> In step 5, you have arrived at the root of the delegation tree. This
>>> is the case, when the to_user equals the signer equals the owner of
>>> the resources (see see Figure 1). This is also how it terminates - 
>>> the
>>> owner of the resource is the root of the trust chain.
>>
>> I'm probably being dense here, but my confusion is in the phrasing of
>> "the "to_user" value user name of the signer of the previously 
>> selected
>> ACL item".  Won't that always be true for every ACL item up the chain
>> after the first?
>>
>
> No, the selected ACL item from the previous step is the row you are 
> in. It basically says that the "to_user" value equals the username of 
> the signer. This is the "A  A" case in row 4 in your example below. 
> This row should be in an ACL only once and the user must be the owner 
> of the resource, which is requested to be verified separately.
>
>> As an example, Lets say I have a delegation chain of A,B,C,D, where A 
>> is
>> the owner. Would the ACL chain look like the following (in 
>> leave-to-root
>> order )?
>>
>>    signer to_user
>> 1   C        D
>> 2   B        C
>> 3   A        B
>> 4   A        A
>>
>> If so, then ACL 2 seems to have a to_user that matches the signer of 
>> ACL
>> 1 (the previously selected ACL), which seems to terminate early.
>>
>> Again, I'm sure I'm missing something.
>>
>
> I believe the confusion comes from the "previously" - this is meant to 
> refer to the "previous step" and the actual row. We changed 
> "previously" to "previous step" to avoid this confusion.

I still think I'm confused. Step 5 basically says iterate over steps 3 
and 4. If I'm currently looking at the ACL from the Nth iteration of 3 
and 4, it seems to me that the "ACL from the previous step" is ACL N-1.

If the terminal condition is when you find an ACL where the signer and 
the to_user are the same, then I you could say _that_ without getting 
into "previous steps."

[...]

>>>
>>>> -- 2nd paragraph from end: The MUST seems more like a statement of
>>>> fact.
>>>> (E.g. "The resulting ... integer is used...")
>>>>
>>>
>>> Mhmm, I don't think so. These are all iterative decision steps:  try
>>> (a), then write ... otherwise try (b), then write ... +++ ...
>>> otherwise refuse.
>>
>> That was a cut and paste error on my part--I meant the 2nd to last
>> paragraph of 3.1.
>>
>
> ... still there it says: Do 1.-3. to obtain an integer, and then use 
> exactly this (and no other). This sounds to me like a normative MUST??

Okay. ( That is,  I still don't think it's necessary, but it also does 
no harm, so I'll withdraw that concern.)


Thanks!

Ben.