[mile] Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-mile-rolie-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Ben, Martin, and Mark: the way this document uses /.well-known/
URIs is not consistent with RFC5785, section 1.1. It should be understood that
/.well-known/ URLs are already a carve-out from overall REST principles
regarding the agency of content publishers to assign URLs within their domain
as they see fit; and, as such, need non-trivial justification for their use.

If there were some fully-defined autodiscovery mechanism that were
(non-artificially) constrained in such a way that only a host and port were
available, then the use of /.well-known/ URIs would be more understandable. The
only constraint hinted at in this document that might have these properties is
the use of DNS SRV records. Given that ROLIE is defining a green-field
protocol, the use of something as constrained as SRV seems ill-advised, given
that the use of NAPTR records would trivially allow retrieval of a complete URL
instead of just a host/port combination.

The bottom line, however, is that we need to defer specification of a
/.well-known/ URL until we completely define a discovery protocol that requires
it. The corollary is that we should avoid defining a discovery protocol that
requires it.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Since ROLIE requires the use of TLS client certificates, all of its resources
need to be conveyed over HTTPS (i.e., ROLIE resources can never use "http" IRI
schemes, only "https" IRI schemes). The following examples need to be fixed to
reflect this:

Section 6.1.2:

         <link rel="self" href="http://example.org/feedA?page=5"/>
         <link rel="first" href="http://example.org/feedA?page=1"/>
         <link rel="prev" href="http://example.org/feedA?page=4"/>
         <link rel="next" href="http://example.org/feedA?page=6"/>
         <link rel="last" href="http://example.org/feedA?page=10"/>

Section B.1:

        <collection href="http://example.org/provider/vulns">
...
        <collection
            href="http://example.org/provider/public/vulns">
...
        <collection
            href="http://example.org/provider/private/incidents">
...
       <link rel="self"
           href="http://example.org/provider/public/vulns" />
       <link rel="service"
           href="http://example.org/rolie/servicedocument"/>
...
         <content type="application/xml"
             src="http://www.example.org/provider/vulns/123456/data"/>
...
       <content type="application/xml"
           src="http://www.example.org/provider/vulns/123456/data">

------------------------------------------------------------

Additionally, the following href values (also in B.1) are illegal, and need to
contain a scheme (presumably, https):

          <atom:link rel="service"
            href="www.example.com/rolie/servicedocument"/>
...
          <atom:link rel="service"
            href="www.example.com/rolie/servicedocument"/>