Skip to main content

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

Yes

(Alissa Cooper)

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Joel Jaeggli)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

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

Alissa Cooper Former IESG member
Yes
Yes (for -09) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-11-01 for -09) Unknown
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 IESG member
No Objection
No Objection (2016-11-03 for -09) Unknown
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 IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2016-11-03 for -09) Unknown
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 IESG member
No Objection
No Objection (for -09) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-10-31 for -09) Unknown
Thank you for addressing the SecDir review findings.
https://www.ietf.org/mail-archive/web/secdir/current/msg06890.html
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-10-31 for -09) Unknown
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 IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2016-11-03 for -09) Unknown
- 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 IESG member
No Objection
No Objection (for -09) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Unknown