RE: [Nea] Draft NEA WG charter: Please review

["Blumenthal, Uri" <uri.blumenthal at intel.com>]

Sue,  do you expect that the protocol (IF-PT) would be different depending on what carrier it's traveling over?

 

I won't want to upset the apple cart, so no objections for it going to BOF as is. But for the WG - perhaps we should reconsider.

 

Regarding the dates - I see Mauricio's point, but again - there's less of a problem completing before the specified date than dragging past it. Let's keep the milestones as they are.

 

 

---

From: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Susan Thomson (sethomso)
Sent: Tuesday, January 31, 2006 12:33 PM
To: Sanchez, Mauricio (PNB Roseville); nea at ietf.org
Cc: Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please review

Thanks for the quick turnaround. Inline ...

---

From: Sanchez, Mauricio (PNB Roseville) [mailto:mauricio.sanchez at hp.com]
Sent: Tuesday, January 31, 2006 11:08 AM
To: Susan Thomson (sethomso); nea at ietf.org
Cc: Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please review

 

Good beginning...

 

Couple comments/questions:

 

-How do protocols #2 and #3 differ if both are called out as being IF-PT.  May lead to confusion.  We may want to consider just calling out IF-PT once and placing various requirements that the single protocol must meet rather than breaking them out to seem like they're two protocols.

[Susan] Yes, the fact that this may lead to confusion crossed my mind as well. The current definition of IF-PT in problem statement I-D is quite general, the intent being (I believe) to cover a broad range of underlying technologies.

 

But in the case of the EAP infrastructure (which is the scope we are talking about here), it covers a number of different protocol layers: EAP method e.g. some EAP tunneling method, EAP protocol itself, and EAP transport e.g. 802.1x, some flavor of EAP over IP. These are all separable protocols, addressed in various working groups both inside and outside the IETF. So we do need to separate out the protocols  and their requirements. However, we may want to re-think the naming scheme.

 

I would propose that we leave this as is for the initial BOF request on Friday so that it is consistent with the naming used  in -00 version of the problem-statement I-D. We can revisit this in the -01 version and then update the charter to match.

 

 

-What is the rationale behind the selected milestone dates? In other words, why did you pick those dates and not others (perhaps by being more aggressive and pulling them in)?

[Susan]  There is always a tension between being aggressive and being realistic! I think this WG may be somewhat more challenging than normal given its broad scope and the need for cross-area, cross-WG collaboration. As it stands, the milestones only give us 2 IETF meetings to wrap up all the requirements in the intial scope assuming this BOF is successful in March. If we can complete before then, great. But I would not bank on it.

 

- Why would December 2006's milestone not be done in conjunction with the prior two milestones?  Waiting until 12/2006 to get the ball rolling on protocols seems like a long wait.

[Susan]  So the intent was not that we need to wait till then for any protocol work to proceed, but rather this is an official checkpoint with ADs of where we think we are in terms of doing any necessary re-chartering or other planning based on the requirements specified. In fact, there is some protocol work already underway e.g. Radius attribute definition in Radext WG, and the start of standardizing EAP methods in the EMU WG. The NEA WG would indeed need to be reviewing related work in other WGs while the requirements are being drawn up, to provide any heads-up and course corrections as soon as possible.

 

Hope this makes sense.

Thanks

Susan

 

Cheers,

MS

---

From: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Susan Thomson (sethomso)
Sent: Tuesday, January 31, 2006 7:26 AM
To: nea at ietf.org
Cc: Steve Hanna
Subject: [Nea] Draft NEA WG charter: Please review

Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards.

 

The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one).

 

The scope of the initial charter is on the following protocols that support architectures for network endpoint assessment (as described in draft-thomson-nea-problem-statement-00.txt):

 

1. IF-PB (posture broker protocol)

2. IF-PT (EAP method suitable for carrying posture information as well as supporting authentication)

3. IF-PT (EAP over IP transport protocol)

4. IF-NAE (Radius attributes for network access enforcement)

 

Other interfaces  that may be included in the charter at a later date include:

--- IF-PA (posture attribute protocol)

--- IF-SB (Protocol between server broker and posture server. Name of interface TBD in problem-statement I-D. )

 

Note that the initial scope of the WG targets architectures that use the EAP/Radius framework for IF-PT (posture transport interface) and IF-NAE (network access enforcement interface). This does not preclude the standardization of other posture transport protocols or network authorization protocols in the future, but this is not part of the initial charter.

 

Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible ADs to identify the appropriate WG for meeting these requirements.

 

Milestones:

 

June 2006:

* Submit requirements I-D to IETF  including 

--- requirements for IF-PT (EAP method layer)

--- requirements for IF-NAE

 

September 2006:

* Submit revised requirements I-D to IETF that includes above plus:

--- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP, EAP over TLS)

--- requirements for IF-PB

 

December 2006:

* Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met.

 

Feb 2007:

* Submit  requirements I-D to IESG for publication as Info RFC

* Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB

* Submit I-D on  protocols to be defined in this WG e.g. IF-PB specification

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