Subject: [mile] Comments on ROLIE draft draft-ietf-mile-rolie-07

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 6 Jul 2017 19:17:51 +0000

Hello,

I was part of a group that did a normative text review of the ROLIE draft and we had some feedback on the -07 draft of the spec.

Section 5.1.2, bullet 3 & Section 6.1.1, bullet 2: Both of these state that an atom: category element with a "scheme" attribute that is not  "urn:ietf:params:rolie:category:information-type" MUST NOT be considered a ROLIE Collection. (5.1.2 says that it MUST be considered not a ROLIE collection, while 6.1.1 says it MUST NOT be considered a ROLIE collection). In addition to be redundant, I don't believe the spec speaks about the implications of a collection not being a ROLIE collection (which makes the normative requirement that it be categorized as such seem odd). Is this just meant to imply that the processing outlined in the ROLIE specification MUST NOT be applied to them?

Section 5.3, paragraph 3: "The server MUST support certificate-based client authentication. The implementation MAY use any TLS cipher suite that supports mutual authentication." The second sentence seems ambiguous in its implications. Does it mean that one may use any mutual authentication suite but are not allowed to use suites that do not support mutual authentication? Or is it just emphasizing that you may support mutual authentication suites but may also support non-mutual authentication suites (in which case the statement seems vacuous)?

Section 5.3, paragraph 5: "Client implementations SHOULD support an equivalent certificate validation approach to the what is defined in Section 6 of [RFC5280], but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings)." My confusion is with "supplement that algorithm ... to achieve equivalent verification". If you are "supplementing" the recommended algorithm, then you should be going beyond the level of verification the algorithm provides, right? Is the second clause just a restatement of the first in saying that validation algorithms *equivalent* to RFC5280 are allowed? And if so, then this is actually triply redundant since RFC5280 itself states that algorithms equivalent to the one it defines are compliant with the standard.

Section 5.5, paragraph 1: "If the "/" resource is supported the following behavior MUST be also supported:" The specification then goes on to list requirements, but all requirements are "SHOULD" and "MAY". I'm not sure what it means to say you MUST support a MAY requirement. I recommend removing the MUST from this sentence and restating it in a non-normative way.

Section 7.1, paragraph 3: "Any category whose "scheme" attribute uses this as a prefix MUST be considered private use. Implementations encountering such a category MUST parse the content without error, but MAY otherwise ignore the element." I am confused by the statement that the category "MUST be parsed" but "MAY be ignored". I spoke to Stephen and he suggested that "parsed" might be better replaced with "validated", which makes more sense to me.

Section 7.4, paragraph 3: "Any category whose "scheme" attribute uses this as a prefix MUST be considered private use. Implementations encountering such a category MUST parse the content without error, but MAY otherwise ignore the element." Same comment and potential solution as 7.1.
 
Section 9, paragraph 2: "All security measures SHOULD be enforced at the source, that is, a provider SHOULD NOT return any Feed content or member Entry content for which the client identity has not been specifically authenticated, authorized, and audited." This makes it sound like enforcing security mechanisms is recommended but not required.

I hope this helps.

Charles