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

["Sanchez, Mauricio" <mauricio.sanchez at hp.com>]

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:sethomso at cisco.com]
Sent: Saturday, March 04, 2006 12:47 PM
To: nea at ietf.org
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
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea