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

["Wolfkiel, Joseph L CIV DISA ID (US)" <[e-mail]>]

That's a hard problem.  It's one we're struggling with currently.  We have a significant set of external "authoritative" sources that maintain lists of names that we need to synchronize with and/or extend with additional child information.  Since the current system wasn't designed to deal with that, we have some customers embedding work-arounds into the name enumerations. For example the Navy is embedding their Unit IDs at the end of the descriptive names for their organizations and our internal users at DISA are embedding the FISMA-reporting system IDs into the accreditation boundary system names they create.  I have a new release of the system in development that offers the ability to synchronize with "authoritative sources" through imports of the names from the external systems, so it can re-expose them through the standard web service.  It's my intent to make the lookup tables available for download as a Rosetta Stone equivalent.  I have had something similar in mind for software names since we have 3 systems deployed now that collect OS, software, and patch names in overlapping populations and return different names for the same software items. 

It becomes even more difficult when there are multiple, potentially conflicting authoritative sources for a given name type and you may be required to mediate back to any of them.  A good example is the ISO country and state codes.  Depending on your preference, they supply 2 and 3-letter abbreviations that are overlapping, yet different representations for geographic enclosed spaces--and that's from the same source.  We have to extend those further to address counties, cities, DoD installations, buildings, etc, but the ISO codes may change over time, so any extensions we build to them will have to have some robust, automatic business logic implemented governing how they will react to additions, deletions, mergers, and display name changes.

The only hope I have for keeping the system reasonably consistent and up to date is that our users depend on it heavily and have the ability to fix incorrect names and name relationships.  Once we get everyone trained and implement the governance through technical controls instead of administrative controls, I'm hoping it will successfully leverage a large user base to be self-correcting, much like Wikipedia.

This does point to a potential problem for interoperability WRT large, dynamic enumerations like organization, location, and system name enumerations that are constantly changing.  I expect SACM will want to push the solution to maintaining and interoperating based on those types of enumerations further down the road, but hopefully in a thoughtful way that positions us for success when they are worked.  I see the near term challenge being with enumerations like the ones I listed below (with the exceptions of organization and location).  Much of what we do in the computer security world depends on characterization of devices that is used for targeting compliance checks, making access control decisions, establishing control requirements, aggregating and organizing data, and other functions.  If we don't have some common set of enumerations maintained and assignable by humans, then we can only commonly manage devices through directly discoverable properties, which is significantly less powerful.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: [phone]
Gov Cell: [phone]
[e-mail]



-----Original Message-----
From: Chris Inacio [mailto:[e-mail]] 
Sent: Tuesday, December 01, 2015 8:11 AM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Jerome Athias; Gunnar Engelbach; Haynes, Dan; [e-mail]
Subject: Re: [sacm] [Non-DoD Source] Re: IM Issue #27 - Selecting an Information Model Representation


You create an interesting thought for me.  Your system is self-consistent – but how does it exchange information with other systems?  (Maybe the answer is:  “it doesn’t, and it will not.)  But for example, your system is US DoD - what if you had to exchange inventory / posture information with US Commerce or with a NATO ally, e.g. Turkey DoD.  How would you know what the definition of operating systems are in “their” management system?

Does the group expect cross enterprise/organizational information / posture exchange?  I assume the US DHS does; since they’ve been driving toward that very goal for quite some time.


personal curiosity:

Can anyone update the “enumeration” of operating systems?  Can any system administrator go into the system and “delete” Windows, for example?


--
Chris Inacio
[e-mail]



> On Nov 30, 2015, at 9:55 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[e-mail]> 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:  
> - 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
> Fort Meade DISA Acquisiton Bldg Cube A4A58E
> Work: [phone]
> Gov Cell: [phone]
> [e-mail]
> 
> 
> 
> -----Original Message-----
> From: sacm [Caution-mailto:[e-mail]] 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; [e-mail]
> Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation
> 
> 
> Your point is valid.
> It's optional in my system.
> 
> 
> 
> On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <[e-mail] < Caution-Caution-mailto:[e-mail] > > 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
> 	Fort Meade DISA Acquisiton Bldg Cube A4A58E
> 	Work: [phone]
> 	Gov Cell: [phone]
> 	[e-mail] < javascript:; > 
> 	
> 	
> 	
> 	-----Original Message-----
> 	From: sacm [Caution-Caution-mailto:[e-mail] < 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; [e-mail] < javascript:; > 
> 	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) <[e-mail] < javascript:; >  < Caution-Caution-Caution-mailto:[e-mail] < 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 sinc!
> e 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: [phone]
> 	        Gov Cell: [phone]
> 	        [e-mail] < javascript:; >  < javascript:; >
> 	
> 	
> 	
> 	        -----Original Message-----
> 	        From: Jerome Athias [Caution-Caution-Caution-mailto:[e-mail] < javascript:; >  < javascript:; > ]
> 	        Sent: Friday, November 27, 2015 10:15 PM
> 	        To: Gunnar Engelbach
> 	        Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [e-mail] < javascript:; >  < javascript:; >
> 	        Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation
> 	
> 	
> 	        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 <[e-mail] < javascript:; >  < javascript:; >  < Caution-Caution-Caution-Caution-mailto:[e-mail] < 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
> 	
> 	
> 	                On 11/24/2015 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) 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. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: [phone]Gov Cell: (571) [e-mail] < javascript:; >  < javascript:; >  < jav!
> ascript:_
> e(%7B%7D,'cvml','[e-mail] < javascript:; >  < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-Caution-mailto:[e-mail] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','[e-mail] < javascript:; >  < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24, 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [e-mail] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','[e-mail] < 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 our!
> IM, 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-Caution-mailto:[e-mail] < javascript:; >  < javascript:; >  <!
>  javascri
> pt:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-Caution-mailto:[e-mail] < javascript:; >  < javascript:; > '); > ] Sent: Friday, November 20, 2015 8:53 AMTo: Haynes, Dan <[e-mail] < javascript:; >  < javascript:; > > < javascript:_e(%7B%7D,'cvml','[e-mail] < javascript:; >  < javascript:; > '); > ; [e-mail] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','[e-mail] < 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: [phone]Gov Cell: (571) [e-mail] < javascript:; >  < ja!
> vascript:
> ; >  < javascript:_e(%7B%7D,'cvml','[e-mail] < javascript:; >  < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-Caution-Caution-mailto:[e-mail] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-Caution-mailto:[e-mail] < javascript:; >  < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo: [e-mail] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','[e-mail] < 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 discu!
> ssed 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 NetworkInterfa!
> ce 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-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-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 >  < 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-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-Ca!
> ution-htt
> ps://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 >  < 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-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 >  < 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 >  >  < Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-!
> informati
> on-model/issues/2 >  < 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-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 >  < 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 >  >  < 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 >  < 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-https://www.ietf.org/mail-ar!
> chive/web
> /sacm/current/msg03199.html < 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-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 >  < 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-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-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://!
> Caution-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-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-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < 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/ >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  >  <Caution-Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rf!
> c7326/ < 
> 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/ >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  >  > [5]Caution-Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-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-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-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-Caution-https://datatracke!
> r.ietf.or
> g/doc/draft-burbridge-lmap-information-model/ >  >  >  <Caution-Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-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-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-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-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  >  > [6] Caution-Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.!
> uml-diagr
> ams.org/ >  >  < Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  >  >  <Caution-Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  < 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/ >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-Caution-http://www.uml-diagrams.org/ >  >  >  > [7] Caution-Caution-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-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!
> .wikipedi
> a.org/wiki/Entity%E2%80%93relationship_model < 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-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  > < Caution-Caution-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-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 >  < 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-Cau!
> tion-Caut
> ion-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < 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/ >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >  <Caution-Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < 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/ >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >  >
> 	
> 	
> 	
> 	                        _______________________________________________sacm mailing [e-mail] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','[e-mail] < javascript:; >  < javascript:; > '); > Caution-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 < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >  >  < Caution-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 < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >  >  >
> 	
> 	
> 	
> 	
> 	
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> Caution-https://www.ietf.org/mailman/listinfo/sacm