Re: [mile] Working group last call for ROLIE

["Panos Kampanakis (pkampana)" <[e-mail]>]

Hello,

I did a final pass. The doc looks good. I think it is almost ready for publication.

I had some last minor suggestions, nits below:

·        s/MUST publish an Category Document that/MUST publish a Category Document that

·        s/URL of the appropriate RID endpoint /URL of the appropriate ROLIE endpoint

·        Section 7.4 mentions “In order to provide a global reference for these properties, this document establishes an IANA registry in Section 7.4<https://tools.ietf.org/html/draft-ietf-mile-rolie-06#section-7.4>”. So you are referring to the section in the section itself.

·        We should have caught this earlier, but there is something that came up in the ACE group multiple times: When using fixed URIs we should put them under the .well-known directory according to https://tools.ietf.org/html/rfc5785. So for every https://{host:port}/rollie/<https://%7bhost:port%7d/rollie/>... it should be https://{host:port}/.well-known/rolie/...

·        “for use in a ROLIE Any element not specified here inherits its definition and requirements” does not read well. I think it should be two sentences.

·        “An atom:feed may include additional atom:category elements using a” should be a “MAY” instead of  “may” right?

·        In 6.2.3, the paragraph “or example, the nominal element <rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"…” should be moved one paragraph above with the paragraph that talks about schema-location

·        About “The server MUST support certificate-based client authentication.” and the last paragraph n section 5.3, I can see usecases where the client does not need to be authenticated when the security information to be shared is public and does not contain any confidential info. Would it be worth to state “In usecases where client authentication is required to access the shared information use TLS client certs”? Also, mandating client cert auth is slightly aggressive. There might be usecases where HTTP Basic or Digest authentication/authorization (described in Section 5.4) would be sufficient. Would it be worth to make TLS client certs a SHOULD.

·        In section 5.3, RFC5280 is referenced. Section 6.3 explains how CRL revocation checks are performed. Even though the draft deals with CRLs it explains that the revocation status can be checked with other methodologies. I am suggesting to spell out in section 5.3 that CRL or OCSP/OCSP stapling are both acceptable for verification of revocation status.

·        In section 5.4, “Implementations MUST support user authentication.  User authentication MAY be enabled for specific Feeds.” Is slightly confusing. User auth is mandatory and the it is a MAY for Feeds? It is worth to rephrase it more clearly.

·        Make sure to remove the paragraph with “[TO BE REMOVED:” in section 8.3.

·        In section 9, “public education may choose to rely upon HTTP Authentication or similar”, I would suggest to reconsider, as I mention above, if authentication is necessary for public information that can be shared openly.

Rgs,
Panos


From: mile [mailto:[e-mail]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, March 28, 2017 7:27 PM
To: [e-mail]
Subject: [mile] Working group last call for ROLIE

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