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

From: Adam Roach <[email-masked]>
Date: Tue, 24 Oct 2017 21:03:57 -0700

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"/>

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Wed, 25 Oct 2017 20:35:56 +0000

Adam,

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

Thanks,
Stephen

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2017 12:04 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Nancy Cam-Winget <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and
> COMMENT)
> 
> 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
> 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
> 
> 
> 
> 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.
> 
> 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.

> 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"/>
> ...
> 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"/>
> ...
> 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">
> 

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"/>
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Oct 2017 16:43:47 -0500

Based on the example you gave Martin ("I'd like to give a tool 
'www.microsoft.com'..."), it sounds like you're not looking for 
*discoverability* as much as you are *guessability*. Is that an accurate 
characterization?

/a

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 26 Oct 2017 15:41:50 +0000

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

> Sent: Wednesday, October 25, 2017 5:44 PM
> To: Banghart, Stephen A. (Fed) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; The
> IESG <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS
> and COMMENT)
> 
> '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
> email
> /.well-
> > 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.
> >
> need