Subject: [sacm] Info Model and Arch Draft

From: Chris Inacio <[email-masked]>
Date: Fri, 6 Nov 2015 22:45:41 +0000

Hello all,

I wanted to continue the discussion from Henk’s and Nancy’s presentation.  I think it might also capture a little bit about what Kathleen is struggling with in regards to our progress adopting implementations.

Part 1
=====

Right now we have a lot of data models that we’ve been discussing, but we haven’t really been discussing the information model.  We have an information model draft but it isn’t a focus.  Additionally, it doesn’t appear to me that the current information model draft aligns with the architecture at all.

I would like to see a simple information model build up that captures some of the basic elements needed in order to conform with the architecture draft.  The NON-COMPREHENSIVE starting point being something like:

* source provider - most recent point sending this information ( system defined UUID )
* source common name - optional, human readable name
* source date/time stamp
* source domain
* source HMAC
* origin provider - the original observation system ( system defined UUID )
* origin common name - optional, human readable
* origin date/time stamp
* origin domain
* origin HMAC

source HMAC would always wrap origin everything.

(And I’m completely not wed to ANY names, either)

The we also need to support operations that are defined in the architecture:

* transport capabilities - tuples of supported transports {{HTTP/REST, TCP, 8901}, {XMPP, TCP, 3456}}
	- topic subscribe list - {}
	- topic publish list - {}
	- data model(s) (?) - for supporting multiple data models; I think there are industry use cases for this, where interoperability for already deployed tech to participate

At what level(s) are we going to establish trust?  Transport layer?  Data payload layer - I think Leif made a compelling argument that a trust encapsulation at the data layer is needed.  

How will those trust relationships be established?  I think that very much speaks to enrollment, and how unresolved that is.  

Is the enrollment of a provider into the controller transport specific?  I think it likely is.  And since I don’t want to build yet another trust model / mechanism, I really want to leverage the trust system an enterprise already has - what is the model that allows existing enterprise mechanisms (e.g. LDAP+Kerberos) to be used.

Part 2
=====

There appears to be consensus that there would be a mandatory to implement data model.  I believe that we agreed that data model would be extensible (IANA  registry of elements?).  We’ve been looking at a large number of data models trying to understand their fitness of purpose.

Henk proposed a very simple mechanism:
	has_a
	is_a

And then you define some basic abstract types (presumably another type system - leverage the basic YANG or IPFIX model and extend?)  Then you can create anything you want in the future with is_a?  I’m guessing this is what Henk implied with the “is_a”.  Henk??  
I believe the spectrum of implementation for “is_a” is pretty wide.  You can simply tell me its type structure, a la IPFIX, “IP address type, 4-octets”, “range, 2-octets”, “counter, 8-octects” - but I think Henk wants to go a step further, more like the class model, “address, 10-octets, is_a L2 address class”.

Would the classes also be extensible?  Would that be a registry?

I’m still not sure I like the “is_a” mechanism.

Part 3
=====

We have XMPP-Grid that we can move forward with.  Do we want to consider other protocols and mappings?  How do we intend to resolve some detailed issues within the architecture (which may not be architecture draft changes) but would like enlighten the conversation on things like enrollment into the system.

It would make it easier to resolve the remaining pieces of work in the architecture draft, right?

--
Chris Inacio
[email-masked]

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 13 Nov 2015 16:32:32 -0600

> * origin common name - optional, human readable

These feel more like architectural issues than information model issues
(most of them anyway).  Maybe you could take a look at the information
model Danny has in GitHub and tie this information into that?

> 	- data model(s) (?) - for supporting multiple data models; I think there are industry use cases for this, where interoperability for already deployed tech to participate

This is good.  We are probably eventually going to need to construct in
the information model some specifics about how to talk about the SACM
ecosystem, which might be what you're getting at.

> Is the enrollment of a provider into the controller transport specific?  I think it likely is.  And since I don’t want to build yet another trust model / mechanism, I really want to leverage the tr…
These all seem like good points/questions for both architecture and
information model.  I encourage you to tie these specifically to one or
both of those drafts.

> I’m still not sure I like the “is_a” mechanism.

I think more discussion is needed here.  There's promise in the
approach, but the information model draft work needs to consider it.

> It would make it easier to resolve the remaining pieces of work in the architecture draft, right?

Technically, we do not have XMPP-Grid as a submission to this WG any
longer (that submission expired); a new submission was made to the MILE
WG.  That does not mean that we can't rely on it, but it's still just a
submission there - it's not yet been adopted.

I think our architecture needs to be reviewed in light of the additional
comments we heard during IETF 94.  This is part of our way forward as well.

>
>
> --
> Chris Inacio
> [email-masked]
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm