Re: [mile] Working group last call for ROLIE

[Adam Montville <[e-mail]>]

More inline :-)

On Thu, Apr 20, 2017 at 10:57 AM Banghart, Stephen A. (Fed) <
[e-mail]> wrote:

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

Thanks!


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

Understood. Also, my comments were not so much about length as about
contributing to a potential rats nest of requirements. But, shortening
would be good too. :-)


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

Right, but therein is sort of the rub. Maybe it's a red herring, but if
there's code sitting there that'll never really be used, isn't that a bad
thing?



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

It might, but I'm a voice of one, so if others are like "dude, what's this
guy talking about?" then I wouldn't worry about it.



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

LOL. Nope. If we're not concerned, then that's fine. Does the Atom spec
indicate the timestamp format? That's probably sufficient.


>
>
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/mile
>
>