Re: [mile] Artart last call review of draft-ietf-mile-rolie-10

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

Martin,

I've put the rest of my comments inline, and uploaded a -11 version of ROLIE to the Github with the changes. Providing there are no additional major comments I'll post this version to datatracker today.

Thanks again for the great review,
Stephen

> -----Original Message-----
> From: mile [mailto:[e-mail]] On Behalf Of Martin Thomson
> Sent: Monday, October 09, 2017 1:08 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> Reviewer: Martin Thomson
> Review result: Almost Ready
> 
> 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.

Discussed in a separate thread.

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

We agree, removed the registration for the category document location.

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

The majority of the section has been reduced to a RFC 7525 reference. We believe that the benefits provided by 0-RTT don't outweigh the loss of forward secrecy. The text currently places this as a suggestion from the authors, and not a normative requirement.

> User authentication is under-specified.

As any repository using user authentication is already inherently pre-communicating with its consumers, we felt that underspecifying authentication mechanisms allowed for each sharing consortium to control their own repositories. Whatever system they are using already for internal/external sharing authentication can be used here as long as it meets the ROLIE requirements.

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

Removed cipher suite text as these recommendations are provided by RFC 7525. 

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

While its true that this is a "don't do anything stupid" requirement, I think that its valuable as a reminder that the authorization checks need to support full granularity through the entire resource tree.

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

Cleaned up the text describing this requirement to be more clear that they only trigger when an implementation has decided to support RFC 6546. Removed the 404 requirement when not supporting RFC6546, as I agree that it was overly restrictive.

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

Atom:content has an attribute for media type, which provides information about the serialization of the content representation. In many cases, we found that different formats can appear for the same content within the same media type. For example, the same piece of information may be represented using two different XML Schemas. The rolie:format element allows the entry to clarify which "format" its using beyond which serialization it is using. Ultimately the format element is not registered anywhere, nor is its contents particularly standardized. We're providing the element as a tool for repository producers to use.

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

The latter example you provide is still possible, as unrecognized elements in ROLIE/Atom don't cause validation to fail, but are just potentially ignored by the client/server. The rolie:property element allows automated systems to have a globally available "vocabulary" of potentially available properties, that can be used to populate tables or fields in automated systems.

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

Agreed, I've clarified the text in this section and removed the normative recommendation.

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

Thanks for catching this, fixed.

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

Agreed, changed.

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

We wanted to stay in line with the requirements in Atom, if this becomes an issue it may be worth re-examining.

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

Agreed. The local registration was providing nothing that XML/Atom don't already provide. As such, we've removed this registration and clarified that any category not registered via the ROLIE table is considered private. This should be more in line with how Atom originally handled categories.

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

Atom:author provides information on the person or entity that authored the entry, while the rolie:content-author-name provides information on the person or entity that authored the content. We found that the two often differed, and added this property to allow both entities to be described. I added some extra text to content-author-name to clarify this.

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

Yes name needs to be unique, I added this requirement. We included an index as an additional unique identifier for the registration as a potential shorthand. We've been discussing the possibility of binary serialization of ROLIE and wanted a shorter form for the registration.

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

Dropped the "secure" descriptor to avoid being misleading.

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

Agreed, none of the privacy issues described included third parties that TLS could keep away.

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

We decided to use Feed for referring to the conceptual Feed, and atom:feed for the actual representation.

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

Agreed, added text explicitly describing the important changes.

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

Reordered and provided some additional text to make the list more clear.

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

I think the formatting issue is caused by the long note to IANA in the first row. When this note is removed the table formatting should be more sensical.

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

Changed.

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

Included your text and removed text that was contributing little, this shorted the paragraph and rendered it more readable. We kept the text listing valid alternatives as we felt it was valuable.

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

Changed.

> _______________________________________________
> mile mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghar
> t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=SykEasQlo1e
> MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=0