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.
Yes
(for -09)
Unknown
No Objection
(for -09)
Unknown
No Objection
(for -09)
Unknown
No Objection
(for -09)
Unknown
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
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.
No Objection
(for -09)
Unknown
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.
No Objection
(for -09)
Unknown
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
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?
No Objection
(for -09)
Unknown
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.
No Objection
(for -09)
Unknown
No Objection
(for -09)
Unknown