Subject: Re: [mile] Working group last call for ROLIE

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 5 Apr 2017 14:30:38 +0000

Hello,

I did a final pass. The doc looks good. I think it is almost ready for publication.

I had some last minor suggestions, nits below:

·        s/MUST publish an Category Document that/MUST publish a Category Document that

·        s/URL of the appropriate RID endpoint /URL of the appropriate ROLIE endpoint

·        Section 7.4 mentions “In order to provide a global reference for these properties, this document establishes an IANA registry in Section 7.4<https://tools.ietf.org/html/draft-ietf-mile-rolie-06#section-7.4>”. So you are referring to the section in the section itself.

·        We should have caught this earlier, but there is something that came up in the ACE group multiple times: When using fixed URIs we should put them under the .well-known directory according to https://tools.ietf.org/html/rfc5785. So for every https://{host:port}/rollie/<https://%7bhost:port%7d/rollie/>... it should be https://{host:port}/.well-known/rolie/...

·        “for use in a ROLIE Any element not specified here inherits its definition and requirements” does not read well. I think it should be two sentences.

·        “An atom:feed may include additional atom:category elements using a” should be a “MAY” instead of  “may” right?

·        In 6.2.3, the paragraph “or example, the nominal element <rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"…” should be moved one paragraph above with the paragraph that talks about schema-location

·        About “The server MUST support certificate-based client authentication.” and the last paragraph n section 5.3, I can see usecases where the client does not need to be authenticated when the security information to be shared is public and does not contain any confidential info. Would it be worth to state “In usecases where client authentication is required to access the shared information use TLS client certs”? Also, mandating client cert auth is slightly aggressive. There might be usecases where HTTP Basic or Digest authentication/authorization (described in Section 5.4) would be sufficient. Would it be worth to make TLS client certs a SHOULD.

·        In section 5.3, RFC5280 is referenced. Section 6.3 explains how CRL revocation checks are performed. Even though the draft deals with CRLs it explains that the revocation status can be checked with other methodologies. I am suggesting to spell out in section 5.3 that CRL or OCSP/OCSP stapling are both acceptable for verification of revocation status.

·        In section 5.4, “Implementations MUST support user authentication.  User authentication MAY be enabled for specific Feeds.” Is slightly confusing. User auth is mandatory and the it is a MAY for Feeds? It is worth to rephrase it more clearly.

·        Make sure to remove the paragraph with “[TO BE REMOVED:” in section 8.3.

·        In section 9, “public education may choose to rely upon HTTP Authentication or similar”, I would suggest to reconsider, as I mention above, if authentication is necessary for public information that can be shared openly.

Rgs,
Panos

From: mile [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, March 28, 2017 7:27 PM
To: [email-masked]
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

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 13 Apr 2017 15:07:31 +0000

Panos,

Thanks for the review! Comments inline.

Your suggestions and other small fixes are being added in our Github repo for the document, if you or anyone else would like to follow along or provide feedback here is the URL: https://github.com/CISecurity/ROLIE

Thanks,
Stephen Banghart

From: mile [mailto:[email-masked]] On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, April 05, 2017 10:31 AM
To: Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]
Subject: Re: [mile] Working group last call for ROLIE

Hello,

Changed.

·         s/URL of the appropriate RID endpoint /URL of the appropriate ROLIE endpoint
I believe that this line is actually referring to a RID endpoint correctly. If a client sends a request to “/” they may be redirected to a RID endpoint.

Fixed.

·         We should have caught this earlier, but there is something that came up in the ACE group multiple times: When using fixed URIs we should put them under the .well-known directory according to https://tools.ietf.org/html/rfc5785. So for every https://{host:port}/rollie/<https://%7bhost:port%7d/rollie/>... it should be https://{host:port}/.well-known/rolie/<https://%7bhost:port%7d/.well-known/rolie/>...
Agreed, we’ve made this change and updated the examples to reflect it. We’ll also add an IANA registration for the .well-known location.

Fixed.

·         “An atom:feed may include additional atom:category elements using a” should be a “MAY” instead of  “may” right?]
Fixed

·         In 6.2.3, the paragraph “or example, the nominal element <rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"…” should be moved one paragraph above with the paragraph that talks about schema-location
I changed the example to better fit at the end of the section, does that resolve your concern?

