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

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

Ben,

My responses are inline.

Thanks,
Stephen

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Wednesday, October 25, 2017 11:35 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: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS
> and COMMENT)
> 
> Thanks for the response. Comments also inline:
> 
> > On Oct 25, 2017, at 3:10 PM, Banghart, Stephen A. (Fed)
> <[e-mail]> wrote:
> >
> > Ben,
> >
> > Thanks for the review, I've put my comments/changes inline.
> >
> > Thanks,
> > Stephen
> >
> >> -----Original Message-----
> >> From: Ben Campbell [mailto:[e-mail]]
> >> Sent: Tuesday, October 24, 2017 10:11 PM
> >> To: The IESG <[e-mail]>
> >> Cc: [e-mail]; [e-mail];
> >> [e-mail]; Nancy Cam-Winget <[e-mail]>;
> >> [e-mail]; [e-mail]; [e-mail]
> >> Subject: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with
> >> DISCUSS and COMMENT)
> >>
> 
> […]
> 
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> DISCUSS:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >> -5.1.3:
> >>
> >> I don't think Martin's  ART-ART review concern (and Mark's support)
> >> about the .well-known URL registration has been fully resolved. While
> >> version 11 removed some of the well-known registrations, it still
> >> leaves the one.  Mark pointed out that RFC 5785 offers explicit
> >> guidance that .well-known URLs are intended to offer site-wide policy
> >> or metadata, and are not intended for general information retrieval,
> >> or to establish a namespace.  This usage seems to me to be exactly the
> sort of thing that the RFC advises against.
> >>
> >> I recognize that security information is important, but I don't
> >> understand why it's discovery needs to be fundamentally different
> >> than for other stuff on using ATOM. I'm willing to be convinced, but
> >> if there's been a convincing argument so far I've missed 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-
> ztMP
> > Y)
> >
> > ROLIE is largely intended to be handled by automated systems that cannot
> reliably locate links given by front-facing sites. In these cases, the ROLIE
> clients need a reliable way of finding a ROLIE repository hosted by a given
> server. The well-known registration provides a standardized place for the
> head of the ROLIE repository to be retrieved, making it possible for an
> automated system to function when only given a host name and port.
> >
> > We've added the following additional justification text to the specification
> to help clarify our reasoning.
> >
> > "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.”
> 
> It’s not clear to me why its substantially easier to learn name and port than it
> is to learn a URL. As Adam pointed out in his separate DISCUSS, there’s no
> discovery mechanism (yet) for the hostname and port—that is, someone will
> have to tell that automated system what name and port to use. Adam also
> pointed out that there are potential design paths (e.g. NAPTR) for discovery
> mechanisms that would give you a URL.
> 
> .well-known URLs are intended for when no other discovery mechanisms
> make sense.

We are considering the use case where a vendor wants to provide security automation information through ROLIE, such as public disclose of vulnerabilities, or software metadata. Potential consumers know the hostname and port of the vendor already, but need to know where to find the ROLIE repository. In this case, providing a tool with a hostname and port is substantially easier than tracking down a ROLIE Service Document URL.

For example, if I want to have my ROLIE client tool check to see if Microsoft is hosting a ROLIE repository, I need only to provide it with "http://microsoft.com" and it'll do the rest.

Additionally, we feel that a well-known registration will be needed for a full discovery system, and as such, this is laying the foundation for that work in the future. 

> >
> > We've dropped the well-known registration for the Category Document, as
> it is locatable from the Service Document where applicable.
> 
> > >
> >> I'm not sure what to make of the second paragraph. It says DNS SRV
> >> can be used to determine the host and port. Is the expectation that
> >> people can just do that without further specification, or that
> >> someone could specify it in the future?
> >> The former is generally not true. If the intent is the latter, please
> >> clarify that in the text.
> >
> > The intent was the latter. I've changed the end of that paragraph to further
> clarify as follows:
> >
> > "Use of a mechanism such as DNS SRV Records  can provide a secure and
> reliable discovery mechanism for determining a specific host and port to use
> for retrieving a Service Document for a given DNS domain. This is a feature
> that may be standardized in the future.”
> 
> That would resolve my concern.
> 
> >
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> COMMENT:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >> Substantive:
> >>
> >> -2: There are a number of lower case versions of 2119 keywords. If
> >> those are intentional, please use the updated boilerplate from RFC
> >> 8174. That being said, the following paragraph says the keywords are used
> for conformance.
> >> 2219/8174 keywords are not about conformance. They are about
> >> interoperability. If you want to use them for conformance, that's
> >> okay--but that means they are no longer being used as intended by
> >> 2119, and the boilerplate should be adjusted accordingly.
> >
> > The lower case keywords are intentional. We've switched the boilerplate
> text to the updated 8174 version.
> 
> Okay.
> 
> >
> >> -3.2: I'm confused by the idea the schema is informative. I expect
> >> that at least some implementors will implement  to the schema. We
> >> have a perennial problem where implementors implement the examples
> >> rather than the text. It seems like a non-normative schema is even
> >> more of an attractive hazard in that regard.
> >
> > We found that available schema languages cannot express the same
> complexities we could express in text. There are difficult conditional
> requirements that are poorly expressed in schemas but can be fit into a neat
> sentence. In order to support the places where we do that, we decided that
> making the text normative was the only way to ensure that the
> requirements were expressed clearly.
> >
> > Additionally, Atom Syndication and the Atom Publishing Protocol both
> specify that the text is normative, not the included schemas. By making the
> schema informative, we are keeping with this practice.
> 
> Do you believe an implementer could reasonably code this just from the text
> without looking at the schema?
> 
> The problem of needing additional constraints over what can be expressed in
> a formal language, whether that’s a schema, ABNF, etc, is common. It’s
> typical to still consider the normative definition to include both the formal
> definition and those additional constraints.

Given that an implementer would need to carefully read the plain text in either case, we feel that using the most expressive option for the normative requirement is the best way of doing it.

Having written an implementation of Atom Pub (Which uses normative plain text) and of ROLIE, I wish I could just copy and paste some schema and be done, but given that it isn’t possible, using the plain text to implement wasn't bad.

> >
> >> -5.4, 2nd paragraph: This seems like an odd thing to state
> >> normatively. It seems to push for a specific organizational model for
> >> consortiums. It's reasonable to offer guidance, but I think
> >> consortiums are going to do whatever they want here.
> >
> > Reworded this paragraph into a non-normative recommendation.
> 
> Okay.
> 
> >
> >> -8.3: What is the registration policy for the top level registry?
> >
> > There was some misleading text that discussed a registry that we didn't
> intend to be created. We've fixed the text to make it clear that there is only
> one registry being defined (ROLIE URN Parameters) in this section. The
> updated text is provided here:
> >
> > "A new top-level registry has been created, entitled "Resource
> > Oriented Lightweight Information Exchange (ROLIE) URN Parameters". [TO
> > BE REMOVED: This registration should take place at the following
> > location: https://www.iana.org/assignments/rolie]
> >
> > Registration in the ROLIE URN Parameters registry is via the Specification
> Required policy . Designated Expert reviews should be routed through the
> MILE WG mailing list. Failing this, the Designated Expert will be assigned by
> the IESG.”
> >
> 
> Okay, that works for moe.
> 
> >> -10:   "Overall, ROLIE introduces few privacy concerns above and beyond
> >> those
> >> present in any other HTTP protocol. " I'm skeptical that that is
> >> true. Security information seems likely to be privacy sensitive,
> >> especially compared to some notional "generic" HTTP based protocol.
> >
> > We've rewritten this last paragraph to provide more clear details around
> privacy concerns in ROLIE. The updated text is provided here:
> >
> > "Overall, privacy concerns in ROLIE can be mitigated by following security
> considerations and careful use of the optional personally identifying
> elements (e.g., author) provided by Atom Syndication and ROLIE.”
> 
> Okay.
> 
> [Your responses to my editorial comments all look good.]
> 
> Thanks!
> 
> Ben.