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

"Thomas C. Schmidt" <t.schmidt@haw-hamburg.de> Fri, 04 November 2016 21:30 UTC

Return-Path: <t.schmidt@haw-hamburg.de>
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 B41861296E7; Fri, 4 Nov 2016 14:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 jJprGpocjgB3; Fri, 4 Nov 2016 14:30:21 -0700 (PDT)
Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2231295C1; Fri, 4 Nov 2016 14:30:10 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.31,445,1473112800"; d="scan'208";a="44342270"
Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 22:30:09 +0100
Received: from CAS04.mailcluster.haw-hamburg.de (2002:8d16:183f::8d16:183f) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 22:30:09 +0100
Received: from [192.168.178.122] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 22:30:08 +0100
To: Ben Campbell <ben@nostrum.com>
References: <2ea1f1a9466348ef9608232182626c11@HUB02.mailcluster.haw-hamburg.de> <1b5e197c-cabf-3463-c8e5-8add4fd46974@haw-hamburg.de> <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de>
From: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Message-ID: <ef20ba15-9bec-ae1e-ee2a-eca1df677485@haw-hamburg.de>
Date: Fri, 4 Nov 2016 22:30:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <398f4e3e19d84c108af172d134931192@HUB02.mailcluster.haw-hamburg.de>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [141.22.250.35]
Archived-At: <https://mailarchive.ietf.org/arch/msg/p2psip/diskreHrQazMW4tv5QnxZiiY8LM>
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: Fri, 04 Nov 2016 21:30:24 -0000

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.

>
> [...]
>
>>
>>> -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..."
>

O.K., done.

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

O.K., thanks: I got your point. Correspondingly, we reversed the order 
to a logical chain of denials.

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


Currently we cannot update due to the cutoff. We'll do so in Seoul.

Thanks again
  Thomas

-- 

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 °