Re: [mile] Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)

["Roman D. Danyliw" <[e-mail]>]

To clarify, a response to the DISCUSS and COMMENTs are in this thread

> -----Original Message-----
> From: Roman D. Danyliw [mailto:[e-mail]]
> Sent: Wednesday, June 1, 2016 10:52 PM
> To: Alissa Cooper <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
> DISCUSS and COMMENT)
> 
> Hello Alissa!
> 
> Thanks for the review.  A response to the DISCUSS is inline ...
> 
> > -----Original Message-----
> > From: Alissa Cooper [mailto:[e-mail]]
> > Sent: Tuesday, May 31, 2016 7:24 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; Roman D. Danyliw
> > <[e-mail]>; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22:
> > (with DISCUSS and COMMENT)
> >
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-mile-rfc5070-bis-22: Discuss
> 
> [snip]
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The Confidence class as defined in 3.12.5 seems underspecified. It
> > does not specify a max value, so some implementations might use 1 as
> > the max while others might use 100.
> 
> Inherited from RFC5070, there are no ranges specified for a valid numeric
> confidence value.  This was an explicit design choice kept in this draft to
> preserve flexibility.  Acceptable ranges and how this value should be
> interpreted are handled out of band.  This approach is consistent with the
> overall design of the data model.  Consider that almost all of the classes in
> the data model are optional.  The minimal valid document, shown is Section
> 7.1, isn't useful.  Profiling between parties in a data sharing consortium will
> determine which optional-in-the-RFC classes should be mandatory-in-the-
> consortium.  This thinking extends to the semantics of classes like
> Confidence.
> 
> 
> > It's also hard to understand how a single confidence value is supposed
> > to be applied to elements with multiple fields, as in 3.12 and 3.29.
> > What do I do if I have high confidence in my estimate of SystemImpact
> > but low confidence in my estimate of MonetaryImpact?
> 
> If the child classes don't have the same Confidence, then each can be
> expressed in a distinct instance of the parent class.  For the high confidence
> SystemImpact but low confidence MonetaryImpact do the following (per
> Section 3.12):
> 
> <Incident ...>
> ...
>   <Assessment>
>      <SystemImpact>...</SystemImpact>
>      <Confidence rating="low" />
>   </Assessment>
>   <Assessment>
>      <MonetaryImpact>...</MonetaryImpact>
>      <Confidence rating="high"/>
>   </Assessment>
> </Incident>
> 
> This same approach doesn't apply to the Indicator class (Section 3.29).  There
> is no way to granularly express a different confidence for different child
> elements that compose the Indicator.  The value expressed in
> Indicator/Confidence is a reflection of the confidence in the totality of the
> information in that Indicator class.
> 
> It would be relatively straightforward to add a Confidence class to
> Observable, IndicatorExpression, AttackPhase, Reference and AttackPhase.
> With some redesign, the same could be done for ObservableReference,
> IndicatorReference, StartTime and EndTime.
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (1) Section 1: It would be useful to define "cyber," "cyber indicator"
> > (somewhere before 3.29), "cyber threat," and "cyber event." I chuckled
> > when I wrote that, but I'm serious. The term "cyber" did not appear in
> > RFC 5070. It has clearly taken on some (mythical, perhaps) meaning in
> > venues external to the IETF. I think if this document is going to use
> > the term, it needs to explain what it means. If there are some
> > external definitions to point to or adopt, that would be fine.
> 
> After a search, it would appear that "cyber" is used in the abstract, Section
> 1.0 (Introduction), 1.3 (About the IODEF Data Model), 3.12.1 (SystemImpact),
> 3.12.2 (BusinessImpact), 3.28 (IndicatorData) and 3.29 (Indicator) -- 14 times
> total.  That can be cleaned up.  Specifically:
> 
> ** Section 1.0 uses the term "cyber security event" once.  I'm going to
> assume that isn't controversial.
> ** Sections 3.12.1 and 3.12.2 use the term "cyber physical system" four
> times.  I'm going to assume this isn't controversial.
> ** s/cyber indicator/indicator/g will address four usages of "cyber"-as-an-
> adjective in the abstract; and Sections 1.0, 3.28 and 3.29
> ** s/cyber incident report/cybersecurity incident report/g will address one
> more usage of "cyber"-as-an-adjective in Section 1.0
> ** I'll reword "cyber threats" and "cyber event mitigation" in Section 1.0; and
> reevaluate the use of "cyber intelligence"
> 
> > (2) Section 3.19.2: If I want to list the admin contact for a
> > particular domain in a Contact element within a DomainContacts
> > element, do I set the role in the Contact to "admin" or to "zone"? I
> > think this is not entirely clear from how the roles are specified in
> > 3.9 since most of the roles are more generic than "zone."
> 
> I'd say "admin".  You're right about the lack of symmetry of "zone" relative to
> the others.  I'll dig through the mailing list to see if I can recollect why we
> have this value.  At first blush, I'd say delete it.
> 
> Roman