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

[Chris Inacio <[e-mail]>]

I believe the general solution is to be able to create an IANA registry with the information elements (IE).  The faster method of updating the registry is to create the registry with "expert review.”  That would mean a few folks designated by the working group review requests for modifications and approve them on to IANA.

I have an issue with deletions though.  If you delete data elements, doesn’t that mean you potentially have data in your collection system that you can no longer make sense of?

Secondly, if the churn is really multiple times a day, then I think we would want a hybrid system:  
* something such as an IANA registry to define IE’s that ensure interoperable exchange between systems, and a type system of some sort that allows a privately defined element to be described in an understandable way if/when it has to be exchanged; these would require review and approval to be standardized.
* coming up with some basic “classes" (counter, delta, range, address, index, …) and some basic types (bool, int32, int64, uint32, uint64, octet string, …) (and possibly allow Henk’s inheritance mechanism “is_a” for inheritance) along with a human description for UI, would allow data interchange.  Hopefully, there would be enough generic information contained in those two metadata fields (maybe a couple more) that would allow an implementor to store the data (using the proper data type in storage) and then filter/search on the data using proper logic.  That would allow the system to understand that a “bitwise and" of a counter and an address has no meaning.  (Some bit of a typed lambda calculus - which some brave sole may which to expand if she would want to create interoperable expressions of search and filter across the collected data.)


--
Chris Inacio
[e-mail]



> On Nov 24, 2015, at 10:47 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[e-mail]> wrote:
> 
> If stability is the goal, then I think a lot of the enumerations in the device characterization area will need to be converted to arbitrary strings.  We use enumerations like organization, location, system accreditation boundary, NIST security control ID, operating system, and others that changes frequently (sometimes daily) to characterize devices on the network, so depending on any given enumeration to be "stable" over a period of years is probably not realistic for our internal use cases.  Instead of trying to force changes out of the environment, I've tried to make the environment as responsive to change as possible.
> 
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Fort Meade DISA Acquisiton Bldg Cube A4A58E
> Work: [phone]
> Gov Cell: [phone]
> [e-mail]
> 
> 
> 
> -----Original Message-----
> From: Ira McDonald [mailto:[e-mail]] 
> Sent: Tuesday, November 24, 2015 10:33 AM
> To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald
> Cc: Haynes, Dan; [e-mail]
> Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation
> 
> All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 
> 
> 
> ________________________________
> 
> 
> 
> Hi Dan and Joseph,
> 
> 
> Thanks for your note Joseph about enumerations.  
> 
> To deal with this problem, the IEEE-ISTO Printer Working Group has 
> moved entirely to use of the keyword datatype (instead of enumeration) 
> for selection data elements in our Internet Printing Protocol abstract 
> model extensions (the keywords are registered with IANA) .
> 
> 
> In some other *data model* mappings these have been converted to 
> enums (or enum / keyword union types) but those data models have 
> stable, named and dated versions and few interoperability problems.
> 
> 
> Cheers,
> 
> - Ira
> 
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> Caution-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: [e-mail] < Caution-mailto:[e-mail] > 
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> On Tue, Nov 24, 2015 at 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[e-mail] < Caution-mailto:[e-mail] > > wrote:
> 
> 
> 	For the DoD, I've implemented an enumeration maintenance system, a standard XML schema, and a restful web service for maintaining enumerations.  Something similar may work for SACM.  Enumeration maintenance ends up being a special challenge in and of itself since enumerations can be flat lists, hierarchies, or have the ability to support multiple hierarchies.  Enumeration items can be added, deleted, modified, and merged over time, so different users of the enumerations may be using different lists based on when they were last updated.
> 	
> 	I doubt SACM considers enumeration management to be within its charter as a generalized solution, but full interoperability will probably involve the ability to maintain and evolve some set of enumerations over time.
> 	
> 	Joseph L. Wolfkiel
> 	SCM Engineering Lead
> 	DISA ID52
> 	Fort Meade DISA Acquisiton Bldg Cube A4A58E
> 	Work: [phone] < tel:%28301%29%20225-8820 > 
> 	Gov Cell: [phone] < tel:%28571%29%20814-8231 > 
> 	[e-mail] < Caution-mailto:[e-mail] > 
> 	
> 	
> 	
> 	-----Original Message-----
> 	From: sacm [Caution-mailto:[e-mail] < Caution-mailto:[e-mail] > ] On Behalf Of Haynes, Dan
> 	Sent: Tuesday, November 24, 2015 10:12 AM
> 	To: Wolfkiel, Joseph L CIV DISA ID (US); [e-mail] < Caution-mailto:[e-mail] > 
> 	Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model Representation
> 	
> 	All active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
> 	
> 	
> 	
> 	
> 	----
> 	
> 	Thanks for the feedback Joe.
> 	
> 	Once we have a way to represent the information that we care about in our
> 	IM, implementers are free to use XML, JSON, or maybe something else to
> 	document/implement the IM via the creation of data model.  I think it would
> 	also be acceptable for them to generate UML diagrams if they would like.
> 	
> 	Yeah, the point about enumerations is a good one given the may change more
> 	frequently.  Does anyone have any thoughts on how to best handle what would
> 	be enumerations in the Information Model?  Would it be best to document the
> 	enumerations in separate document that would change over time and the IM
> 	could just reference out to it?
> 	
> 	Agree, I am going to add a track that points to this thread and the previous
> 	thread regarding whether or not a network interface is hardware, software,
> 	or something else.  That way we can refer back to the relevant discussions
> 	when it comes time to design it in the IM.
> 	
> 	Thanks,
> 	
> 	Danny
> 	
> 	-----Original Message-----
> 	From: Wolfkiel, Joseph L CIV DISA ID (US)
> 	
> 	[Caution-Caution-mailto:[e-mail] < Caution-mailto:[e-mail] > ]
> 	Sent: Friday, November 20, 2015 8:53 AM
> 	To: Haynes, Dan <[e-mail] < Caution-mailto:[e-mail] > >; [e-mail] < Caution-mailto:[e-mail] > 
> 	Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
> 	Model Representation
> 	
> 	+1 here for something like option 1.  I personally like using XML schema to
> 	document this type of thing in a machine-readable manner.  JSON schema and
> 	UML class diagrams should also be considered.
> 	
> 	For this particular example, I suggest that enumerations be maintained
> 	separately from the data model since they are subject to change over time.
> 	
> 	This specific example also highlights an issue that merits consideration.
> 	There are aspects of endpoints that are ephemeral and some that are
> 	persistent.  For example, a hardware Network Interface *card* is persistent
> 	and discoverable.  However, a virtual network interface card (for example, a
> 	network interface generated by a VPN client) may come and go, so the model
> 	should be able to identify both, along with any metadata required to note
> 	that a given component existed for a given time period.
> 	
> 	Also, a "network interface" could be understood to describe a logical
> 	connection to a specific network and would address issues like IP/MAC
> 	addresses, network name, default gateway, DNS Name, initial connection time,
> 	address "lease", and other issues.  It's good that the data model helps to
> 	understand that saying "network interface" doesn't actually mean the same
> 	thing to everyone talking about it.
> 	
> 	Joseph L. Wolfkiel
> 	SCM Engineering Lead
> 	DISA ID52
> 	Fort Meade DISA Acquisiton Bldg Cube A4A58E
> 	Work: [phone] < tel:%28301%29%20225-8820 > 
> 	Gov Cell: [phone] < tel:%28571%29%20814-8231 > 
> 	[e-mail] < Caution-mailto:[e-mail] > 
> 	
> 	
> 	
> 	-----Original Message-----
> 	
> 	From: sacm [Caution-Caution-mailto:[e-mail] < Caution-mailto:[e-mail] > ] On Behalf Of Haynes, Dan
> 	Sent: Friday, November 20, 2015 6:57 AM
> 	To: [e-mail] < Caution-mailto:[e-mail] > 
> 	Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an Information
> 	Model Representation
> 	
> 	Hi Everyone,
> 	
> 	
> 	During the Information Model Update [1] at the IETF 94 Meeting, we discussed
> 	various modeling syntax options for our Information Model elements.  This
> 	corresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted to
> 	include all the options so the group could review them.
> 	
> 	
> 	
> 	Specifically, we discussed the following options which provided on the list.
> 	Please note that I used the example below because it was very convenient :).
> 	It does not represent any agreed upon model for a network interface.
> 	Furthermore, it does not mean a decision has been made around whether or not
> 	a network interface is a hardware component, software component, both, or
> 	something else.  That decision is currently being worked out on the list
> 	[3].
> 	
> 	
> 	
> 	----------
> 	
> 	
> 	
> 	OPTION 1 (RFC 7326 - Energy Management Framework [4]):
> 	
> 	
> 	
> 	    CLASS NetworkInterface EXTENDS HardwareComponent {
> 	
> 	        name            : string
> 	
> 	        index           : int
> 	
> 	        hardwareAddress : MACAddress
> 	
> 	        type            : enum {ether, fddi, loopback, .}
> 	
> 	        flags [0..n]    : enum {up, broadcast, debug, .}
> 	
> 	    }
> 	
> 	
> 	
> 	    Network Interface (Class):
> 	
> 	         name               string        The name of the interface.
> 	
> 	         index              int           The index of the interface.
> 	
> 	         hardwareAddress    MACAddress    The IEEE 802 MAC address.
> 	
> 	         type               Enumeration   Describes the type of the network
> 	interface.
> 	
> 	         flags [0..n]       Enumeration   Describes the flags set on the
> 	interface.
> 	
> 	
> 	
> 	----------
> 	
> 	
> 	
> 	OPTION 2 (Information Model for Large-Scale Measurement Platforms [5]):
> 	
> 	
> 	
> 	    Definition of network-interface-obj
> 	
> 	
> 	
> 	    object {
> 	
> 	        string name;
> 	
> 	        int index;
> 	
> 	        mac-address-obj hardware-address;
> 	
> 	        string type;
> 	
> 	        string flags<0..n>;
> 	
> 	    } network-interface-obj;
> 	
> 	
> 	
> 	    A network-interface-object consists of the following elements:
> 	
> 	
> 	
> 	    name:               The name of the interface.
> 	
> 	    index:              The index of the interface.
> 	
> 	    hardwareAddress:    The IEEE 802 MAC address.
> 	
> 	    type:               Describes the type of the network interface. The
> 	value 'ether' indicates.
> 	
> 	    flags:              Describes the flags set on the interface. The value
> 	'up' indicates.
> 	
> 	
> 	
> 	----------
> 	
> 	
> 	
> 	OPTION 3 (Unified Modeling Language [6]):
> 	
> 	
> 	
> 	    +-------------------+
> 	
> 	    | HardwareComponent |
> 	
> 	    +-------------------+
> 	
> 	    | .                 |
> 	
> 	    +-------------------+
> 	
> 	             ^
> 	
> 	             |
> 	
> 	    +---------------------+
> 	
> 	    | NetworkInterface    |
> 	
> 	    +---------------------+
> 	
> 	    | string name         |
> 	
> 	    | int    index        |
> 	
> 	    | enum   type         |
> 	
> 	    | enum   flags [0..n] |<>----[ MACAddress ]
> 	
> 	    +---------------------+
> 	
> 	
> 	
> 	    The aggregate class that constitutes a NetworkInterface is:
> 	
> 	         MACAddress
> 	
> 	             One. The IEEE 802 MAC address.
> 	
> 	
> 	
> 	    The Network Interface class has four attributes:
> 	
> 	         name
> 	
> 	             Required. String. The name of the interface.
> 	
> 	         index
> 	
> 	             Required. Int. The index of the interface.
> 	
> 	         type
> 	
> 	             Required. Enum. Describes the type of network interface.
> 	
> 	         flags
> 	
> 	             Optional. 0..n. Describes the flags set on the interface.
> 	
> 	
> 	
> 	----------
> 	
> 	
> 	
> 	OPTION 4 (Entity-Relationship Diagram [7]):
> 	
> 	
> 	
> 	    +-------------------+
> 	
> 	    | HardwareComponent |
> 	
> 	    +-------------------+
> 	
> 	             |
> 	
> 	         < IS-A >
> 	
> 	             |
> 	
> 	    +------------------+
> 	
> 	    | NetworkInterface |--------
> 	
> 	    +------------------+       |
> 	
> 	             |----( name )     |
> 	
> 	             |----( index )    |
> 	
> 	             |----( type )     |
> 	
> 	             |----(( flags ))  |
> 	
> 	                               |
> 	
> 	         +------------+        |
> 	
> 	        | MACAddress |----< HAS-A >
> 	
> 	        +------------+
> 	
> 	
> 	
> 	    The NetworkInterface entity IS-A HardwareComponent and HAS-A MACAddress.
> 	
> 	
> 	
> 	    It has four attributes:
> 	
> 	
> 	
> 	    name
> 	
> 	        Required. String. The name of the interface.
> 	
> 	    index
> 	
> 	        Required. Int. The index of the interface.
> 	
> 	    type
> 	
> 	        Required. Enum. Describes the type of network interface.
> 	
> 	    flags
> 	
> 	        Optional. 0..n. Describes the flags set on the interface.
> 	
> 	
> 	
> 	----------
> 	
> 	
> 	
> 	Lastly, during the meeting the Kerberos information model was suggested as
> 	another option so that has been added to the list.
> 	
> 	
> 	
> 	----------
> 	
> 	OPTION 5 (RFC 6880 - An Information Model for Kerberos Version 5 [8]):
> 	
> 	
> 	
> 	    1.1 NetworkInterface
> 	
> 	            The NetworkInterface represents an network interface card...The
> 	NetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in an
> 	implementation.
> 	
> 	
> 	
> 	    1.1.1 NetworkInterface : Attributes
> 	
> 	
> 	
> 	    1.1.1.1 name
> 	
> 	        The name of the network interface card. It MUST be provided...
> 	
> 	
> 	
> 	    1.1.1.2 index
> 	
> 	        The index of the interface.  It MUST be provided...
> 	
> 	
> 	
> 	    1.1.1.2 type
> 	
> 	        The type of the interface.  It MUST be provided...
> 	
> 	
> 	
> 	    1.1.1.2 flags
> 	
> 	        The flags set on the interface.  It MAY be provided...
> 	
> 	
> 	
> 	    1.1.2 NetworkInterface : Associations
> 	
> 	        Each NetworkInterface MUST be associated with a single MACAddress.
> 	The MACAddress is represented in this model below...
> 	
> 	
> 	
> 	----------
> 	
> 	
> 	
> 	During the meeting, there seemed to be consensus around OPTION 1.  There was
> 	also a suggestion by Jim Schaad that we will want to use a syntax that can
> 	be checked in some automated fashion.  It would be great to learn more about
> 	that.
> 	
> 	
> 	
> 	Anyways, please let me know, by  December 1st, what option you prefer so
> 	that we can reach a decision on how to represent our Information Model.
> 	
> 	
> 	
> 	Please let me know if you have any questions.
> 	
> 	
> 	
> 	Thanks,
> 	
> 	Danny
> 	
> 	
> 	
> 	
> 	[1] Caution-Caution-Caution-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
> 	[e-mail] < Caution-mailto:[e-mail] > 
> 	Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm > 
> 	
> 	
> 
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm