Subject: [sacm] Endpoint ID Design Team Notes: 2015-10-23

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 23 Oct 2015 17:33:19 +0000

Hi Everyone,

Here are the notes from today's Endpoint ID Design Team Meeting (EID-DT).

Attendees

*         Ron Colvin

*         Josh Stevens

*         Joe Wolfkiel

*         Danny Haynes

Note Well

Agenda

*         Task descriptions

*         Open issues from the last virtual interim meeting

*         Next steps

Materials

*         Slides from meeting (see attached)

*         Task descriptions (see attached).

Notes

*         First, the task descriptions document was discussed.  All the discussion and feedback around this was captured in Word comments in the document.  An updated version based on feedback and discussion, will be sent out prior to the next EID-DT meeting.

*         A question was asked about where we were at with the Architecture document.  It was explained that we have made a lot of good progress recently during the two calls after the virtual interim meeting and that notes for those meetings were captured in the GitHub issue trackers that were discussed.  It was also noted that if anyone had feedback on the Architecture that they should send it out to the group sooner rather than later.

*         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.

Action Items

*         Update tasks descriptions before next EID-DT meeting (Danny Haynes)

*         Contribute NetD data model  (Joe Wolfkiel).

Please let me know if I missed anything, got anything wrong, or if you have any questions.

Thanks,

Danny

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 23 Oct 2015 14:22:18 -0400

Defining an algorithm would help with consistency in correlation 
outcomes between implementers.  However, it would need to be 
acknowledged that such an algorithm could not be expected to cover all 
scenarios, and that in some cases that consistency could just mean it 
was consistently incorrect.

As part of a standard, I'd like to see such an algorithm and have it 
cover as much variance as possible -- the whole endpoint identification 
thing does not have much worth as a standard if results are 
inconsistent/unpredictable across implementers.  At the same time 
implementers are going to be much quicker to respond to errors and 
changing technologies than a standards body and they need to be free to 
do so.

So I think this creates two needs:

1) The algorithm should not attempt to cover all variations, just as 
many as we have a high confidence in being able to define
2) The ability to utilize the algorithm should be available on request, 
but not required to always be used.  For example, when a consumer is 
making a request from a provider, that request should have the ability 
to specify that correlation must be done using the standard algorithm.

--gun

On 10/23/2015 1:33 PM, Haynes, Dan wrote:
>
> Hi Everyone,
>
>
> Here are the notes from today’s Endpoint ID Design Team Meeting (EID-DT).
>
> *Attendees*
>
> ·Ron Colvin
>
> ·Josh Stevens
>
> ·Joe Wolfkiel
>
> ·Danny Haynes
>
> *Note Well*
>
> **
>
> *Agenda*
>
> ·Task descriptions
>
> ·Open issues from the last virtual interim meeting
>
> ·Next steps
>
> *Materials *
>
> ·Slides from meeting (see attached)
>
> ·Task descriptions (see attached).
>
> *Notes*
>
> ·First, the task descriptions document was discussed.  All the 
> discussion and feedback around this was captured in Word comments in 
> the document.  An updated version based on feedback and discussion, 
> will be sent out prior to the next EID-DT meeting.
>
> ·A question was asked about where we were at with the Architecture 
> document.  It was explained that we have made a lot of good progress 
> recently during the two calls after the virtual interim meeting and 
> that notes for those meetings were captured in the GitHub issue 
> trackers that were discussed.  It was also noted that if anyone had 
> feedback on the Architecture that they should send it out to the group 
> sooner rather than later.
>
> ·There was also a question about the SACM Charter.  Specifically, in 
> addition to specifying the different data fields associated with 
> identifying endpoints, are their plans to standardize any business 
> logic around them.  For example, an algorithm for matching devices 
> using the data collected by two different sensors.  If the data 
> collected by two sensors, using the algorithm, match then the data 
> could be combined as it all represents the same endpoint.  It was 
> noted that this is a real problem that they are facing in the field 
> and that it might be good to have an industry standard around it.  
> Another example, is around defining populations such as “these are all 
> the devices owned by an organization”, or “these are all the devices 
> in a single location”.  There is also a question around how accurate 
> can it be (state, city, building, closet, etc.).  A last example is 
> making statements such as this applies to all servers running Windows 
> 2012, containing sensitive information, and running these databases.  
> It was noted that there are no explicit plans to create matching 
> algorithms, etc. as of yet, but, that you could seem the matching 
> possibly being part of a query language for interfacing with a 
> repository or the information about the location of an endpoint or the 
> sensitivity of the data on an endpoint being covered under the 
> manually assigned data associated with an endpoint. This is something 
> the broader group may want to discuss further.
>
> *Action Items*
>
> ·Update tasks descriptions before next EID-DT meeting (Danny Haynes)**
>
> ·Contribute NetD data model  (Joe Wolfkiel).**
>
> **
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Mon, 26 Oct 2015 06:59:13 -0500

> On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> Defining an algorithm would help with consistency in correlation outcomes between implementers.  However, it would need to be acknowledged that such an algorithm could not be expected to cover all scenarios, and that in some cases that consistency could just mean it was consistently incorrect.
> 
> As part of a standard, I'd like to see such an algorithm and have it cover as much variance as possible -- the whole endpoint identification thing does not have much worth as a standard if results are inconsistent/unpredictable across implementers.  At the same time implementers are going to be much quicker to respond to errors and changing technologies than a standards body and they need to be free to do so.
> 
> 1) The algorithm should not attempt to cover all variations, just as many as we have a high confidence in being able to define
> 2) The ability to utilize the algorithm should be available on request, but not required to always be used.  For example, when a consumer is making a request from a provider, that request should have the ability to specify that correlation must be done using the standard algorithm.

These seem reasonable.  We should consider algorithm agility as another need.

>> ·         Ron Colvin
>> ·         Josh Stevens
>> ·         Joe Wolfkiel
>> ·         Danny Haynes
>> ·         Task descriptions
>> ·         Open issues from the last virtual interim meeting
>> ·         Next steps
>> 
>> Materials
>> ·         Slides from meeting (see attached)
>> ·         Task descriptions (see attached).
>> 
>> Notes
>> ·         First, the task descriptions document was discussed.  All the discussion and feedback around this was captured in Word comments in the document.  An updated version based on feedback and discussion, will be sent out prior to the next EID-DT meeting.
>> 
>> ·         A question was asked about where we were at with the Architecture document.  It was explained that we have made a lot of good progress recently during the two calls after the virtual interim meeting and that notes for those meetings were captured in the GitHub issue trackers that were discussed.  It was also noted that if anyone had feedback on the Architecture that they should send it out to the group sooner rather than later.
>> 
>> ·         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as “these are all the devices owned by an organization”, or “these are all the devices in a single location”.  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.
>> 
>> Action Items
>> ·         Update tasks descriptions before next EID-DT meeting (Danny Haynes)
>> ·         Contribute NetD data model  (Joe Wolfkiel).
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>