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

From: "Sanchez, Mauricio" <[email-masked]>
Date: Wed, 8 Mar 2006 09:37:06 -0800

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..." 
 
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.  
 
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?
 
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?
 
Section 5.2
Second paragraph: Do you mean 802.11i?  
 
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?   
 
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.
 
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.
 
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.
 
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?  
 
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?
 
Cheers,
MS

________________________________

	From: Susan Thomson (sethomso) [mailto:[email-masked]] 
	Sent: Saturday, March 04, 2006 12:47 PM
	To: [email-masked]
	Subject: [Nea] Updated problem statement I-D

	I have sent the updated problem statement I-D to the IETF
secretariat for publication. In the meantime, have attached the document
for your review.
	 
	The I-D has been updated to be  consistent with the proposed WG
charter and to take into account  comments received on the mailing list.
(The proposed charter will need to be tweaked to reflect new names for
some of the interfaces). 
	 
	Main Changes:
	
	--- Terminology changed to that suggested by Mauricio Sanchez in
his comments to mailing list
	--- Emphasized throughout that focus not on new architecture,
but interoperability 
	--- Put an explicit stake in the ground that the initial focus
is on an EAP/Radius instantiation of an NEA architecture
	--- Identified the 2 EAP protocols at IF-PT layer as IF-PTT (EAP
tunneling method) and IF-PTC (EAP carrier protocol). 
	--- For convenience, mapped NEA terminology with that used in 3
existing architectures: TNC, NAP, NAC
	--- References added 
	 
	Feedback appreciated, especially where there may be lack of
clarity or disagreement that may preclude a successful BoF. Better to
air these on the mailing list now so that we can attempt to address them
prior to the BoF.
	 
	Thanks
	Steve & Susan

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

---

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Mon, 13 Mar 2006 22:42:27 -0500

Hi Mauricio

Inline ...

From: Sanchez, Mauricio [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 12:37 PM
To: Susan Thomson (sethomso); [email-masked]
Cc: Steve Hanna
Subject: RE: [Nea] Updated problem statement I-D - My comments

Section 1

[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

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

Section 4

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

[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

[Susan] Yes.

Section 6.2.1.2

[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

[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

[Susan] NAC is one example of such an architecture. Agree that rewording
is required.

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

[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

[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