Managed Incident Lightweight Exchange
charter-ietf-mile-04

[Ballot comment]
I'm re-balloting to remove my Block, based on my conversation with Nancy about transport protocols versus mapping onto transport protocols.

Thanks for the quick response.

[Ballot comment]
I agree with Spencer. Would it make sense for the last 3 paragraphs could talk about "bindings" to http and xmpp, rather than "transports"?

[Ballot block]
It doesn't look like the conversation Nancy Cam-Winget and I had about my comments on our previous ballot have been reflected yet - this version of the charter still describes work on transport protocols, and Nancy said it shouldn't be, because they're already based on HTTP and XMPP.

The correct term is something like "substrate for application protocol", if I'm understanding https://tools.ietf.org/html/rfc3205 (BCP 56).

I'm happy to clear when the edit happens, but not happy to charter work on transport protocols outside TSV by accident.

My position on the previous ballot is at https://datatracker.ietf.org/doc/charter-ietf-mile/ballot/630408/.

[Ballot block]
Is this the right reference for STIX? https://oasis-open.github.io/cti-documentation/stix/intro  If so, it looks like it has a different acronym expansion: Structured Threat Information Expression. If not, it's not immediately obvious what STIX this references. I think this needs to be clarified to have meaningful external review.

I would also expect to see OASIS listed as an organization that the WG may interface with if necessary in the course of documenting transports to support STIX, assuming it is the STIX linked above.

[Ballot comment]
I do not think it is appropriate for a WG charter to cite a government policy from a specific country in the way that this charter references a US executive order. I also think the reference is vague (which order?) and the order will not be "recent" for the life of this charter. So it should be dropped IMO.

[Ballot comment]
I agree with Spencer's comment.

I was going to comment that perhaps this needed some cross-area participation from ART, but then noticed the responsible AD :-)

[Ballot comment]
I don't think I have a BLOCKing concern with what's being proposed, but I do have a significant concern about how it's being characterized.

In this text,

"The MILE WG is focused on two areas: standardizing a data format for
representing incident and indicator data, and standardizing transport
protocol(s) for sharing the structured data"

and in this text,

"Though the working group also adopted Real-time Inter-network Defense (RID, RFC
6545) as further enabling information exchange of security policy, its
transport mechanism, based on the Simple Object Access Protocol (SOAP), led to
the second focus for MILE: adopting more modern transport through the adoption
of a RESTful interface through ROLIE (Resource-oriented lightweight information
exchange, RFC 8322) and the adoption of a publish-subscribe model through
XMPP-Grid (draft-ietf-mile-xmpp-grid). The MILE WG will continue to:

"- Update and enhance these transport protocols to optimize their performance
and representations. More explicitly, documenting how ROLIE can transport JSON
representations.

"- Define and document how these transport protocols can also be used to support
other security information exchange formats. For example, documenting how ROLIE
can transport STIX (Secure Threat Intelligence eXchange) data."

I'm not sure that what I think is being described, is exactly "standardizing transport protocol(s)". I THINK it's more like "standardizing mapping onto an application substrate", if I'm using the vocabulary of https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-07 correctly, and I'm wondering whether all of these formats would end up riding over HTTP, which would shorten any conversation about my ballot a lot.

Am I confused here?

If this work is correctly described as "standardizing a transport protocol", I should probably be balloting BLOCK.

[Ballot comment]
I tend to support Benoit's block on this one.  I'm not convinced that there's a way to fix this without preventing the working group from doing the work they want to do, but I'd like to see a little more dialog with the principals before reaching that conclusion.

[Ballot block]
One point I frowned upon.
"An incident could be a ... an infraction to a service level agreement (SLA)"
Oh, these guys don't only focus on the S in FCAPS, but they also want to focus on the P?
This is a completely different world than security to try to model SLA and SLA infraction. This is is world of passive monitoring, active probing (IPPM), sharing (or not) SLA inofo with other providers, inter-provider QoS, etc...

Then I checked the previous charter, and this was already included. So maybe it's OK?

Finally, I spoke with Brian Trammell about this, and MILE does not want to model SLAs or even infractions to SLAs, but they want to use this as an indication that something is happening in the network, which could be related to security.

I've been hesitating between a COMMENT and a BLOCK on this one for some time.  But that point bothers me, and I don't want anybody to "IODEF" SLA incident based on that sentence. At least at this point, without carefully thinking about it.

[Ballot comment]
Looking at the paragraph starting with
"- Revise the IODEF document to incorporate enhancements and extensions
based on operational experience."
It seems that the rest of paragraph explains the WHY, and not the WHAT. It's useful info, but not there.
I'm not too sure what the enhancements and extensions are about in fact.

[Ballot comment]
Pure punctuation pedantry, but I actually had a hard time parsing these sentences the first time through:

OLD
  The MILE WG is focused on two areas, IODEF the data format and
  extensions to represent incident and indicator data and RID, the
  policy and transport for structured data.

NEW
  The MILE WG is focused on two areas: IODEF, the data format and
  extensions to represent incident and indicator data, and RID, the
  policy and transport for structured data.

OLD
  - Revise the IODEF document to incorporate enhancements and
  extensions based on operational experience; use by Computer Security
 
NEW
  - Revise the IODEF document to incorporate enhancements and
  extensions based on operational experience. Use by Computer Security

Added charter milestone "Submit a draft on the representation of Structured Cybersecurity Information in IODEF to the IESG for publication as a Standards Track RFC", due August 2013