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

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Oct 2017 19:10:44 -0700

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

-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'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.

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

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

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

-8.3: What is the registration policy for the top level registry?

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

Editorial:

-5.1.2, definition of ROLIE collection: This uses the MUST as a definition,
rather than a normative requirement. It would be sufficient to say that a ROLIE
collection _is_ one that contains...

-5.1.3: Typo on first word "..his".
-- "requires that an implementation MUST publish"
"requires" and "MUST" are redundant. Consider simply saying "An implementation
MUST publish..."

-6: "The normative requirements in this section are generally oriented towards
any content to be published to a ROLIE server." I don't understand the intent
here. What else would they be about?

8.1, XML:
s/"section A" / "appendix A"

---

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

Ben,

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

Thanks,
Stephen

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2017 10:11 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Nancy Cam-Winget <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Ben Campbell'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%7Cab55648c
> 898f4291535708d51b4d9a50%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7
> C0%7C636444942482475233&sdata=rfVq54TJBPZDlpiVa2uf7%2B2OI31PnAonh
> MQVDlCyUvA%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%7Cab55648c898f
> 4291535708d51b4d9a50%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%
> 7C636444942482475233&sdata=T%2FhpAG02iZ%2BDDvqziEcfOMIRDz69C9hV
> b02Y7Xi0t7Y%3D&reserved=0
> 
> 
> 
> 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 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) 

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

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

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

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

> reasonable to offer guidance, but I think consortiums are going to do
> whatever they want here.

Reworded this paragraph into a non-normative recommendation.

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

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

> rather than a normative requirement. It would be sufficient to say that a
> ROLIE collection _is_ one that contains...

We've reworked the text to be more appropriate definitions of terms, and removed all normative text from them. The updated definitions follow:

"An app:collection is considered a ROLIE Collection when it contains an app:categories element that contains only one atom:category element with the "scheme" attribute value of "urn:ietf:params:rolie:category:information-type". Further, this category has an appropriate "term" attribute value as defined in section . This ensures that a given Collection corresponds to a specific type of security automation information.

An app:collection is considered a non-ROLIE Collection when it does not contain an atom:category element with a "scheme" attribute value of "urn:ietf:params:rolie:category:information-type"."

> "requires" and "MUST" are redundant. Consider simply saying "An
> implementation MUST publish..."

Agreed, changed.

> -6: "The normative requirements in this section are generally oriented
> towards any content to be published to a ROLIE server." I don't understand
> the intent here. What else would they be about?

This sentence does seem rather strange in retrospect. I've struck the whole sentence and changed the wording slightly. Here is the new text:

" This section describes a number of restrictions of and extensions to the Atom Syndication Format that define valid use of the format in the context of a ROLIE implementation. An understanding of the Atom Syndication Format specification  is helpful to understand the requirements in this section."

> s/"section A" / "appendix A"

Fixed.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Oct 2017 22:35:06 -0500

Thanks for the response. Comments also inline:

> On Oct 25, 2017, at 3:10 PM, Banghart, Stephen A. (Fed) <[email-masked]> wrote:
> 
> Ben,
> 

[…]

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

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

> The lower case keywords are intentional. We've switched the boilerplate text to the updated 8174 version.

Okay.

> 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 practic…

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.

> Reworded this paragraph into a non-normative recommendation.

Okay.

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

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

---

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

Ben,

My responses are inline.

Thanks,
Stephen

> Sent: Wednesday, October 25, 2017 11:35 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: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS
> and COMMENT)
> 
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]; Nancy Cam-Winget <[email-masked]>;
> >> [email-masked]; [email-masked]; [email-masked]
> >> Subject: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with
> >> DISCUSS and COMMENT)
> >>
> 
> […]
> 
> >>
> >> 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.
> >
> > "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.
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 27 Oct 2017 16:44:47 -0500

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

I think we are talking past each other. I understand the use case. I haven’t seen an explanation about why you think that use case fits the guidance from section 1.1 of RFC 5785. (I note the expert reviewer for the .well-known URL registry gave the same feedback.)

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

Why do you assume that the ROLIE data is at at microsoft.com and not rolie.microsoft.com? Do you assume the data is at the default HTTPS port? (I don’t recall seeing either in the draft, but may have missed it.) I think this was the sort of questions Adam had in mind when he described this as “guessing”.

(You could learn the port via DNS SRV, but as you clarified, that’s not specified yet.)

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

It’s laying that foundation based on an assumption that may or may not be well founded. Do you have a mechanism in mind?

More to the point, RFC 5785 says “[well-known URLs] are designed to facilitate discovery of information on a site when it isn't practical to use other mechanisms” You could fairly easily specify a discovery system that doesn’t require a well-known registration. Adam’s comment about DNS NAPTR is an existence proof. Is there a reason why that would not be practical?

If the justification for the well-known registration is that the discovery mechanism will likely need it, then I propose the registration be done as part of the spec for the discovery mechanism.

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

Just to make sure my point is clear: The fact that a schema is incomplete does not normally make it non-normative. Do you believe the ROLIE spec would be complete without the schema? If the answer is no, then the schema is effectively normative. If the answer is yes, then why include it at all?

Thanks!

Bne.