Hi Emmanuel, all,
On 23.04.2015 11:03, Emmanuel Baccelli wrote:
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.
thanks - please find our records below.
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 ;)
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."
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.
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."
in Section 3.1: in step 3, I suggest being explicit that the 8bit part
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"
in Section 4.1:
- "...Alice is also granted (limited) write access..."
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."
- "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
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)."
- "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.
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."
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.
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.."
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).
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."
- "... 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?
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
sure no one is confused?
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."
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.
I guess ... ;)
So, we've updated and submit in a second.
Thanks again,
Thomas
On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper <[email protected]
<mailto:[email protected]>> wrote:
Yes, that’s fine, thanks.
Alissa
On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli
<[email protected] <mailto:[email protected]>> 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 protected] <mailto:[email protected]>
>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 protected]
https://www.ietf.org/mailman/listinfo/p2psip
