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.

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.

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.

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.

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.

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?

Nits and Such...

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

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

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

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

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

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.

Kind regards,

Adam

On Tue, Mar 28, 2017 at 6:27 PM Nancy Cam-Winget (ncamwing) <
ncamwing@cisco.com> 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
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
>