Subject: [sacm] IM Issue #27 - Selecting an Information Model Representation

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 20 Nov 2015 11:56:45 +0000

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] https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf

[2] https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27

[3] https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html

[4] https://datatracker.ietf.org/doc/rfc7326/

[5] https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/

[6] http://www.uml-diagrams.org/

[7] https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

[8] https://datatracker.ietf.org/doc/rfc6880/

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 20 Nov 2015 13:53:15 +0000

+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: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Friday, November 20, 2015 6:57 AM
To: [email-masked]
Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information Model Representation

Hi Everyone,

----------

        name            : string

        index           : int

        type            : enum {ether, fddi, loopback, .}

        flags [0..n]    : enum {up, broadcast, debug, .}

    }

----------

    object {

        string name;

        int index;

        string type; 

        string flags<0..n>;

    } network-interface-obj;

    type:               Describes the type of the network interface. The value 'ether' indicates.

    flags:              Describes the flags set on the interface. The value 'up' indicates.

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

    | .                 |

    +-------------------+

             ^

             |

    +---------------------+

    | NetworkInterface    |

    +---------------------+

    | string name         |

    | int    index        |

    | enum   type         |

    +---------------------+      

         MACAddress

         name

         index

         type

         flags

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

             |

         < IS-A >

             |

    +------------------+

    +------------------+       |

             |----( name )     |

             |----( index )    |

             |----( type )     |

             |----(( flags ))  |

                               |

         +------------+        |

        +------------+         

    It has four attributes:

    name

    index

    type

    flags

----------

----------

    1.1 NetworkInterface

    1.1.1.1 name

    1.1.1.2 index

    1.1.1.2 type

    1.1.1.2 flags

----------

Thanks,

Danny

[1] Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > 

[2] Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27 > 

[3] Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html > 

[4] Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ > 

[5] Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ > 

[6] Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ > 

[7] Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model > 

[8] Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 20 Nov 2015 15:06:50 +0000

I also like option 1.

Dave

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L CIV DISA ID (US)
Sent: Friday, November 20, 2015 8:53 AM
To: Haynes, Dan <[email-masked]>; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Friday, November 20, 2015 6:57 AM
To: [email-masked]
Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information Model Representation

Hi Everyone,

----------

        name            : string

        index           : int

    }

----------

    object {

        string name;

        int index;

        string type; 

        string flags<0..n>;

    } network-interface-obj;

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

    | .                 |

    +-------------------+

             ^

             |

    +---------------------+

    | NetworkInterface    |

    +---------------------+

    | string name         |

    | int    index        |

    | enum   type         |

    +---------------------+      

         MACAddress

         name

         index

         type

         flags

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

             |

         < IS-A >

             |

    +------------------+

    +------------------+       |

             |----( name )     |

             |----( index )    |

             |----( type )     |

             |----(( flags ))  |

                               |

         +------------+        |

        +------------+         

    It has four attributes:

    name

    index

    type

    flags

----------

----------

    1.1 NetworkInterface

    1.1.1.1 name

    1.1.1.2 index

    1.1.1.2 type

    1.1.1.2 flags

----------

Thanks,

Danny

---

From: Jerome Athias <[email-masked]>
Date: Fri, 20 Nov 2015 18:36:01 +0300

answer (preferred option) should be dictated by our
vision/strategy/roadmap/deadlines
objectives regarding ease of guidance/implementation
level of abstraction (e.g.: UML), platform independence
"complexity"/flexibility/modularity/extensibility/interoperability

2015-11-20 14:56 GMT+03:00 Haynes, Dan <[email-masked]>:
> 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]):
>
>
>
>         type            : enum {ether, fddi, loopback, …}
>
>         flags [0..n]    : enum {up, broadcast, debug, …}
>
>     }
>
>
>
>     type:               Describes the type of the network interface. The
> value 'ether' indicates…
>
>     flags:              Describes the flags set on the interface. The value
> 'up' indicates…
>
>
>
> ----------
>
>
>
>     | …                 |
> 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.
>
>
>
>         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.
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 20 Nov 2015 11:35:46 -0500

Hi,

I also like option 1.

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
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Nov 20, 2015 at 10:06 AM, Waltermire, David A. <
[email-masked]> wrote:

> +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
> 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].
>
>
>
> ----------
>
>
>
> value 'ether' indicates.
>             The NetworkInterface represents an network interface
> card...The NetworkInterface MUST be implemented in full and MUST NOT be
> OPTIONAL in an implementation.
>
>
>
> 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.
>
>
>
> [1] Caution-
> https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-
> https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >
>
> [2] Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27 <
> Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27 >
>
> [3] Caution-
> https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html <
> Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >
>
> [4] Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >
>
> [5] Caution-
> https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/
> < Caution-
> https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >
>
> [7] Caution-
> https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-
> https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >
>
> [8] Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >
>
>
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 24 Nov 2015 15:11:46 +0000

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)
[mailto:[email-masked]] 
Sent: Friday, November 20, 2015 8:53 AM
To: Haynes, Dan <[email-masked]>; [email-masked]
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.  

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

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Friday, November 20, 2015 6:57 AM
To: [email-masked]
Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
Model Representation

Hi Everyone,

----------

        name            : string

        index           : int

    }

         type               Enumeration   Describes the type of the network
interface.

         flags [0..n]       Enumeration   Describes the flags set on the
interface.

----------

    object {

        string name;

        int index;

        string type; 

        string flags<0..n>;

    } network-interface-obj;

'up' indicates.

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

    | .                 |

    +-------------------+

             ^

             |

    +---------------------+

    | NetworkInterface    |

    +---------------------+

    | string name         |

    | int    index        |

    | enum   type         |

    +---------------------+      

         MACAddress

         name

         index

         type

         flags

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

             |

         < IS-A >

             |

    +------------------+

    +------------------+       |

             |----( name )     |

             |----( index )    |

             |----( type )     |

             |----(( flags ))  |

                               |

         +------------+        |

        +------------+         

    It has four attributes:

    name

    index

    type

    flags

----------

----------

    1.1 NetworkInterface

    1.1.1.1 name

    1.1.1.2 index

    1.1.1.2 type

    1.1.1.2 flags

----------

Thanks,

Danny

[1] Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf
< Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > 

[2]
Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2
7 <
Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2
7 > 

[3] Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html
< Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >

[4] Caution-https://datatracker.ietf.org/doc/rfc7326/ <
Caution-https://datatracker.ietf.org/doc/rfc7326/ > 

[5]
Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
del/ <
Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
del/ > 

[6] Caution-http://www.uml-diagrams.org/ <
Caution-http://www.uml-diagrams.org/ > 

[7] Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
< Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model > 

[8] Caution-https://datatracker.ietf.org/doc/rfc6880/ <
Caution-https://datatracker.ietf.org/doc/rfc6880/ >

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 24 Nov 2015 15:20:24 +0000

Thanks for all the feedback so far.  Did anyone else have any other thoughts on this?

Also, Jim, did you have any thoughts on this with respect to automated checking of this representation?  I know we briefly discussed it during IETF 94.

Thanks,

Danny

From: Ira McDonald [mailto:[email-masked]]
Sent: Friday, November 20, 2015 11:36 AM
To: Waltermire, David A. <[email-masked]>; Ira McDonald <[email-masked]>
Cc: Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>; Haynes, Dan <[email-masked]>; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

Hi,
I also like option 1.
Cheers,
- Ira

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

On Fri, Nov 20, 2015 at 10:06 AM, Waltermire, David A. <[email-masked]<mailto:[email-masked]>> wrote:
I also like option 1.

Dave

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Wolfkiel, Joseph L CIV DISA ID (US)
Sent: Friday, November 20, 2015 8:53 AM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: (301) 225-8820<tel:%28301%29%20225-8820>
Gov Cell: (571) 814-8231<tel:%28571%29%20814-8231>
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Haynes, Dan
Sent: Friday, November 20, 2015 6:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information Model Representation

Hi Everyone,

----------

        name            : string

        index           : int

    }

----------

    object {

        string name;

        int index;

        string type;

        string flags<0..n>;

    } network-interface-obj;

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

    | .                 |

    +-------------------+

             ^

             |

    +---------------------+

    | NetworkInterface    |

    +---------------------+

    | string name         |

    | int    index        |

    | enum   type         |

    +---------------------+

         MACAddress

         name

         index

         type

         flags

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

             |

         < IS-A >

             |

    +------------------+

    +------------------+       |

             |----( name )     |

             |----( index )    |

             |----( type )     |

             |----(( flags ))  |

                               |

         +------------+        |

        +------------+

    It has four attributes:

    name

    index

    type

    flags

----------

----------

    1.1 NetworkInterface

    1.1.1.1 name

    1.1.1.2 index

    1.1.1.2 type

    1.1.1.2 flags

----------

Thanks,

Danny

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

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Tue, 24 Nov 2015 15:21:48 +0000

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

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, November 24, 2015 10:12 AM
To: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]
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,

Danny

-----Original Message-----
[Caution-mailto:[email-masked]] 

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [Caution-mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Friday, November 20, 2015 6:57 AM
To: [email-masked]
Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
Model Representation

Hi Everyone,

----------

        name            : string

        index           : int

    }

----------

    object {

        string name;

        int index;

        string type; 

        string flags<0..n>;

    } network-interface-obj;

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

    | .                 |

    +-------------------+

             ^

             |

    +---------------------+

    | NetworkInterface    |

    +---------------------+

    | string name         |

    | int    index        |

    | enum   type         |

    +---------------------+      

         MACAddress

         name

         index

         type

         flags

----------

    +-------------------+

    | HardwareComponent |

    +-------------------+

             |

         < IS-A >

             |

    +------------------+

    +------------------+       |

             |----( name )     |

             |----( index )    |

             |----( type )     |

             |----(( flags ))  |

                               |

         +------------+        |

        +------------+         

    It has four attributes:

    name

    index

    type

    flags

----------

----------

    1.1 NetworkInterface

    1.1.1.1 name

    1.1.1.2 index

    1.1.1.2 type

    1.1.1.2 flags

----------

Thanks,

Danny

[1] 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-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2
7 <
Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2
7 > 

[3] 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-https://datatracker.ietf.org/doc/rfc7326/ <
Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ > 

[5]
Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
del/ <
Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
del/ > 

[6] Caution-Caution-http://www.uml-diagrams.org/ <
Caution-Caution-http://www.uml-diagrams.org/ > 

[7] 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-https://datatracker.ietf.org/doc/rfc6880/ <
Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 24 Nov 2015 10:25:00 -0500

An enumeration, then, becomes another type of content.  It needs an 
authoritative source, plus the abilities to create notifications when it 
changes and be distributed to all points of usage.

--gun

---

From: Ira McDonald <[email-masked]>
Date: Tue, 24 Nov 2015 10:33:18 -0500

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

On Tue, Nov 24, 2015 at 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> 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
> 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.
>
>
>
>
> ----
>
> a
> time,
> discussed
> list.
> was
> [1] Caution-Caution-
> https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf
> < Caution-Caution-
> Caution-Caution-
> Caution-Caution-
> [3] 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-
> https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
> del/ <
> Caution-Caution-
> [7] Caution-Caution-
> https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
> < Caution-Caution-

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Tue, 24 Nov 2015 15:47:19 +0000

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

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2015 10:33 AM
To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald
Cc: Haynes, Dan; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

________________________________

Hi Dan and Joseph,

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-http://sites.google.com/site/blueroofmusic < Caution-http://sites.google.com/site/blueroofmusic > 
Caution-http://sites.google.com/site/highnorthinc < Caution-http://sites.google.com/site/highnorthinc > 
Caution-mailto: [email-masked] < Caution-mailto:[email-masked] > 
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) <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	
	Joseph L. Wolfkiel
	SCM Engineering Lead
	DISA ID52
	Fort Meade DISA Acquisiton Bldg Cube A4A58E
	Work: (301) 225-8820 < tel:%28301%29%20225-8820 > 
	Gov Cell: (571) 814-8231 < tel:%28571%29%20814-8231 > 
	[email-masked] < Caution-mailto:[email-masked] > 

	-----Original Message-----
	From: sacm [Caution-mailto:[email-masked] < Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
	Sent: Tuesday, November 24, 2015 10:12 AM
	To: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < Caution-mailto:[email-masked] > 
	Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

	
	
	----

	

	Thanks,
	
	Danny
	
	-----Original Message-----
	
	[Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] > ]
	Sent: Friday, November 20, 2015 8:53 AM
	To: Haynes, Dan <[email-masked] < Caution-mailto:[email-masked] > >; [email-masked] < Caution-mailto:[email-masked] > 
	Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
	Model Representation

	

	Joseph L. Wolfkiel
	SCM Engineering Lead
	DISA ID52
	Fort Meade DISA Acquisiton Bldg Cube A4A58E
	Work: (301) 225-8820 < tel:%28301%29%20225-8820 > 
	Gov Cell: (571) 814-8231 < tel:%28571%29%20814-8231 > 
	[email-masked] < Caution-mailto:[email-masked] > 

	-----Original Message-----
	
	From: sacm [Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
	Sent: Friday, November 20, 2015 6:57 AM
	To: [email-masked] < Caution-mailto:[email-masked] > 
	Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
	Model Representation
	
	Hi Everyone,

	

	----------

	
	
	        name            : string
	
	        index           : int

	
	
	    }

	

	

	
	----------

	

	    object {
	
	        string name;
	
	        int index;

	        string type;
	
	        string flags<0..n>;
	
	    } network-interface-obj;

	

	

	
	----------

	
	    +-------------------+
	
	    | HardwareComponent |
	
	    +-------------------+
	
	    | .                 |
	
	    +-------------------+
	
	             ^
	
	             |
	
	    +---------------------+
	
	    | NetworkInterface    |
	
	    +---------------------+
	
	    | string name         |
	
	    | int    index        |
	
	    | enum   type         |

	    +---------------------+

	
	         MACAddress

	
	
	         name

	         index

	         type

	         flags

	
	----------

	
	    +-------------------+
	
	    | HardwareComponent |
	
	    +-------------------+
	
	             |
	
	         < IS-A >
	
	             |
	
	    +------------------+

	    +------------------+       |
	
	             |----( name )     |
	
	             |----( index )    |
	
	             |----( type )     |
	
	             |----(( flags ))  |
	
	                               |
	
	         +------------+        |

	        +------------+

	
	    It has four attributes:

	    name

	    index

	    type

	    flags

	
	----------

	
	----------

	
	    1.1 NetworkInterface

	

	    1.1.1.1 name

	
	    1.1.1.2 index

	
	    1.1.1.2 type

	
	    1.1.1.2 flags

	

	
	----------

	

	
	Thanks,
	
	Danny

	
	[1] Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > 
	< Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >
	
	[2]
	Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 > 
	7 <
	Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 > 
	7 >
	
	[3] Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html > 
	< Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >

	[4] Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  <
	Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >
	
	[5]
	Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
	del/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  <
	Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
	del/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >
	
	[6] Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  <
	Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >
	
	[7] Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model > 
	< Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >
	
	[8] Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  <
	Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >

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

---

From: Chris Inacio <[email-masked]>
Date: Thu, 26 Nov 2015 04:10:19 +0000

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
[email-masked]

> On Nov 24, 2015, at 10:47 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]> wrote:
> 
> 	[1] Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 27 Nov 2015 14:05:28 +0000

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

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]] 
Sent: Wednesday, November 25, 2015 11:10 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Ira McDonald; Haynes, Dan; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

--
Chris Inacio
[email-masked]

> From: Ira McDonald [Caution-mailto:[email-masked]] 
> 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: [email-masked] < Caution-Caution-mailto:[email-masked] > 
> On Tue, Nov 24, 2015 at 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-Caution-mailto:[email-masked] > > wrote:
> 
> 
> 	[email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	
> 	
> 	
> 	From: sacm [Caution-Caution-mailto:[email-masked] < Caution-Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
> 	To: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	[Caution-Caution-Caution-mailto:[email-masked] < Caution-Caution-mailto:[email-masked] > ]
> 	To: Haynes, Dan <[email-masked] < Caution-Caution-mailto:[email-masked] > >; [email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	[email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	
> 	
> 	
> 	From: sacm [Caution-Caution-Caution-mailto:[email-masked] < Caution-Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
> 	To: [email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	[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/ >  >
> 	
> 	
> 	
> 	
> 	[email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm > 
> 	
> 	
> 
> 
> Caution-https://www.ietf.org/mailman/listinfo/sacm

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 27 Nov 2015 13:51:28 -0500

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

-- 

Best regards,
Kathleen

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 27 Nov 2015 19:36:56 +0000

Understood.  Hopefully, the fact that I said "XML" and "REST" won't detract too much from my attempted explanation of the business logic required to maintain dynamic enumerations and the attributes needed to support the business logic.  I'm a big fan of modeling data with UML class diagrams and E-R diagrams. 

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Friday, November 27, 2015 1:51 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Chris Inacio; Ira McDonald; Haynes, Dan; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation

Hi,

Thanks,
Kathleen

On Fri, Nov 27, 2015 at 9:05 AM, Wolfkiel, Joseph L CIV DISA ID (US)
<[email-masked]> wrote:
> From: Chris Inacio [Caution-mailto:[email-masked]]
>> From: Ira McDonald [Caution-Caution-mailto:[email-masked]]
>> Caution-Caution-Caution-http://sites.google.com/site/blueroofmusic < Caution-Caution-Caution-http://sites.google.com/site/blueroofmusic >
>> Caution-Caution-Caution-http://sites.google.com/site/highnorthinc < Caution-Caution-Caution-http://sites.google.com/site/highnorthinc >
>> Caution-Caution-Caution-mailto: [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>> On Tue, Nov 24, 2015 at 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-Caution-Caution-mailto:[email-masked] > > wrote:
>>
>>
>>       [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>>
>>
>>
>>       From: sacm [Caution-Caution-Caution-mailto:[email-masked] < Caution-Caution-Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
>>       To: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>>       [Caution-Caution-Caution-Caution-mailto:[email-masked] < Caution-Caution-Caution-mailto:[email-masked] > ]
>>       To: Haynes, Dan <[email-masked] < Caution-Caution-Caution-mailto:[email-masked] > >; [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>>       [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>>
>>
>>
>>       From: sacm [Caution-Caution-Caution-Caution-mailto:[email-masked] < Caution-Caution-Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
>>       To: [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>>       [1] Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf>
>>       < Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > >
>>
>>       [2]
>>       Caution-Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
>>       7 <
>>       Caution-Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
>>       7 >
>>
>>       [3] Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >
>>       < Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >
>>
>>
>>       [4] Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  <
>>       Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >
>>
>>       [5]
>>       Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
>>       del/ < Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  <
>>       Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-mo
>>       del/ < Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >
>>
>>       [6] Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-Caution-http://www.uml-diagrams.org/ >  <
>>       Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-Caution-http://www.uml-diagrams.org/ >  >
>>
>>       [7] Caution-Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >
>>       < Caution-Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >
>>
>>       [8] Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  <
>>       Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >
>>
>>
>>
>>
>>       [email-masked] < Caution-Caution-Caution-mailto:[email-masked] >
>>       Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >
>>
>>
>>
>>
>> Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm
>
>

-- 

Best regards,
Kathleen

---

From: Jerome Athias <[email-masked]>
Date: Sat, 28 Nov 2015 06:14:58 +0300

In XORCISM I am managing the enumerations using what I call Vocabularies:
Vocabulary has a relationship to Organisation(s)
(Gives you the name space)

Vocabulary has versioning

Vocabulary supports various enumerations hierarchy

Vocabulary's enumeration could be deprecated (better than just deleting one
item, and in case you don't want to increase the version)

Vocabularies have a mapping (when needed) allowing switching or direct
retrieval of equivalents (v1/v2 or org1/org2, etc.)

On Tuesday, 24 November 2015, Gunnar Engelbach <
[email-masked]> wrote:

> Gov Cell: (571) [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
>
>
> From: sacm [mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of Haynes, Dan
> To: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [Caution-mailto:[email-masked] <javascript:_e(%7B%7D,'cvml','Caution-mailto:[email-masked]');>]
> To: Haynes, Dan <[email-masked]> <javascript:_e(%7B%7D,'cvml',[email-masked]');>; [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> Gov Cell: (571) [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
>
>
> From: sacm [Caution-mailto:[email-masked] <javascript:_e(%7B%7D,'cvml','Caution-mailto:[email-masked]');>] On Behalf Of Haynes, Dan
> To: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> del/ <https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/> <
> del/ <https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/> >
>
> sacm mailing [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>https://www.ietf.org/mailman/listinfo/sacm
>
>
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 30 Nov 2015 13:31:58 +0000

If there is actually interest in this topic, we can discuss in detail.  One of the reasons I didn't go with a version-based implementation is usability.  In general, our name maintenance system is a real-time system where users can go in, update a hierarchy with new locations, organizations, or system names, then immediately download the updated list.  As you can imagine, if multiple users are doing this over the course of a day, then trying to track versions becomes onerous to maintain and understand.  In the system we're using, the downloaded hierarchy contains a timestamp of when it was downloaded.  Since all changes (additions, modifications, deletions) are included and timestamped, you can walk back through time by just selecting the modifications that happened before the time you're concerned with.  This is implemented as an alternative to versioning.  The timestamp approach also allows consumers to do incremental downloads where they only receive changes since the last time a 
 download was made instead of having to download an entire version of each enumeration/taxonomy.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]] 
Sent: Friday, November 27, 2015 10:15 PM
To: Gunnar Engelbach
Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked]
Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation

Vocabulary's enumeration could be deprecated (better than just deleting one item, and in case you don't want to increase the version)

Vocabularies have a mapping (when needed) allowing switching or direct retrieval of equivalents (v1/v2 or org1/org2, etc.)

On Tuesday, 24 November 2015, Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	An enumeration, then, becomes another type of content.  It needs an authoritative source, plus the abilities to create notifications when it changes and be distributed to all points of usage.

	--gun

		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. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > -----O
 riginal Message-----From: sacm [Caution-mailto:[email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24, 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model RepresentationAll 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 ourIM, implementers are free to use XML, JSON, or maybe something else todocument/implement the IM via the creation of data model.  I think it wouldalso be acceptable for them to generate UML diagrams if they would like.Yeah, the point about enumerations is a good on
 e given the may change morefrequently.  Does anyone have any thoughts on how to best handle what wouldbe enumerations in the Information Model?  Would it be best to document theenumerations in separate document that would change over time and the IMcould just reference out to it?Agree, I am going to add a track that points to this thread and the previousthread regarding whether or not a network interface is hardware, software,or something else.  That way we can refer back to the relevant discussionswhen it comes time to design it in the IM.Thanks,Danny-----Original Message-----From: Wolfkiel, Joseph L CIV DISA ID (US)[Caution-Caution-mailto:[email-masked] < javascript:_e(%7B%7D,'cvml','Caution-Caution-mailto:[email-masked]'); > ] Sent: Friday, November 20, 2015 8:53 AMTo: Haynes, Dan <[email-masked]> < javascript:_e(%7B%7D,'cvml',[email-masked]'); > ; [email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > Subject: RE: [Non-DoD Source] 
 [sacm] IM Issue #27 - Selecting an InformationModel Representation+1 here for something like option 1.  I personally like using XML schema todocument this type of thing in a machine-readable manner.  JSON schema andUML class diagrams should also be considered.  For this particular example, I suggest that enumerations be maintainedseparately 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 arepersistent.  For example, a hardware Network Interface *card* is persistentand discoverable.  However, a virtual network interface card (for example, anetwork interface generated by a VPN client) may come and go, so the modelshould be able to identify both, along with any metadata required to notethat a given component existed for a given time period.Also, a "network interface" could be understood to describe a logicalconnection to a specific netw
 ork and would address issues like IP/MACaddresses, network name, default gateway, DNS Name, initial connection time,address "lease", and other issues.  It's good that the data model helps tounderstand that saying "network interface" doesn't actually mean the samething to everyone talking about it.Joseph L. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > -----Original Message-----From: sacm [Caution-Caution-mailto:[email-masked] < javascript:_e(%7B%7D,'cvml','Caution-Caution-mailto:[email-masked]'); > ] On Behalf Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo: [email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel RepresentationHi Everyone,During the Information Model Update [1] at the IETF 94 Meeting, we
  discussedvarious modeling syntax options for our Information Model elements.  Thiscorresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted toinclude 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 nota network interface is a hardware component, software component, both, orsomething 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 networkinterface.         flags [0..n]       Enumeration   Describes the flags set on theinterface. ---------- 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. Thevalue '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 meet
 ing the Kerberos information model was suggested asanother 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...TheNetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in animplementation.     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 w
 asalso a suggestion by Jim Schaad that we will want to use a syntax that canbe checked in some automated fashion.  It would be great to learn more aboutthat. Anyways, please let me know, by  December 1st, what option you prefer sothat 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-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  > [2]Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 > 7 <Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.c
 om/sacmwg/draft-ietf-sacm-information-model/issues/2 > 7 > [3] Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html > < Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >[4] Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  <Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  > [5]Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  <Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-i
 nformation-model/ >  > [6] Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  <Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  > [7] Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model > < Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  > [8] Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  <Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  

		_______________________________________________sacm mailing [email-masked] < javascript:_e(%7B%7D,'cvml',[email-masked]'); > Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >

---

From: Jerome Athias <[email-masked]>
Date: Mon, 30 Nov 2015 17:03:16 +0300

I have implemented something like this with the use of 2 objects
A CreationRecord and a ChangeRecord objects attached to all the other
objects
Everything is time stamped + traceable in terms of who did what when +
confidence level, trust level...

On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> If there is actually interest in this topic, we can discuss in detail.
> One of the reasons I didn't go with a version-based implementation is
> usability.  In general, our name maintenance system is a real-time system
> where users can go in, update a hierarchy with new locations,
> organizations, or system names, then immediately download the updated
> list.  As you can imagine, if multiple users are doing this over the course
> of a day, then trying to track versions becomes onerous to maintain and
> understand.  In the system we're using, the downloaded hierarchy contains a
> timestamp of when it was downloaded.  Since all changes (additions,
> modifications, deletions) are included and timestamped, you can walk back
> through time by just selecting the modifications that happened before the
> time you're concerned with.  This is implemented as an alternative to
> versioning.  The timestamp approach also allows consumers to do incremental
> downloads where they only receive changes since the last time a download
> was made instead of having to download an entire version of each
> enumeration/taxonomy.
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> [email-masked] <javascript:;>
>
>
>
> From: Jerome Athias [mailto:[email-masked] <javascript:;>]
> <javascript:;>
> Vocabulary's enumeration could be deprecated (better than just deleting
> one item, and in case you don't want to increase the version)
>
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> > > wrote:
>
>
>
>         An enumeration, then, becomes another type of content.  It needs
> an authoritative source, plus the abilities to create notifications when it
>                 For the DoD, I've implemented an enumeration maintenance
> system, a standard XML schema, and a restful web service for maintaining
> 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. WolfkielSCM
> Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork:
> (301) 225-8820Gov Cell: (571) [email-masked]
> <javascript:;> < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;>'); > -----Original
> Message-----From: sacm [Caution-mailto:[email-masked]
> <javascript:;> < javascript:_e(%7B%7D,'cvml',[email-masked]
> <javascript:;>'); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24,
> 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]
> <javascript:;> < javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>');
> > Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an
> Information Model RepresentationAll 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
> ourIM, implementers are free to use XML, JSON, or maybe something else
> todocument/implement the IM via the creation of data model.  I think it
> wouldalso 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
> morefrequently.  Does anyone have any thoughts on how to best handle what
> wouldbe enumerations in the Information Model?  Would it be best to
> document theenumerations in separate document that would change over time
> and the IMcould just reference out to it?Agree, I am going to add a track
> that points to this thread and the previousthread regarding whether or not
> a network interface is hardware, software,or something else.  That way we
> can refer back to the relevant discussionswhen it comes time to design it
> in the IM.Thanks,Danny-----Original Message-----From: Wolfkiel, Joseph L
> CIV DISA ID (US)[Caution-Caution-mailto:[email-masked]
> <javascript:;> < javascript:_e(%7B%7D,'cvml','Caution-Caution-mailto:
> [email-masked] <javascript:;>'); > ] Sent: Friday,
> November 20, 2015 8:53 AMTo: Haynes, Dan <[email-masked] <javascript:;>>
> < javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>'); > ;
> [email-masked] <javascript:;> < javascript:_e(%7B%7D,'cvml',[email-masked]
> <javascript:;>'); > Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 -
> Selecting an InformationModel Representation+1 here for something like
> option 1.  I personally like using XML schema todocument this type of thing
> in a machine-readable manner.  JSON schema andUML class diagrams should
> also be considered.  For this particular example, I suggest that
> enumerations be maintainedseparately 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 arepersistent.  For example, a hardware Network Interface
> *card* is persistentand discoverable.  However, a virtual network interface
> card (for example, anetwork interface generated by a VPN client) may come
> and go, so the modelshould be able to identify both, along with any
> metadata required to notethat a given component existed for a given time
> period.Also, a "network interface" could be understood to describe a
> logicalconnection to a specific network and would address issues like
> IP/MACaddresses, network name, default gateway, DNS Name, initial
> connection time,address "lease", and other issues.  It's good that the data
> model helps tounderstand that saying "network interface" doesn't actually
> mean the samething to everyone talking about it.Joseph L. WolfkielSCM
> Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork:
> (301) 225-8820Gov Cell: (571) [email-masked]
> <javascript:;> < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;>'); > -----Original
> Message-----From: sacm [Caution-Caution-mailto:[email-masked]
> <javascript:;> < javascript:_e(%7B%7D,'cvml','Caution-Caution-mailto:
> [email-masked] <javascript:;>'); > ] On Behalf Of Haynes, DanSent:
> Friday, November 20, 2015 6:57 AMTo: [email-masked] <javascript:;> <
> javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>'); > Subject:
> [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel
> RepresentationHi Everyone,During the Information Model Update [1] at the
> IETF 94 Meeting, we discussedvarious modeling syntax options for our
> Information Model elements.  Thiscorresponds to IM issue #27 [2].  Sorry
> for the long email, but, I wanted toinclude 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 nota network interface is a hardware component, software
> component, both, orsomething 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
> networkinterface.         flags [0..n]       Enumeration   Describes the
> flags set on theinterface. ---------- 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. Thevalue '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 asanother 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...TheNetworkInterface MUST be implemented in full
> and MUST NOT be OPTIONAL in animplementation.     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... ----------
> wasalso a suggestion by Jim Schaad that we will want to use a syntax that
> canbe checked in some automated fashion.  It would be great to learn more
> aboutthat. Anyways, please let me know, by  December 1st, what option you
> prefer sothat 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-
> https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf > <
> Caution-Caution-Caution-
> https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >
> [2]Caution-Caution-Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 <
> Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 > 7
> <Caution-Caution-Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 <
> 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-Caution-
> Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html
> >  >[4] Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/
> < Caution-https://datatracker.ietf.org/doc/rfc7326/ >
> <Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ <
> Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >
> [5]Caution-Caution-Caution-
> >  <Caution-Caution-Caution-
> >  > [6] Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-
> http://www.uml-diagrams.org/ >  <Caution-Caution-Caution-
> http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >
> [7] Caution-Caution-Caution-
> https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model > <
> Caution-Caution-Caution-
> https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  > [8]
> Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ <
> <Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ <
> Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >
>
>
>
>                 _______________________________________________sacm
> mailing [email-masked] <javascript:;> < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;>'); > Caution-
> https://www.ietf.org/mailman/listinfo/sacm < Caution-
> https://www.ietf.org/mailman/listinfo/sacm >
>
>
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 30 Nov 2015 14:10:46 +0000

Is that in addition to versioning?  Seems like the complexity would ultimately make maintaining all the historical information and business logic difficult to scale, particularly when you try to do something smart with respect to reconciling versions vs status of enumeration entries.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Monday, November 30, 2015 9:03 AM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Gunnar Engelbach; Haynes, Dan; [email-masked]
Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation

I have implemented something like this with the use of 2 objects
A CreationRecord and a ChangeRecord objects attached to all the other objects
Everything is time stamped + traceable in terms of who did what when + confidence level, trust level...

On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	Joseph L. Wolfkiel
	SCM Engineering Lead
	DISA ID52
	Fort Meade DISA Acquisiton Bldg Cube A4A58E
	Work: (301) 225-8820
	Gov Cell: (571) 814-8231
	[email-masked] < javascript:; > 

	-----Original Message-----
	From: Jerome Athias [Caution-mailto:[email-masked] < javascript:; > ]
	Sent: Friday, November 27, 2015 10:15 PM
	To: Gunnar Engelbach
	Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked] < javascript:; > 
	Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation

	

	
	On Tuesday, 24 November 2015, Gunnar Engelbach <[email-masked] < javascript:; >  < Caution-Caution-mailto:[email-masked] < javascript:; >  > > wrote:

	        --gun

	                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. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml','Joseph.L.
 [email-masked] < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24, 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model RepresentationAll 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 ourIM, implementers are free to use XML, JSON, or maybe something else todocument/implement the IM via the creation of data model.  I th
 ink it wouldalso 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 morefrequently.  Does anyone have any thoughts on how to best handle what wouldbe enumerations in the Information Model?  Would it be best to document theenumerations in separate document that would change over time and the IMcould just reference out to it?Agree, I am going to add a track that points to this thread and the previousthread regarding whether or not a network interface is hardware, software,or something else.  That way we can refer back to the relevant discussionswhen 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:[email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-mailto:[email-masked] < javascript:; > '); > ] Sent: Friday, November 20, 2015 8:53 AMTo:
  Haynes, Dan <[email-masked] < javascript:; > > < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > ; [email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel Representation+1 here for something like option 1.  I personally like using XML schema todocument this type of thing in a machine-readable manner.  JSON schema andUML class diagrams should also be considered.  For this particular example, I suggest that enumerations be maintainedseparately 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 arepersistent.  For example, a hardware Network Interface *card* is persistentand discoverable.  However, a virtual network interface card (for example, anetwork interface generated by a VPN client) 
 may come and go, so the modelshould be able to identify both, along with any metadata required to notethat a given component existed for a given time period.Also, a "network interface" could be understood to describe a logicalconnection to a specific network and would address issues like IP/MACaddresses, network name, default gateway, DNS Name, initial connection time,address "lease", and other issues.  It's good that the data model helps tounderstand that saying "network interface" doesn't actually mean the samething to everyone talking about it.Joseph L. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-mailto:sacm-
 [email-masked] < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo: [email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel RepresentationHi Everyone,During the Information Model Update [1] at the IETF 94 Meeting, we discussedvarious modeling syntax options for our Information Model elements.  Thiscorresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted toinclude 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 nota network interface is a hardware component, software component, both, orsomething 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 networkinterface.         flags [0..n]       Enumeration   Describes the flags set on theinterface. ---------- 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. Thevalue '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 consti
 tutes 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 e
 ntity 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 asanother 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...TheNetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in animplementation.     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 ty
 pe 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 wasalso a suggestion by Jim Schaad that we will want to use a syntax that canbe checked in some automated fashion.  It would be great to learn more aboutthat. Anyways, please let me know, by  December 1st, what option you prefer sothat 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-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.pd
 f < 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-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-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-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < 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-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  < Caution-Caution-https://github.c
 om/sacmwg/draft-ietf-sacm-information-model/issues/2 < 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-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-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-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-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  >[4] Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.i
 etf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  <Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  > [5]Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  <Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-h
 ttps://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  > [6] Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  <Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  > [7] Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < 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-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Cauti
 on-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  > [8] Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  <Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >

	                _______________________________________________sacm mailing [email-masked] < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; > '); > Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  >

---

From: Jerome Athias <[email-masked]>
Date: Mon, 30 Nov 2015 17:36:28 +0300

Your point is valid.
It's optional in my system.

On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> Is that in addition to versioning?  Seems like the complexity would
> ultimately make maintaining all the historical information and business
> logic difficult to scale, particularly when you try to do something smart
> with respect to reconciling versions vs status of enumeration entries.
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> From: sacm [mailto:[email-masked] <javascript:;>] On Behalf Of
> Jerome Athias
> Cc: Gunnar Engelbach; Haynes, Dan; [email-masked] <javascript:;>
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> > > wrote:
>
>
>         If there is actually interest in this topic, we can discuss in
> detail.  One of the reasons I didn't go with a version-based implementation
> is usability.  In general, our name maintenance system is a real-time
> system where users can go in, update a hierarchy with new locations,
>         [email-masked] <javascript:;> < javascript:; >
>
>
>
>         From: Jerome Athias [Caution-mailto:[email-masked]
> <javascript:;> < javascript:; > ]
>         Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan;
> [email-masked] <javascript:;> < javascript:; >
>         Vocabulary's enumeration could be deprecated (better than just
> deleting one item, and in case you don't want to increase the version)
>
>         Vocabularies have a mapping (when needed) allowing switching or
> direct retrieval of equivalents (v1/v2 or org1/org2, etc.)
>
>
>
> [email-masked] <javascript:;> < javascript:; >  <
> Caution-Caution-mailto:[email-masked] <javascript:;> <
> javascript:; >  > > wrote:
>
>
>
>                 An enumeration, then, becomes another type of content.  It
> needs an authoritative source, plus the abilities to create notifications
> when it changes and be distributed to all points of usage.
>
>
>                 --gun
>
>
>                         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.
> WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube
> A4A58EWork: (301) 225-8820Gov Cell: (571)
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>
> < javascript:; > '); > -----Original Message-----From: sacm
> [Caution-Caution-mailto:[email-masked] <javascript:;> <
> javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked]
> <javascript:;> < javascript:; > '); > ] On Behalf Of Haynes, DanSent:
> Tuesday, November 24, 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US);
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;> < javascript:;
> > '); > Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an
> CIV DISA ID (US)[Caution-Caution-Caution-mailto:
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-mailto:
> [email-masked] <javascript:;> < javascript:; > '); > ]
> Sent: Friday, November 20, 2015 8:53 AMTo: Haynes, Dan <[email-masked]
> <javascript:;> < javascript:; > > < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; > '); > ; [email-masked]
> <javascript:;> < javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; > '); > Subject: RE: [Non-DoD
> Source] [sacm] IM Issue #27 - Selecting an InformationModel
> Representation+1 here for something like option 1.  I personally like using
> XML schema todocument this type of thing in a machine-readable manner.
> JSON schema andUML class diagrams should also be considered.  For this
> particular example, I suggest that enumerations be maintainedseparately
> 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 arepersistent.
> For example, a hardware Network Interface *card* is persistentand
> discoverable.  However, a virtual network interface card (for example,
> anetwork interface generated by a VPN client) may come and go, so the
> modelshould be able to identify both, along with any metadata required to
> notethat a given component existed for a given time period.Also, a "network
> interface" could be understood to describe a logicalconnection to a
> specific network and would address issues like IP/MACaddresses, network
> name, default gateway, DNS Name, initial connection time,address "lease",
> and other issues.  It's good that the data model helps tounderstand that
> saying "network interface" doesn't actually mean the samething to everyone
> talking about it.Joseph L. WolfkielSCM Engineering LeadDISA ID52Fort Meade
> DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571)
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>
> < javascript:; > '); > -----Original Message-----From: sacm
> [Caution-Caution-Caution-mailto:[email-masked] <javascript:;> <
> javascript:; >  <
> javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-mailto:
> [email-masked] <javascript:;> < javascript:; > '); > ] On Behalf
> Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo: [email-masked]
> <javascript:;> < javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; > '); > Subject: [Non-DoD
> Source] [sacm] IM Issue #27 - Selecting an InformationModel
> Caution-Caution-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 >  >  >
> [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-
> >  > < Caution-Caution-Caution-Caution-
> >  >  >[4] Caution-Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc7326/ < Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-
> https://datatracker.ietf.org/doc/rfc7326/ < Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >  >
> <Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/
> < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-
> https://datatracker.ietf.org/doc/rfc7326/ < Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >  >  >
> [5]Caution-Caution-Caution-Caution-
> >  >  <Caution-Caution-Caution-Caution-
> >  >  > [6] Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/
> < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-
> <Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-
> http://www.uml-diagrams.org/ >  < Caution-Caution-
> > [7] Caution-Caution-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 >  >  >
> [8] Caution-Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc6880/ < Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-
> https://datatracker.ietf.org/doc/rfc6880/ < Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >  >
> <Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/
> < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-
> https://datatracker.ietf.org/doc/rfc6880/ < Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >  >  >
>
>
>
>
> _______________________________________________sacm mailing
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;> < javascript:;
> > '); > Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm <
> Caution-https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-
> https://www.ietf.org/mailman/listinfo/sacm >  >
>
>
>
>
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 30 Nov 2015 14:55:05 +0000

That makes sense then.  I suppose the question back to the SACM team is whether they (we?) want to track enumerations through versioning or timestamps with change logs.  Maybe some combination of both, based on the expected frequency of change.  It may be worthwhile to identify a few places in the expected information model where enumerations are expected to play heavily.

Possible examples:  
- Compliance results (e.g. Pass, Fail, Not Checked, Error, Fixed, Not Selected, etc)
- Device Roles (e.g. server, workstation, router, switch, etc)
- Device Form Factors (Tower, mini-tower, Blade, tablet, Phablet, virtual, etc)
- Device Functions (routing, switching, file server, web server, database server, email server, email client, hypervisor, etc)
- Software functions (word processing, spreadsheet automation, database management, calculator, Jabber Client, email client,  etc.)
- Severity Enumerations (high, med-high, med, med-low, low)
- Colors (red, orange, yellow, green, blue, indigo, violet, etc)
- Logical network location (Direct Internet connected, direct private WAN connected, DMZ, protected network connected, etc)
- Government organization names (US, UK, France, ... Maybe look at ISO names?)
- Geopolitical location names
- Human Security Roles (Approving Authority, System Administrator, Network Administrator, etc)
- Directory systems (DNS, AD,X.500, etc)
- Operating System Names (Windows, Android, Apple IOS, Cisco IOS, Linux, etc [though we still need to decide if those are "names" or not])

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Monday, November 30, 2015 9:36 AM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Gunnar Engelbach; Haynes, Dan; [email-masked]
Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation

Your point is valid.

	
	Joseph L. Wolfkiel
	SCM Engineering Lead
	DISA ID52

	-----Original Message-----
	From: sacm [Caution-mailto:[email-masked] < javascript:; > ] On Behalf Of Jerome Athias
	Sent: Monday, November 30, 2015 9:03 AM
	To: Wolfkiel, Joseph L CIV DISA ID (US)
	Cc: Gunnar Engelbach; Haynes, Dan; [email-masked] < javascript:; > 
	Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation

	On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < javascript:; >  < Caution-Caution-mailto:[email-masked] < javascript:; >  > > wrote:

	        If there is actually interest in this topic, we can discuss in detail.  One of the reasons I didn't go with a version-based implementation is usability.  In general, our name maintenance system is a real-time system where users can go in, update a hierarchy with new locations, organizations, or system names, then immediately download the updated list.  As you can imagine, if multiple users are doing this over the course of a day, then trying to track versions becomes onerous to maintain and understand.  In the system we're using, the downloaded hierarchy contains a timestamp of when it was downloaded.  Since all changes (additions, modifications, deletions) are included and timestamped, you can walk back through time by just selecting the modifications that happened before the time you're concerned with.  This is implemented as an alternative to versioning.  The timestamp approach also allows consumers to do incremental downloads where they only receive changes since the las
 t time a download was made instead of having to download an entire version of each enumeration/taxonomy.
	
	        Joseph L. Wolfkiel
	        SCM Engineering Lead
	        DISA ID52
	        Fort Meade DISA Acquisiton Bldg Cube A4A58E
	        Work: (301) 225-8820
	        Gov Cell: (571) 814-8231
	        [email-masked] < javascript:; >  < javascript:; >

	        -----Original Message-----
	        From: Jerome Athias [Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; > ]
	        Sent: Friday, November 27, 2015 10:15 PM
	        To: Gunnar Engelbach
	        Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked] < javascript:; >  < javascript:; >
	        Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation

	

	
	        On Tuesday, 24 November 2015, Gunnar Engelbach <[email-masked] < javascript:; >  < javascript:; >  < Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  > > wrote:

	                --gun

	                        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. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:; >  < javascript:; >  < javascript:_
 e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24, 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model RepresentationAll 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 ourIM, imple
 menters are free to use XML, JSON, or maybe something else todocument/implement the IM via the creation of data model.  I think it wouldalso 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 morefrequently.  Does anyone have any thoughts on how to best handle what wouldbe enumerations in the Information Model?  Would it be best to document theenumerations in separate document that would change over time and the IMcould just reference out to it?Agree, I am going to add a track that points to this thread and the previousthread regarding whether or not a network interface is hardware, software,or something else.  That way we can refer back to the relevant discussionswhen it comes time to design it in the IM.Thanks,Danny-----Original Message-----From: Wolfkiel, Joseph L CIV DISA ID (US)[Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  < javascri
 pt:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; > '); > ] Sent: Friday, November 20, 2015 8:53 AMTo: Haynes, Dan <[email-masked] < javascript:; >  < javascript:; > > < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > ; [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel Representation+1 here for something like option 1.  I personally like using XML schema todocument this type of thing in a machine-readable manner.  JSON schema andUML class diagrams should also be considered.  For this particular example, I suggest that enumerations be maintainedseparately from the data model since they are subject to change over time.This specific example also highlights an issue that merits consideration.There are aspec
 ts of endpoints that are ephemeral and some that arepersistent.  For example, a hardware Network Interface *card* is persistentand discoverable.  However, a virtual network interface card (for example, anetwork interface generated by a VPN client) may come and go, so the modelshould be able to identify both, along with any metadata required to notethat a given component existed for a given time period.Also, a "network interface" could be understood to describe a logicalconnection to a specific network and would address issues like IP/MACaddresses, network name, default gateway, DNS Name, initial connection time,address "lease", and other issues.  It's good that the data model helps tounderstand that saying "network interface" doesn't actually mean the samething to everyone talking about it.Joseph L. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:; >  < javascript:
 ; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo: [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel RepresentationHi Everyone,During the Information Model Update [1] at the IETF 94 Meeting, we discussedvarious modeling syntax options for our Information Model elements.  Thiscorresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted toinclude 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 nota network interface is a hardware component, software component, both, orsomething 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.         typ
 e               Enumeration   Describes the type of the networkinterface.         flags [0..n]       Enumeration   Describes the flags set on theinterface. ---------- 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. Thevalue '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 asanother 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 repres
 ents an network interface card...TheNetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in animplementation.     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 wasalso a suggestion by Jim Schaad that we will want to use a syntax that canbe checked in some automated fashion.  It would be great to learn more aboutthat. Anyways, please let me know, by  December 1st, what option you prefer sothat we can reac
 h 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-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < 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-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < 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-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  > < Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  < Caution-Caution-htt
 ps://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < 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-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  >  > [2]Caution-Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < 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 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  < Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-informati
 on-model/issues/2 >  < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  > 7 <Caution-Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < 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 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  < Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < 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 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  > 7 > [3] Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web
 /sacm/current/msg03199.html < 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-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  < Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < 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-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  > < Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < 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-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  < Caution-Caution-Caution-https://www.ietf.
 org/mail-archive/web/sacm/current/msg03199.html < 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-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  >  >[4] Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  >  <Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < 
 Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  >  > [5]Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.or
 g/doc/draft-burbridge-lmap-information-model/ >  >  >  <Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  >  > [6] Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagr
 ams.org/ >  >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  >  <Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  >  > [7] Caution-Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  < Caution-Caution-Caution-https://en.wikipedi
 a.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  > < Caution-Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  < Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  >  > [8] Caution-Caution-Caution-Caut
 ion-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >  <Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >  >

	                        _______________________________________________sacm mailing [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  >  < Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  >  >

---

From: Jerome Athias <[email-masked]>
Date: Mon, 30 Nov 2015 20:38:08 +0300

Sure
For those examples (and I would add the sample collection link below) I
think versioning is ok (manageable/acceptable)
But a mechanism for deprecation and furthermore mappings have been useful
in my experience

http://www.frhack.org/research/Information_Security_Vocabularies.xlsx

On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> That makes sense then.  I suppose the question back to the SACM team is
> whether they (we?) want to track enumerations through versioning or
> timestamps with change logs.  Maybe some combination of both, based on the
> expected frequency of change.  It may be worthwhile to identify a few
> places in the expected information model where enumerations are expected to
> play heavily.
>
> Possible examples:
> - Device Functions (routing, switching, file server, web server, database
> server, email server, email client, hypervisor, etc)
> - Software functions (word processing, spreadsheet automation, database
> management, calculator, Jabber Client, email client,  etc.)
> - Logical network location (Direct Internet connected, direct private WAN
> connected, DMZ, protected network connected, etc)
> - Operating System Names (Windows, Android, Apple IOS, Cisco IOS, Linux,
> etc [though we still need to decide if those are "names" or not])
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
>         Is that in addition to versioning?  Seems like the complexity
> would ultimately make maintaining all the historical information and
> business logic difficult to scale, particularly when you try to do
> something smart with respect to reconciling versions vs status of
> enumeration entries.
>
>         Joseph L. Wolfkiel
>         SCM Engineering Lead
>         DISA ID52
>         From: sacm [Caution-mailto:[email-masked] <javascript:;> <
> javascript:; > ] On Behalf Of Jerome Athias
>         Cc: Gunnar Engelbach; Haynes, Dan; [email-masked] <javascript:;> <
> javascript:; >
> Caution-Caution-mailto:[email-masked] <javascript:;> <
>                 If there is actually interest in this topic, we can
> discuss in detail.  One of the reasons I didn't go with a version-based
> implementation is usability.  In general, our name maintenance system is a
> real-time system where users can go in, update a hierarchy with new
> locations, organizations, or system names, then immediately download the
> updated list.  As you can imagine, if multiple users are doing this over
> the course of a day, then trying to track versions becomes onerous to
> maintain and understand.  In the system we're using, the downloaded
> hierarchy contains a timestamp of when it was downloaded.  Since all
> changes (additions, modifications, deletions) are included and timestamped,
> you can walk back through time by just selecting the modifications that
> happened before the time you're concerned with.  This is implemented as an
> alternative to versioning.  The timestamp approach also allows consumers to
> do incremental downloads where they only receive changes since the last
> time a download was made instead of having to download an entire version of
> each enumeration/taxonomy.
>
>                 Joseph L. Wolfkiel
>                 SCM Engineering Lead
>                 DISA ID52
>                 [email-masked] <javascript:;> <
> javascript:; >  < javascript:; >
>
>
>
>                 From: Jerome Athias [Caution-Caution-mailto:
> [email-masked] <javascript:;> < javascript:; >  < javascript:; > ]
> [email-masked] <javascript:;> < javascript:; >  < javascript:; >
>                 Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 -
> Selecting an Information Model Representation
>
>
>                 Vocabulary's enumeration could be deprecated (better than
> just deleting one item, and in case you don't want to increase the version)
>
>                 Vocabularies have a mapping (when needed) allowing
> switching or direct retrieval of equivalents (v1/v2 or org1/org2, etc.)
>
>
>
> javascript:; >  < Caution-Caution-Caution-mailto:
>                         An enumeration, then, becomes another type of
> content.  It needs an authoritative source, plus the abilities to create
> notifications when it changes and be distributed to all points of usage.
>
>
>                         --gun
>
>
>                                 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. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA
> Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571)
> javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:; > '); > -----Original Message-----From: sacm
> javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; >  < javascript:; >
> '); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24, 2015 10:12
> AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] <javascript:;> <
> javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; >  < javascript:; > '); >
> CIV DISA ID (US)[Caution-Caution-Caution-Caution-mailto:
> javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-mailto:
> javascript:; > '); > ] Sent: Friday, November 20, 2015 8:53 AMTo: Haynes,
> Dan <[email-masked] <javascript:;> < javascript:; >  < javascript:; >
> > < javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;> <
> javascript:; >  < javascript:; > '); > ; [email-masked] <javascript:;> <
> javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; >  < javascript:; > '); >
> Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an
> InformationModel Representation+1 here for something like option 1.  I
> personally like using XML schema todocument this type of thing in a
> machine-readable manner.  JSON schema andUML class diagrams should also be
> considered.  For this particular example, I suggest that enumerations be
> maintainedseparately 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 arepersistent.  For example, a hardware Network Interface *card* is
> persistentand discoverable.  However, a virtual network interface card (for
> example, anetwork interface generated by a VPN client) may come and go, so
> the modelshould be able to identify both, along with any metadata required
> to notethat a given component existed for a given time period.Also, a
> "network interface" could be understood to describe a logicalconnection to
> a specific network and would address issues like IP/MACaddresses, network
> javascript:; >  < javascript:_e(%7B%7D,'cvml','
> [email-masked] <javascript:;> < javascript:; >  <
> javascript:; > '); > -----Original Message-----From: sacm
> [Caution-Caution-Caution-Caution-mailto:[email-masked]
> <javascript:;> < javascript:; >  < javascript:; >  <
> javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-mailto:
> [email-masked] <javascript:;> < javascript:; >  < javascript:; >
> '); > ] On Behalf Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo:
> [email-masked] <javascript:;> < javascript:; >  < javascript:; >  <
> >  < javascript:; > '); > Subject: [Non-DoD Source] [sacm] IM Issue #27 -
> Selecting an InformationModel RepresentationHi Everyone,During the
> Information Model Update [1] at the IETF 94 Meeting, we discussedvarious
> modeling syntax options for our Information Model elements.
> Thiscorresponds to IM issue #27 [2].  Sorry for the long email, but, I
> wanted toinclude all the options so the group could review them.
> 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 nota network interface is a hardware component, software
> Caution-Caution-Caution-Caution-Caution-
> https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  > <
> Caution-Caution-Caution-Caution-Caution-
> > [2]Caution-Caution-Caution-Caution-Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
> >  > 7 <Caution-Caution-Caution-Caution-Caution-
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >
> >  > 7 > [3] Caution-Caution-Caution-Caution-Caution-
> >  >  > < Caution-Caution-Caution-Caution-Caution-
> >  >  >  >[4] Caution-Caution-Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >  >  < Caution-Caution-Caution-
> <Caution-Caution-Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >  >  < Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc7326/ >  >  >  >
> [5]Caution-Caution-Caution-Caution-Caution-
> >  >  >  <Caution-Caution-Caution-Caution-Caution-
> >  >  >  > [6] Caution-Caution-Caution-Caution-Caution-
> http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  <
> Caution-Caution-http://www.uml-diagrams.org/ < Caution-
> http://www.uml-diagrams.org/ >  >  < Caution-Caution-Caution-
> http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  <
> Caution-Caution-http://www.uml-diagrams.org/ < Caution-
> http://www.uml-diagrams.org/ >  >  >
> <Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ <
> Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-
> < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-
> >  > [7] Caution-Caution-Caution-Caution-Caution-
> https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  > <
> Caution-Caution-Caution-Caution-Caution-
> > [8] Caution-Caution-Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >  >  < Caution-Caution-Caution-
> <Caution-Caution-Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >  >  < Caution-Caution-Caution-
> https://datatracker.ietf.org/doc/rfc6880/ >  >  >  >
>
>
>
>
> [email-masked] <javascript:;> < javascript:; >  < javascript:; >  <
> >  < javascript:; > '); > Caution-Caution-Caution-
> https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-
> https://www.ietf.org/mailman/listinfo/sacm >  >  <
> Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm <
> https://www.ietf.org/mailman/listinfo/sacm >  >  >
>
>
>
>
>
>
>