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

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

Adam,

Thanks for the review. I've put my comments/changes inline.

Thanks,
Stephen

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]]
> Sent: Wednesday, October 25, 2017 12:04 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Nancy Cam-Winget <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and
> COMMENT)
> 
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fiesg%2Fstatement%2Fdiscuss-
> criteria.html&data=02%7C01%7Cstephen.banghart%40nist.gov%7C08456d09f
> a1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7
> C0%7C636445010437837404&sdata=YCi7gTAwFZDvxiwzV66Iuhnx73ziHe8GJ6J
> MJneINjc%3D&reserved=0
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-mile-
> rolie%2F&data=02%7C01%7Cstephen.banghart%40nist.gov%7C08456d09fa1d
> 4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0
> %7C636445010437837404&sdata=T%2FiVFaPIorBa3igDpRk87MM%2Bl1sw1hA
> rBEhqmqqjVjI%3D&reserved=0
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 

I replied to Martin's concern on this issue in an earlier e-mail and I think we've reached agreement on the justification for the well-known registration (https://mailarchive.ietf.org/arch/msg/mile/gbG5nC8Oh4q76P-0dXHwM-ztMPY)

We believe that we have a minimal use case/discovery story where ROLIE clients only have the host name and port for a potential ROLIE server, and need a standardized way to check/locate the metadata of an associated ROLIE repository. In these cases automated systems need a means to locate a ROLIE repository without a human needing to track down a link through browsing the site, email, etc. Providing a URL template for the Service Document allows these automated systems to find the head of the ROLIE repository, from there it can browse the rest of the Collections/Entries present.

We've added additional text to the section in order to provide more justification/reasoning around our well-known registration. I've provided the new paragraph here:

"ROLIE repositories are largely intended to be consumed by automated systems. While humans may be able to navigate a web page or receive an email to find a link to the repository, automated systems struggle with such tasks. By creating a standardized location for the Service Document, ROLIE clients need only a host name and port in order to locate a ROLIE repository. This lower barrier to entry reduces the amount of human intervention required for ROLIE clients to begin reading Feeds."

We discussed this within the MILE WG and the WG agreed to define the .well-known approach, but to defer on a specific means to determine the host and port of the server at this time. This will allow the group to get some implementation experience with ROLIE, while reviewing the SRV and NAPTR record approaches to determine what the best approach is. We can then write another draft that provides these details when we are ready. In any case, we still need a way to discover the Service Document, so the WG found it to be prudent to do that now.

Following Martin's comments, we removed the well-known registration for the Category Document, as this is discoverable from the Service Document.

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

Thanks for catching this. The links have been changed to https.

> Section 6.1.2:
> 
>          <link rel="self"
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2FfeedA%3Fpage%3D5&data=02%7C01%7Cstephen.banghart
> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=N2XIUWecIr%
> 2BoEHnBSTVZS0X2BZRBdpR3N%2BWHYC3UZI4%3D&reserved=0"/>
>          <link rel="first"
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2FfeedA%3Fpage%3D1&data=02%7C01%7Cstephen.banghart
> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=r2w32N%2B8F
> JYWnVIObX%2BLWSuyCyLV%2BHAEQlKRAEBkAo0%3D&reserved=0"/>
>          <link rel="prev"
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2FfeedA%3Fpage%3D4&data=02%7C01%7Cstephen.banghart
> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=QhEYN4Z%2F
> %2B8neikPNwJGL%2BGtoEU0gBrVlQbanXnaQrgQ%3D&reserved=0"/>
>          <link rel="next"
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2FfeedA%3Fpage%3D6&data=02%7C01%7Cstephen.banghart
> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=pEJKm1Zuyj6S
> dDUkUkCrQURq5KzMmawwTISZSWd3%2B3o%3D&reserved=0"/>
>          <link rel="last"
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2FfeedA%3Fpage%3D10&data=02%7C01%7Cstephen.banghar
> t%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=mH77rw1TlsX
> 8JuOY3EHJyOEpEzGPcokuxgiT%2F32%2FlkY%3D&reserved=0"/>
> 
> Section B.1:
> 
>         <collection
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2Fprovider%2Fvulns&data=02%7C01%7Cstephen.banghart%4
> 0nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93
> e054655c61dec%7C1%7C0%7C636445010437837404&sdata=SHNoV3KOd9BxB
> ngCKAmpnKwx9AqfWBTdZTTevIZFMcw%3D&reserved=0">
> ...
>         <collection
> 
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2Fprovider%2Fpublic%2Fvulns&data=02%7C01%7Cstephen.ba
> nghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8f
> a4797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=Bt2SOn0
> bseMv9ZE3dxkm5%2FtqFJosQKE1XC4OpRfkHZw%3D&reserved=0">
> ...
>         <collection
> 
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2Fprovider%2Fprivate%2Fincidents&data=02%7C01%7Cstephe
> n.banghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d8
> 2fd8fa4797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=TX
> NY424A3JuHjqMlPoRfZmVTlwRq0%2FGSeWFIPgblPe0%3D&reserved=0">
> ...
>        <link rel="self"
> 
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2Fprovider%2Fpublic%2Fvulns&data=02%7C01%7Cstephen.ba
> nghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8f
> a4797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=Bt2SOn0
> bseMv9ZE3dxkm5%2FtqFJosQKE1XC4OpRfkHZw%3D&reserved=0" />
>        <link rel="service"
> 
> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> example.org%2Frolie%2Fservicedocument&data=02%7C01%7Cstephen.bang
> hart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4
> 797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=zoDLn699V
> T%2FlqiYzauR1ItbKSiIq%2FbhwUzwhMt7u5oI%3D&reserved=0"/>
> ...
>          <content type="application/xml"
> 
> src="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.example.org%2Fprovider%2Fvulns%2F123456%2Fdata&data=02%7C01%
> 7Cstephen.banghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%
> 7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636445010437837404&
> sdata=hDThkxcmP30XYHMeD58AaT9kJsNo51L97NTAnVTnUPs%3D&reserved
> =0"/>
> ...
>        <content type="application/xml"
> 
> src="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.example.org%2Fprovider%2Fvulns%2F123456%2Fdata&data=02%7C01%
> 7Cstephen.banghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%
> 7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636445010437837404&
> sdata=hDThkxcmP30XYHMeD58AaT9kJsNo51L97NTAnVTnUPs%3D&reserved
> =0">
> 
> ------------------------------------------------------------
> 
> Additionally, the following href values (also in B.1) are illegal, and need to
> contain a scheme (presumably, https):

Also fixed.

>           <atom:link rel="service"
> 
> href="https://na01.safelinks.protection.outlook.com/?url=www.example.co
> m%2Frolie%2Fservicedocument&data=02%7C01%7Cstephen.banghart%40ni
> st.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e0
> 54655c61dec%7C1%7C0%7C636445010437837404&sdata=rank6Smbmq%2BQs
> GpVJ1qscYn%2F3SA0krqKDPQB5GSxm1Q%3D&reserved=0"/>
> ...
>           <atom:link rel="service"
> 
> href="https://na01.safelinks.protection.outlook.com/?url=www.example.co
> m%2Frolie%2Fservicedocument&data=02%7C01%7Cstephen.banghart%40ni
> st.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e0
> 54655c61dec%7C1%7C0%7C636445010437837404&sdata=rank6Smbmq%2BQs
> GpVJ1qscYn%2F3SA0krqKDPQB5GSxm1Q%3D&reserved=0"/>
>