·         About “The server MUST support certificate-based client authentication.” and the last paragraph n section 5.3, I can see usecases where the client does not need to be authenticated when the security information to be shared is public and does not contain any confidential info. Would it be worth to state “In usecases where client authentication is required to access the shared information use TLS client certs”? Also, mandating client cert auth is slightly aggressive. There might be usecases where HTTP Basic or Digest authentication/authorization (described in Section 5.4) would be sufficient. Would it be worth to make TLS client certs a SHOULD.
The intention of the requirement is that implementations MUST support the authentication, but that any given repo may use it as they see fit. Publicly shared repos wouldn’t require this, but the implementation they use MUST have support for it if that repo desired authentication. To help avoid confusion, we’ve added a section in the front matter that clarifies that all requirements in the document pertain to implementations, not usage.

·         In section 5.3, RFC5280 is referenced. Section 6.3 explains how CRL revocation checks are performed. Even though the draft deals with CRLs it explains that the revocation status can be checked with other methodologies. I am suggesting to spell out in section 5.3 that CRL or OCSP/OCSP stapling are both acceptable for verification of revocation status.
Changed the wording to make it clear that any functionally equivalent method is acceptable.

·         Make sure to remove the paragraph with “[TO BE REMOVED:” in section 8.3.
The “TO BE REMOVED” is an IANA action that should be processed during publication without our interference (hopefully).

·         In section 9, “public education may choose to rely upon HTTP Authentication or similar”, I would suggest to reconsider, as I mention above, if authentication is necessary for public information that can be shared openly.
To help avoid confusion, we’ve added a section in the front matter that clarifies that all requirements in the document pertain to implementations, not usage.

Rgs,
Panos

---

From: Adam Montville <[email-masked]>
Date: Wed, 19 Apr 2017 18:14:06 +0000

Hi all.

I've read through the entire draft and found it to be a decent draft. Keep
in mind that I've not attempted an implementation, and must rely on
implementers to pick out any technical impacts from this specification.
That said, I have two broad categories of feedback. The first includes
suggestions and concerns that are something more than nits. The second are
really just nits and stylistic (i.e. take them or leave them) types of
concerns.

Suggestions/Concerns More Than Nits...

Page 6: There are two similar terms in the second paragraph of section 4.2:
"endpoint management system" and "endpoint monitoring system". Are they
intended to be distinct, or interchangeable in this context? I could
conclude either way, but if they are intended to be interchangeable, then I
recommend picking and using one.

Page 10: I've probably missed something along the way -- perhaps out of a
secdir lunch or other discussion -- but it really seems like section 5.3
could be dramatically reduced by saying, follow RFC7589. There are a lot of
non-ROLIE-specific things happening in this section, which mostly amount to
good practice overall (so I don't necessarily mind having the information
in here), but imagine this information being available in every draft
intended to be, in part, secured using TLS. That sounds like a nightmare
for managing requirements.

Page 11: First paragraph at the top of that page (part of section 5.3)
says, "The server MUST support certificate-based client authentication..."
Why is this not a SHOULD? Yes, we'd like them to, but there are perfectly
valid cases where they needn't support client authentication. Of course, if
a proper TLS server implementation does this already, then my previous
comment applies here as well.

Page 11: First pargraph of section 5.4. A similar concern to the previous,
the first sentence reads, "Implementations MUST support user
authentication." Why not SHOULD? Again, there are valid cases where
authentication is not, strictly speaking, needed.

Page 12: Section 5.5 treats GET and POST, but ignores the other methods
that may be treated similarly by stating, in section 5.6, "Servers MAY
accept request methods beyond those specified in this document." Do we
really want to leave those undefined? PUT? DELETE? I'm not an expert in
this area, but PUT could be treated similarly to POST. DELETE is probably
something that SHOULD be implemented only for user agents properly
authenticated and authorized, etc.

Sections 6.1 and 6.2 and maybe others I can't recall: These sections
provide an informative syntax for a given element that is a "stricter
representation" than the original RFC, but they don't ever really state
which part of that element is stricter, which forces the reader out to that
original RFC. If there is a way to make the statement right there, please
do so.

Page 15: First sentence of section 6.1.3 indicates that "the atom:updated
element MUST be populated with the current time at the instant the Feed
representation was last updated..." Is "instant" sufficient definition?

Nits and Such...

Page 5: Second sentence of section 3.2. Strike "However, " from the
beginning.

Page 5: Last sentence of section 3.2. Proposed change: "A non-normative
RELAX NG Compact Schema..." or "An informative RELAX NG Compact Schema..."

Page 5: Last sentence of only paragraph in Section 4 (proper). Proposed
change: "...human-in-the-loop sharing arise...". It just reads funny (to
me) using "become apparent" followed by something else that "becomes
apparent".

Page 19: First sentence of first bullet point in section 6.2.5. Proposed
change: "...have an atom:link element...".

Page 26: Last sentence in first paragraph of section 9. Proposed change:
"...All that follows is guidance.  More specific instruction is out of
scope for this document."

Page 26: The term CSIRT is used in the last paragraph on this page. Not
sure whether we would prefer to use a more generalized example, as CSIRTs
may not be the only type of sharing consortium.

Kind regards,

Adam

On Tue, Mar 28, 2017 at 6:27 PM Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Thu, 20 Apr 2017 15:57:53 +0000

Hey Adam,

Thanks for the review, responses inline.

-Stephen

From: mile [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, April 19, 2017 2:14 PM
To: Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]
Subject: Re: [mile] Working group last call for ROLIE

Hi all.

I've read through the entire draft and found it to be a decent draft. Keep in mind that I've not attempted an implementation, and must rely on implementers to pick out any technical impacts from this specification. That said, I have two broad categories of feedback. The first includes suggestions and concerns that are something more than nits. The second are really just nits and stylistic (i.e. take them or leave them) types of concerns.

Page 6: There are two similar terms in the second paragraph of section 4.2: "endpoint management system" and "endpoint monitoring system". Are they intended to be distinct, or interchangeable in this context? I could conclude either way, but if they are intended to be interchangeable, then I recommend picking and using one.

They were originally meant to be interchangeable, I’ve changed them both to “endpoint management system” to avoid confusion.

Page 10: I've probably missed something along the way -- perhaps out of a secdir lunch or other discussion -- but it really seems like section 5.3 could be dramatically reduced by saying, follow RFC7589. There are a lot of non-ROLIE-specific things happening in this section, which mostly amount to good practice overall (so I don't necessarily mind having the information in here), but imagine this information being available in every draft intended to be, in part, secured using TLS. That sounds like a nightmare for managing requirements.

We’ve selectively chosen pieces out of RFC7589 to put into ROLIE, so referencing the whole document may include unintended requirements. That said, there may be a way to shorten this section slightly if you are concerned about section length.

Page 11: First paragraph at the top of that page (part of section 5.3) says, "The server MUST support certificate-based client authentication..." Why is this not a SHOULD? Yes, we'd like them to, but there are perfectly valid cases where they needn't support client authentication. Of course, if a proper TLS server implementation does this already, then my previous comment applies here as well.

Page 11: First pargraph of section 5.4. A similar concern to the previous, the first sentence reads, "Implementations MUST support user authentication." Why not SHOULD? Again, there are valid cases where authentication is not, strictly speaking, needed.

We decided that implementations MUST support the authentication in both of these cases to maintain secure interoperability between implementations. A given ROLIE repo does not have to actually use the authentication. Panos had similar comments to these two as well, so I’ve added a paragraph in section 2 that clarifies that all requirements in the ROLIE specification are conformance requirements for implementations, and are not usage requirements.

Page 12: Section 5.5 treats GET and POST, but ignores the other methods that may be treated similarly by stating, in section 5.6, "Servers MAY accept request methods beyond those specified in this document." Do we really want to leave those undefined? PUT? DELETE? I'm not an expert in this area, but PUT could be treated similarly to POST. DELETE is probably something that SHOULD be implemented only for user agents properly authenticated and authorized, etc.

Section 5.5 only applies to requests sent to the “/” resource to maintain RID compatibility. GET,POST,PUT,DELETE,etc are all defined for general usage in the Atom Publishing Protocol specification

Sections 6.1 and 6.2 and maybe others I can't recall: These sections provide an informative syntax for a given element that is a "stricter representation" than the original RFC, but they don't ever really state which part of that element is stricter, which forces the reader out to that original RFC. If there is a way to make the statement right there, please do so.

The definitions for elements we’ve provided in ROLIE are full definitions, so a reader shouldn’t need to flip back to RFC4287 in order to get the whole picture. Any element defined in ROLIE does a full override of the 4287 element, and any element not defined in ROLIE fully inherits from 4287. Would it help if I added some text describing that relationship in more detail somewhere?

Page 15: First sentence of section 6.1.3 indicates that "the atom:updated element MUST be populated with the current time at the instant the Feed representation was last updated..." Is "instant" sufficient definition?

Time being the beast that it is I’m not sure how to better describe the requirement. Do you have any suggestions/recommendations on how to define it?

Nits and Such...

Page 5: Second sentence of section 3.2. Strike "However, " from the beginning.

Changed

Page 5: Last sentence of section 3.2. Proposed change: "A non-normative RELAX NG Compact Schema..." or "An informative RELAX NG Compact Schema..."

Added

Page 5: Last sentence of only paragraph in Section 4 (proper). Proposed change: "...human-in-the-loop sharing arise...". It just reads funny (to me) using "become apparent" followed by something else that "becomes apparent".

Agreed, changed the sentence to avoid the repetition.

Page 19: First sentence of first bullet point in section 6.2.5. Proposed change: "...have an atom:link element...".

Changed

Page 26: Last sentence in first paragraph of section 9. Proposed change: "...All that follows is guidance.  More specific instruction is out of scope for this document."

Changed

Page 26: The term CSIRT is used in the last paragraph on this page. Not sure whether we would prefer to use a more generalized example, as CSIRTs may not be the only type of sharing consortium.

Agreed, changed to “consortium”.

Kind regards,

Adam

On Tue, Mar 28, 2017 at 6:27 PM Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:
Colleagues,

Regards, Nancy
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: Adam Montville <[email-masked]>
Date: Thu, 20 Apr 2017 19:16:18 +0000

More inline :-)

On Thu, Apr 20, 2017 at 10:57 AM Banghart, Stephen A. (Fed) <
[email-masked]> wrote:

> *From:* mile [mailto:[email-masked]] *On Behalf Of *Adam Montville
> *Sent:* Wednesday, April 19, 2017 2:14 PM
>
>
> *To:* Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]
> *Subject:* Re: [mile] Working group last call for ROLIE
>
>
>
> Hi all.
>
>
>
> Page 6: There are two similar terms in the second paragraph of section
> 4.2: "endpoint management system" and "endpoint monitoring system". Are
> they intended to be distinct, or interchangeable in this context? I could
> They were originally meant to be interchangeable, I’ve changed them both
> to “endpoint management system” to avoid confusion.
>

Thanks!

> We’ve selectively chosen pieces out of RFC7589 to put into ROLIE, so
> referencing the whole document may include unintended requirements. That
> said, there may be a way to shorten this section slightly if you are
> concerned about section length.
>

Understood. Also, my comments were not so much about length as about
contributing to a potential rats nest of requirements. But, shortening
would be good too. :-)

> We decided that implementations MUST support the authentication in both of
> these cases to maintain secure interoperability between implementations. A
> given ROLIE repo does *not* have to actually use the authentication.
> Panos had similar comments to these two as well, so I’ve added a paragraph
> in section 2 that clarifies that all requirements in the ROLIE
> specification are conformance requirements for implementations, and are not
> usage requirements.
>

Right, but therein is sort of the rub. Maybe it's a red herring, but if
there's code sitting there that'll never really be used, isn't that a bad
thing?

> Section 5.5 only applies to requests sent to the “/” resource to maintain
> RID compatibility. GET,POST,PUT,DELETE,etc are all defined for general
> usage in the Atom Publishing Protocol specification
>
>
>
> The definitions for elements we’ve provided in ROLIE are full definitions,
> so a reader shouldn’t need to flip back to RFC4287 in order to get the
> whole picture. Any element defined in ROLIE does a full override of the
> 4287 element, and any element not defined in ROLIE fully inherits from
> 4287. Would it help if I added some text describing that relationship in
> more detail somewhere?
>

It might, but I'm a voice of one, so if others are like "dude, what's this
guy talking about?" then I wouldn't worry about it.

> Time being the beast that it is I’m not sure how to better describe the
> requirement. Do you have any suggestions/recommendations on how to define
> it?
>

LOL. Nope. If we're not concerned, then that's fine. Does the Atom spec
indicate the timestamp format? That's probably sufficient.

---

From: John Field <[email-masked]>
Date: Fri, 21 Apr 2017 12:47:09 -0400

Hi All,

Thanks Adam for the review comments.

