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

From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Date: Tue, 31 Jan 2006 09:55:53 -0800

Okay...sounds like there are appropriate plans in place.
 
MS

________________________________

	From: Susan Thomson (sethomso) [mailto:[email-masked]] 
	Sent: Tuesday, January 31, 2006 9:33 AM
	To: Sanchez, Mauricio (PNB Roseville); [email-masked]
	Cc: Steve Hanna
	Subject: RE: [Nea] Draft NEA WG charter: Please review

	Thanks for the quick turnaround. Inline ...

________________________________

		From: Sanchez, Mauricio (PNB Roseville)
[mailto:[email-masked]] 
		Sent: Tuesday, January 31, 2006 11:08 AM
		To: Susan Thomson (sethomso); [email-masked]
		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: [email-masked]
[mailto:[email-masked]] On Behalf Of Susan Thomson (sethomso)
			Sent: Tuesday, January 31, 2006 7:26 AM
			To: [email-masked]
			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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 31 Jan 2006 17:24:25 -0500

I also think this is a good starting point.  I tend to agree with  
Mauricio that it would be good to group the two IF-PT items or  
perhaps call them IF-PTa and IF-PTb.

Regardless what you decide about this I think the proposed charter is  
excellent, and I assume can be refined a bit based on the BOF  
discussions.

I am looking forward to working on this

John

On Jan 31, 2006, at 12:55 PM, Sanchez, Mauricio (PNB Roseville) wrote:

> -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  
> [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  
> 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: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Susan Thomson (sethomso)
> 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  
> 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):
>
> 2. IF-PT (EAP method suitable for carrying posture information as  
> well as supporting authentication)
> 4. IF-NAE (Radius attributes for network access enforcement)
>
> Other interfaces  that may be included in the charter at a later  
> date include:
> --- 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 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)
> * 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