Minutes for SACM at interim-2015-sacm-3
minutes-interim-2015-sacm-3-1

============================================================================================================================================
IETF SACM WG Virtual Interim Meeting
10:00 AM EST – 12:00 EST)
May 12, 2015
Minute taker #1: Danny Haynes
======================================================================
Agenda Bashing (Dan Romascanu / Adam Montville)
======================================================================
[Adam Montville]: There was a request to change agenda items #2 (Introduction
to the OVAL Information Model Mapping) and the #3 (Introduction to Endpoint
Compliance). Since there were no objections to this change, the agenda was
updated.

======================================================================
Endpoint Compliance Standard (Jessica Fitzgerald-McKay)
======================================================================
[Jessica Fitzgerald-McKay]: This draft was born out of what SACM partially
requires which is to do collection directly on an endpoint about the state of
an endpoint. Some of this work has already been done in the Trusted Computing
Group and the IETF NEA working group and this draft explains how it could be
appropriate to bring this work to the IETF SACM working group. There are
intellectual property rights associated with many of specifications which are
owned by the Trusted Computing Group. This draft begins to help introduce the
specifications to see if they are something we even want to use before we go
back to the Trusted Computing Group to see what it would take to move the
specifications into the IETF SACM working group.  While I don’t know what they
would say to this request, in the past, the TCG was willing to transfer
specifications to the IETF and other groups. The TNC architecture was
originally used to do the comply-to-connect use case. Initially, the Access
Requestor, a device trying to connect to the network, would have a software
stack with integrity measurement collectors which would gather information from
the endpoint which would then communicate to the TNC Client which would then
communicate to the Network Access Requestor which initiates the connection with
the Policy Decision Point.  The Policy Decision Point could then take this
information, send it up its software stack all the way to the Integrity
Measurement Verifiers (IMVs) which would take this information and decide
whether or not the endpoint was compliant enough with the policy to join the
network.  It then sends the decision down to the TNC Server which either allows
the endpoint to join the network or reject the endpoint and have it go to a
remediation network, quarantine, or don’t let it access the network. Many of
the specifications have already been shared with the IETF in the NEA WG. IF-M
became PA-TNC, IF-TNCCS became PB-TNC, and IF-T became PT-TLS and PT-EAP. Now,
I would like to frame the TNC work in terms of our work.  Instead of doing
Integrity Measurement Collection (IMC) and Integrity Measurement Verification
(IMV) we want to think of Posture Collectors and Posture Validators speaking to
Posture Broker Clients and Servers just they do in the NEA work.  These then
communicate with Posture Transport Clients and Servers.  The parts that we can
borrow from the TNC architecture which are valuable to SACM is the ability to
collect posture attributes from and endpoint like internal collectors in SACM,
evaluation of the posture attributes against policy guidance which is something
that we can already do with the architecture today.  There are secure channels
for exchanging posture assessment information which meets a lot of our
requirements that we specified in our Requirements document.  I think there is
some room for some changes to the basic architecture that we could work in the
SACM work group and better meet some of our use cases.  There is some work we
could do with the SACM evaluator and the SACM internal collector and the need
to separate collection from evaluation.  In the draft, I talked about taking
some of those validator functions and splitting them up.  Maybe on our NEA
Server we can keep the aspects of the Posture Validator that do things that
better align with provider-consumer roles in our architecture and keep the part
of the Posture Validator that allows you to request and report information from
an endpoint.  Then we could keep the part of the Posture Validator that lets
you know if an endpoint can provide you with the information that you are
looking for, whether or not it has the right Posture Collectors on it, and keep
that all of that at the server.  However, we can move some parts of the Posture
Validator of off the NEA Server.  Maybe, we could take the pieces of the
Posture Validator that do the evaluation against the network policy and move
that out to an evaluator role that better meets our SACM use cases.  We have
mapped the TNC/NEA roles to the roles that we have already described in our
architecture and we already have our provider and consumer, the Posture
Collectors and Posture Validators, our Posture Broker Clients and Servers act
as SACM controllers, and through our protocols and interfaces, we have a secure
channel to exchange posture assessment information between the providers and
consumers.  As mentioned before, a lot of the TNC architecture has been worked
in the NEA working group, but, there are still a lot of places where we can use
the standards that still existing solely in TCG in our work to expand our use
cases.  We could standardize the inter-endpoint and intra-component interfaces
as well as standardize the different types of attributes.  For example in the
Internet Draft, I call out SWID Messages and the communication of SWID Messages
between an endpoint and posture server.  I think we can make use of that
because it meets lot of our information model use cases.  We can also
standardize some of the bootstrapping activities like the initial connection
between the endpoint and the collector that will be collecting the data for
evaluation.  Here we list off some of the standards that meet each of these
points.  So, if we could bring IF-IMC and IF-IMV, we could get that endpoint to
component interfaces.  SWID Messages and Attributes for IF-M standardize the
collection and transmission of that specific type of information.  That may not
be the only information SACM wants to collect.  I understand that we have a lot
more data that we will need to collect to meet all of use cases, but, doing
software asset management meets a lot of our needs so we can start there and
see where this architecture, with that particular piece of posture information,
and see if that is something that we can then build upon.  Server Discovery and
Validation is a TNC specification that is in progress and there is a public
draft, available now, which allows you to locate and verify appropriate servers
for sending this posture information.  Reusing standards such as TNC is good
because it is better to not re-invent the wheel and see if we can build upon
them for our particular use cases.  So why do this.  TNC already defines
several parts of security automation which is aligned with NEA and can be
aligned with SACM.  There is no reason to re-invent the wheel for internal
collection, it exists, and is out there.  With TCG’s permission, maybe we can
go ahead and take these specifications, expand on them to meet our specific
needs, and make sure we have unification rather than bifurcation of these
standards.  There is running code as strongSwan has implemented all of these
specs and the code is available open source.  There is also a more recent Java
implementation for the same standards.  We have the running code, now we just
need the rough consensus.  With the group’s agreement, I would like to request
that the TCG submit these standards to SACM.  Within the TCG, everyone is
comfortable with that, but, we would just need to go through some work with the
board there, but, I don’t really foresee that being a huge problem.  Within
SACM, we can then adapt these standards to meet our requirements while we
maintain compatibility with TNC.  I think this represents a huge step forward
in tackling some of our more basic use cases and provides us with an
architecture to build on for further collection of data from endpoints.  I am
happy to discuss this and answer any questions with the remaining time. [Dan
Romascanu]: I have a couple of clarification questions.  First of all, we are
talking about how many standards?  You listed two and I get the impression that
they come in pairs.  So we are talking about two or four documents? [Jessica
Fitzgerald-McKay]: IF-IMC and IF-IMV come as a pair.  They are complimentary. 
One is on the endpoint side and the other is on the server side.  SWID Messages
doesn’t come in a pair.  It is standalone and just rides over IF-M.  Server
Discovery and Validation is just a single specification and doesn’t have a
partner specification to go with it.  It just allows the endpoint to find an
appropriate server to which it can report its posture information.

