Subject: RE: [Nea] NEA "problem statement" I-D submitted

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 16 Jan 2006 01:03:56 -0800

Hi Susan, All

Here is my feedback on the problem statement draft that you guys
submitted...

Overall I think the draft is very well written, describes the problem,
scope and terminology very well. Great job done by the authors!

Few comments...

The introduction states that NEA would 'optionally' influence network
admission decision...why is this optional?

The use of the term "state" for describing posture in the Introduction
section confuses me a bit...need to qualify this further since state
means many things to many people

Figure 1 could be drawn in a better fashion showing multiple plugins
interacting with the brokers, etc... to be more insync with what the
text describes. I'll be happy to provide a more detailed picture if you
like

I don't completely agree with 6.3.5 and 7. I feel like some of the
interfaces such as the one between the server broker and server plugins
should not be out of scope of this WG...this is an important interface
for end-to-end interoperability and should be left within the scope of
standardization

Need to add more references. Lots of references such as EAP, etc missing

----

I feel like now is a good time to start discussion on BoF scope and
goals. Let me know what you guys think,

Thanks

Hormuzd

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Susan Thomson (sethomso)
Sent: Wednesday, December 21, 2005 7:24 AM
To: [email-masked]
Cc: Steve Hanna; Thomas Hardjono
Subject: [Nea] NEA "problem statement" I-D submitted

Folks

This is a heads-up that a first draft of the  co-authored "problem
statement" I-D  for "network endpoint assessment" has been sent to the
secretariat for publication
(draft-thomson-nea-problem-statement-00.txt).

The intent of the draft is to help us reach a common understanding of
terms and model, and facilitate a discussion for identifying and
prioritizing interfaces that may be candidates for standardization in
the IETF.

Input from this discussion will be used to revise the document and scope
a BOF on this topic currently targeted for the Spring meeting.

We would appreciate your feedback as soon as possible as BOF preparation
timelines are fast approaching. (Please note I'll be out of the office
and out of email contact from today till Jan 9, but Steve Hanna and
Thomas Hardjono will be around. Steve is looking into posting the draft
on a public site as well in the interim.).

Thanks

Susan (and Steve and Thomas)

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Wed, 18 Jan 2006 10:44:19 -0500

Hi Hormuzd
 
Thanks for your review.
 
Responses inline ...

	From: Khosravi, Hormuzd M [mailto:[email-masked]] 
	Sent: Monday, January 16, 2006 4:04 AM
	To: Susan Thomson (sethomso); [email-masked]
	Cc: Steve Hanna; Thomas Hardjono
	Subject: RE: [Nea] NEA "problem statement" I-D submitted

	Hi Susan, All

	Overall I think the draft is very well written, describes the
problem, scope and terminology very well. Great job done by the authors!

	Few comments...

	The introduction states that NEA would 'optionally' influence
network admission decision...why is this optional?
	[Susan] Its possible that users will deploy this technology in
order to monitor compliance to security policy, rather than enforce it.
This may happen on initial roll-out, in certain critical areas of the
network, etc. 

	The use of the term "state" for describing posture in the
Introduction section confuses me a bit...need to qualify this further
since state means many things to many people
	[Susan] Will try to clarify. 

	Figure 1 could be drawn in a better fashion showing multiple
plugins interacting with the brokers, etc... to be more insync with what
the text describes. I'll be happy to provide a more detailed picture if
you like
	[Susan] OK. I can send you source for this separately so that
you can make proposed updates. 

	I don't completely agree with 6.3.5 and 7. I feel like some of
the interfaces such as the one between the server broker and server
plugins should not be out of scope of this WG...this is an important
interface for end-to-end interoperability and should be left within the
scope of standardization
	[Susan] You refer to the interface between the "server broker
and server plugin". Do you mean the interface between server broker and
posture server, or something else?

	I think there are two separate questions here: 1) whether these
