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

"Ben Campbell" <ben@nostrum.com> Thu, 03 November 2016 21:42 UTC

Return-Path: <ben@nostrum.com>
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 A26D1129AF2; Thu, 3 Nov 2016 14:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=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 eGD9PwOEsQFU; Thu, 3 Nov 2016 14:42:19 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EE38A129AD9; Thu, 3 Nov 2016 14:42:18 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA3LgC9F082039 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Nov 2016 16:42:14 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: "Ben Campbell" <ben@nostrum.com>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Date: Thu, 03 Nov 2016 16:42:12 -0500
Message-ID: <D0891DA9-E6B8-40D7-A02F-575F05AC52B9@nostrum.com>
In-Reply-To: <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de>
References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/p2psip/JIOTFs24etvKX--QbngXqJYt_Y8>
Cc: "draft-ietf-p2psip-share@ietf.org" <draft-ietf-p2psip-share@ietf.org>, "marc@petit-huguenin.org" <marc@petit-huguenin.org>, The IESG <iesg@ietf.org>, "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>
Subject: Re: [P2PSIP] Ben Campbell's No Objection on draft-ietf-p2psip-share-09: (with COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 21:42:21 -0000

Hi, thanks for the response. Also see inline. I removed text that 
doesn't seem to need further discussion.

Ben.

On 3 Nov 2016, at 10:45, Thomas C. Schmidt wrote:

> Hi Ben,
>
> thanks for your comments. Please see inline.
>
> On 01.11.2016 23: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.


>
>  ... 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?

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.


[...]

>
>> -3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user
>> actually required to access the array in the first place?
>>
>
> It says "If the data model of the Shared Resource is an array, each 
> Authorized..".
>
> So the user is not required to use an array for sharing, but if an 
> array is used, write conflicts MUST not be produced.

This is pedantic, but my issue is that the SHALL does not leave the 
authorized peer the opportunity to choose not to write anything at all. 
Being granted permission to write does not imply a decision to write. 
Perhaps something like "...each Authorized Peer that chooses to write 
data SHALL..."

>
>> -6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not 
>> other
>> (perhaps application specific)  reasons one might choose not to write 
>> the
>> value?
>>
>
> I believe the MUST is correct: we're in a section that describes the 
> behavior of the storing peer. When receiving a store request, this 
> peer should not behave according to its own application semantic, but 
> to the common overlay rule.

(pedantic again): So the storing peer couldn't have an application 
policy that, for example, chooses not to honor a write that violates 
some data validation rule? It seems to me that this section is saying 
that you MUST deny the request unless one of the listed is true, which 
is not the same as saying you MUST accept if one of the conditions is 
true.
>
>> -- 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.

[...]