Subject: [sacm] Endpoint ID Design Team Notes: 2015-05-15

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 15 May 2015 11:46:30 -0500

Agenda
Continuation - ID Characteristics/Properties
Next Steps

Agenda Bashing
How do we take the work and document it in the information model
Review “Other things to consider” that we’ve been hanging on to

Materials (including recordings) are available here
https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0 <https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0>

Notes
Asking about the “Other things to consider”.  The notion of provenance is particularly interesting because we’ve talked about it at various times and we’ve looked at it several times.  The consensus within this team appears to be that we need to allow for provenance in the information model and the data models.  The provenance of an attribute would be, perhaps, emitted by the endpoint itself and not necessarily externally verified (though it could be verified as such).  It was also noted that the notion of provenance could be proxied under certain circumstances.

Of the list of “Other things to consider” we are going to account for provenance, consider recommendations for additional work.  The rest will fall out naturally.

Moving on to how we take the work we’ve done and document it in the information model.  There seems to be some concern about how to characterize the attribute properties pertaining to making automated judgements about identification suitability.  We should have something like “if a device has attribute X, then it must be available”.  This would give us an ability to enumerate certain attributes in a controlled vocabulary / registry.  We expect this to be a short list of the most useful attributes across the most relevant scenarios.

The notion of profiles has been mentioned.  There could, for example, a “SACM profile for IP networks”.  This is approaching the controlled vocabulary / registration perspective and could be viable.   The importance here is that we need to be careful when we say “MUST” pertaining to an attribute because in some environments that thing may simply be unavailable, and therefore can’t be used.

There are a lot of network topology methods that we might eventually need to support, so it seems even more important to be able to talk about the properties of the attributes and register those interpretations in some widely available location.

Do we have a summary of what we’ve agreed on?  A non-draft document that summarizes the results of these conversations.   

We’re likely to need conceptual reorganization in the Information Model.  For example, perhaps we need to have an “endpoint identity” section, then reference that section elsewhere in the document.   We are going to need to update/add information on provenance, catalog, assertion model, exposition on the attributes we’ve been working on.  Tie back to the use cases/scenarios.  

We need someone to look at this deck and identify where it needs to be worked on/updated.  Who can do this over the course of the next week or perhaps two weeks?  Cliff is signing up to flesh out an outline about how we can organize the material.