Subject: [mile] review comments on the rolie draft

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 3 Sep 2015 14:38:54 +0900

Hi John,

We have reviewed the document draft-ietf-mile-rolie-00.txt.

https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/

Here are the comments on the draft.

[feasibility check]

We have implemented a prototype of the ROLIE draft.

Though some non-core functions (such as authentication) are not implemented
by the system, the core functions were implemented.

It works well without any problem.

I thus I believe the technique written in the draft is fine.

[comments on the questions mentioned in the Section 8 of the draft]

1.    Need to make a decision on whether new IANA link registrations are
required, or whether fully qualified private link types are sufficient.

I would go with the IANA registrations, since the list of terms could be
expanded further in the future.

2.    Should we require atom categories that correspond to IODEF expectation
class and/or iodef impact class?

That would be helpful, if you could prepare that. We could probably have an
appendix for that.

3.    Should we include specific requirements for Archive and Paging?

Well, we MAY do so, I think.

Server may provide paged feeds as defined by RFC 5005.

4.    We need more requirements input on use cases involving RID schema in
the Atom member entry content model for link rel=report.

Well, I personally do not see that much need to work no this.

Having said that, if somebody could provide such inputs, that would be
helpful.

5.    Should we include a MILE media type parameter?

I would say "no". if we wish to negotiate the content, we have many other
ways to do so, so I do not see the needs to include a MIME media type for
this purpose.

6.    If so, these parameters may require media type registration as per
rfc4288

Since I would prefer not to include a MIME media type parameters, I would
skip this question.

[overall feeling toward this draft]

I feel like the document is fairly stable.

So, if the editors feel happy, we could try to finalize this work.

Thank you.

Take

2015-01-29 9:51 GMT+09:00 Takeshi Takahashi <[email-masked]>:
> Hi John,
>
> Thank you for letting me know about your willingness to discuss the
> ROLIE draft remotely.
> It would be helpful if you can do that.
>
> Kind regards,
> Take
>
>
>
> 2015-01-26 23:52 GMT+09:00 John Field <[email-masked]>:
>> Thanks Takeshi,
>>
>> Due to scheduling conflicts I won't be able to attend the Dallas meeting
in
>> person, but I would make sure to participate remotely if there will be
>> discussion of the ROLIE draft on the agenda.
>>
>> Thanks,
>> John
>>
>> On Sun, Jan 25, 2015 at 11:03 PM, Takeshi Takahashi
>> <[email-masked]> wrote:
>>>
>>> Hi all,
>>>
>>> Time passes quickly, and it is already the season to start thinking
about
>>> the next meeting in Dallas.
>>> Though the discussion on this mailing list has been not that active in
>>> this
>>> year-end vacation season, I see several updated drafts after the
previous
>>> MILE meeting.
>>>
>>> 1. draft-ietf-mile-rfc5070-bis-10 (published on 9, Nov)
>>> 2. draft-ietf-mile-implementreport-01 (published on 20, Nov)
>>> 3. draft-ietf-mile-rolie-00.txt (published on 5, Dec)
>>> 4. draft-ietf-mile-enum-reference-format-12 (published on 24, Dec)
>>>
>>> It would be great if you could spare some time to review these drafts
and
>>> share the comments on this mailing list.
>>>
>>> Best regards,
>>> Take
>>>
>>>
>>>
>>> _______________________________________________
>>> mile mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mile
>>
>>
>>
>>
>> --
>>
>> John P. Field | Security Architect | Pivotal Services @ EMC
>>
>> Direct: (908) 962-3394 | [email-masked]
>>
>>
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile
>>
>
>
>
> --
> --
> Takeshi Takahashi, Ph.D.
> +81 80 3490 2971
> http://www.taketaka.com/

-- 
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 3 Sep 2015 06:24:18 -0400

Hi Take,

Your giving ROLLE a new lease on life raises
two obvious questions.  Now that TAXII is generating
such hyperactivity in OASIS CTI, have you used TAXII?
Should there be ongoing collaboration between the
two groups?

best,
tony

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 3 Sep 2015 20:15:20 +0900

Hi Tony,

Thank you for posting a comment.

> such hyperactivity in OASIS CTI, have you used TAXII?

I tries to keep eyes on TAXII since I am fond of this activity (I like
activities that contribute to security automation) very much, but I have not
used it before.
I am pretty sure that these OASIS activities are very important for the
security automation works.
TAXII/STIX is one of the most active and prominent works in this area.

> Should there be ongoing collaboration between the

