Subject: [mile] Addressing 5070bis schema comments (Issue #21)

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 22 Jan 2014 04:25:05 +0000

Good evening!

Issue #21 is tracking the need to either act on or delete various questions noted in the 5070bis schema.  This note is intended to call out each of these comments and open the discussion on what to do.  

With all of the snippets of text presented here for clarity, my recommendations are noted as "RD" so it's easier to follow along when others add their thinking.

(1) In Reference class:

"<!-- CHANGE: Do we want an indicator_set_id here to connect data in the reference class to specific indicators? is there a better way to do this? Should the indicator_uid be used to mark data so that you have a way to limit who you share that data with in products? -->

(RD) I'm not sure what the first question is asking as Reference has both an @indicator-set-id and @indicator-uid.  To the second question, using indicator-uid in a way limit with whom to share information is a use case I haven't seen previously documented.  Could the interested/originating party please clarify.

(2) In Impact@type:

"<!-- CHANGE question: do we want to allow multiple values to be selected in case it is a combination? -->"

(RD) While multiple attributes can't occur in a single class, multiple instances of Impact are possible in a single instance of Assessment.  I would recommend that this is sufficient and to delete this comment.

(3) In Flow
"<!--   Added System unbounded for use only when the source or target watchlist is in use, otherwise only one system entry         is expected. -->"

(RD) This comment notes a change in the data model.  However, the modeling flexibility this change is intended to support is not documented.  This is an action.

(4) In Service
" <!-- CHANGE - email from address indicator, may be better as a sub class? Would only make sense with the service set to              email ports or none at all here or a new class. -->"

(RD) An known, issue.  Whether we need to place in the same class to represent email information was posed to the list, http://www.ietf.org/mail-archive/web/mile/current/msg01275.html.  

(5) In EmailInfo
"<!-- CHANGE: added the email details in a subclass for use when you do not need all of the email details provided in the       RFC5901 or ARF extensions.  No extension mechanism here, is it needed? Possible to create an IANA table to extend this class       if needed in the future outside of schema edit cycles -->"

(RD) If we want an extension mechanism we could either implement something like ApplicationHeader to allow arbitrary Email headers, or add in AdditionalData.  I recommend the former and this is tracked in Issue #24.  To the second question, I don't understand the purpose of an IANA table in this context.  Could the interested/originating party please clarify.

(6) In WindowsRegistryKeysModified
" <!-- CHANGE: Should this be broken out as another class for WindowsRegistryKeyModified and add attributes for indicator_ID and action - add_value, removes_value, etc. as is demonstrated? -->

(RD) I don't understand which class the pronoun "this" is referencing to reason about whether it should be divided into multiple classes. Could the interested/originating party please clarify.

(7) In HashInformation
"<!-- QUESTION: Do we want an AdditionalData here? -->"

(RD)  I would recommend it.  By adding AdditionalData, an extension could add richer file information.  Supporting this richer information is tracked as Issue #23.  

(8) In HashInformation@type
"<!-- QUESTION: Are values needed to differentiate the key information shared when the ds:KeyInfo class is referenced? -->"

(RD) I don't appreciate the issue here.  Could the interested/originating party please clarify.

(9) In SoftwareType
"<!-- CHANGE: Should UserAgent or HTTPUserAgent fit in SoftwareTypes? This is typically intended to mean servers, but the category seems more appropriate than others.-->"

(RD) I recommend having a separate discussion on how to best represent it.  For example, HTTPUserAgent could also be represented as in Service/ApplicationHeader.

Roman

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 22 Jan 2014 19:08:03 -0500

Hi Roman,

I'll answer in-line with KM> and using +1 where appropriate.  Others, please chime in!

Some of the questions were off-list in a group testing interoperability of implementations and working against use cases.  Some were questions to track options and can just be removed.  I tried to look up what I could and jog my memory for other questions.

Thanks,
Kathleen

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Tuesday, January 21, 2014 11:25 PM
To: [email-masked]
Subject: [mile] Addressing 5070bis schema comments (Issue #21)

Good evening!

(1) In Reference class:

KM> Unfortunately, this was a discussion outside of mailing lists.  I think this may have to do with the walls needed within a product when you share with multiple groups.  If an indicator_UID is from a particular source, you may have to restrict access to team members of one organization where some may not have approved access for some data (clearance levels, privacy information, human resources sensitivity, etc.).

(2) In Impact@type:

KM> +1

(3) In Flow

KM> +1 on the action.

(4) In Service

(RD) An known, issue.  Whether we need to place in the same class to represent email information was posed to the list, http://www.ietf.org/mail-archive/web/mile/current/msg01275.html.  
KM> OK, so this decision is tracked elsewhere...

(5) In EmailInfo

(RD) If we want an extension mechanism we could either implement something like ApplicationHeader to allow arbitrary Email headers, or add in AdditionalData.  I recommend the former and this is tracked in Issue #24.  To the second question, I don't understand the purpose of an IANA table in this context.  Could the interested/originating party please clarify.
KM> I think your proposal is fine.  I think the IANA table suggestion was along the thought process of Take's SCI draft where entire schemas may get embedded.

(RD) I don't understand which class the pronoun "this" is referencing to reason about whether it should be divided into multiple classes. Could the interested/originating party please clarify.
KM> I think there was no interest in additional changes and that folks were happy with the current proposal, meaning you can just delete the comment.

(7) In HashInformation

KM> +1

(RD) I don't appreciate the issue here.  Could the interested/originating party please clarify.
KM> I think this might be referring to key types, like X.509 or PGP, but I believe that is covered in ds:

(9) In SoftwareType

(RD) I recommend having a separate discussion on how to best represent it.  For example, HTTPUserAgent could also be represented as in Service/ApplicationHeader.
KM> +1 on separate discussion

I hope that helps!
Kathleen

Roman
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 27 Jan 2014 17:56:01 +0000

Hello Kathleen,

I've added inline comments for questions #1, 4, and 8.  In the interest of future readability, I kept the entire thread.

Roman

> From: Moriarty, Kathleen [mailto:[email-masked]]
> Sent: Wednesday, January 22, 2014 7:08 PM
> To: Roman D. Danyliw; [email-masked]
> Subject: RE: Addressing 5070bis schema comments (Issue #21)
> 
> Hi Roman,
> 
> Some of the questions were off-list in a group testing interoperability of
> implementations and working against use cases.  Some were questions to
> track options and can just be removed.  I tried to look up what I could and jog
> my memory for other questions.
> 
> Thanks,
> Kathleen
> 
> Issue #21 is tracking the need to either act on or delete various questions
> noted in the 5070bis schema.  This note is intended to call out each of these
> comments and open the discussion on what to do.
> 
> With all of the snippets of text presented here for clarity, my
> recommendations are noted as "RD" so it's easier to follow along when others
> add their thinking.
> 
> (1) In Reference class:
> 
> "<!-- CHANGE: Do we want an indicator_set_id here to connect data in the
> reference class to specific indicators? is there a better way to do this? Should
> the indicator_uid be used to mark data so that you have a way to limit who
> you share that data with in products? -->
> 
> (RD) I'm not sure what the first question is asking as Reference has both an
> @indicator-set-id and @indicator-uid.  To the second question, using
> indicator-uid in a way limit with whom to share information is a use case I
> haven't seen previously documented.  Could the interested/originating party
> please clarify.
> 
> KM> Unfortunately, this was a discussion outside of mailing lists.  I think this
> may have to do with the walls needed within a product when you share with
> multiple groups.  If an indicator_UID is from a particular source, you may have
> to restrict access to team members of one organization where some may not
> have approved access for some data (clearance levels, privacy information,
> human resources sensitivity, etc.).

RD>  Is there something that needs to be done in the document or is it an implementation detail?  I'd like to either decide whether we can remove the comment with no action or whether a discussion needs to be started to clarify the way ahead.  If there is an action, then I'd recommend casting the discussion in terms of the other issues posed with defining the @indicator-uid and @indicator-set-id attributes in http://www.ietf.org/mail-archive/web/mile/current/msg01299.html.

> (RD) While multiple attributes can't occur in a single class, multiple instances
> of Impact are possible in a single instance of Assessment.  I would recommend
> that this is sufficient and to delete this comment.
> KM> +1
> 
> (3) In Flow
> "<!--   Added System unbounded for use only when the source or target
> watchlist is in use, otherwise only one system entry         is expected. -->"
> 
> (RD) This comment notes a change in the data model.  However, the modeling
> flexibility this change is intended to support is not documented.  This is an
> action.
> KM> +1 on the action.
> 
> (4) In Service
> " <!-- CHANGE - email from address indicator, may be better as a sub class?
> Would only make sense with the service set to              email ports or none at
> all here or a new class. -->"
> 
> (RD) An known, issue.  Whether we need to place in the same class to
> represent email information was posed to the list, http://www.ietf.org/mail-
> archive/web/mile/current/msg01275.html.

RD> No decision has been made.  This link posed the question to the group.  Does anyone have thoughts on the matter?  As I noted in the link, it is my opinion that we need to have only one place to describe this information.  Service/EmailInfo currently provides the most flexibility.

> (5) In EmailInfo
> "<!-- CHANGE: added the email details in a subclass for use when you do not
> need all of the email details provided in the       RFC5901 or ARF extensions.
> No extension mechanism here, is it needed? Possible to create an IANA table
> to extend this class       if needed in the future outside of schema edit cycles --
> >"
> 
> (RD) If we want an extension mechanism we could either implement
> something like ApplicationHeader to allow arbitrary Email headers, or add in
> AdditionalData.  I recommend the former and this is tracked in Issue #24.  To
> the second question, I don't understand the purpose of an IANA table in this
> context.  Could the interested/originating party please clarify.
> KM> I think your proposal is fine.  I think the IANA table suggestion was along
> the thought process of Take's SCI draft where entire schemas may get
> embedded.
> 
> " <!-- CHANGE: Should this be broken out as another class for
> WindowsRegistryKeyModified and add attributes for indicator_ID and action -
> add_value, removes_value, etc. as is demonstrated? -->
> 
> (RD) I don't understand which class the pronoun "this" is referencing to
> reason about whether it should be divided into multiple classes. Could the
> interested/originating party please clarify.
> KM> I think there was no interest in additional changes and that folks were
> happy with the current proposal, meaning you can just delete the comment.
> 
> (7) In HashInformation
> (RD)  I would recommend it.  By adding AdditionalData, an extension could
> add richer file information.  Supporting this richer information is tracked as
> Issue #23.
> KM> +1
> 
> "<!-- QUESTION: Are values needed to differentiate the key information
> shared when the ds:KeyInfo class is referenced? -->"
> 

RD> Just to clarify, there is no action here and the comment can be deleted?  

> (9) In SoftwareType
> "<!-- CHANGE: Should UserAgent or HTTPUserAgent fit in SoftwareTypes? This
> is typically intended to mean servers, but the category seems more
> appropriate than others.-->"
> 
> (RD) I recommend having a separate discussion on how to best represent it.
> For example, HTTPUserAgent could also be represented as in
> Service/ApplicationHeader.

Roman