Last Call Review of draft-ietf-mile-rolie-10
review-ietf-mile-rolie-10-artart-lc-thomson-2017-10-08-00

I have reviewed this document, and - despite what appears to be a lengthy list
of issues - I think that it is in pretty good shape.  It's clear, readable, and
addresses the requirements well.  Most of my comments should be trivial to
resolve.

Major:

The decision to define a .well-known URI without a discovery story is - in my
opinion - inadvisable.  Such a registration is usually appropriate if you
design a protocol that depends on discovery by hostname and port.  As such,
this does not use that at all.  A configuration system can (and should) accept
a complete URI for the service endpoint.  It would be better to defer creation
of yet another .well-known URI registration until the working group is certain
that discovery requires it.

The same comment applies to the .well-known resource for the category document.
 Given that this sort of document is readily discoverable via the service
document, I would say that the need for a .well-known resource is less
well-justified than the service document.

The requirements in Section 5.3 on TLS use are unnecessarily strict.  It's
great to recommend the use of TLS 1.2, but given that the document has no real
requirement on any particular version of TLS, the use of "MUST" here is not
needed.  Similarly, the prohibition on the use of 0-RTT is groundless.  The
lengthy list of requirements around certificate validation only risk creating a
conflict with advice in other RFCs.  Many, if not all, of these requirements
are transitively included by way of referencing HTTPS documents.  I would
prefer to see this entire section reduced to a simple RFC 7525 reference.

User authentication is under-specified.

* Section 5.3 mandates the use of TLS cipher suites that support client
authentication using certificates, but offers no further advice.  Aside from
being an unnecessary requirement - cipher suites that support certificate-based
authentication of servers all allow for client authentication - this sort of
requirement is rarely sufficient for interoperation.  For instance, you need to
specify how a server will request a certificate such that clients can select
the correct certificate.  If a client and server have agreed to share
information on terms that rely on authentication of clients, it is better for
those peers to arrange the terms on which they will authenticate.

* Section 5.4 uses "SHOULD" regarding client authentication using federation,
but offers no hints about what this entails.  It also uses "SHOULD" regarding
authorization checks, which isn't an interoperability requirement.  It's more
of a "don't be silly" type of requirement, which doesn't need to be written
down in an RFC.

Section 5.5 prohibits the use of GET on "/".  This prohibits use of the
resource for other purposes.  It seems reasonable to accept POST messages as
defined in RFC 6546, but this requirement is overly strict (and further
entrenches the violation of RFC 7320).  If, for instance, the server operator
wishes to provide HTML in response to a GET request to "/", this would prohibit
that.  The requirement to return 404 if RFC 6546 is not supported is worse; not
supporting RFC 6546 might be a choice that a deployment makes to avoid the need
to reserve "/" for that protocol.

In Section 6.2.3, what is the advantage of "rolie:format" over having a
well-defined media type?  Media types can take advantage of content
negotiation, existing support in link relations, and other existing tools. 
This rolie:format element has namespace, format, and schema; these are not
useful to anyone that is ignorant of their contents.  The only advantage I see
is that syntax might be validated, but semantics can't be extracted.  There's a
lot of implied work in adding this element, but that doesn't seem to be
justified by that advantage.  (I see that RFC 7970 doesn't define a media type,
but it seems like it would be easier to correct that than to define an element
like this.)

Section 6.2.4 defines a generic key-value mechanism.  But that is something
that XML is actually good at.  Why can't users that require additional metadata
use additional metadata as originally defined by Atom?  That is, replace
<rolie:property name="urn:ietf:params:rolie:property:csirt-iodef-id"
value="12345"/> with something like
<rolie:csirt-iodef-id>12345</rolie:csirt-iodef-id>.  The final paragraph of the
section recognizes this possibility.

Minor:

Section 5.1.1 recommends the use of workspaces to separate "private" and
"public" information.  But workspaces don't really contain enough information
to signal their status to a consumer of the information.  I would suggest
mentioning this, removing the recommendation, or expanding on the manner in
which the status of information is signaled.

Section 6.1.1 says "zero or more atom:category elements", but this contradicts
the text and amendment to the schema in Section 6.1.

Section 6.1.3 requires updating the "atom:updated" element when the
representation changes.  I don't think that this is what was intended.  I think
that the element needs to be updated when the contents of the feed change in
any way.

Question: it's fairly widely accepted that use of IRIs in Atom has been less
than successful.  Do you want to mandate use of URIs instead?  This would apply
to both link relations and the "src" attribute.

In Section 7.1, the definition of the namespace prefix
"urn:ietf:params:rolie:category:local" seems unnecessary.  Namespace URIs are
cheap and it seems reasonable to experiment with feeds that produce non-ROLIE
information by omitting the "urn:ietf:params:rolie:category:information-type"
category, even if that feed might comply with the requirements of ROLIE.  The
other way to experiment would be to use the category, but define a way to
identify "term" attributes that are for use in private or experimental contexts.

In Section 7.4, how is "...:rolie:property:content-author-name" superior to
"atom:author"?

In Section 8.4,  is there a uniqueness requirement on "name"?  I understand
this to be the thing that being registered.   Assuming that, what purpose does
the "index" serve?

This statement from Section 9, "As described in the discovery section, DNS SRV
Records are a possible secure solution to discovery." is false without further
qualification.  SRV with DNSSEC might be secure, but a lot depends on the input
to the discovery process and its provenance.

In Section 10, the following statement is false (all of the described privacy
violations are available to a client or server, not third parties): "Proper
usage of TLS as described in Section 5.3 will in many cases aid in the
mitigation of these issues."  I think that you can strike this statement (most
of the reason for use of TLS is justified by the security considerations
anyway).

Nits:

Is it "Feed" or "feed"?  RFC 4287 uses the latter, but this document seems to
prefer the Proper Noun form.

Section 6.2 should say what changed in the schema.  It's hard to eyeball the
schema to discover that "atomContent" is no longer optional.  The two new
elements are easy to spot and might cause the first change to be missed.

Section 6.2.1 is the same.  It should explicitly say that it only permits the
atomOutOfLineContent formulation.

I found the formulation of Section 7.1.1 confusing.  It includes a list that
seems to be authoritative, then disclaims any attempt to register these terms. 
Maybe this is because the statement "This document does not specify any
information types." appears too late.  Some reordering might help.

The formatting of the table in Section 8.3 makes most of the columns
unreadable.  I would recommend a simple nested list.

In section 9, the use of the term "well-known" to refer to information that is
either public or widely available risks misinterpretation.

FWIW, I would reword this entire paragraph to say simply "Access control to
information published using ROLIE should use mechanisms that are appropriate to
the sensitivity of the information.  Primitive authentication mechanisms like
HTTP Basic Authentication [RFC7617] are rarely appropriate for sensitive
information."  I didn't find the remainder of the text on authentication
especially helpful.  The text seems to equivocate on the subject of federation,
where it would be easier to say nothing.

Also in Section 9, the use of the term "message" is used in the context of
using additional security controls.  I think that the word "representation" is
what was intended here.