interfaces are candidates for standardization, and 2) whether the IETF
is the place to do the standardization. For the purposes of this
discussion, we are obviously interested in 2).  To the extent these
interfaces are APIs, this likely does not fall within the IETF. To the
extent the interfaces are protocols (and this is the case where posture
server is not co-located), then this is a candidate for standardization,
although this may still be pushing the boundaries of what the IETF has
traditionally been involved in. This is something that needs to be
discussed further.

	 Need to add more references. Lots of references such as  EAP,
etc missing
	[Susan] Yes. The doc was sent out in somewhat incomplete form to
get review as soon as possible. The intent is to update the document
before the next IETF.

	----

	I feel like now is a good time to start discussion on BoF scope
and goals. Let me know what you guys think,
	[Susan] We need to start defining the BOF, since the cutoff date
for a BOF request is 2/13, so will work on getting a draft proposal on
the table. However, it is still important to get as much document
feedback on the table asap, which will inform this charter.

	Thanks 

	Susan

	Thanks

	Hormuzd

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Susan Thomson (sethomso)
	Sent: Wednesday, December 21, 2005 7:24 AM
	To: [email-masked]
	Cc: Steve Hanna; Thomas Hardjono
	Subject: [Nea] NEA "problem statement" I-D submitted

	Folks

	This is a heads-up that a first draft of the  co-authored
"problem statement" I-D  for "network endpoint assessment" has been sent
to the secretariat for publication
(draft-thomson-nea-problem-statement-00.txt).

	The intent of the draft is to help us reach a common
understanding of terms and model, and facilitate a discussion for
identifying and prioritizing interfaces that may be candidates for
standardization in the IETF.

	Input from this discussion will be used to revise the document
and scope a BOF on this topic currently targeted for the Spring meeting.

	We would appreciate your feedback as soon as possible as BOF
preparation timelines are fast approaching. (Please note I'll be out of
the office and out of email contact from today till Jan 9, but Steve
Hanna and Thomas Hardjono will be around. Steve is looking into posting
the draft on a public site as well in the interim.).

	Thanks

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 19 Jan 2006 17:29:19 -0800

Hi Susan
 
Yes I mean server broker & posture server. I agree that APIs don't fall
within IETF standardization scope, however in this particular scenario,
these entities are usually not co-located and protocols are used here.
Therefore, I feel this should be something that is pursued by this
working group, if we want to build interoperable solutions.
 
Thanks
Hormuzd

From: Susan Thomson (sethomso) [mailto:[email-masked]] 

	 

	Thanks 

	Susan

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 20 Jan 2006 08:37:33 -0500

I want to correct one statement here. API in general don't fall within
IETF scope - HOWEVER there are some notable exceptions. Best-known
example is GSS-API.
 
I second the opinion that interfaces are candidates as well, not just
the protocols.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Khosravi, Hormuzd M
	Sent: Friday, January 20, 2006 3:29 AM
	To: Susan Thomson (sethomso); [email-masked]
	Cc: Steve Hanna; Thomas Hardjono
	Subject: RE: [Nea] NEA "problem statement" I-D submitted

	Hi Susan
	 
	Yes I mean server broker & posture server. I agree that APIs
don't fall within IETF standardization scope, however in this particular
scenario, these entities are usually not co-located and protocols are
used here. Therefore, I feel this should be something that is pursued by
this working group, if we want to build interoperable solutions.
	 
	Thanks
	Hormuzd

		I don't completely agree with 6.3.5 and 7. I feel like
some of the interfaces such as the one between the server broker and
server plugins should not be out of scope of this WG...this is an
important interface for end-to-end interoperability and should be left
within the scope of standardization
		[Susan] You refer to the interface between the "server
broker and server plugin". Do you mean the interface between server
broker and posture server, or something else?

		I think there are two separate questions here: 1)
whether these interfaces are candidates for standardization, and 2)
whether the IETF is the place to do the standardization. For the
purposes of this discussion, we are obviously interested in 2).  To the
extent these interfaces are APIs, this likely does not fall within the
IETF. To the extent the interfaces are protocols (and this is the case
where posture server is not co-located), then this is a candidate for
standardization, although this may still be pushing the boundaries of
what the IETF has traditionally been involved in. This is something that
needs to be discussed further.

		Thanks 

		Susan