With regard to your specific comments on page 11 of the draft, i.e. MUST
versus SHOULD, this is a very good point.  I too struggled with this
question in the earlier drafts.  I can see the motivation to not exclude
legitimate use cases or specific deployments that for whatever reason might
not require mutually authenticated TLS.  But, at the end of the day, I
agree with Stephen's response that as ROLIE is a security service endpoint,
we should keep this as a MUST in terms of conformance.  Here's my rationale:

In general, we want to raise the bar -- in terms of current best practice,
and use "TLS everywhere."  This ensures privacy (and, depending upon
specific cipher suite, perfect forward secrecy). Going the next step, and
requiring mutually authenticated TLS, helps by defining at least 1
specific, and consistent client authentication mechanism, and so should
promote better interoperability.

As a practical matter, there are many tools and libraries available to
implementers, and so the associated certificate issuance is just not as big
a burden as it might first seem.

Also, ensuring data integrity will be an important security characteristic
for any ROLIE implementation.  Although specific audit requirements are out
of scope, requiring mutually authenticated TLS will provide a
standards-based way for a server to associate an identity with a client
endpoint and provide accountability/audit of client actions. This could be
useful as a remember-me, even if the identity provisioning process does not
involve strong vetting.

Of course, implementations may choose to support additional authentication
mechanisms as needed.  There is a brief discussion of this in the 3rd
paragraph of section 9, security considerations, where guidance is given to
align the client authentication requirement to the threat model.

Regards,
John

On Thu, Apr 20, 2017 at 3:16 PM, Adam Montville <[email-masked]>
wrote:

>> I've read through the entire draft and found it to be a decent draft.
>> Keep in mind that I've not attempted an implementation, and must rely on
>> Page 11: First pargraph of section 5.4. A similar concern to the
>> previous, the first sentence reads, "Implementations MUST support user
>> We decided that implementations MUST support the authentication in both
>> of these cases to maintain secure interoperability between implementations.
>> A given ROLIE repo does *not* have to actually use the authentication.
>> The definitions for elements we’ve provided in ROLIE are full
>> definitions, so a reader shouldn’t need to flip back to RFC4287 in order to
>> get the whole picture. Any element defined in ROLIE does a full override of
>> the 4287 element, and any element not defined in ROLIE fully inherits from

-- 

John P. Field | Security PM | Pivotal

Direct: (908) 962-3394 | jfield@ <[email-masked]>pivotal.io

---

From: Adam Montville <[email-masked]>
Date: Fri, 21 Apr 2017 19:25:18 +0000

Thanks for the additional perspective. It's all good, and I like the idea
of upping the game. Just felt, for some reason, compelled to ask about it.

On Fri, Apr 21, 2017 at 11:47 AM John Field <[email-masked]> wrote:

> On Thu, Apr 20, 2017 at 3:16 PM, Adam Montville <
> [email-masked]> wrote:
>
>> More inline :-)
>>
>>> Page 10: I've probably missed something along the way -- perhaps out of
>>> a secdir lunch or other discussion -- but it really seems like section 5.3
>>> Section 5.5 only applies to requests sent to the “/” resource to
>>> maintain RID compatibility. GET,POST,PUT,DELETE,etc are all defined for
>>> general usage in the Atom Publishing Protocol specification
>>>
>>>
>>>
>> It might, but I'm a voice of one, so if others are like "dude, what's
>> this guy talking about?" then I wouldn't worry about it.
>>
>>
>>
>>>
>>>
>>> Page 15: First sentence of section 6.1.3 indicates that "the
>>> atom:updated element MUST be populated with the current time at the instant
>>> the Feed representation was last updated..." Is "instant" sufficient
>>> definition?
>>>
>>>
>>>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 24 Apr 2017 19:44:07 +0000

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-----
> Sent: Tuesday, March 28, 2017 6:27 PM
> To: [email-masked]

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Mon, 24 Apr 2017 21:02:09 +0000

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

> From: mile [mailto:[email-masked]] On Behalf Of Schmidt, Charles M.
> Sent: Monday, April 24, 2017 3:44 PM
> To: [email-masked]
> 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.
> 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.

> > From: mile [mailto:[email-masked]] On Behalf Of Nancy
> > Cam-Winget
> > (ncamwing)
> > Please provide comments before May 1st and provide your support and/
> > or raise any issue you feel are yet to be addressed.
> >
> >
> >
> > Regards, Nancy
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 24 Apr 2017 21:22:09 +0000

Hi Stephen,

Thanks for the response. I have one follow-up to your follow-up:

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