[Dan Romascanu]: I don’t know anything about the structure of the standards,
but, is there a combination of the protocol mechanisms and data model
attributes? [Jessica Fitzgerald-McKay]: The SWID Messages specification is more
in alignment with collecting a specific type of posture information so, yes, it
is appropriate to think of it as a format to meet our data model needs.  Server
Discovery and Validation is more of a bootstrapping to a protocol and IF-IMC
and IF-IMV are the interfaces. [Dan Romascanu]: Are the standards available for
anybody who wants to to go and read them? [Jessica Fitzgerald-McKay]: Yes, I
link to all of them in the Internet Draft.  Certain ones that are in draft form
have been worked pretty extensively since they were last published for public
review.  Server Discovery and validation is one of them and has been pretty
heavily updated, but, the basic ideas on how you would discover the appropriate
server to report to has been maintained through the revisions.  But again, if
this is something that the group looks at that and decides it is more or less
the right path, we can talk to TNC about getting a more up-to-date copy out
there for people to take a look at. [Dan Romascanu]: Talking about talking to
TNC.  The previous experience with NEA is that they didn’t release the
specifications for change control to the IETF. [Jessica Fitzgerald-McKay]: The
way that I understood it was that they took the specifications from TNC and
completely rewrote them with the same ideas, same content and if you
implemented it, it would be the same specification, but, with different words. 
All of the change control for the IETF was maintained by the IETF and TNC had a
responsibility to keep their specifications in alignment with IETF
standardization.  I am not actually recommending that we take this path, unless
people want to take that route.  I think we would have more success just going
to the TCG board and asking for it and see what they say.  If they say we need
to rewrite it, we will face that if we must, but, I don’t feel uncomfortable
asking them if we can just release the specifications. [Dan Romascanu]: Yes,
that helps under the precedent and the possible parts, but, the first step is
to go and read the specifications and see to what extent they meet our
requirements, compare them with other options if available, but, this is a good
start. [Jessica Fitzgerald-McKay]: Any other questions.  There were no
questions. [Phyllis Lee]: Is the group interested in pursuing this Internet
Draft and getting these specifications over? [Dan Romascanu]: If you are asking
about the immediate next steps, we are interested in reading the specifications
and forming an opinion. [Dave Waltermire]: Would it make sense to have
volunteers read the specifications that Jessica has called out and do some
analysis with respect to the requirements? [Dan Romascanu]: Yes, that would be
a good thing to do and if there are volunteers, please say now or consider
stepping up.  But, we probably need to at least have some level of
understanding about what they are about.  If there are volunteers at this
point, that would be great. [Adam Montville]: We look forward to having some
volunteers step up and we will ask this on the list.
======================================================================
OVAL and the SACM Information Model (Matt Hansbury / Danny Haynes)
======================================================================
[Matt Hansbury]: First thing, I don’t know if everyone knows what OVAL is and
OVAL is the Open Vulnerability and Assessment Language which is an XML-based
language for encoding details about endpoint posture assessment.  So, you could
imagine a natural fit for SACM.  It has been around since 2002 and MITRE has
operated as the moderator for OVAL on behalf of the Department of Homeland
Security.  A couple of other things, OVAL is widely adopted with broad support
and defined as the primary checking language for SCAP which most of you should
be familiar with.  OVAL is certainly supported within SCAP.  A quick note
similar to what Jessica went over, there are some IPR considerations.  We, DHS
and MITRE, are working to figure out what that means, but, we think it
shouldn’t be an issue and we are working on that and will figure that out.

[Dan Romascanu]: Out of the 45 organizations, maybe some of them are
international so there is no border or nation border limitation because it
belongs to DHS? [Matt Hansbury]: You are correct.  There is definitely
international support for OVAL and there are 13 countries that use it.  There
are no international constraints there, it just happened to be funded by the US
Government.  We created this paper to do a few things, with the main objectives
being to take the existing parts of OVAL and map them to the different parts
within the SACM information model and make some concrete recommendations that
we believe are the correct way to make use of them in SACM as well as some
lessons learned from the 12+ years of working on it.  One point that is not
here is that the information model was a moving target and when we started the
paper, there were some additional changes to the information model so if there
needs to be some updating we will do that, but, we wanted to get it out there
to get the conversation started.  The paper goes through the different parts of
the OVAL Language that could be used within the SACM information model, but, I
think the key takeaways are the recommendations and the things that we think
are worth doing within SACM.  One of the things is that OVAL is composed of
several different models each of which do different things and the paper goes
over this in a bit of detail and I hope that you can check this out.  In short,
the model called system characteristics which is the way to the take the
information that you pull off the endpoint and encode it in XML so that you can
pass it around and do things with it.  One of our recommendations is to take
that model and use it as the base for a data model for SACM for data
collection. We don’t think the OVAL Language today will do everything that SACM
needs to do, but, is a good starting point for doing these different things. 
The second recommendation is the OVAL Definition Model which defines the check
itself, what data needs to be collected, and what the data needs to look like
which is combined and a limitation of OVAL.  OVAL wraps together collection and
evaluation guidance into a single thing which is a design feature although in
SACM we want to separate those two things.  So, we would want to separate those
things apart and use them as a base for which we would build the SACM
collection and guidance from.  Our last recommendation is yet another model
OVAL Results which captures the assessment results and we are recommending that
we do not use that for SACM.  It just never quite satisfied the needs for
granularity of the community.  Those are our three main recommendations and the
paper lays this out in more detail.  Another key part of the paper is the
lessons learned and there are more than the four, but, we just wanted to
highlight what we thought were the most important.  One of the key ones is
simplicity.  This goes beyond our lessons learned for OVAL, but, aligns with
some of the other efforts that we have been involved in.  When you are involved
in an information sharing effort, we need to make sure that we are sharing the
right information with the right people.  We found that if you try to share too
much information, you end up with an unsuccessful sharing effort.  The next
thing that the group understands very well is that we need to decouple
collection and evaluation.  The third one is to empower subject matter experts
and this is a key one that we touched on a few times in the paper and the
history with OVAL is that we have, for years, been taking on a very
comprehensive approach including doing all of the research for the OVAL
Language and writing the different tests and basically trying to figure out and
reverse engineer different products and platforms and the more and more we
tried to push to have those to know that best, typically the primary source
vendors, to empower them to share the information.  That is, we don’t try to do
it for them, but, let them do it.  Also, carrots work better than sticks. 
Mainly, we need to give them good business reasons to do it rather than
mandating that they do it.  We would like to continue this discussion on the
mailing list and we will revise the document based on feedback.  We are looking
at the IPR issues and will work that out.  Then, we will plan a schedule for
contributing the data models as it makes sense.  Does anybody have any
questions?

