Subject: Re: [sacm] [draft-ietf-sacm-requirements] Matching Algorithms (#73)

From: adammontville <[email-masked]>
Date: Tue, 19 Jan 2016 13:40:21 -0800

I'm not confident that there's consensus in either direction with respect to matching algorithms.  If it doesn't need to be mentioned in this document, then where does treatment of the subject belong?  Correctly matching endpoints between disparate implementations seems critical to the success of this effort.  

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-172995938

---

From: Nancy <[email-masked]>
Date: Wed, 20 Jan 2016 11:30:37 -0800

I can potentially see the need for SACM to "name" the data models.....and agree with Jim that SACM needs to have a good IM (and DM) so that the SACM components can discern on the information afforded (by the DM).  That said, I still do not see how "algorithm" comes into play....but rather SACM has a well understood information model from which SACM components can extract what they are looking for.  Where I see the "naming" of DM's comes from the group understanding that there may be different DM's in use (but they all have to map to the IM if they are to be SACM compliant)......we have requirements to allow for discovery of this, which I guess implies we are labeling the DMs.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-173333717

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Jan 2016 15:13:04 -0800

So IM-004 says that DMs have to be identifiable.  That should address that need.

Adam,  I am unsure of what the problem is you are describing.is.  Are you saying that Vendor A and Vendor B are going to assign different asset identifier to the same asset and that without some type of help it will be impossible to know that they are the same assets?  

I have much larger worries that this, are they using the same DMs and is there a converter between the two models in the system.  Based on what I expect to see, it should be easy to enumerate all of the ids assigned by Vendor A and all of them assigned by Vendor B.  The trick is then to try and figure out if the assets ids refer to the same item.  This will depend on the traits of the two assets.  If the vendors do not populate their view of the asset with enough data for the matching to work, then you are going to be out of luck. This is a function of the IM model being sufficiently complete in describing each of the different assets classes and specifying the correct set of minimal items.  This is an IM problem and not a requirements problem.  

If the IM has an asset ID field, and it is filled in differently by the two different vendors then there is a different problem.  The IM, and thus the matching algorithm, would need to make statements about the uniqueness of a value for a specific asset.   But again these are statements about the IM/DM and not the matching algorithm.

Clarifications would be appreciated.  I also do not understand why the TLS reference makes any sense here.  When looking at it I would call this the definition of a field in the IM about a specific attribute.  Again not related to a matching algorithm.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-173395295

---

From: adammontville <[email-masked]>
Date: Thu, 21 Jan 2016 12:37:30 -0800

Maybe I'm not taking in the view from the proper perspective.  Maybe "algorithm" is not the right word either. As you mention, the trick is to figure out whether two distinct identifiers reference the same item - a "same as" relationship.  If conditions for establishing this "same as" relationship must exist solely in the IM, and if these conditions are already known to be required, then my concern is satisfied.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-173700805

---

From: adammontville <[email-masked]>
Date: Wed, 27 Jan 2016 10:05:36 -0800

If all you assign is an internal DB index, then you've got insufficient data to discover a "same as" relationship.  We need to support reasonably deterministic endpoint identity matching, wherever that needs to be articulated.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-175775566

---

From: adammontville <[email-masked]>
Date: Thu, 28 Jan 2016 05:20:02 -0800

No, that's not at all what I'm advocating.  Did you perhaps misread "insufficient" as "sufficient"?

I want to ensure that our requirements don't make it hard for disparate implementations to reconcile endpoint data between each other.  Wherever this sort of thing is best described in our documentation, is fine by me. 

Lisa had suggested that these were aligned with DM requirements and you had disagreed.  This is about where this conversation stands at this point, and I'd like to try and wrap it up so we can move ahed.  As I said before, I think we need to support reasonably deterministic endpoint identity matching.  I think Lisa agreed that this would be critical for SACM.

Further, the points you made in your last comment are those that I believe support the need for us to say as much as possible when it comes to how endpoints can be matched.  You mention all the attributes we can look at and use to _infer_ the match.  What are those relationships? How many valid assertions do we need before we are confident in the match?  Which assertions matter?

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-176183217

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Jan 2016 10:24:45 -0800

Adam,  If there is a requirement here, and I am not convinced that there is, then it would appear to be a requirement on the IM and not the DM.  The requirement would run along the lines of - All of the elements of the SACM standard endpoint matching algorithm MUST be in the IM.  I think that this would be a real problem for the WG if it was not the case and is therefore not needed.

Gunnar,  Does this mean that as a vendor I cannot define additional attributes in my DM which would allow me to produce a better result than the standard SACM matching algorithm?  This would violate the apparent requirement that you have stated for reproducibility.  My vendor specific algorithm would not match the standard SACM algorithm in this case.

Based on what you are saying, there needs to be a milestone for an endpoint matching algorithm draft.  This might be part of the IM document, but it would probably be better starting separately.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-176322218

---

From: GunnarEngelbach <[email-masked]>
Date: Thu, 28 Jan 2016 11:44:51 -0800

Jim,

I think allowance has to be made for both.  A standard algorithm is necessary for interoperability, but implementors need to have the option to use proprietary methods to account for usages not covered by the standard algorithm, because the standard isn't as likely to keep pace with changes, because the standard algorithm might be incorrect in some edge cases, etc.

An alternative would be that attribute-based endpoint matching be an MTI service available as part of a SACM deployment.  Id est, some node in the SACM infrastructure provides a public service of indicating whether or not two sets of endpoint attributes refer to the same endpoint or not.  But that has some serious drawbacks as well.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-176369535