RE: [Nea] Updated problem statement I-D - My comments

["Susan Thomson \(sethomso\)" <sethomso at cisco.com>]

Hi Mauricio

Inline ...
________________________________

From: Sanchez, Mauricio [mailto:mauricio.sanchez at hp.com] 
Sent: Wednesday, March 08, 2006 12:37 PM
To: Susan Thomson (sethomso); nea at ietf.org
Cc: Steve Hanna
Subject: RE: [Nea] Updated problem statement I-D - My comments


Nice progress.  Here's some comments/questions on this version:
 
Section 1
First paragraph: "These architectures are not fully interoperable..."
When I read this sentence it first struck me as meaning that a given
architecture (e.g. TNC, NAP, NAC) is not interoperable with itself.
Moreover, "fully" signals there may be some existing interoperability,
which I doubt there is.   May want to consider changing to "Components
from these architectures cannot be intermixed..." 

[Susan] Yes, will change to something like "components from different
architectures are  not interoperable because not all required protocols
are standards" or some such. The reason for the "fully" is because, to
the extent that 802.1x and RADIUS are standards, there is some
interoperability today.
 
Section 3
Second paragraph: "Remediation instructions or warnings may be sent to
the endpoint."  Is "remediation" within scope of NEA?  Consider defining
remediation in terminology section, since remediation means different
things to different people.  

[Susan] Remediation itself is not part of NEA, but information about
posture status and remediations steps (e.g. URL of remediation server to
contact) can take place at the PA layer and possibly at PB layer.
Remediation steps are typically specific to the application being
validated and will be part of PA layer. The PA leyer is not part of
initial scope of NEA charter as currently proposed, though. User
notifications and warnings may be done at the PB layer based on the
overall posture result, and since the PB layer is in scope, so is this.
 
Fifth paragraph: "...,these architectures are still not fully
interoperable because..."  Same as first comment.

Section 4
How are the third and fourth goals different from one another?

[Susan]The third says NEA can happen at a L2 or L3 hop. The fourth says
it could happen at multiple hops on a path. (If one supports L3 hops,
one cannot preclude a deployment scenario where NEA is enabled in
multiple places on a path.)
 
Last goal:  Is assessment without a client within scope of NEA?  It's a
good goal, but unsure whether we'd be able to make substantive progress
on a "clientless" solution?

[Susan] When I included this, I had something specific in mind, but
don't recall what it is now. Probably was not thinking clearly, so I'll
plan to take it out.
 
Section 5.2
Second paragraph: Do you mean 802.11i?  

[Susan] Yes.
 
Table 1: Nice table.  It's going to be my cheat-cheat until I learn all
28 terms.

 
Section 6.2.1.2
May there be more the one client broker?   

[Susan] Could be, although from NEA point of view, not sure that it
matters given the interface between client broker and Network access
requestor is not in scope.
 
Section 6.2.1.3
For the case there are multiple network access requestors, is there one
associated client broker.  What is the relationship?  May want to
consider updating figure 1 to show that there may be multiple NAR's (and
perhaps client brokers) as has been done with the posture collectors.

[Susan] The assumption is one client broker per Network access
requestor. Likely to be same client broker for multiple Network access
requestors.
 
Section 6.2.3.3
First paragraph: Which architectures don't have posture validators
co-located with the NEA server?  Moreover, is the NEA server not but a
logical concept?  If it is, then this statement is misleading since the
posture validator will always be part of the logical NEA server.  I
think what you mean is that the posture validators are some instances
not co-located with the NAA and server broker.

[Susan] NAC is one example of such an architecture. Agree that rewording
is required.
 
Third responsibility: Is the posture collector really responsible for
taking "remediation" actions?  The description for posture collector in
6.2.1.1 does not mention "remediation" as part of its repertoire.

[Susan] An example of "information on remediation actions" (this could
be better worded) may be to send the URL of the remediation server to
the posture collector. Section 6.2.1.1 does have text about receiving
such a thing.
 
Section 6.3.1
Typo on title: Posture Attribute Interface not Posture Attribute
interface
 
Section 6.3.3
May want to consider showing an updated Diagram 1 to visually show the
relationship of these two new sub-interfaces to the rest of the NEA
architecture.  Any reason these are not part of the base NEA
description?  

[Susan] Agreed that this should be made explicit. Probably another
figure is required, the idea being to have the general picture that does
not assume an underlying EAP framework to allow for other possible
"instantiations" of the architecture in the future, along with a figure
that is more specific to the EAP framework.
 
Section 7
Seventh standardization goal:  Can you elaborate in which instances
IF-PV may not fall within IETF's domain?  How are we going to decide
this one?  If it's not going to fall into IETF (i.e. NEA) why even
bother describing it?

[Susan] Depending on what technology is used, it could be OASIS, for
example. There is no pre-judgement here. Once we have made progress on
the other protocols in the initial charter, we can revisit including
this interface in NEA as part of revising the charter scope at the end
of the year. 

[Susan] Thanks for the comments. Assuming the BOF is successful, this
doc in its current form will likely die, with those sections deemed
useful pulled into a requirements I-D and more detail added sufficient
for a requirements spec.

Susan
 
Cheers,
MS
 
 
 
 

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea