Subject: [sacm] Endpoint ID Design Team Meeting Notes: 2015-06-19

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 23 Jun 2015 07:06:36 -0500

Thanks to Cliff for sharing the notes below and to Dave (and others) for running the show.  The following are pretty much raw notes, and the recording will be available at the materials link shortly.

Thanks,

Adam

Materials
	•	https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0 <https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0> 

We discussed Cliff’s email titled “Next draft of Common Identifying Attributes subjection of information model” (https://mailarchive.ietf.org/arch/msg/sacm/aD_dNh2ohNbywQmXSb2iYkNvoIs <https://mailarchive.ietf.org/arch/msg/sacm/aD_dNh2ohNbywQmXSb2iYkNvoIs>)
 
IP Address
 
It does not sound like we should avoid preferred addresses. Rather, the issue seems to be that some address assignments are short-lived.
 
Cliff to find notes of previous discussion on lifetime of address assignments, and incorporate them into the draft.
 
An address can change because a DHCP assignment expires, or because of roaming (for example). Cliff to add that to the draft, as background.
 
Dave: Should scope string be a separate attribute?
 
Dave: More generally, how do we capture relationships among attributes?
 
Cliff: Agree we need relationships among attributes.
 
Henk has suggested triples
 
Dave says, sound like a good idea.
 
Dave: We need some kind of structure – groupings of attributes is another possibility.
 
Cliff: There's a fourth source, interaction.
 
Dave: Interesting.
 
Change "source" to "source of information", for clarity.
 
Dave: With IPv6 stateless auto-configuration, the endpoint is the authority.
But isn't it also the source?
 
Cliff: So are these sources not mutually exclusive?
 
Dave: Yes.
 
About multiplicity, add "can *ordinarily* be used by only one endpoint at a time".
 
Add "immutability/persistence", as background for each attribute.
 
Add "verifiability", as background for each attribute.
 
Add a section on particular relationships/groupings, for example, between an interface an address.
 
Cliff: Should we mandate that the assertion include *all* IP addresses known to the asserter?
 
Shouldn't inclusion be determined by guidance?
 
And if there is no guidance available, do we provide a fallback?
 
Cliff: Let's go easy with the MUSTs.
 
We can remove Conditions of Inclusion. Instead, have a statement at the top of the section that says guidance will govern.
 
Hardware Serial Number
 
This is assigned by the manufacturer.
 
Make the vendor ID a SHOULD. Make it a string.
 
Accept that collisions between vendors are possible.
 
Source could be an authority: an inventory database. Let's not preclude that.
 
Almost any attribute could come from a data store.
 
Cliff to move the enumeration of sources to the top of the section, so that it is applicable to all attributes.
 
What serial number(s) do we want?
The serial number of the endpoint, as assigned by the manufacturer?
The serial number of the motherboard?
VMID
 
Although inclusion will be determined by guidance, the I-D needs to mandate certain ones that a collector MUST be able to collect.
 
In addition, we probably want a minimum set of attributes that you always provide if you can. This is implicit guidance.
 
Let's tee up identification of virtual machines as a future topic.
 
Info model draft is due July 6

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 24 Jun 2015 07:05:19 -0500

I heard from Dave these additional pieces of information regarding the last ID design team meeting.

Actions:
 
1)      Cliff will update his attribute section based on the discussion last Friday. We will review these changes on 9/26.
2)      Danny agreed to write some text around attribute collections to address groups of related attributes.
3)      Dave agreed to setup a short call to arrange access to GitHub. Required attendees Cliff, Dave, and Adam. Anyone else welcome. If time allows, it would also be good to discuss any structural changes in the IM draft outline.
 
We also agreed that we want to make a goal each week to capture any conversations in the information model between meetings.

> On Jun 23, 2015, at 7:06 AM, Adam W. Montville <[email-masked]> wrote:
>