[Adam Montville]: Please review the submission and resources here and offer
suggestions.

[Dan Romascanu]: As co-chair, let me take an action to send a message to the
list to call for volunteers to review both contributions as there may be some
people who could not make the call today.  It would be very good if there would
be a couple of folks for each of the contributions, of course not the authors,
to investigate how it aligns with SACM and hear back at the next virtual
interim meeting.  People should try to find some time to read because that is
the next step.

======================================================================
Endpoint Identity Design Team Update (Dave Waltermire / Adam Montville / Cliff
Kahn / Danny Haynes)
======================================================================
[Dave Waltermire]: We started the Endpoint Identity Design Team back in
December 2014 and have been meeting about once a week since then.  We have come
up with quite a bit of information that we believe will help augment the
information model document.  We have a set of goals that we defined at the
onset of the design team.  We want to provide an assertion model for endpoint
identifying attributes so we want to define effectively a logical model that
can be used to represent a number of attributes that can uniquely identify a
given endpoint.  We want to be able to support correlation between different
sets of assertions over time and are recognizing that there may be multiple
points of view that can be captured as part of collecting posture information
from the endpoint and those points of view will have a set of identifying
attributes and we want to be able to correlate those different points of view
between the posture information that is collected.  We want to focus on direct
observations over network-based or indirect observations.  While we talked some
about network-based observations, looking at traffic on the wire, protocols
activities to identify the endpoint, etc. our primary focus has been collecting
identifying attributes through direct observations such as software on the
endpoint and software that interacts with software that is on the endpoint. 
Secondarily, we have been working to establish a method of confidence
assertions that has not been the largest focus of our work and has been a
fairly minimal focus.  Next, we will go through the different tests cases.
[Adam Montville]: In the following slides, we will go through the different
tests cases that we have done. [Danny Haynes]: At previous Endpoint Identity
Design Team meetings and at the meeting in Dallas, we came up with a set of
tests cases that we originally came up with as the set of identifying
attributes and tried to determine which ones do we really need versus which
ones we can toss to the side.  We really just wanted to get to a core set that
we thought was important and then go from there.  We wanted to use that core
set of attributes to update the information model.  This first test case is the
collector on an endpoint and it really represents the traditional endpoint in
an enterprise environment, your workstations, servers, and things like that
with an internal collector on them.  In this test case, the collector is
responsible for collecting attributes either based on guidance that provides
instructions on what to collect or the collection may be trigged by an event
that happens on the network.  From there, once it collects the attributes off
of the endpoint, it will take those attributes and send it to some consumer
whether it is a data store housing all the attributes on the network or
possibly an evaluator that may take in addition some evaluation guidance, and
come up with some results and then use it later on.  In this test case, we
looked at two specific scenarios.  One using endpoint identity information to
retrieve guidance from a data store which is important because a lot of times
the guidance you are using to collect information from the system can depend on
a variety of factors such as the software of the endpoint, the criticality of
the endpoint with respect to the organization, and things like that.  Knowing
how the endpoint is composed will help figure that out.  The second scenario is
once you have a bunch of attributes collected off the endpoint when you are
going to send them somewhere else, you will need to be able to associate them
with the endpoint from which they were collected and the identifying
information would be used in that respect.  We are not going to go over the
lessons learned slides in the interest of time. [Dave Waltermire]: There is a
lot of information in the slides though so if you are interested in reading in
greater detail about the work that we have done, please review the slides.
[Cliff Kahn]: In the external collector that queries endpoints, we get an
architectural distinction that is in the information model.  There are existing
management protocols and different ways to get information from an endpoint
which are available for SACM.  Here, we are envisioning that the architecture
is extensible enough to get information in whichever way it works and talks to
the rest of SACM using a SACM protocol.  An adapter, proxy, or whatever we want
to call it could be on the endpoint, it could be a NETCONF server, a SNMP
server, and it could be this proxy thing that talks to the endpoint with
SSH-ing into the endpoint and using proprietary or command lines to scrape
information about the state.  It doesn’t matter which is good, but, it matters
a little bit in the information model in which it may not be modeled exactly
the same which is why we wanted to.  The pragmatic way is that this should be
accommodating.  The next test case is the network profiler test case.  While
network observations aren’t focal, it is still important in the practical
reality and to test our information model against the kinds of information that
a network profiler would be able to provide.  A network profiler is a synonym
for characterizing an endpoint’s operating system, version, etc.  We are not
trying to decide whether or not an endpoint is misbehaving as that is something
that we don’t want to get into with SACM right now.  I am talking about this
being iOS version X based on seeing how it acts on the wire and there are
commercial products that do this.  We defined network profiler as a component
that observes network traffic or infrastructure such as ARP caches, etc. and
working at that kind of level.  Within this, there are three ways that a
network profiler can add value into a SACM ecosystem deployment.  One way is to
characterize an endpoint that is not possible to query (e.g. SNMP, NETCONF,
NEA, etc.) because what software is on it, or it is not part of the network
enterprise infrastructure to do these things which is going to be a significant
portion of the world for a significant portion for a while.  We have BYOD that
in principle may be able to participate in some of these protocols, but, in
practice they are not doing it.  We have constrained devices.  I know we said
that they were out of focus, but, the fact is profilers learn about them and it
is potentially good to know what you have on your network.  Maybe you are happy
to have BYOD Windows 7 machines, but, you are not happy to have Windows XP
machines so it would be good to know whether you have any.  This is also useful
for detecting rouge endpoints in the network infrastructure.  Another use for a
network profiler is detecting an endpoint that should be under SACM monitoring,
but, maybe the endpoint should be under more SACM monitoring.  For example, all
Windows systems should have a full-fledge SACM monitor that can provide all
kinds of attributes, but, one of them isn’t.  A profiler could find that. 
Again, we need to be able to correlate what the profiler has found with the
other sacm collectors to determine what is or is not under monitoring by other
collectors.  The third use is to cross-check.  For example, a network profiler
might contradict what another collector is saying, you may want to dig into
that and find out what is happening.  For example, an endpoint may be
compromised and lying, or if the collector is confused, etc. and you may be
able to determine something is wrong.  So, cross-checking seems really
important in a security system.  We also need to correlate identities with the
identities that other SACM collectors observe to achieve any of these
scenarios. [Danny Haynes]: The next test case that we looked at is around the
endpoint identity information in the data store which serves a pretty important
role in housing guidance, attributes, previous assessment information, etc.  It
is also a source for data.  You may be able to get attributes from an internal
collector on the endpoint or depending on the requirements on the data you need
you may be able to query a data store and collect information that was
collected at a previous time.  So, the two big scenarios here were that a lot
of the information that is collected and stored in the data store will be
associated with a particular endpoint and as such the identifying information
will serve as a valuable key for either storing information in the data store
or looking it up.  So, in this test case, we looked at what are those minimum
set of attributes that we need to be able to grab a particular piece of
information from the data store with regards to particular types of endpoints
whether they be traditional such as workstations and servers, mobile devices,
or even network infrastructure devices.  We didn’t really look at constrained
devices because at the IETF meeting in Dallas we decided that was out of focus
for now and we will pick it up at a later iteration.  Again, we have some
examples of things that we may want to look at when further looking at data
stores for SACM.  The last test case was around the evaluation capability. 
During one of the Endpoint Identity Design Team meetings someone described an
evaluator as something that takes input and provides some output which is a
good basic definition.  In this test case, we looked at the input being posture
assessment information collected of an endpoint, possibly using previous
evaluation results and reports to make comparisons about how the state has
changed over time, and obviously evaluation guidance which will guide how the
evaluation is carried out.  In the evaluation of posture assessment
information, the output would be evaluation results.  The endpoint identity
information really comes into play here in that information may be passed to
the evaluation capability or the evaluation capability may have to track it
down itself and knowing the identity for the target endpoint that it is looking
at and needs to make some evaluation about it will need to use the identity
information to find out what posture attributes it needs and things like such. 
We also have some examples.  One last thing that I would say is if there are
some important test cases that we haven’t covered that we should, please let us
know or send it to the list so we make sure that we cover everything. [Adam
Montville]: Basically, I think what we have learned so far is that we don’t
know everything and what one enterprise uses as an identifier might not be
applicable to a different enterprise so we should probably accept the open
world view and say that somebody else might see something as an identifier that
we don’t.  So, extensibility is a must and we might consider a controlled
vocabulary approach as a way to manage these things in the future.  So, what do
we do now?  We need to continue discovering how we talk about identifying
endpoints which is what we are going to introduce here.  There are certain
properties that are interesting: multiplicity, persistence, immutability, and
verifiability.  We also need to further discuss these which will happen in the
Endpoint Identity Design Team and then as a working group as a whole.  Next, we
will go over the spreadsheet which discusses the attributes and how they align
with the different properties. [Dave Waltermire]: One of the challenges that we
are having in the design team, one of the things that we were trying to
accomplish was that we were trying to highlight specific attributes that we
would suggest that be provided in most identifying cases as a way to provide a
baseline for correlation which is one of our goals and we had started with this
concept of primary versus secondary identifying attributes.  The idea was that
the primary attributes would be the ones that we would promote to be provided
as much as possible when reporting the identity of an endpoint.  The challenge
that we ran into was we were largely making qualitative judgements on various
attributes based on personal preferences and we were really struggling with
what should be in that primary versus secondary category.  A couple weeks ago,
we started kicking around a notion of really trying to decompose our analysis
along a number of different dimensions that may allow us to take a more
quantitative approach to characterize various identifying attributes:
multiplicity, persistence, immutability, and verifiability.  We are looking
today for some input into are these the right set of attributes that we should
be considering, are there additional attributes that we should consider
important from an identification and correlation perspective?  So, keep that in
mind as we talk through this and feel free to jump in if you have any questions
or comments as we go through the spreadsheet. [Cliff Kahn]: Just to clarify,
when you talk about attributes, are you talking about the meta-attributes like
persistence?  Or, about the attributes like MAC addresses? [Dave Waltermire]: I
would call the four meta-attributes properties.  What I was talking about was
these are the properties that we are using to describe attributes. [Cliff
Kahn]: You asked people for input on attributes and you meant to say properties
right? [Dave Waltermire]: Yes, we are looking for input on these four
properties of attributes and we are looking for if we are missing any specific
properties that might be important from an identification perspective. [Cliff
Kahn]: No worries.  Thanks for clarifying. [Dave Waltermire]: Thanks for
asking.  So, I am going to go through the specific properties.  The first one
is multiplicity.  We have two values that we have been considering for
multiplicity: one-to-one and one-to-many and what this really means is for a
given attribute value is that value assigned to a single endpoint or is that
value typically assigned to more than one endpoint and this really speaks to
some degree the uniqueness of the attribute value and the ability to use that
attribute value to uniquely identify a given endpoint.  One-to-one means that
attribute is associated with a single endpoint and can help to uniquely
identify the endpoint and the one-to-many is the attribute might be assigned to
more than one endpoint and might not be able to discriminate against a given
endpoint. The next property is persistence which is really how likely an
attribute value is to change and we have been characterizing this property as
1-to-5 with 1 meaning the attribute value is constantly changing meaning that
it is probably not a good attribute for identification because of that constant
change.  The next level up is the value changes on an ad-hoc and often
unpredictable basis and that we cannot predict when it is going to change.  The
middle value is that the attribute value should only change based on an event
and the change is essentially predictable and event driven on some level.  The
fourth level that we have is the attribute value should only change when the
device is re-provisioned or initially provisioned as well.  These tend to be
very persistent values that are configured initially and maybe only
periodically updated when the attribute value expires and needs to be
re-provisioned.  Finally, the highest and the most ideal value for persistence
is the attribute value never really changes and is always the same.  The next
property that we were considering is immutability and this deals with how
difficult it is to change this attribute value.  Typically, what we are talking
about here is software versus hardware rooted types of concepts.  The lowest
level of immutability means that the attribute can be basically changed without
any kind of controlled access and anyone of who effectively has access to the
device can make that change there is really no controls in place to prevent
that change from occurring.  The middle level deals with effectively
implementing some kind of user process level access control to limit the change
of the attribute to some authorized set of users or processes and then the
highest level is effectively that the attribute is hardware rooted and cannot
change.  Granted, hardware rooted is a concept that we have some difficulty
with because in virtualized environments are often virtualizing hardware which
often makes it easier to change values that are embedded in the hardware in
those cases.  One thought that we had there is if you were virtualizing
hardware you effectively cannot have the highest level and are likely looking
at the next level down which can be changed with the appropriate access.  This
is something that we are still trying to sort out, specifically, is how do we
deal with this hardware versus software rooted situation and how do we account
for virtualization.  Finally, the last property is verifiable which is maybe a
synonym for how easy can we corroborate that information using another source
which is actually something that Cliff was talking about earlier when he was
talking about profiling and one method is corroboration where we can
effectively observe that information on the network and corroborate what the
endpoint is reporting about itself as an example.  An alternate way of doing
that may be using various cryptographic mechanisms to verify information that
the endpoint is reporting.  So, we have been considering three different values
for this verifiable property.  The lowest value is the attribute value cannot
be externally verified and there is no method that would allow for
corroboration of the attribute and when it’s reported and we would have to take
the word of the reporter without the ability to externally verify it.  The
middle is the attribute value can be externally verified and corroborated, but,
there is no way to absolutely tie that value back to the source endpoint that
might be asserting that attribute value.  The highest is the ideal case where
it can be externally verified and we can tie that value to the specific
endpoint that it is asserting or that the software on the endpoint is asserting
it.  Any questions on these properties?  Comments?  I probably don’t have time
to go into any kind of detail on the specific attributes.  I guess one thing we
could do if people want to glance at this and raise any questions that they
might have.  I guess I can speak briefly to some of the questions that we are
currently struggling with.  I did mention the immutability question relative to
virtualization.  In our last Endpoint Identity Design Team meeting, we broke
out the various attributes to talk about the attributes where they are hardware
rooted versus software rooted to try and characterizes those differences.  One
thing that came up during the last conversation we had is should we really
consider a difference between MAC addresses that are basically encoded in the
network interface card versus those that have been assigned by the operating
system or networking stack.  From that perspective, we largely are seeing the
effective version of that MAC address and depending on the operating system
capability, it may be difficult to determine the difference between the
interface-assigned MAC address versus the one that is hardware encoded. [Dan
Romascanu]: Typically, the MAC addresses assigned by the operating system or
some other software are those not locally assigned addresses?  There is a
48-bit format and there is a locally assigned bit? [Dave Waltermire]: You are
suggesting there is a bit in the MAC address that should be used when the
address is locally assigned? [Dan Romascanu]: I don’t claim that I know all the
operating systems, but, I assume the operating system will use the software
algorithms and use the locally assigned space. [Dave Waltermire]: I see and
that goes in the vendor-associated segment of the MAC address? [Dan Romascanu]:
Yeah.  Basically, the vendor has a mask out of which the 24 bits, which are
tied to OUI, and actually only 22 are used for vendor assignment because one is
indicating the network card and the other is used for local assignment. [Dave
Waltermire]: I see. [Dan Romascanu]: Having said this, I should point to the
IEEE which just started work to provide even more structure within the
global-assigned space and locally-assigned space.  So, there will be some rules
that will not necessarily accommodate virtual machines and other virtual
entities, but, it is supposed to be backwards compatible so everything else
should remain in place. [Dave Waltermire]: That is something that we will need
to investigate.  There are also some protocols. [Dan Romascanu]: The person who
knows a lot about this mechanism is Donald Eastlake in both those working
groups IEEE 802.11 and the IETF groups that are related to mobility because
many of those mechanisms are used in mobile networks. [Dave Waltermire]: Maybe
we can invite Donald to the Endpoint Identity Design Team meetings? [Dan
Romascanu]: That would be a good idea. [Henk Birkholz]: I just tried Linux,
UNIX, and BSD operating systems and they can differentiate at the software
level between the software-assigned address and the hardware-assigned address.
[Dan Romascanu]: They can. [Henk Birkholz]: My question to the team is that, is
it possible that some systems can get the original address of the operating
system? [Dan Romascanu]: That’s exactly my question.  I don’t know if all
operating systems support it.  The probably expect the IEEE standard, but, they
may use some other mechanism which I am not aware of.  So, I don’t know if that
is the only mechanism in place.  An enterprise can always buy a space which
would be out of fixed space and apply some rules within this space and this is
what the new IEEE standard tries to avoid and actually tries to provide some
more structure within the locally-assigned space. [Dave Waltermire]: There has
been some protocol work that I have seen that allows you to rotate assigned MAC
addresses dynamically to be disruptive to malicious actors on a given network. 
That is something that could impact the persistence of the assigned MAC
address. [Dan Romascanu]: The main person you may want to talk with is Juan
Carlos Zuniga.  He is the guy who runs the privacy experiments at the last
couple of IETF meetings and he is actually very much involved with the new work
in the IEEE.  So, because some of those mechanisms actually have privacy
implications and Kathleen Moriarty may actually know a lot about this, but,
basically the idea is that you need to protect against attacks and
vulnerabilities so those systems if they use a certain, but, fixed space they
are also easier to attack from a privacy point of view.  Now, Juan Carlos
Zuniga is using and deploying at the last couple of IETF meetings an
anonymization algorithm which basically blurs the MAC address to disallow the
identification on a network which is kept in the internal layer. [Kathleen
Moriarty]: Good point Dan.  Thanks for bringing that up.  I think it is just
going to be the continuing trend of looking for places to obscure any type of
identifier so that privacy is more protected. [Dan Romascanu]: So probably the
observation is, as you are looking at your structure right now, don’t assume
there is a finite set of types or you may want to add something that is more
generic that is kind of anonymized MAC address because those things are already
starting to be deployed especially for privacy purposes. [Dave Waltermire]: Ok.
[Dan Romascanu]: Inviting Juan Carlos Zuniga and/or Donald Eastlake to one of
the design team meetings is a very good idea. [Dave Waltermire]: Ok. [Kathleen
Moriarty]: So, if other identifiers are in use, things that are coming through
are schemas or other information models for other areas within the IETF where
you have the option to put in the identifier, but, the optimal option is to
have it obscured or left out or generalized in some way so that it is not the
identifier that we have known in the past.  But, they are showing up in schemas
with privacy options included. [Dave Waltermire]: Ok. [Kathleen Moriarty]: So
on local network, the local network might decide it is fine with the use of
identifiers, but, they may not. [Dave Waltermire]: Right and I think this
further justifies our initial thoughts that we need some type of controlled
vocabulary approach because this situation is going to continue to evolve and
we may need to characterize different kinds of attributes and things will need
to be added dynamically to whatever models we end up developing.  So, it seems
to me a reasonable way to account for that.  Maybe something like an IANA
registry would benefit us. [Adam Montville]: Just a quick time check as we
still need to go through requirements. [Dave Waltermire]: I am happy to stop
here.  This has been a good discussion and we have some actions that we need to
take.  So, if we could defer further discussion to the list then we can get
started on requirements.
================================================
SACM Requirements (Nancy Cam-Winget)
================================================
[Nancy Cam-Winget]: So one logistical question that I have, and part of it is
that I just have not had time to play with GitHub, once I was responding to all
of the issues I couldn’t figure out how to go back and look at how to go back
and look at the threads that I had already responded to.  Do you know? [Adam
Montville]: I do not know, but, that is something that we will have to look at.
[Dan Romascanu]: This sounds like an Aziz question, but, he is not on the call
so send to the list and copy him to make sure he pays attention. [Nancy
Cam-Winget]: Ok, I will shoot him and Jim Schaad a message because the other
thing that I noted was that I thought part of the reason why we used GitHub and
I couldn’t figure out how to put the proposed changes of the actual draft text
in GitHub.  Those are logistic questions that would be good for the group to
know moving forward and I wanted to improve as I started addressing comments on
the Architecture draft and not being able to see when I respond to the issues
to the original messages.  Given that, I did post the updated draft version -05
so I don’t know how many on the call have had time to look at it since I posted
it not that long ago.  If you go onto the next slide Adam.  So, I received a
really good set of comments from both Jim Schaad, Chris Inacio, and some follow
up from Lisa Lorenzin as well.  So, if you guys can go in GitHub, you will see
all of the issues that Jim opened and then Chris basically sent a long list on
the SACM mailing list that I responded to so as far as I can tell all of them
but one is closed by Jim.  I haven’t heard back from Chris yet.  On to the next
slide, so there is one last editorial issue from Jim’s point of view, but, in
the process of going through all of the comments from Chris and Jim and follow
up from Lisa, I thought it would be good for us to review some of the bigger
ones that I required for the whole group to be aware of so the two biggest ones
that I put on this slide was that we had a long thread with respect to how many
information models are there and I couldn’t quite tell from the SACM mailing
list whether or not we reached consensus and that there would be one and only
one and the interpretation that I had taken from the charter and the thread and
the interpretation that I had been going along with is that the information
model is the abstract definition of the types of attributes and potentially the
types of operations as well to allow us to do the collection, guidance, and
evaluation of posture information by which that would provide the guidance by
which we could then instantiate one or more data models.  So, let me stop there
and see if there are any comments or questions on that one. [Henk Birkholz]:
One question from me is in some side comments I tried to be funny and was
answering that some operations may be part of the architecture.  I saw that you
were adopting that again and I wasn’t sure what the result of that was. [Nancy
Cam-Winget]: That’s why I am posting it here because if I didn’t make it clear
in the requirements I need to make that language stronger, but, in both the
requirements and architecture I have been going with the assumption that there
would be one and only one SACM information model, but, then there would be
proposal by the SACM group then accept and up to the group whether we say
applicability or standardize on one or more data models. [Dan Romascanu]: So, I
believe that we have had this discussion a couple of years ago and maybe some
of us have forgotten it and new people joined, but, we are using the
terminology that has been defined in RFC 3444 or something around it which is
about the information model and data models which kind of define the
information model as the abstract schema which tries to be protocol independent
and defines the semantics of the object while whatever goes on the wire and the
information model is instantiated by the data models which are language
specific.  Now, from a point of view of the architecture, the assumption that
we made is that we meant to define one information model because we want for
any given information element to have one definition to work with.  That’s why
we are creating consistent dictionary that is why we are working on one schema.
 Now, this may be the right instantiation on multiple data models and those
data models may be in some cases language specific, in some cases it may be
classes of applications, or they may be broken up.  Data models at the end of
the day such as Yang modules, SMI MIB modules, or schemas and you break them
into multiple models for reason of readability and modularity.  So, that is why
we took this approach and I am yet to understand what would be the problem with
this approach. [Dave Waltermire]: I have been kind of on the fence on this
topic which is why I haven’t dropped in on the conversation, but, one of the
things that came up on our Endpoint Identity Design Team discussions maybe a
month or two ago was a lot of discussion around capturing provenance
information around certain endpoint identifying attributes.  As an example, we
started looking at W3C work in that area and we recognized that it was a pretty
big space and it would take some time to develop some information model around
provenance and I think that is a really good example in this case.  Although
provenance is important to be able to characterize an endpoint identity and to
really make that identity really understandable and how it originated it may
not necessarily be at the core of the work that we are trying to do to enable
endpoint assessment.  I liked what you said on the list and that maybe what we
are looking at is an umbrella information model that may point to other
hierarchical information models that may address more specific concepts. [Dan
Romascanu]: Exactly.  So, for example, to take the example that you have just
given provenance is one dimension, but, it may not be the core dimension in
describing the identity or in other words you can work with a subset of objects
that do not necessarily reflect provenance or it may not apply to our classes. 
So, there is certainly a hierarchy and modeler approach, but, when I say on
information model, I am saying that we must not have multiple definitions for
the same concept. [Nancy Cam-Winget]: Yeah, I think you said it well initially
where the initial concept when we went through the clarification of information
versus data model.  I thought we went through the exercise of the clarifying it
and the information model is meant to be that abstraction that does provide the
semantic interpretation and meaning of the attributes.  So, I agree with you if
that is the case, which I thought it was, then there should only be one. 
Otherwise, we would get into confusion if we ended up with multiple meanings.
[Dan Romascanu]: That’s the case I believe. [Dave Waltermire]: I think in doing
that, we have to be very disciplined as to what we choose to do in detail about
in that information model within that abstraction versus what we leave as
future work.  I think there is risk that we indefinitely work on an information
model without making too much forward progress. [Dan Romascanu]: Yes. [Nancy
Cam-Winget]: I agree. [Ira McDonald]: It’s ok to extend an information model. 
For instance Dave, with modular work on provenance and it’s ok after doing a
data model, or two, or three.  Let’s be realistic.  To come back and say there
are fundamental operations or semantic attributes that we should add to the
information model that kind of recursion does normally occur in a work group
over a span of years, but, I think it is also important Dave to avoid
rat-holing on provenance for instance although we recognize its importance to
the validity and verification because otherwise we could spend the next two
years doing an information model while other people are doing private data
models which is not helping. [Dan Romascanu]: No.  I agree such a thing and I
am actually will say that even go one step further.  I think it is important as
we are writing our first generation of the information model to write if not in
parallel, immediately soon after.  At least one data model to verify the
assumptions implemented in real work using a data modeling language in order to
have a sense if what we defined at construct level works. [Dave Waltermire]: I
am in favor of doing that. [Nancy Cam-Winget]: So Dan and Adam, how do you want
me to proceed?  Jim pretty much said that based on the clarification he was
fine and he closed the issue, but, I still felt that I needed to open.  So, are
we ok then as a group?  Or, do you want to go back from the mailing list and
get consensus? [Dan Romascanu]: We haven’t got to our way forward slide, but, I
believe the milestones call for a WGLC in May so I would try to close as many
as possible for the open issues or be prepared to close them and reopen them at
last call.  That is why we have last call; so people may kind of jump against
the concepts or find themselves on the wrong side, but, they certainly do it
using last call.  People could participate in the discussion and they can also
join the discussion so I would go to closing the issue and being ready to
reopen it during last call. [Nancy Cam-Winget]: The good news is that Jim has
closed out that issue so I think we are clean.  The next one that I want to
bring up was raised kind of through different comments both by Jim and by Chris
in that in the architecture, we talk about the communication between the
broker, the controller, and the provider and the consumer that all of the
communication that go between them.  I think that I described them as
interfaces in the architecture draft.  In the requirements draft, I think there
were one or two places where, especially in the architecture, I called out the
interfaces, but, then I actually could have explicit sections for transport and
operations which seemed to be confusing to them one in part because we don’t
have these terms in the terminology draft and two I don’t know if we needed to
make and pose it to the group.  My interpretation of an interface is the way in
which two architectural components communicate and that communication means
transport to me which is that network layer transport and then would send that
network layer transport for transporting data and operating on the data. So,
that is where I make the distinction in the requirements and I have that
explicitly as one of the comments in the next couple of slides.  So, I wanted
to kick this back up to the group to get some general guidance.  And again, Jim
was fine with the clarifications that I made both through the responses and the
draft -05.  So for him, this should be closed, but, I thought I would raise it
up with the group as well. [Dan Romascanu]: My only question is that we have a
document right now, where would you find our meaning or definition of
transport?  Is it in the architecture draft or in the terminology? [Nancy
Cam-Winget]: It is not in the terminology.  So, since I am going to work on the
architecture draft next, I can make sure that it is clear there. [Dan
Romascanu]: Yeah, we should probably be clear because the risk here is that is
actually having somebody in the general area review, for drafts, getting a
working group last call and someone that is not as familiar encountering a
familiar term that is used in a non-familiar manner. [Nancy Cam-Winget]: Well,
right.  I was trying to stay consistent, from my view with my thinking, with
the IETF understanding of these terms.  You are absolutely right though.  I
need to go back and look at the architecture draft and make sure they have been
made clear. [Dan Romascanu]: Exactly. [Nancy Cam-Winget]: Let’s go on to the
specific issues.  I sprinkled a bunch of editor notes in draft -05 that I would
like to clean up and now that I know Jim is going to close out all of them
except for one, I can go ahead and close out some of the editor notes as well. 
So, specifically, there was some questions and I put some of the suggested
actions on the right column.  For the remaining issues that we kind of went
back and forth on and Lisa also provided some feedback, I don’t know that they
are major, but, I thought that it would be good for me to review them here.  If
I could go through them individually.  In Section 2, where we lay out the
potential tasks that applications could act as providers, consumers, or both
would have to go through.  The first task that we actually list is defining the
asset, but in essence, Jim kind of put a question as to whether this isn’t
really included as part of the definition of the information model and should
it be removed.  So, my suggested proposal is a couple of options is to remove
it and add in the introductory paragraph, prior to the enumerating the task,
that I make clear that the assets are defined in the composition of an asset. 
It is defined in the information model. [Ira McDonald]: I much prefer that
Nancy. [Nancy Cam-Winget]: Ok. [Ira McDonald]: Otherwise, I think we have a
constant tug between the information model and the architecture and the
requirements. [Nancy Cam-Winget]: Yeah, Jim is right in that it makes the tasks
seem to be more fluid. [Ira McDonald]: Yeah.  Right.  More dynamic. [Nancy
Cam-Winget]: Yes.  Ok.  Going once, going twice.  Alright, the second task is
to actually map the assets so Jim posed the question of should there be a
subtask to actually create that mapping and then thinking and reading the task
list again.  To me, it felt like that is what the task was about, to actually
create that mapping.  Given that he has closed the issue, it is too bad that
Jim is not here.  I am not sure that I need to do anything for this one, but,
if anyone has looked at it and has feedback, you should let me know. Going
once, going twice.  So, I think I will let this one be as well.  On the third
row, for the first general requirement, there is the paraphrase for the first
requirement which goes to the query language specification and we list what we
mean by the query language and then one of the phrases, we also note as well as
the expression of the specific tasks to follow which now includes for
inspection.  Jim noted that potentially from an IETF perspective means
routability.  So, he questioned whether or not that was really in scope for
SACM to sort out or not.  So, I don’t know.  I think this is something that the
group needs to agree on.  Again, he closed it, but, I think since he mentioned
it, I think I left the phrase still in the draft, but if it is in scope, then
we really need to put another requirement in the operation of the data to
ensure that routability is there.  Otherwise, I should just remove that phrase.
[Henk Birkholz]: Routability is not about layer 3, yes?  It is routability in
another context? [Nancy Cam-Winget]: It could be layer 3 or above. [Henk
Birkholz]: I think the expression of a specific path to follow is referring to
a graph model and that may be the context of the expression and I am not really
sure it is about routing. [Ira McDonald]: But, as it is written, routability is
inherently ambiguous.  Nancy, I suggest, and others should chime in, that
routing paths and the internal behavior of routers and forwarding metal boxes
is right out of scope for SACM.  We have got NETCONF and Border Gateway
Protocol, and all kinds of protocols for configuring routers. [Nancy
Cam-Winget]: Ira, my personal opinion is that not only that I agree with that,
but, Henk to your point of how we traverse information, should be out of scope
that perhaps that has played on the specific data model and how they choose to
implement their own traversal schemes. [Henk Birkholz]: Ok, I just wanted to
make sure that this is really about routing. [Nancy Cam-Winget]: Yeah. [Dan
Romascanu]: It is more about transport to be precise, but yes, your observation
is usually part of the protocol.  For example, NETCONF, in order to be capable
to ensure each ability of a service that may be placed behind a firewall
implemented something that is like a mechanism which can be added later into
some base protocol. [Nancy Cam-Winget]: Dan, to me, that seems specific to the
data model and operations on the data model. [Dan Romascanu]: It is specific to
the protocol that carries the data model, yes?  Some protocols mix the two with
the data model within the protocol.  Some others actually separate, for
modularity, the data model from the protocol itself.  In practice, because the
Yang data model right now is supported by NETCONF, but, there is a light
version which is designed for RESTful entities.  It will be like two protocols
that can work with the same data modeling language and the same set of data
models because of the modular design that has been the approach from the start.
[Nancy Cam-Winget]: In the interest of time, I am going to give myself to the
end of the day or maybe tomorrow to get a draft -06 out.  To clarify, some of
these and hopefully that draft, Dan and Adam, should be ready for last call,
but, it is up to you guys.  I will try and take a stab at either removing it or
clarifying the intent behind that phrase.  Alright? [Dan Romascanu]: Right and
you know it is only the first working group last call so you should assume that
you may not reach the perfect document in the first round. [Nancy Cam-Winget]:
I am guaranteed to get lots of feedback right because we are going to go
through a lot of review. [Dan Romascanu]: So, if you can get it by the end of
the week or the beginning of the next week, version -06, then we will make a
sanity check Adam and myself and if it is sane enough we will send it to
working group last call. [Nancy Cam-Winget]: Sounds good. Ok, in the interest
of time, let me accelerate if I can.  So, there were questions and I tend to
agree with Jim that I mean a lot of the drafts that we put out in the IETF
presume that we are defining enough specificity to ensure interoperability. 
So, he put into question whether we really needed to make this an explicit
requirement or not.  This was G-002 and we have gone back and forth, Lisa has
asked to keep it so I have kept it for now and then, in the interest of time,
unless I hear others we can go to last call and I can keep it in there for now.
 On the next row, G-006, we seek data integrity, but in the description, I only
speak of it in terms of the transport and again transport to me meant that the
network layer transport and again Dan that goes to your point there are some
instances in which they decouple the data protocol from data transport and
network transport so the question is whether we need to do something.  So, I
may defer this until we get more comments and again because I am giving myself
the pass since Jim has already closed this, but, we can leave this open as we
go into the next version. [Ira McDonald]: A quick comment.  I don’t know what
the word is, but, I suggest that we need a word, not transport, because to
other IETF participants that means the whole stack below the application layer
operation whether it is a fat stack running on top of HTTP or a thin stack
running at layer 2 or layer 3 and that is it.  The operations go right there,
they are transported operations and in either case we don’t really care.  We
mean everything below the application operation; the SACM operation. [Nancy
Cam-Winget]: I will try to find a better way to clarify it. [Ira McDonald]: I
don’t have any idea on a different word to use besides transport, but, we
wrestle with this problem in TCG regularly. [Nancy Cam-Winget]: Ok. [Henk
Birkholz]: One could use the word extradition somehow because components
acquire data from other SACM components in order to build a chain in a process
and maybe something in that area could be applicable. [Nancy Cam-Winget]: I
didn’t quite understand Henk, are you suggesting that we say anything post
acquisition? [Henk Birkholz]: It’s an extradition procedure or either is it
requested by another component or it is initiated by guidance.  Effectively,
components acquire relevant data from other SACM components.  I think transport
is what everybody is talking about here. This extradition process should be
data integrity ensured. [Nancy Cam-Winget]: I am not sure that I quite
understand that.  There are protocols and the protocols can be layered on the
network transport or they could be intertwined right?  So, if they are
decoupled then the question is: is it sufficient that the protocol rely on the
network transport integrity only?  Or, do you want to impose that if the
protocol is separate from the network layer transport that is being allowed to
have an integrity security mechanisms in there as well?  So, I will try to
noodle over this and I notice that I only have five minutes left, but, I just
wanted to go through this table and let the group know that these were the last
ones that I thought and I am trying to raise to the group, but, I will try to
work on the clarification for some of the suggestions for the next draft and
then you guys can take a closer scrutiny and comment in the next revision.  So,
let me go to the next one, G-009 and G-010.  G-009 speaks to the general
discovery and the intent there is the description of that discovery is
referring to the discovery of the specific component, architectural component,
that a consumer, data broker, or the control plane and capabilities within the
endpoint as an endpoint could be playing multiple SACM components if you will. 
G-010 speaks to the discovery of the actual target endpoint so the quickest for
me to do now is to clarify G-010 to say target endpoint instead of just
endpoint.  In the question that Jim posed was that requirement should be a
subset of G-009 and I think for now I may just leave them as separate so that I
don’t have to battle the requirement numbering and so on.  G-012, we already
spoke to interface versus transport versus data operations and protocol.  I
will work on that one as well.  The question is whether or not we need to
include it.  I will make sure that we have those clarifications in the
architecture.  The question to the group is whether we should also include this
in the terminology draft.  Next slide please.  The last two.  In Section 2.4,
DM-010.  I think some of this data model definitions and operations which is
already described in the information model in the first requirement of the
information model and I recall that I was asked to make them explicitly because
the information model speaks to it abstractly and the data model speaks to the
actual instantiation and use of that data model.  For now, I left it and in a
future draft it would be great to get feedback as to whether or not you really
care about removing it or not.  Jim was fine with my response so I am going to
let it be.  Then, in Section 2.6, which is the whole of the transport layer
section, when I wrote the description of the requirement was to speak to the
network layer so I need more feedback.  I will work on the clarification that
the intent was for the network transport and not necessarily inclusive to the
data transport as the data transport and protocol has its own section which I
titled operations on the data model.  Those were the remaining notes.  Dan, my
intent was to remove all of the editor notes for the next draft presuming that
those editor notes ended to be removed so that we could go to the working group
last call. [Dan Romascanu]: The editor notes may be removed and you may want to
include something like changes from -05 to -06 where basically you describe the
principal changes where the issues were addressed.  That is how you keep track
of the history and the end of the process meaning before submission to the IESG
and in any case before publication will be removed. [Nancy Cam-Winget]: Ok.
[Dan Romascanu]: We don’t need the editor note history in the document any
longer.  Adam, would you go through the way forward? [Adam Montville]: Yes, we
can do that now. [Dan Romascanu]: The main question is basically future
meetings and we should probably have another interim meeting five or six weeks
from now is something that would be useful.  If we go to WGLC, which will be in
something like three weeks, will you be able to address the last call comments.
[Nancy Cam-Winget]: I will be able to work over email, but, I am flipping too
many time zones between now and then. [Dan Romascanu]: What about 6/24 or 6/25?
[Nancy Cam-Winget]: I don’t know yet.  I am trying to firm up where I will be
that week. [Dan Romascanu]: I believe the submission deadline for IETF 93 is
July 6th so what about Monday 6/29 or Tuesday 6/30? [Nancy Cam-Winget]: That’s
good for me as well. [Adam Montville]: That is all good with me. [Dan
Romascanu]: For IETF 93, I have asked for two meetings like we did at the last
IETF meeting.  Please be prepared for a Monday morning or Tuesday morning
session and a Wednesday second session.  Plan your trips accordingly.  I will
send an email for a call for comments for the two submissions that we discussed
at the beginning of the call and of course we will hopefully have material to
discuss at the interim meetings. [Adam Montville]: Great. [Dan Romascanu]: The
Endpoint Identity Design Team meeting every Friday right. [Adam Montville]:
Yes, until we don’t need to meet anymore.  Then, we can meet about something
else. [Dan Romascanu]: Ok.  Thank you everyone. [Adam Montville]: That
concludes the meeting.  Thanks everyone.