I agree, having collaboration between the two groups is really great.
I think TAXII will be appreciated and used by many people.
I myself wish to use it.
On the other hand, I do not see ROLIE as the substitute or competing tool
against TAXII; I see ROLIE as a tool that could be used for some use cases
that did not matches TAXII.
(I didn't think about the use cases that much, but I feel like this way.)

ROLIE is, at this moment, an Informational draft.
This document provides "information" on how to distribute IODEF documents
using atom.
If people likes it, we could build a specification or standard, or it could
become the basis of developing another standards (including TAXII).

TAXII is surely one important activity, so I appreciate your kind
information from time to time.
I am looking forward to the further development of TAXII and STIX.

Best regards,
Take

From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Thursday, September 3, 2015 7:24 PM
To: Takeshi Takahashi; [email-masked]
Subject: Re: [mile] review comments on the rolie draft

Hi Take,

best,
tony

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 3 Sep 2015 07:30:43 -0400

Hi Tony,

Changing the subject as you are asking a different question from the review Take & team provided from their implementation.

REST is being used widely in incident response products and ROLIE provides a formal way to have interoperable solutions.  The MILE WG thought it was useful to progress this work for that reason.  Its a widely used method and makes sense for a few incident response and data exchange use cases.  It's also simple in that it is one protocol and may be peered to more complex solutions (A RESTful interface can be accessed from a browser).  

It's a separate protocol from TAXII, so it will be worked on independently from that and other protocols.  OASIS TC members (and anyone else interested) are welcome to review and contribute to this work.  Unless TAXII is brought to the IETF, MILE won't be working on it as that would raise copyright and other issues.  If folks in MILE are interested, they would need to join OASIS and follow their requirements for contributions.  I'm sure there is already overlap between the two groups in terms of who participates.  Let's focus on what we can get done.  If you have comments on ROLIE or other drafts in MILE, please share them.  

Thank you,
Kathleen 

Sent from my iPhone

> On Sep 3, 2015, at 6:24 AM, Tony Rutkowski <[email-masked]> wrote:
> 
> Hi Take,
>

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 3 Sep 2015 10:17:48 -0400

Hi Kathleen,

Actually the subject matter overlaps.
You are "renewing" a -00 draft that has
been around now for several years without
apparent sufficient interest to keep it rolling. :-)
The value proposition of the platform is
understood.

Given the rather significant dynamics and
success of TC CTI, it seemed natural to ask
whether maybe ROLIE was better pursed
there in conjunction with TAXII under the
STIX aegis. It is almost trivially simple to
join OASIS and to participate - even as
an individual, so the barriers are low.

Take's more gentle, less institutional,
cooperative suggestions seem appropriate
here.

--tony

On 2015-09-03 7:30 AM, Kathleen Moriarty wrote:
> Hi Tony,
>
> Changing the subject as you are asking a different question from the 
> review Take & team provided from their implementation.
>
> REST is being used widely in incident response products and ROLIE 
> provides a formal way to have interoperable solutions.  The MILE WG 
> thought it was useful to progress this work for that reason.  Its a 
> widely used method and makes sense for a few incident response and 
> data exchange use cases.  It's also simple in that it is one protocol 
> and may be peered to more complex solutions (A RESTful interface can 
> be accessed from a browser).
>
> It's a separate protocol from TAXII, so it will be worked on 
> independently from that and other protocols.  OASIS TC members (and 
> anyone else interested) are welcome to review and contribute to this 
> work.  Unless TAXII is brought to the IETF, MILE won't be working on 
> it as that would raise copyright and other issues.  If folks in MILE 
> are interested, they would need to join OASIS and follow their 
> requirements for contributions.  I'm sure there is already overlap 
> between the two groups in terms of who participates.  Let's focus on 
> what we can get done.  If you have comments on ROLIE or other drafts 
> in MILE, please share them.
>
> Thank you,
> Kathleen
>
> Sent from my iPhone
>
> On Sep 3, 2015, at 6:24 AM, Tony Rutkowski <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi Take,
>>
>> [email-masked] <mailto:[email-masked]>

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]>

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 3 Sep 2015 10:30:39 -0400

Hi Tony,

> The value proposition of the platform is

This was discussed at the last MILE meeting and it was agreed to move
it forward.  REST has quite a few product implementations at this
point, so the WG discussed it and decided it would be good to
formalize this draft as informational.  It had previously been adopted
by the WG and now has an implementation.

Take's message is a review of a protocol draft and your question is a
more general topic.  It's better to keep those separate so that others
can chime into the thread relevant to their interests and the review
thread can get more traction if needed rather than be diverted to
other topics.  I was not blocking this discussion, rather trying to
make sure both are facilitated.

> an individual, so the barriers are low.

I am glad to see the success of the OASIS effort.  As I said
previously, there may be overlap between groups and that is the best
way to coordinate (if needed) at the moment.  TAXII is a bunch of
protocols and requires a gateway to negotiate which one should be
used, ROLIE is a single protocol interface.  ROLIE can continue to be
formalized in the IETF and will be easy for those interested in just
supporting a RESTful interface to use this and integrate it where
needed.  TAXII may already support REST, I'm not sure.  I see the
usefulness in continuing with ROLIE for those not interested in
supporting a gateway negotiation before using REST.  This will be
easier for browser clients, so I think the ROLIE approach is needed as
REST is used in this way today in relevant products.

> cooperative suggestions seem appropriate

I'm sorry you don't see my message as cooperative.  It is considering
IPR and copyright constraints that exist as well as that the work was
contributed to the IETF for several reasons (openness, preference of
submitter to work in the IETF, it relies on other IETF protocols, and
can benefit from the IETF's experience with protocol work).  TAXII can
reference ROLIE just like it references many other IETF protocols for
their work that combines multiple protocols into a single solution.
This is likely to be a much faster path forward for both with
overlapping participants helping where needed.

Best regards,
Kathleen

> Changing the subject as you are asking a different question from the review
> Take & team provided from their implementation.
>
> REST is being used widely in incident response products and ROLIE provides a
> formal way to have interoperable solutions.  The MILE WG thought it was
> useful to progress this work for that reason.  Its a widely used method and
> makes sense for a few incident response and data exchange use cases.  It's
> also simple in that it is one protocol and may be peered to more complex
> solutions (A RESTful interface can be accessed from a browser).
>
> It's a separate protocol from TAXII, so it will be worked on independently
> from that and other protocols.  OASIS TC members (and anyone else
> interested) are welcome to review and contribute to this work.  Unless TAXII
> is brought to the IETF, MILE won't be working on it as that would raise
> copyright and other issues.  If folks in MILE are interested, they would
> need to join OASIS and follow their requirements for contributions.  I'm
> sure there is already overlap between the two groups in terms of who
> participates.  Let's focus on what we can get done.  If you have comments on
> ROLIE or other drafts in MILE, please share them.
>
> Thank you,
> Kathleen
>
> Sent from my iPhone
>
> ________________________________
>
> Anthony Michael Rutkowski
>
> [email-masked]
> +1 703 999 8270
> ________________________________
>
> Yaana Technologies LLC
>
> 542 Gibraltar Drive
>
> Milpitas CA 95035 USA

-- 

Best regards,
Kathleen

---

From: John Field <[email-masked]>
Date: Tue, 22 Sep 2015 10:26:57 -0400

Hi Take,

Sorry for the delay in responding.

FWIW, I have recently taken on a new role, and as a result of meetings and
travel fell behind on my e-mail.

I am glad to hear that you have a prototype implementation of ROLIE.

Please let me know if you still want to pursue this, and we can determine
next steps.

Thanks,
John

On Thu, Sep 3, 2015 at 1:38 AM, Takeshi Takahashi <
[email-masked]> wrote:

> Though some non-core functions (such as authentication) are not
> implemented by the system, the core functions were implemented.
>
> 2.    Should we require atom categories that correspond to IODEF
> expectation class and/or iodef impact class?
>
>
>
> That would be helpful, if you could prepare that. We could probably have
> an appendix for that.
>
>
>
> 4.    We need more requirements input on use cases involving RID schema
> in the Atom member entry content model for link rel=report.
>
>
>
> I would say “no”. if we wish to negotiate the content, we have many other
> >> Due to scheduling conflicts I won't be able to attend the Dallas
> meeting in

-- 

John P. Field | Security Architect | Pivotal

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

---

From: John Field <[email-masked]>
Date: Wed, 23 Sep 2015 10:50:57 -0400

All,

Please see below for my responses to Take's original questions, at the top
of this thread.

Regards,

John

> expanded further in the future.

[John]

I agree, this is the best way to ensure interoperability.  And individual
sharing consortia can always choose to use fully qualified links in their
community, in addition to the globally standardized ones.

> That would be helpful, if you could prepare that. We could probably have

[John]
OK, the reason I raised the question is that I was not sure as to how
CSIRTs might be using expectation and impact.  The category could enable
easier retrieval if that access pattern is common.

> Server may provide paged feeds as defined by RFC 5005.
[John]
Makes perfect sense to reference 5005.

> Having said that, if somebody could provide such inputs, that would be
[John]

IIRC, my motivation was to ensure that we optimize the usage/data access
patterns.  We want to enable requestors to minimize the number of round
trips.

> ways to do so, so I do not see the needs to include a MIME media type for
[John]
Agreed.
Media type should remain generic, application/atom+xml. The addition of a
more specialized media type might have some benefits, but would also limit
interoperability with clients that do not recognize the specialized type.
The overall goal of the draft is to enable the broadest possible
interactions.

> Since I would prefer not to include a MIME media type parameters, I would

[John]

Agreed.

--