This makes sense. I think my confusion was that it sounded to me like you were saying that people SHOULD follow this design choice because this was *the* way to control visibility of the content. Based on your response, it sounds like you are citing this as one way to effectively manage visibility, but it is not the only way. I wonder if it might be clearer if instead of saying "It is RECOMMENDED that public and private Collections be segregated into different Workspaces" the document could say, "One way of efficiently controlling visibility of continent is to have public and private Collections be segregated into different Workspaces." Maybe you could further drive home that ROLIE is not tied to this model by appending "ROLIE supports other ways of organizing Collections and because ROLIE supports fine-grained access control, owners can control visibility of content regardless of how Collections are organized." 

Does this make sense?

Thanks,
Charles

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 27 Apr 2017 20:27:15 +0000

After talking with a few people, I have realized it might be a good idea to allow for a private use portion of the ROLIE property namespace defined in section 8.3<https://tools.ietf.org/html/draft-ietf-mile-rolie-06#section-8.3>. This would be in addition to the current specification required portion of the namespace. This would allow private extensions to be tried out on a local server basis. A registration of “property:local” could set aside the portion of the namespace for local use. Local properties could then follow the pattern “urn:ietf:params:rolie:property:local:{name}” where name is a locally used private property.

Any concerns with adding this?

Regards,
Dave

Colleagues,

Regards, Nancy

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 27 Apr 2017 20:42:47 +0000

Hi David,

I am starting a review of this draft too ☺
I personally don’t have concerns, though that would also need to be reviewed….so we’d have to delay the WGLC hopefully not by much….but would be good to hear Kathleen as AD provide feedback as well…

                Nancy
From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thursday, April 27, 2017 at 1:27 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Working group last call for ROLIE

Regards,
Dave

Colleagues,

Regards, Nancy

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 28 Apr 2017 13:44:49 +0000

Nancy,

Thanks for agreeing to review. We are happy with how much review the draft is getting and are happy to see the WGLC delayed to allow it to receive more review. This will only help to improve the draft in the end.

Thanks,
Dave

From: Nancy Cam-Winget (ncamwing) [mailto:[email-masked]]
Sent: Thursday, April 27, 2017 4:43 PM
To: Waltermire, David A. (Fed) <[email-masked]>; [email-masked]
Subject: Re: Working group last call for ROLIE

Hi David,

                Nancy
From: "Waltermire, David A. (Fed)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 27, 2017 at 1:27 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Working group last call for ROLIE

Regards,
Dave

From: mile [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, March 28, 2017 7:27 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mile] Working group last call for ROLIE

Colleagues,

Regards, Nancy

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 28 Apr 2017 15:47:41 +0000

Hi David,
A couple of approaches is to let this WGLC complete and then do a mini-review of only the updates after that
Or we can just delay this WGLC….
I think its still good to get this round of reviews done but am fine either way.

                Nancy

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Friday, April 28, 2017 at 6:44 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Working group last call for ROLIE

Nancy,

Thanks,
Dave

Hi David,

                Nancy

Regards,
Dave

Colleagues,

Regards, Nancy

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 28 Apr 2017 14:02:40 -0400

Hi Nancy,

On Fri, Apr 28, 2017 at 9:44 AM, Waltermire, David A. (Fed)
<[email-masked]> wrote:
> Nancy,
>
>
>
> Thanks for agreeing to review. We are happy with how much review the draft
> is getting and are happy to see the WGLC delayed to allow it to receive more
> review. This will only help to improve the draft in the end.
>
>
>
> Thanks,
>
> Dave
>
>
>
> I am starting a review of this draft too J
>
> I personally don’t have concerns, though that would also need to be
> reviewed….so we’d have to delay the WGLC hopefully not by much….but would be
> good to hear Kathleen as AD provide feedback as well…
>

I usually do my AD review after WGLC, when the draft is sent for IESG
publication.

Thanks,
Kathleen
> After talking with a few people, I have realized it might be a good idea to
> allow for a private use portion of the ROLIE property namespace defined in
> section 8.3. This would be in addition to the current specification required
> portion of the namespace. This would allow private extensions to be tried
> out on a local server basis. A registration of “property:local” could set
> aside the portion of the namespace for local use. Local properties could
> then follow the pattern “urn:ietf:params:rolie:property:local:{name}” where
> name is a locally used private property.
>
>
>

-- 

Best regards,
Kathleen