Re: [mile] Working group last call for ROLIE

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

Charles,

Thanks for the comments and review, I've put my responses in-line.

Several of your comments speak to some focus issues in the front matter (sections 1 and 4). In lieu of attempting to address each of these issues individually, I believe the document would benefit most from these sections being tightened and condensed to focus on the most important aspects of ROLIE. These edits would only address the front matter and have no normative impact on the specification, so I'll make those edits on the Github to be included with the rest of the incorporated feedback.

I'll inform you and the list on the status of those changes as they occur.

-Stephen Banghart

> -----Original Message-----
> From: mile [mailto:[e-mail]] On Behalf Of Schmidt, Charles M.
> Sent: Monday, April 24, 2017 3:44 PM
> To: [e-mail]
> Subject: Re: [mile] Working group last call for ROLIE
> 
> Hello,
> 
> I have only gotten as far as 5.1.2 (inclusive), but in the interest of getting this
> information to you sooner rather than later, my comments so far are below:
> 
> Section 1:
> - "As the set of resource Collections are forward facing, the consumer may
> search all available content for which they are authorized to view, and
> request the information resources which are desired." - I wasn't sure what
> "forward facing" means in this case. Also, I found the wording a bit awkward.
> I suggest rewriting the second clause as, "the consumer may search all
> available content they are authorized to view, and request the desired
> information resources."

Forward-facing was intended to note that the collections are easily visible to the user, I've changed the wording of the first clause to reflect that and accepted your change on the second clause.

> - Paragraph 1, second to last sentence: In the preceding sentences, you talk
> about a customer contacting repository and requesting data. This sounds like
> a point-to-point solution. This makes the penultimate sentence of the
> paragraph, which describes point-to-point messaging as the "old way" of
> doing things over which ROLIE provides an improvement, very odd sounding.
> I understand how ROLIE does, in fact, go beyond point-to-point relationships,
> but given that, thus far, only the point-to-point aspects of ROLIE have been
> discussed, the contrast seems off.
> - Paragraph 1, second to last sentence: you point out that the "old way" of
> doing things involves an interaction "following a triggering event". I would
> argue that all automated systems follow "a triggering event" of some kind, so
> I think you need some more context here if you are going to contrast ROLIE
> with "triggering event"-driven systems.
> - Paragraph 1, last sentence: You describe some disadvantages of point-to-
> point systems here. I don't think I agree with any of your assertions here.
> Specifically, HTTP is used in point-to-point solutions and I would argue that it
> is not inherently closed, duplicative, or hindering of automated security.
> 

See top of message.

> Section 2:
> - Definition of Information Type: You state that this is a class of information
> "that can be automated". So does this mean that ROLIE will not support
> dissemination of security information unless that information can support
> automation? I think a fair amount of cyber threat intelligence (for example)
> remains informative in nature, but there is still a value to its dissemination.

Agreed, we've changed the definition to "A class of security automation information having an associated data model. Often this information is the subject of a security process that can be automated." in order to be more inclusive of human information whilst making it clear that this is automation focused.

> Section 4:
> - General comment: I think this section overlooks some of the real benefits
> of ROLIE while simultaneously making some questionable claims about it. The
> way I see it, the main ROLIE benefits are:
> 1) Open interface for virtually any type of cybersecurity information. While
> most existing tools focus on a specific kind of info, ROLIE seeks to be the
> common language.
> 2) Distributed model making it make new data available in an existing
> network and have it be found by users.
> 3) Stateless communication model simplifies use. (You dance around this in
> 4.3, but spend most of that time talking about other supposed aspects of
> RESTful systems and less about the state.) I think these are important values
> of ROLIE and are more real than many of the other claims.
> 
> Section 4.1:
> - General comment: I have read this section a few times and still do not
> understand what you are claiming. In first paragraph you point out the old
> way requires consumers to gather information and then to evaluate it. Thus
> (by implication), a contrasting new way would just have the data appear, and
> for it to be the right data even if the consumer doesn't know what they
> need.
> By contrast, in the last paragraph you talk about more typical "search a body
> of data and request what you need". Again, you state how the old ways are
> weak, but then describe a solution that seems to use those same methods.
> 
> Section 4.2:
> - Section title: I think "Knowledge *Aggregation*"  is the wrong word.
> Aggregation implies that many sources are being integrated into a unified set
> of information. What you describe in paragraph 1 is "having lots of
> information", paragraph 2 is "having the right information", and paragraph 3
> alludes to a federated model. I'm not really sure what your main point is, but
> it doesn't seem to be "aggregation".
> 
> Section 4.3:
> - Paragraph 2, sentence 1: "A key aspect of any RESTful Web service is the
> ability to provide multiple resource representations." - This is an aspect of
> multiple RESTful implementations (HTTP, Atom, etc.), but it is not part of any
> definition of the RST Model itself as far as I have found. My understanding is
> that REST is about the exchange more than the data. Maybe I'm looking at
> the wrong reference...
> - Paragraph 3, sentence 1: "Finally, an important principle of the REST
> architectural style is the focus on hypermedia as the engine of application
> state (HATEOAS)." - I think this statement is a mischaracterization. HATEOAS
> is defined as a constraint/refinement of REST. As such, it builds on REST
> rather than serving as a core principle of it.
> 

See top of message.

> Section 5.1
> - Figure: I think you need an ellipsis or some other indicator of variable
> numbers, or does each service contain exactly two Workspaces, each with
> one Collection, and each of those with one child?
> 

Each workspace and collection can be zero to many. We'll add some notation to show that cardinality.

> Section 5.1.1
> - Bullet 1: "I'm confused by this recommendation. If a Workspace contained a
> mix of public and private data, would it not be possible to hide the private
> data in that case? What about the case where you have multiple levels of
> access for private data - should each level have its own workspace? I'm
> assuming ROLIE supports highly granular access controls, so the "separate
> workspace for public and private data so that private data can be hidden"
> seems like it fails to encompass the versatility that people will want to have."

We've provided this just as a recommendation because there are a couple way to handle the situation. You certainly could hide each collection independently, you could even hide entries individually. By moving the authentication check to the highest level available you avoid potential performance issues and reduce the attack surface.

> 
> I hope this is helpful. I'll try to have comments on more of the spec soon.
> 
> Charles
> 
> > -----Original Message-----
> > From: mile [mailto:[e-mail]] On Behalf Of Nancy
> > Cam-Winget
> > (ncamwing)
> > Sent: Tuesday, March 28, 2017 6:27 PM
> > To: [e-mail]
> > Subject: [mile] Working group last call for ROLIE
> >
> > Colleagues,
> >
> >
> >
> > Given the significant changes made to the last draft, we are doing
> > another 30day WGLC for
> >
> > https://tools.ietf.org/html/draft-ietf-mile-rolie-06
> >
> >
> >
> > Please provide comments before May 1st and provide your support and/
> > or raise any issue you feel are yet to be addressed.
> >
> >
> >
> > Regards, Nancy
> 
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile