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

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

Adam,

To avoid arguing semantics on guessability vs discoverability, I would say that at this current stage, the well-known registration allows an automated system to reliably check if a given host is hosting a ROLIE repository, and if they are, to provide the head of that repository. This mechanism is usable across all ROLIE repositories.

Fully automated discoverability is something that we want, and we'll need this registration for that in the future. Guessability, in the mean time, provides demonstrable value.

Thanks,
Stephen

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]]
> Sent: Wednesday, October 25, 2017 5:44 PM
> To: Banghart, Stephen A. (Fed) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; The
> IESG <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS
> and COMMENT)
> 
> Based on the example you gave Martin ("I'd like to give a tool
> 'https://na01.safelinks.protection.outlook.com/?url=www.microsoft.com&d
> ata=02%7C01%7Cstephen.banghart%40nist.gov%7C83c286c926ed4c85274308
> d51bf180ba%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C63644564
> 6445352559&sdata=uH4jvj33bqTg5N2FSjQwgS8KysdxaQ2gdVrwNV3LCjc%3D
> &reserved=0'..."), it sounds like you're not looking for
> *discoverability* as much as you are *guessability*. Is that an accurate
> characterization?
> 
> /a
> 
> On 10/25/17 3:35 PM, Banghart, Stephen A. (Fed) wrote:
> > 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]; mile-
> [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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaila
> rchive.ietf.org%2Farch%2Fmsg%2Fmile%2FgbG5nC8Oh4q76P-0dXHwM-
> ztMPY&data=02%7C01%7Cstephen.banghart%40nist.gov%7C83c286c926ed4c
> 85274308d51bf180ba%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C
> 636445646445352559&sdata=fjcTclj2pcjVyFL0%2F9xmNjVWw8V8XnEfWWJB
> OshqlBM%3D&reserved=0)
> >
> > 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"/>
> >>