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?
[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:
nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Susan Thomson
(sethomso)
Sent: Wednesday,
December 21, 2005 7:24 AM
To:
nea at ietf.org
Cc: Steve Hanna;
Thomas Hardjono
Subject:
[Nea] NEA "problem statement" I-D submitted
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.).
Susan (and Steve and
Thomas)
