A Usage for Shared Resources in RELOAD (ShaRe)

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

(Alissa Cooper) Yes

(Jari Arkko) No Objection

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

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2016-11-01 for -09)
No email
send info
I have a one set of substantive comments/questions, and some editorial comments:


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


-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) No Objection

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

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (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

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

(Joel Jaeggli) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

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

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-10-31 for -09)
No email
send info
Thank you for addressing the SecDir review findings.

Alvaro Retana No Objection