Re: [mile] Working group last call for ROLIE

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Hey Adam,

Thanks for the review, responses inline.

-Stephen

From: mile [mailto:[e-mail]] On Behalf Of Adam Montville
Sent: Wednesday, April 19, 2017 2:14 PM
To: Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
Subject: Re: [mile] Working group last call for ROLIE

Hi all.

I've read through the entire draft and found it to be a decent draft. Keep in mind that I've not attempted an implementation, and must rely on implementers to pick out any technical impacts from this specification. That said, I have two broad categories of feedback. The first includes suggestions and concerns that are something more than nits. The second are really just nits and stylistic (i.e. take them or leave them) types of concerns.

Suggestions/Concerns More Than Nits...

Page 6: There are two similar terms in the second paragraph of section 4.2: "endpoint management system" and "endpoint monitoring system". Are they intended to be distinct, or interchangeable in this context? I could conclude either way, but if they are intended to be interchangeable, then I recommend picking and using one.

They were originally meant to be interchangeable, I’ve changed them both to “endpoint management system” to avoid confusion.

Page 10: I've probably missed something along the way -- perhaps out of a secdir lunch or other discussion -- but it really seems like section 5.3 could be dramatically reduced by saying, follow RFC7589. There are a lot of non-ROLIE-specific things happening in this section, which mostly amount to good practice overall (so I don't necessarily mind having the information in here), but imagine this information being available in every draft intended to be, in part, secured using TLS. That sounds like a nightmare for managing requirements.

We’ve selectively chosen pieces out of RFC7589 to put into ROLIE, so referencing the whole document may include unintended requirements. That said, there may be a way to shorten this section slightly if you are concerned about section length.

Page 11: First paragraph at the top of that page (part of section 5.3) says, "The server MUST support certificate-based client authentication..." Why is this not a SHOULD? Yes, we'd like them to, but there are perfectly valid cases where they needn't support client authentication. Of course, if a proper TLS server implementation does this already, then my previous comment applies here as well.

Page 11: First pargraph of section 5.4. A similar concern to the previous, the first sentence reads, "Implementations MUST support user authentication." Why not SHOULD? Again, there are valid cases where authentication is not, strictly speaking, needed.

We decided that implementations MUST support the authentication in both of these cases to maintain secure interoperability between implementations. A given ROLIE repo does not have to actually use the authentication. Panos had similar comments to these two as well, so I’ve added a paragraph in section 2 that clarifies that all requirements in the ROLIE specification are conformance requirements for implementations, and are not usage requirements.

Page 12: Section 5.5 treats GET and POST, but ignores the other methods that may be treated similarly by stating, in section 5.6, "Servers MAY accept request methods beyond those specified in this document." Do we really want to leave those undefined? PUT? DELETE? I'm not an expert in this area, but PUT could be treated similarly to POST. DELETE is probably something that SHOULD be implemented only for user agents properly authenticated and authorized, etc.

Section 5.5 only applies to requests sent to the “/” resource to maintain RID compatibility. GET,POST,PUT,DELETE,etc are all defined for general usage in the Atom Publishing Protocol specification

Sections 6.1 and 6.2 and maybe others I can't recall: These sections provide an informative syntax for a given element that is a "stricter representation" than the original RFC, but they don't ever really state which part of that element is stricter, which forces the reader out to that original RFC. If there is a way to make the statement right there, please do so.

The definitions for elements we’ve provided in ROLIE are full definitions, so a reader shouldn’t need to flip back to RFC4287 in order to get the whole picture. Any element defined in ROLIE does a full override of the 4287 element, and any element not defined in ROLIE fully inherits from 4287. Would it help if I added some text describing that relationship in more detail somewhere?

Page 15: First sentence of section 6.1.3 indicates that "the atom:updated element MUST be populated with the current time at the instant the Feed representation was last updated..." Is "instant" sufficient definition?

Time being the beast that it is I’m not sure how to better describe the requirement. Do you have any suggestions/recommendations on how to define it?

Nits and Such...

Page 5: Second sentence of section 3.2. Strike "However, " from the beginning.

Changed

Page 5: Last sentence of section 3.2. Proposed change: "A non-normative RELAX NG Compact Schema..." or "An informative RELAX NG Compact Schema..."

Added

Page 5: Last sentence of only paragraph in Section 4 (proper). Proposed change: "...human-in-the-loop sharing arise...". It just reads funny (to me) using "become apparent" followed by something else that "becomes apparent".

Agreed, changed the sentence to avoid the repetition.

Page 19: First sentence of first bullet point in section 6.2.5. Proposed change: "...have an atom:link element...".

Changed

Page 26: Last sentence in first paragraph of section 9. Proposed change: "...All that follows is guidance.  More specific instruction is out of scope for this document."

Changed

Page 26: The term CSIRT is used in the last paragraph on this page. Not sure whether we would prefer to use a more generalized example, as CSIRTs may not be the only type of sharing consortium.

Agreed, changed to “consortium”.

Kind regards,

Adam

On Tue, Mar 28, 2017 at 6:27 PM Nancy Cam-Winget (ncamwing) <[e-mail]<mailto:[e-mail]>> wrote:
Colleagues,

Given the significant changes made to the last draft, we are doing another 30day WGLC for
https://tools.ietf.org/html/draft-ietf-mile-rolie-06

Please provide comments before May 1st and provide your support and/ or raise any issue you feel are yet to be addressed.

Regards, Nancy
_______________________________________________
mile mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mile