Subject: [sacm] The one true SACM IM

From: "Jim Schaad" <[email-masked]>
Date: Tue, 5 May 2015 12:55:00 -0700

Nancy and I having some discussions about issues that I have raised on the
requirements draft, and there is one difference in the view of the world
that has arisen as part of those discussions.  I would like to get some more
input into this and find out if I am just out in left field.

I did the scanning of the documents about the information model and looked
at some of the documents that described how the IM was put together.  In the
process of doing this I came up with some concepts of how the world works
that might not jive with how the group thinks things are going to be done:

1.  It is not clear to me that there is a single one true SACM IM rather
than having multiple IMs that might come out of the group. The current IM is
targeted at endpoint assessment.  I was thinking that there could be other
IMs that were targeted at other problems.

2.  It is not clear to me that the current IM will not/should not have some
modularity built into it from the start so that it is easy to update
sub-components (such as network address types) at a later date as we either
find new components and systems that need to be added to the overall system.

3.  It is not clear to me that external parties will not create other IMs
that might want to be used in a SACM system either dealing with different
problems or that just don't have the energy to get adopted by the IETF as
projects.

I would appreciate general remarks on the question of one vs multiple
Information models in terms of how the requirements are stated.  I am not
really worried about the questions dealing with is the SACM WG going to
produce or adopt multiple models.

Jim

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 05 May 2015 16:45:12 -0400

An information model sufficient to do endpoint assessments *should* be 
capable of being re-purposed for other uses as well, but there's no 
guarantee that it will be capable of stretching much further than that, 
so I have always assumed that multiple data models would be necessary.  
And while it might be possible to fulfill the current reduced charter 
with a single IM, I doubt it.

In fact, I would say that having a single monolithic IM that tries to do 
everything necessary will make it needlessly complex and difficult to 
maintain/update.  Smaller IMs focused on specific functions keeps each 
IM much simpler and means that customization/repurposing can more easily 
be done by retaining those that do work for the new function.

Likewise, modularity has always been my assumption -- in fact, I believe 
that's one of the requirements that Lisa added quite a while ago.

Third party/proprietary extensions are entirely possible at any level, 
and I would go so far as to say encouraged.  That means trying to design 
in a way that allows that, but otherwise out of scope.

--gun

On 5/5/2015 3:55 PM, Jim Schaad wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 5 May 2015 22:18:14 +0100

With my AD hat off...

Sent from my iPhone

> On May 5, 2015, at 8:55 PM, "Jim Schaad" <[email-masked]> wrote:
> 
I think there will be real deployment issues/hurdles with a single IM.  I don't see this as practical and may prevent adoption.
> find new components and systems that need to be added to the overall system.
Or that specific modules might be used depending on your end points.

> problems or that just don't have the energy to get adopted by the IETF as
Agreed.

> produce or adopt multiple models.
I'm worried about he problem getting solved and have been thinking it should be scoped differently as one IM will take forever to develop and may not be used by the time it's done as opposed to models that fit the type of infrastructure - routers, windows, unix servers, mobile, etc.

Kathleen

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 05 May 2015 18:17:52 -0400

+1

It also begs the question why the model
was framed in terms of "endpoints."  The
SA3 SACM counterpart (SCAS) that just met two
weeks ago and plowed through 66 mobile
industry contributions for mobile infrastructure
doesn't use the construct (for obvious reasons).

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 May 2015 11:42:18 +0000

I am confused by this discussion.

First, the SACM charter dully says: 

> this working group will first address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209).

The definition for endpoint in RFC 5209 is: 

> Endpoint - Any computing device that can be connected to a network.
      Such devices normally are associated with a particular link layer
      address before joining the network and potentially an IP address
      once on the network.  This includes: laptops, desktops, servers,
      cell phones, or any device that may have an IP address.
 
I always have interpreted this definition as containing those properties of any network attached device that allow for posture assessment, whatever the nature of this device is - this includes routers, servers, mobile device, etc. 

Developing separate IMs for different classes of elements in the infrastructure seems non-necessary to me (as the evaluation and then automation policies need to be consistent) and very complex to deploy. 

I certainly miss something. 

Regards,

