Subject: [sacm] IM Issue #3 from IETF 96 - IE Datatypes

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 20 Jul 2016 08:43:47 +0000

We discussed a few open issues during the first SACM session at IETF 96 and I wanted to follow up on the list to see if I could get some additional feedback.  Please review each question and let me know if you have any feedback on the proposed resolutions.

QUESTION:
What other datatypes do we need to create and add to the IM?

DISCUSSION:
During the meeting, there were no requests for additional datatypes.  It was noted that SWIDs provide an enumeration for representing different types of versions.  There was another comment that it is useful to explicitly define the datatypes we care about so we can document the appropriate operations because simple equality checks are not sufficient for SACM's needs.  In a side discussion, it was also suggested that we may want to reduce the number of primitive datatypes and simply define things like rpm version as string IEs with special restrictions (e.g. epoch:version-revision).

PROPOSED RESOLUTION:
As a result of the discussion, we should explicitly call out the additional version types, however, we should try to implement them as IEs.  We should also work to define types for URIs, maps, and arrays as suggested at previous virtual interim meeting.

QUESTION:
Do we need IPFIX datatype semantics (quantity, identifier, flags, etc.)?

DISCUSSION:
There was some clarifying discussion around datatype semantics, but, there was not really any discussion around whether or not we should use them in the SACM IM.

PROPOSED RESOLUTION:
Do not include datatype semantics in the IPFIX template specification until there is a concrete need.

Please let me know if you have any questions.

Thanks,

Danny

---

From: Chris Inacio <[email-masked]>
Date: Wed, 20 Jul 2016 09:23:22 +0000

I like including the data type semantics because it makes extending the info model NOT require a giant body to make it happen and still keep some amount of interoperability.

I think the version of being able to build a data repository that can accept multiple vendors host based modules - think Vendor A on Windows, Vendor B on Linux, etc. and going to Vendor X to collect the data.  When Vendor B makes a proprietary enhancement, if data type semantics are included, I might not know how to make human intelligence for the datum, but I would know how to capture it, store it, and possibly allow the user to combine it.

One of the things that does work in IPFIX is that we know not to allow a user to do mathematical addition on a enumeration and a value.  We know that IP addresses, while they might be big numbers, are really enums/labels - so you can search them, but maybe ordering them as regular ordinals might not make sense.  So by sending this information from the probes to the data repository really allows the data repository implementations a lot more flexibility in creating capability while decoupling that from the probe/sensor.

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

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 10:44:07 AM
To: [email-masked] <[email-masked]><mailto:[email-masked]>
Subject:  [sacm] IM Issue #3 from IETF 96 - IE Datatypes

QUESTION:

DISCUSSION:
During the meeting, there were no requests for additional datatypes.  It was noted that SWIDs provide an enumeration for representing different types of versions.  There was another comment that it is useful to explicitly define the datatypes we care about so we can document the appropriate operations because simple equality checks are not sufficient for SACM’s needs.  In a side discussion, it was also suggested that we may want to reduce the number of primitive datatypes and simply define things like rpm version as string IEs with special restrictions (e.g. epoch:version-revision).

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

Thanks,

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

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 21 Jul 2016 09:28:52 +0000

I was talking to Jim yesterday and he suggested it might be good to also have an enumeration (i.e. flags) primitive datatype.  We could potentially have a structure that follows: <name>  < value> <description>.

The reasoning behind this is that between this and the list types, you would know how to parse the structures (as previously mentioned here https://www.ietf.org/mail-archive/web/sacm/current/msg04320.html).  Do others have thoughts on this?

Also, Chris, I have a few comments inline below.

Thanks,

Danny

From: Chris Inacio [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 11:23 AM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: Re: [sacm] IM Issue #3 from IETF 96 - IE Datatypes

[danny] Can you clarify what you mean by the IM not requiring a giant body?

[danny] Wouldn’t they document how to process/capture this information in their extension documentation regardless of datatype semantics?

From: Haynes, Dan <[email-masked]><mailto:[email-masked]>
Date: July 20, 2016 at 10:44:07 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  [sacm] IM Issue #3 from IETF 96 - IE Datatypes

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

QUESTION:

DISCUSSION:

PROPOSED RESOLUTION:

Thanks,

Danny
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Jerome Athias <[email-masked]>
Date: Thu, 21 Jul 2016 13:18:44 +0300

Right, looks like interesting/useful.

For some ideas
Stolen from there
https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.fbffi5fz6dkd

8.2.1.7. List (list)

A list contains an ordered sequence of values. When the phrasing “list
of type <type>” is used, all values in the list MUST be of the
specified type. For instance, list of type number means that all
values of the list must be of the number type. Upper and lower bounds
of the list – the minimum and maximum number of elements – may be
specified where the list is used. This section does not specify the
upper and lower bounds of list.

The JSON MTI serialization uses the JSON array type, which is an
ordered list of zero or more values.

8.2.1.8. Dictionary (dictionary)

A dictionary captures a set of key/value pairs. Keys in the dictionary
MUST be unique and MUST be of type string. CybOX dictionary keys MUST
use the printable ASCII character set, that is U+0021 through U+007e
inclusive, and MUST be length-constrained to 128 characters or less.
Dictionary values MUST be valid CybOX property data types.

On Thu, Jul 21, 2016 at 12:28 PM, Haynes, Dan <[email-masked]> wrote:
> I was talking to Jim yesterday and he suggested it might be good to also
> have an enumeration (i.e. flags) primitive datatype.  We could potentially
> have a structure that follows: <name>  < value> <description>.
>
>
>
> The reasoning behind this is that between this and the list types, you would
> know how to parse the structures (as previously mentioned here
> https://www.ietf.org/mail-archive/web/sacm/current/msg04320.html).  Do
> others have thoughts on this?
>
>
>
> I like including the data type semantics because it makes extending the info
> model NOT require a giant body to make it happen and still keep some amount
> of interoperability.
>
> I think the version of being able to build a data repository that can accept
> multiple vendors host based modules - think Vendor A on Windows, Vendor B on
> Linux, etc. and going to Vendor X to collect the data.  When Vendor B makes
> a proprietary enhancement, if data type semantics are included, I might not
> know how to make human intelligence for the datum, but I would know how to
> capture it, store it, and possibly allow the user to combine it.
>
> [danny] Wouldn’t they document how to process/capture this information in
> their extension documentation regardless of datatype semantics?
>
> One of the things that does work in IPFIX is that we know not to allow a
> user to do mathematical addition on a enumeration and a value.  We know that
> IP addresses, while they might be big numbers, are really enums/labels - so
> you can search them, but maybe ordering them as regular ordinals might not
> make sense.  So by sending this information from the probes to the data
> repository really allows the data repository implementations a lot more
> flexibility in creating capability while decoupling that from the
> probe/sensor.
>
>
>
>
>
> --
> Chris Inacio
> [email-masked]
>
>
>
>
> From: Haynes, Dan <[email-masked]>
> To: [email-masked] <[email-masked]>
> We discussed a few open issues during the first SACM session at IETF 96 and
> I wanted to follow up on the list to see if I could get some additional
> feedback.  Please review each question and let me know if you have any
> feedback on the proposed resolutions.
>
>
>
> QUESTION:
>
> During the meeting, there were no requests for additional datatypes.  It was
> noted that SWIDs provide an enumeration for representing different types of
> versions.  There was another comment that it is useful to explicitly define
> the datatypes we care about so we can document the appropriate operations
> because simple equality checks are not sufficient for SACM’s needs.  In a
> side discussion, it was also suggested that we may want to reduce the number
> of primitive datatypes and simply define things like rpm version as string
> IEs with special restrictions (e.g. epoch:version-revision).
>
>
>
> PROPOSED RESOLUTION:
>
> As a result of the discussion, we should explicitly call out the additional
> version types, however, we should try to implement them as IEs.  We should
> also work to define types for URIs, maps, and arrays as suggested at
> previous virtual interim meeting.
>
>
>
> QUESTION:
>
> There was some clarifying discussion around datatype semantics, but, there
> was not really any discussion around whether or not we should use them in
> the SACM IM.
>
>
>
> PROPOSED RESOLUTION:
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 22 Jul 2016 04:36:49 +0000

Hi Jerome,

A few comments inline.

Thanks,

Danny

> -----Original Message-----
> From: Jerome Athias [mailto:[email-masked]]
> Sent: Thursday, July 21, 2016 12:19 PM
> To: Haynes, Dan <[email-masked]>
> Cc: Chris Inacio <[email-masked]>; [email-masked]
> https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedb
> hYJkgNVzwW9E6A/edit#heading=h.fbffi5fz6dkd
> 
> 8.2.1.7. List (list)
> 
> A list contains an ordered sequence of values. When the phrasing “list of
> type <type>” is used, all values in the list MUST be of the specified type. For
> instance, list of type number means that all values of the list must be of the
> number type. Upper and lower bounds of the list – the minimum and
> maximum number of elements – may be specified where the list is used. This
> section does not specify the upper and lower bounds of list.

[danny] In the IM, our list can contain any number of IE datatypes and is unbounded so I am not sure this definition would work.

> The JSON MTI serialization uses the JSON array type, which is an ordered list
> of zero or more values.
> 
> A dictionary captures a set of key/value pairs. Keys in the dictionary MUST be
> unique and MUST be of type string. CybOX dictionary keys MUST use the
> printable ASCII character set, that is U+0021 through U+007e inclusive, and
> MUST be length-constrained to 128 characters or less.

[danny] This could potentially be repurposed for the map datatype, but, I haven't looked at any other definitions either.  When I go to define the map datatype, I will include this definition as a possible option.

> > I was talking to Jim yesterday and he suggested it might be good to
> > also have an enumeration (i.e. flags) primitive datatype.  We could
> > potentially have a structure that follows: <name>  < value> <description>.
> >
> >
> >
> > The reasoning behind this is that between this and the list types, you
> > would know how to parse the structures (as previously mentioned here
> > I like including the data type semantics because it makes extending
> > the info model NOT require a giant body to make it happen and still
> > keep some amount of interoperability.
> >
> > I think the version of being able to build a data repository that can
> > accept multiple vendors host based modules - think Vendor A on
> > Windows, Vendor B on Linux, etc. and going to Vendor X to collect the
> > data.  When Vendor B makes a proprietary enhancement, if data type
> > semantics are included, I might not know how to make human
> > intelligence for the datum, but I would know how to capture it, store it, and
> possibly allow the user to combine it.
> >
> > [danny] Wouldn’t they document how to process/capture this information
> > in their extension documentation regardless of datatype semantics?
> >
> > One of the things that does work in IPFIX is that we know not to allow
> > a user to do mathematical addition on a enumeration and a value.  We
> > know that IP addresses, while they might be big numbers, are really
> > enums/labels - so you can search them, but maybe ordering them as
> > regular ordinals might not make sense.  So by sending this information
> > from the probes to the data repository really allows the data
> > repository implementations a lot more flexibility in creating
> > capability while decoupling that from the probe/sensor.
> >
> >
> >
> >
> >
> > --
> > Chris Inacio
> > [email-masked]
> >
> >
> >
> >
> > We discussed a few open issues during the first SACM session at IETF
> > 96 and I wanted to follow up on the list to see if I could get some
> > additional feedback.  Please review each question and let me know if
> > you have any feedback on the proposed resolutions.
> >
> >
> >
> > QUESTION:
> >
> > During the meeting, there were no requests for additional datatypes.
> > It was noted that SWIDs provide an enumeration for representing
> > different types of versions.  There was another comment that it is
> > useful to explicitly define the datatypes we care about so we can
> > document the appropriate operations because simple equality checks are
> > not sufficient for SACM’s needs.  In a side discussion, it was also
> > suggested that we may want to reduce the number of primitive datatypes
> > and simply define things like rpm version as string IEs with special
> restrictions (e.g. epoch:version-revision).
> >
> >
> >
> > PROPOSED RESOLUTION:
> >
> > As a result of the discussion, we should explicitly call out the
> > additional version types, however, we should try to implement them as
> > IEs.  We should also work to define types for URIs, maps, and arrays
> > as suggested at previous virtual interim meeting.
> >
> >
> >
> > QUESTION:
> >
> > There was some clarifying discussion around datatype semantics, but,
> > there was not really any discussion around whether or not we should
> > use them in the SACM IM.
> >
> >
> >
> > PROPOSED RESOLUTION:
> >