Re: [mile] Working group last call for ROLIE

["Schmidt, Charles M." <[e-mail]>]

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

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.

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.

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?

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

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