Dan

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Tony Rutkowski
> Sent: Wednesday, May 06, 2015 1:18 AM
> To: Kathleen Moriarty; Jim Schaad
> Cc: <[email-masked]>
> Subject: Re: [sacm] The one true SACM IM
> 
> +1
> 
> SA3 SACM counterpart (SCAS) that just met two weeks ago and plowed
> through 66 mobile industry contributions for mobile infrastructure doesn't
> use the construct (for obvious reasons).
> 
> 
> > I'm worried about he problem getting solved and have been thinking it
> should be scoped differently as one IM will take forever to develop and may
> not be used by the time it's done as opposed to models that fit the type of
> infrastructure - routers, windows, unix servers, mobile, etc.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_sacm&d=AwICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=WihTP
> H7amJ0Do3n-GO7dMXZBoY9jPfmMupt74p_kDfA&s=80CdHd3aC-
> FuWUCHMnUgbifCmWhEeql06CgTjw2xCgE&e=

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 06 May 2015 08:04:38 -0400

Hi Dan,

It is certainly possible to apply this connotation,
although the definition seems to exclude permanent
network infrastructure.  In a NFV world, however,
the constructs get more fuzzy.

It's not apparent that any other body uses the endpoint
terminology/construct, and at best it is an unfortunate
choice of basic term for SACM that exacerbates the
uncertainties of scope and the dialog with other venues
developing similar platforms.

It seems, however, a lesser problem.

--tony

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 6 May 2015 07:18:54 -0500

> On May 5, 2015, at 4:18 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> With my AD hat off...
> 
> Sent from my iPhone
> 

I think I disagree, but I’m also hoping that we’re just talking about things in a different way.  If we don’t have one information model - a window through which we see the rest of the world - we’re shooting ourselves in the foot.  Instead, we should have an information model that is at the abstract level but with meaningful semantics, so that different data models can be viewed by mapping them into the information model.

Your statement seems to imply that we may have different ways to, say, represent an attribute value pair.  So, a NETCONF attribute value pair would need to be understood equally to an OVAL attribute value pair equally to a WMI attribute value pair, and so on.  Instead, it makes sense to specify the representation of an attribute value pair, then describe what facets of the underlying data model qualify as attribute, what facets of the underlying data model qualify as values, and carry on.  

> Or that specific modules might be used depending on your end points.

We have requirements for extensibility already.  Do we need requirements for modularity?

>> problems or that just don't have the energy to get adopted by the IETF as

We can’t control what others are going to do.  We can control what we do.  The best we can do is solve our problems at hand and allow for extension and adaptation (i.e. controlled vocabularies that can change over time).  

> I'm worried about he problem getting solved and have been thinking it should be scoped differently as one IM will take forever to develop and may not be used by the time it's done as opposed to mod…

Again, I disagree here, but see above. 

>> [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>

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 6 May 2015 07:22:54 -0500

> On May 6, 2015, at 7:04 AM, Tony Rutkowski <[email-masked]> wrote:
> 
> Hi Dan,
> 

Would be great if you could expand NFV for those who may not know it.

> developing similar platforms.

Does the definition of “endpoint” suffice?  If so, then call it what you’d like in your world, Tony.  Endpoint is actually quite a common term in enterprise IT shops, and that’s our main target here.

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 06 May 2015 09:32:29 -0400

I wholeheartedly agree, a separate IM for communicating endpoint 
attributes each platform/class of platforms would be ridiculous.

But attributes isn't the only type of communication that needs to 
happen.  There's authentication, tasking, discovery, attribute request, 
assessment content acquisition, etc.

When I say that there should be different IMs, that's what I'm referring to.

--gun

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 06 May 2015 09:50:25 -0400

Like FDCC?  If that's de facto scope, maybe it should
be stated up front, and it will make life simpler and
more focused for everyone.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 6 May 2015 15:49:43 +0200

Unfortunately, the term "endpoint" itself implies "leaf node" in a 
network topology, which poses a rather unintuitive discrepancy to the 
actual definition of the term.

The current SACM terminology draft provides additional clarification for 
the definition of endpoint:

"To further clarify the [RFC5209] definition, an endpoint is any 
physical or virtual device that may have a network address. Note that, 
network infrastructure devices (e.g. switches, routers, firewalls), 
which fit the definition, are also considered to be endpoints within 
this document."

A corresponding rudimentary definition of (network) addresses can be 
found in the IM draft, atm (4.6).

At least the VM perspective of VNF instances works quite well with the 
clarified definition of the term "endpoint" in the context of SACM, I 
think. Also, the context of VNF Forwarding Graphs, which focuses 
primarily on layer 3, aligns well with the clarified definition of an 
endpoint.

Cheers,

Henk

On 05/06/2015 02:04 PM, Tony Rutkowski wrote:
>> I always have interpreted this definition as containing those
>> properties of any network attached device that allow for posture
>> assessment, whatever the nature of this device is - this includes
>> routers, servers, mobile device, etc.
>>
>> Developing separate IMs for different classes of elements in the
>> infrastructure seems non-necessary to me (as the evaluation and then
>> automation policies need to be consistent) and very complex to deploy.
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 May 2015 13:56:02 +0000

So maybe this is an issue of terminology (?). IMs are about Information Elements ('attributes'). Authentication, discovery, requests, content acquisition - all these belong in the protocol(s) not in the IM(s). 

Regards,

Dan

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Wednesday, May 06, 2015 4:32 PM
> To: Romascanu, Dan (Dan); [email-masked]; Kathleen Moriarty; Jim
> Schaad
> Cc: <[email-masked]>
> But attributes isn't the only type of communication that needs to happen.
> There's authentication, tasking, discovery, attribute request, assessment
> content acquisition, etc.
> 
> >> this working group will first address enterprise use cases pertaining to the
> assessment of endpoint posture (using the definitions of Endpoint and
> Posture from RFC 5209).
> > I always have interpreted this definition as containing those properties of
> any network attached device that allow for posture assessment, whatever
> the nature of this device is - this includes routers, servers, mobile device, etc.
> >
> >> It also begs the question why the model was framed in terms of
> >> "endpoints."  The
> >> through 66 mobile industry contributions for mobile infrastructure
> >> should be scoped differently as one IM will take forever to develop
> >> and may not be used by the time it's done as opposed to models that
> >> fit the type of infrastructure - routers, windows, unix servers, mobile, etc.
> >>
> 3A__www.ietf.org_mail
> > man_listinfo_sacm&d=AwIC-
> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
> rphpBsFA&m=W_7Iep9qaTWQx9sL5G9yyn3JDRhFdxhK8q_-Vggd1ek&s=osg-
> Uad1YR97CMYJF_lhrmp2lLLgqP4OkImEwUfNpe0&e=

---

From: Michael Hammer <[email-masked]>
Date: Wed, 6 May 2015 14:02:35 +0000

The endpoint definition accurately captures the original discussion on this.

The "enterprise IT shop" focus is just a subset of that.
But, that should not preclude wider applicability.

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: Wednesday, May 06, 2015 9:50 AM
To: Tony Rutkowski; Romascanu, Dan (Dan); Kathleen Moriarty; Jim Schaad
Cc: <[email-masked]>
Subject: Re: [sacm] The one true SACM IM

Unfortunately, the term "endpoint" itself implies "leaf node" in a network
topology, which poses a rather unintuitive discrepancy to the actual
definition of the term.

The current SACM terminology draft provides additional clarification for the
definition of endpoint:

"To further clarify the [RFC5209] definition, an endpoint is any physical or
virtual device that may have a network address. Note that, network
infrastructure devices (e.g. switches, routers, firewalls), which fit the
definition, are also considered to be endpoints within this document."

A corresponding rudimentary definition of (network) addresses can be found
in the IM draft, atm (4.6).

At least the VM perspective of VNF instances works quite well with the
clarified definition of the term "endpoint" in the context of SACM, I think.
Also, the context of VNF Forwarding Graphs, which focuses primarily on layer
3, aligns well with the clarified definition of an endpoint.

Cheers,

Henk

On 05/06/2015 02:04 PM, Tony Rutkowski wrote:
> Hi Dan,
>
> It is certainly possible to apply this connotation, although the 
> definition seems to exclude permanent network infrastructure.  In a 
> NFV world, however, the constructs get more fuzzy.
>
> terminology/construct, and at best it is an unfortunate choice of 
> basic term for SACM that exacerbates the uncertainties of scope and 
> the dialog with other venues developing similar platforms.
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 6 May 2015 16:06:10 +0200

And the architecture, most likely :)

Grüße,

Henk

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 06 May 2015 10:28:51 -0400

There hasn't been any substantive discussion about these other 
communications yet, but I'm confident they are not going to be easily 
codified in the same Information Elements as communication of endpoint 
attributes.

I do expect some overlap, though.  Endpoint Identification will be a 
commonality.  Even at that, Endpoint Identification as it currently 
exists is not sufficient for requesting the appropriate guidance for an 
endpoint.  For that the role and criticality (CIA values) are needed, 
and that's not something that can be determined by querying and endpoint.

Call it an educated hunch at this point, but I don't think all of these 
things are going to play nicely under the same IM.  Plus, there's the 
very good points Kathleen made.

Finally, I'd like to see it broken out for the simple reason of 
expediting keeping up with future changes.  Even if everything can fit 
under the same IM right now, will that make it more difficult to replace 
portions of this in the future as necessary to keep up with changes in 
the real world?

--gun

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Wed, 6 May 2015 14:35:12 +0000

Please.  In our data collection efforts, we started out using a data model that mirrored a device information model (DoD ARF), but it's horribly inefficient since it mirrors the truly relational nature of a device with hardware, software, network configurations, file systems, etc.   Many of the elements and attributes we need to capture are 4-5 relationships away from the device root element, making for very inefficient XML and complex business logic to de-serialize and parse the data.  The actual data models we're using to communicate findings and inventory have been simplified to allow for much smaller message size and easier parsing.  Also the ability to just send changes as update events versus having to collect entire inventories every time.  We use several different protocols to transfer the data around, so mixing IM, DM, and protocol together would leave us with a hopeless mess.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, May 06, 2015 9:56 AM
To: Gunnar Engelbach; [email-masked]; Kathleen Moriarty; Jim Schaad
Cc: <[email-masked]>
Subject: Re: [sacm] The one true SACM IM

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 May 2015 14:47:23 +0000

Hi,

My experience is very different, as from what I have seen only one IM in a given functional space can offer premises for interoperability. (Of course, multiple DMs can be derived from the same IM.) 

Second - for the good or for the worse - this WG is chartered to work on ' the informational model for endpoints data posture'. One IM only.  The words in the charter are very clear on this respect. Any change of this scope requires re-chartering. If I am mistaken I am sure that Kathleen with her AD hat on will  keep me honest. 

Regards,

Dan

> Sent: Wednesday, May 06, 2015 5:29 PM
> commonality.  Even at that, Endpoint Identification as it currently exists is not
> sufficient for requesting the appropriate guidance for an endpoint.  For that
> the role and criticality (CIA values) are needed, and that's not something that
> can be determined by querying and endpoint.
> 
> Call it an educated hunch at this point, but I don't think all of these things are
> going to play nicely under the same IM.  Plus, there's the very good points
> Kathleen made.
> 
> Finally, I'd like to see it broken out for the simple reason of expediting
> keeping up with future changes.  Even if everything can fit under the same
> IM right now, will that make it more difficult to replace portions of this in the
> future as necessary to keep up with changes in the real world?
> 
> 
> --gun
> 
> 
> > So maybe this is an issue of terminology (?). IMs are about Information
> Elements ('attributes'). Authentication, discovery, requests, content
> acquisition - all these belong in the protocol(s) not in the IM(s).
> >
> > Regards,
> >
> > Dan
> >
> >
> >> There's authentication, tasking, discovery, attribute request,
> >>> properties of
> >> any network attached device that allow for posture assessment,
> >> whatever the nature of this device is - this includes routers, servers,
> mobile device, etc.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 6 May 2015 11:54:55 -0400

Hi,

+1 to all of Dan's comments.

IETF SACM doesn't have a charter (and would never get one approved)
to solve all problems in the security space (such as discovery and key
and configuration provisioning).

A wider scope for SACM would simply guarantee failure.

Let's please all keep to our current chartered scope, for which a single
Information Model is a prerequisite for success.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, May 6, 2015 at 10:47 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

> Hi,
>
> My experience is very different, as from what I have seen only one IM in a
> given functional space can offer premises for interoperability. (Of course,
> multiple DMs can be derived from the same IM.)
>
> Second - for the good or for the worse - this WG is chartered to work on '
> the informational model for endpoints data posture'. One IM only.  The
> words in the charter are very clear on this respect. Any change of this
> scope requires re-chartering. If I am mistaken I am sure that Kathleen with
> her AD hat on will  keep me honest.
>
> Regards,
>
> Dan
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 May 2015 13:14:16 -0700

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Wednesday, May 06, 2015 7:47 AM
> Subject: RE: [sacm] The one true SACM IM
> 
> Hi,
> 
scope
> requires re-chartering. If I am mistaken I am sure that Kathleen with her
AD
> hat on will  keep me honest.

Do you believe that this statement would prevent a decomposition of a single
IM into a top level one with sub-pieces?  This is what I kind of expect to
make future updates easier, but I could be wrong.

Jim

> > exists is not sufficient for requesting the appropriate guidance for
> > an endpoint.  For that the role and criticality (CIA values) are
> > needed, and that's not something that can be determined by querying and
> endpoint.
> >
> > Call it an educated hunch at this point, but I don't think all of
> > these things are going to play nicely under the same IM.  Plus,
> > there's the very good points Kathleen made.
> >
> > under the same IM right now, will that make it more difficult to
> > replace portions of this in the future as necessary to keep up with
changes
> in the real world?
> > >> To: Romascanu, Dan (Dan); [email-masked]; Kathleen Moriarty;
> > >> Jim Schaad
> > >> Cc: <[email-masked]>
> happen.
> > >> When I say that there should be different IMs, that's what I'm
> > >> referring
> > to.
> > >>
> > >>
> > >> --gun
> > >>
> > >> assessment of endpoint posture (using the definitions of Endpoint
> > >> and Posture from RFC 5209).
> > >> infrastructure seems non-necessary to me (as the evaluation and
> > >> then automation policies need to be consistent) and very complex to
> deploy.
> > >>>> SA3 SACM counterpart (SCAS) that just met two weeks ago and
> > >>>> plowed through 66 mobile industry contributions for mobile
> > >>>> infrastructure doesn't use the construct (for obvious reasons).
> > >>>>
> > >>>>
> > >>>> should be scoped differently as one IM will take forever to
> > >>>> develop and may not be used by the time it's done as opposed to
> > >>>> models that fit the type of infrastructure - routers, windows,
> > >>>> unix servers, mobile,
> > etc.
> > >>>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 06 May 2015 16:59:59 -0400

I'm not sure if Dan was referring to "informational model" being of 
singular in case or if he was referring to the focus on "endpoints data 
posture."

If the latter, I agree, the original scope of this working group was 
intentionally whittled way down in order to stand a chance of 
accomplishing something and we need to stick with that.

But if the former -- well, that's a non-issue if the consensus is that a 
single IM is the best approach.

But if it's not the best approach I'd much rather do what it takes to 
update the wording in the charter rather than put effort into what would 
be deemed an inferior approach.

--gun

On 5/6/2015 11:54 AM, Ira McDonald wrote:
> mailto: [email-masked] <mailto:[email-masked]>
> On Wed, May 6, 2015 at 10:47 AM, Romascanu, Dan (Dan) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     My experience is very different, as from what I have seen only one
>     IM in a given functional space can offer premises for
>     interoperability. (Of course, multiple DMs can be derived from the
>     same IM.)
>
>     Second - for the good or for the worse - this WG is chartered to
>     work on ' the informational model for endpoints data posture'. One
>     IM only.  The words in the charter are very clear on this respect.
>     Any change of this scope requires re-chartering. If I am mistaken
>     I am sure that Kathleen with her AD hat on will  keep me honest.
>
>     Regards,
>
>     Dan
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 6 May 2015 22:39:34 +0100

With AS hat on...

Sent from my iPhone

> On May 6, 2015, at 9:14 PM, "Jim Schaad" <[email-masked]> wrote:
> 
> 
> 
The current charter works for this model in my opinion.

Kathleen

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 7 May 2015 00:27:47 +0000

I agree with Dan.

That is, I agree that the visual I have is IM = information elements (ergo
only 1 IM)Š..DM = an instantiation/representation that is implementable of
the information elementsŠ.and then I separate the operations on the data
elements.
But I think I have mixed nomenclature of using both interfaces and
protocols to infer authentication, discovery, etc. that should all perhaps
be covered under protocol (or operations)?

Thanks, Nancy

On 5/6/15, 6:56 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>>referring to.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 May 2015 05:57:12 +0000

>  Do you believe that this statement would prevent a decomposition of a
> single IM into a top level one with sub-pieces?  

Certainly not, quite the opposite, a hierarchical and modular design of the IM seems a fine architectural approach. This is different than 'multiple IMs'. 

Regards,

Dan

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Wednesday, May 06, 2015 11:14 PM
> To: Romascanu, Dan (Dan); 'Gunnar Engelbach'; [email-masked];
> 'Kathleen Moriarty'
> Cc: [email-masked]
> > My experience is very different, as from what I have seen only one IM
> > in a given functional space can offer premises for interoperability.
> > (Of
> course,
> Do you believe that this statement would prevent a decomposition of a
> single IM into a top level one with sub-pieces?  This is what I kind of expect to
> > > communications yet, but I'm confident they are not going to be
> > > easily codified in the same Information Elements as communication of
> > > endpoint attributes.
> > >
> > > expediting keeping up with future changes.  Even if everything can
> > > fit under the same IM right now, will that make it more difficult to
> > > Elements ('attributes'). Authentication, discovery, requests,
> > > content acquisition - all these belong in the protocol(s) not in the IM(s).
> > > >
> > > > Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > > >> From: Gunnar Engelbach
> [mailto:[email-masked]]
> > > >>>         Such devices normally are associated with a particular
> > > >>> link
> layer