Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

[Kathleen Moriarty <[e-mail]>]

Hi,

When you switch from information model (UML) to putting this in a data
format, a serious conversation on what that should be should happen.
Allowing for multiple (I saw that somewhere in this thread), will lead
to interoperability issues.  XML may turn a number of developers off
as well .  It's probably best to focus on the information model for
now, but then to have this conversation and have the WG collectively
decide what to do and I know this group is very comfortable with XML,
but it may not be the best answer.

Thanks,
Kathleen

On Fri, Nov 27, 2015 at 9:05 AM, Wolfkiel, Joseph L CIV DISA ID (US)
<[e-mail]> wrote:
> I believe your thinking mirrors my own.  The way I have it set up now, the enumerations are "name spaced" to link to the enumeration source, so commonly used enumerations (e.g. the forms of computing devices [tablet, phablet, laptop, tower, mini tower, blade, 1u rack mountable, 2u rack mountable, virtual, etc]) could be maintained by IANA in an IANA namespace, while private and semi-private enumerations (semi-private=US Government organization names, private=locations of a company's CoLos) can be maintained in an alternative location.  That said, since metadata we'll want to track will evolve over time as the threat and technology environment change, I recommend against hard coding the enumerations into a schema.
>
> As for your statement: "I have an issue with deletions though.  If you delete data elements, doesn’t that mean you potentially have data in your collection system that you can no longer make sense of?", I agree with that too.  Our system handles deletions as placing an element in an enumeration into "inactive" status.  The recipient of the update is then expected to figure out what to do with the information.  One of our solutions shows the metadata associations with deleted/inactive enumeration elements as bold, red so users can understand that they have tagged some device metadata with enumeration elements that are no longer valid and need to be updated with valid information.  Other systems are less sophisticated and will allow users to continue to use inactive enumeration elements--a less desirable option (for example, it's been almost a year since my organization did a re-organization, and some devices are still showing as belonging to organization names that no longer exist).  I suppose you can say that being able to recognize that metadata is invalid is "making sense" of it, to some extent.
>
> As a warning, maintaining complex enumerations is a significant undertaking when you accept the need to deal with parent-child relationships and the idea that relationships between enumerated "things" can change based on the functional context.  One example I like to use is the concept that locations can have one parent-child relationship based on geo-political relationships that are different from their relationships in a geographic function (e.g. Hawaii, geographically, is a Pacific island; geopolitically, it's part of the United States of America).
>
> To deal with this complexity, we're using an XML language and restful web service to distribute lists and hierarchies of names that keep subscribing systems updated as they change over time.  The metadata we track for each name/enumeration element includes:
> display name=A human readable, stand-alone representation of the name;
> short name=Office Symbol, abbreviation, or other minimal representation of an element, which may derive meaning through inheritance from its parents;
>  active status=Boolean indicating that the element should/shouldn't be used; time of last update=when any attribute of the element was last updated;
> unique ID=a globally unique integer associated with the element that is constant regardless of changes to display name, short name, active status, or parent;
> parent ID=the unique ID of the element's parent;
> functional rollup=The namespace of the functional relationship for which the names and parent relationship are valid.
>
> Managing our enumerations this way seems to be working reasonably well.  The system has been in place for close to 3 years now and has survived multiple re-organizations, creations of new locations and destruction of others, and deployment of new tools and systems that subscribe.
>
> Of course, this system only works for fairly simple enumerations that can be represented as lists or taxonomies.  Doing things like maintaining control mappings or tracking different benchmark versions and profiles over time requires a different concept with a significantly higher level of complexity.  I haven't conquered that problem, so I'm curious to see if SACM can solve it, or even tries.
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Fort Meade DISA Acquisiton Bldg Cube A4A58E
> Work: [phone]
> Gov Cell: [phone]
> [e-mail]
>
>
> -----Original Message-----
> From: Chris Inacio [mailto:[e-mail]]
> Sent: Wednesday, November 25, 2015 11:10 PM
> To: Wolfkiel, Joseph L CIV DISA ID (US)
> Cc: Ira McDonald; Haynes, Dan; [e-mail]
> Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation
>
> I believe the general solution is to be able to create an IANA registry with the information elements (IE).  The faster method of updating the registry is to create the registry with "expert review.”  That would mean a few folks designated by the working group review requests for modifications and approve them on to IANA.
>
> I have an issue with deletions though.  If you delete data elements, doesn’t that mean you potentially have data in your collection system that you can no longer make sense of?
>
> Secondly, if the churn is really multiple times a day, then I think we would want a hybrid system:
> * something such as an IANA registry to define IE’s that ensure interoperable exchange between systems, and a type system of some sort that allows a privately defined element to be described in an understandable way if/when it has to be exchanged; these would require review and approval to be standardized.
> * coming up with some basic “classes" (counter, delta, range, address, index, …) and some basic types (bool, int32, int64, uint32, uint64, octet string, …) (and possibly allow Henk’s inheritance mechanism “is_a” for inheritance) along with a human description for UI, would allow data interchange.  Hopefully, there would be enough generic information contained in those two metadata fields (maybe a couple more) that would allow an implementor to store the data (using the proper data type in storage) and then filter/search on the data using proper logic.  That would allow the system to understand that a “bitwise and" of a counter and an address has no meaning.  (Some bit of a typed lambda calculus - which some brave sole may which to expand if she would want to create interoperable expressions of search and filter across the collected data.)
>
>
> --
> Chris Inacio
> [e-mail]
>
>
>
>> On Nov 24, 2015, at 10:47 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[e-mail]> wrote:
>>
>> If stability is the goal, then I think a lot of the enumerations in the device characterization area will need to be converted to arbitrary strings.  We use enumerations like organization, location, system accreditation boundary, NIST security control ID, operating system, and others that changes frequently (sometimes daily) to characterize devices on the network, so depending on any given enumeration to be "stable" over a period of years is probably not realistic for our internal use cases.  Instead of trying to force changes out of the environment, I've tried to make the environment as responsive to change as possible.
>>
>> Joseph L. Wolfkiel
>> SCM Engineering Lead
>> DISA ID52
>> Fort Meade DISA Acquisiton Bldg Cube A4A58E
>> Work: [phone]
>> Gov Cell: [phone]
>> [e-mail]
>>
>>
>>
>> -----Original Message-----
>> From: Ira McDonald [Caution-mailto:[e-mail]]
>> Sent: Tuesday, November 24, 2015 10:33 AM
>> To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald
>> Cc: Haynes, Dan; [e-mail]
>> Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation
>>
>> All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
>>
>>
>> ________________________________
>>
>>
>>
>> Hi Dan and Joseph,
>>
>>
>> Thanks for your note Joseph about enumerations.
>>
>> To deal with this problem, the IEEE-ISTO Printer Working Group has
>> moved entirely to use of the keyword datatype (instead of enumeration)
>> for selection data elements in our Internet Printing Protocol abstract
>> model extensions (the keywords are registered with IANA) .
>>
>>
>> In some other *data model* mappings these have been converted to
>> enums (or enum / keyword union types) but those data models have
>> stable, named and dated versions and few interoperability problems.
>>
>>
>> Cheers,
>>
>> - Ira
>>
>>
>>
>> Ira McDonald (Musician / Software Architect)
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music / High North Inc
>> Caution-Caution-http://sites.google.com/site/blueroofmusic < Caution-Caution-http://sites.google.com/site/blueroofmusic >
>> Caution-Caution-http://sites.google.com/site/highnorthinc < Caution-Caution-http://sites.google.com/site/highnorthinc >
>> Caution-Caution-mailto: [e-mail] < Caution-Caution-mailto:[e-mail] >
>> Winter  579 Park Place  Saline, MI  48176  734-944-0094
>> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>>
>>
>>
>> On Tue, Nov 24, 2015 at 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[e-mail] < Caution-Caution-mailto:[e-mail] > > wrote:
>>
>>
>>       For the DoD, I've implemented an enumeration maintenance system, a standard XML schema, and a restful web service for maintaining enumerations.  Something similar may work for SACM.  Enumeration maintenance ends up being a special challenge in and of itself since enumerations can be flat lists, hierarchies, or have the ability to support multiple hierarchies.  Enumeration items can be added, deleted, modified, and merged over time, so different users of the enumerations may be using different lists based on when they were last updated.
>>
>>       I doubt SACM considers enumeration management to be within its charter as a generalized solution, but full interoperability will probably involve the ability to maintain and evolve some set of enumerations over time.
>>
>>       Joseph L. Wolfkiel
>>       SCM Engineering Lead
>>       DISA ID52
>>       Fort Meade DISA Acquisiton Bldg Cube A4A58E
>>       Work: [phone] < tel:%28301%29%20225-8820 >
>>       Gov Cell: [phone] < tel:%28571%29%20814-8231 >
>>       [e-mail] < Caution-Caution-mailto:[e-mail] >
>>
>>
>>
>>       -----Original Message-----
>>       From: sacm [Caution-Caution-mailto:[e-mail] < Caution-Caution-mailto:[e-mail] > ] On Behalf Of Haynes, Dan
>>       Sent: Tuesday, November 24, 2015 10:12 AM
>>       To: Wolfkiel, Joseph L CIV DISA ID (US); [e-mail] < Caution-Caution-mailto:[e-mail] >
>>       Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation
>>
>>       All active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
>>
>>
>>
>>
>>       ----
>>
>>       Thanks for the feedback Joe.
>>
>>       Once we have a way to represent the information that we care about in our
>>       IM, implementers are free to use XML, JSON, or maybe something else to
>>       document/implement the IM via the creation of data model.  I think it would
>>       also be acceptable for them to generate UML diagrams if they would like.
>>
>>       Yeah, the point about enumerations is a good one given the may change more
>>       frequently.  Does anyone have any thoughts on how to best handle what would
>>       be enumerations in the Information Model?  Would it be best to document the
>>       enumerations in separate document that would change over time and the IM
>>       could just reference out to it?
>>
>>       Agree, I am going to add a track that points to this thread and the previous
>>       thread regarding whether or not a network interface is hardware, software,
>>       or something else.  That way we can refer back to the relevant discussions
>>       when it comes time to design it in the IM.
>>
>>       Thanks,
>>
>>       Danny
>>
>>       -----Original Message-----
>>       From: Wolfkiel, Joseph L CIV DISA ID (US)
>>
>>       [Caution-Caution-Caution-mailto:[e-mail] < Caution-Caution-mailto:[e-mail] > ]
>>       Sent: Friday, November 20, 2015 8:53 AM
>>       To: Haynes, Dan <[e-mail] < Caution-Caution-mailto:[e-mail] > >; [e-mail] < Caution-Caution-mailto:[e-mail] >
>>       Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
>>       Model Representation
>>
>>       +1 here for something like option 1.  I personally like using XML schema to
>>       document this type of thing in a machine-readable manner.  JSON schema and
>>       UML class diagrams should also be considered.
>>
>>       For this particular example, I suggest that enumerations be maintained
>>       separately from the data model since they are subject to change over time.
>>
>>       This specific example also highlights an issue that merits consideration.
>>       There are aspects of endpoints that are ephemeral and some that are
>>       persistent.  For example, a hardware Network Interface *card* is persistent
>>       and discoverable.  However, a virtual network interface card (for example, a
>>       network interface generated by a VPN client) may come and go, so the model
>>       should be able to identify both, along with any metadata required to note
>>       that a given component existed for a given time period.
>>
>>       Also, a "network interface" could be understood to describe a logical
>>       connection to a specific network and would address issues like IP/MAC
>>       addresses, network name, default gateway, DNS Name, initial connection time,
>>       address "lease", and other issues.  It's good that the data model helps to
>>       understand that saying "network interface" doesn't actually mean the same
>>       thing to everyone talking about it.
>>
>>       Joseph L. Wolfkiel
>>       SCM Engineering Lead
>>       DISA ID52
>>       Fort Meade DISA Acquisiton Bldg Cube A4A58E
>>       Work: [phone] < tel:%28301%29%20225-8820 >
>>       Gov Cell: [phone] < tel:%28571%29%20814-8231 >
>>       [e-mail] < Caution-Caution-mailto:[e-mail] >
>>
>>
>>
>>       -----Original Message-----
>>
>>       From: sacm [Caution-Caution-Caution-mailto:[e-mail] < Caution-Caution-mailto:[e-mail] > ] On Behalf Of Haynes, Dan
>>       Sent: Friday, November 20, 2015 6:57 AM
>>       To: [e-mail] < Caution-Caution-mailto:[e-mail] >
>>       Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
>>       Model Representation
>>
>>       Hi Everyone,
>>
>>
>>       During the Information Model Update [1] at the IETF 94 Meeting, we discussed
>>       various modeling syntax options for our Information Model elements.  This
>>       corresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted to
>>       include all the options so the group could review them.
>>
>>
>>
>>       Specifically, we discussed the following options which provided on the list.
>>       Please note that I used the example below because it was very convenient :).
>>       It does not represent any agreed upon model for a network interface.
>>       Furthermore, it does not mean a decision has been made around whether or not
>>       a network interface is a hardware component, software component, both, or
>>       something else.  That decision is currently being worked out on the list
>>       [3].
>>
>>
>>
>>       ----------
>>
>>
>>
>>       OPTION 1 (RFC 7326 - Energy Management Framework [4]):
>>
>>
>>
>>           CLASS NetworkInterface EXTENDS HardwareComponent {
>>
>>               name            : string
>>
>>               index           : int
>>
>>               hardwareAddress : MACAddress
>>
>>               type            : enum {ether, fddi, loopback, .}
>>
>>               flags [0..n]    : enum {up, broadcast, debug, .}
>>
>>           }
>>
>>
>>
>>           Network Interface (Class):
>>
>>                name               string        The name of the interface.
>>
>>                index              int           The index of the interface.
>>
>>                hardwareAddress    MACAddress    The IEEE 802 MAC address.
>>
>>                type               Enumeration   Describes the type of the network
>>       interface.
>>
>>                flags [0..n]       Enumeration   Describes the flags set on the
>>       interface.
>>
>>
>>
>>       ----------
>>
>>
>>
>>       OPTION 2 (Information Model for Large-Scale Measurement Platforms [5]):
>>
>>
>>
>>           Definition of network-interface-obj
>>
>>
>>
>>           object {
>>
>>               string name;
>>
>>               int index;
>>
>>               mac-address-obj hardware-address;
>>
>>               string type;
>>
>>               string flags<0..n>;
>>
>>           } network-interface-obj;
>>
>>
>>
>>           A network-interface-object consists of the following elements:
>>
>>
>>
>>           name:               The name of the interface.
>>
>>           index:              The index of the interface.
>>
>>           hardwareAddress:    The IEEE 802 MAC address.
>>
>>           type:               Describes the type of the network interface. The
>>       value 'ether' indicates.
>>
>>           flags:              Describes the flags set on the interface. The value
>>       'up' indicates.
>>
>>
>>
>>       ----------
>>
>>
>>
>>       OPTION 3 (Unified Modeling Language [6]):
>>
>>
>>
>>           +-------------------+
>>
>>           | HardwareComponent |
>>
>>           +-------------------+
>>
>>           | .                 |
>>
>>           +-------------------+
>>
>>                    ^
>>
>>                    |
>>
>>           +---------------------+
>>
>>           | NetworkInterface    |
>>
>>           +---------------------+
>>
>>           | string name         |
>>
>>           | int    index        |
>>
>>           | enum   type         |
>>
>>           | enum   flags [0..n] |<>----[ MACAddress ]
>>
>>           +---------------------+
>>
>>
>>
>>           The aggregate class that constitutes a NetworkInterface is:
>>
>>                MACAddress
>>
>>                    One. The IEEE 802 MAC address.
>>
>>
>>
>>           The Network Interface class has four attributes:
>>
>>                name
>>
>>                    Required. String. The name of the interface.
>>
>>                index
>>
>>                    Required. Int. The index of the interface.
>>
>>                type
>>
>>                    Required. Enum. Describes the type of network interface.
>>
>>                flags
>>
>>                    Optional. 0..n. Describes the flags set on the interface.
>>
>>
>>
>>       ----------
>>
>>
>>
>>       OPTION 4 (Entity-Relationship Diagram [7]):
>>
>>
>>
>>           +-------------------+
>>
>>           | HardwareComponent |
>>
>>           +-------------------+
>>
>>                    |
>>
>>                < IS-A >
>>
>>                    |
>>
>>           +------------------+
>>
>>           | NetworkInterface |--------
>>
>>           +------------------+       |
>>
>>                    |----( name )     |
>>
>>                    |----( index )    |
>>
>>                    |----( type )     |
>>
>>                    |----(( flags ))  |
>>
>>                                      |
>>
>>                +------------+        |
>>
>>               | MACAddress |----< HAS-A >
>>
>>               +------------+
>>
>>
>>
>>           The NetworkInterface entity IS-A HardwareComponent and HAS-A MACAddress.
>>
>>
>>
>>           It has four attributes:
>>
>>
>>
>>           name
>>
>>               Required. String. The name of the interface.
>>
>>           index
>>
>>               Required. Int. The index of the interface.
>>
>>           type
>>
>>               Required. Enum. Describes the type of network interface.
>>
>>           flags
>>
>>               Optional. 0..n. Describes the flags set on the interface.
>>
>>
>>
>>       ----------
>>
>>
>>
>>       Lastly, during the meeting the Kerberos information model was suggested as
>>       another option so that has been added to the list.
>>
>>
>>
>>       ----------
>>
>>       OPTION 5 (RFC 6880 - An Information Model for Kerberos Version 5 [8]):
>>
>>
>>
>>           1.1 NetworkInterface
>>
>>                   The NetworkInterface represents an network interface card...The
>>       NetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in an
>>       implementation.
>>
>>
>>
>>           1.1.1 NetworkInterface : Attributes
>>
>>
>>
>>           1.1.1.1 name
>>
>>               The name of the network interface card. It MUST be provided...
>>
>>
>>
>>           1.1.1.2 index
>>
>>               The index of the interface.  It MUST be provided...
>>
>>
>>
>>           1.1.1.2 type
>>
>>               The type of the interface.  It MUST be provided...
>>
>>
>>
>>           1.1.1.2 flags
>>
>>               The flags set on the interface.  It MAY be provided...
>>
>>
>>
>>           1.1.2 NetworkInterface : Associations
>>
>>               Each NetworkInterface MUST be associated with a single MACAddress.
>>       The MACAddress is represented in this model below...
>>
>>
>>
>>       ----------
>>
>>
>>
>>       During the meeting, there seemed to be consensus around OPTION 1.  There was
>>       also a suggestion by Jim Schaad that we will want to use a syntax that can
>>       be checked in some automated fashion.  It would be great to learn more about
>>       that.
>>
>>
>>
>>       Anyways, please let me know, by  December 1st, what option you prefer so
>>       that we can reach a decision on how to represent our Information Model.
>>
>>
>>
>>       Please let me know if you have any questions.
>>
>>
>>
>>       Thanks,
>>
>>       Danny
>>
>>
>>
>>
>>       [1] Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf>
>>       < Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > >
>>
>>       [2]
>>       Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
>>       7 <
>>       Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
>>       7 >
>>
>>       [3] Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >
>>       < Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >
>>
>>
>>       [4] Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  <
>>       Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >
>>
>>       [5]
>>       Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
>>       del/ < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  <
>>       Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
>>       del/ < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >
>>
>>       [6] Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  <
>>       Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  >
>>
>>       [7] Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >
>>       < Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >
>>
>>       [8] Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  <
>>       Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >
>>
>>
>>
>>
>>       _______________________________________________
>>       sacm mailing list
>>       [e-mail] < Caution-Caution-mailto:[e-mail] >
>>       Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >
>>
>>
>>
>>
>> _______________________________________________
>> sacm mailing list
>> [e-mail]
>> Caution-https://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>



-- 

Best regards,
Kathleen