A Usage for Shared Resources in RELOAD (ShaRe)
draft-ietf-p2psip-share-10

Note: This ballot was opened for revision 09 and is now closed.

Alvaro Retana No Objection

(Alissa Cooper; former steering group member) Yes

Yes ( for -09)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2016-11-01 for -09)
No email
send info
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?


Editorial:

-1, first paragraph, first sentence: s/that/, which
-- recurring singular plural mismatch "resources with a variable name".

-1, 2nd paragraphs: "It transfers the authorization..."
What is the antecedent for "it"?

-3. First paragraph after numbered list, "user called Authorized Peer": missing article.

-3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user actually required to access the array in the first place?

- 6.5, first paragraph: Does the MAY grant permission, or is it a statement of fact?

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

-- 2nd paragraph from end: The MUST seems more like a statement of fact. (E.g. "The resulting ... integer is used...")

- 4.1, last paragraph: s/implementations/implementors

- 4.2, definition of res_name_ext: The sentence starting with "This name serves..." is hard to parse.

-5.1, 4th paragraph (paragraph after example) : s/witch/which

(Benoît Claise; former steering group member) No Objection

No Objection (2016-11-03 for -09)
No email
send info
Below is Rick Casarez's OPS DIR review:

Section 6.5:
"Since stored values could have been modified or invalidated prior to their expiration, an accessing peer SHOULD use a Stat request to check for updates prior to using the data cache"

When considering security, and how this works, I would recommend changing this to MUST or advising that the lifetime be set very low. A stale ACL could allow access were none should occur.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2016-11-03 for -09)
No email
send info
Please look at comments from Matt Miller's Gen-ART review:

---

Nits/editorial comments:

* idnits reports a stale reference to I-D.ietf-p2psip-sip (should
 be RFC 7904).

* In 5.1. "Overview", the word "witch" should be "which".

* In 5.3. "Overlay Configuration Document Extension", there should
 be a space between "P2PSIP" and "[I-D.ietf-p2psip-sip]".

* In 6.2. "Revoking White Access", there should be a space between
 "see" and "[RFC6940]".

* In 6.4. "Operations of Storing Peers", a comma is missing between
 "peers" and "at" in the phrase "Storing peers at which Shared
 Resource and ACL are physically stored ...".


Non-issue comments:

* idnits is reporting weird spacing and "possible code", but that
 appears to be due to the Relax NG grammar.  In my opinion the nit
 can be safely ignored.

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-10-31 for -09)
No email
send info
Thank you for addressing the SecDir review findings.
https://www.ietf.org/mail-archive/web/secdir/current/msg06890.html

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-10-31 for -09)
No email
send info
Quick questions on sec 6.3. (Validating Write Access through an ACL):
Do I really need to validate the authorization chain in the ACL every time I give access to a resource? Wouldn't I rather validate the ACL when it's modified and then simply assume that it is sufficient that I have an entry in the ACL to provide access?

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-11-03 for -09)
No email
send info
- General: this feels more like an experimental spec. If the
authors didn't object I think that'd be more appropriate.

- General: can these ACLs be resources to which access is
controlled via another of these ACLs? If so, then it seems like
there may be some nasty corner-cases where things get lost (so
nobody can change 'em in future) and I don't see how one might
recover from that. (Apologies if I'm just mixed up here, I read
this fairly quickly and didn't reload RELOAD into my little head
first;-)

- 3.1: 24 bits of collision resistance isn't many. I'm not clear
why that's ok 

- 3.1, last para: SHA-1 isn't a good example really, SHA-256
would be better today.

- 5.3: Is the mapping to USER and DOMAIN from certificates
well-defined? It may be in RELOAD, I forget, sorry;-) It doesn't
seem to be well-defined here anyway.

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -09)
No email
send info