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

From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Date: Tue, 31 Jan 2006 08:07:42 -0800

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. 
 
-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)?
 
- 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. 
 
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: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Tue, 31 Jan 2006 12:32:49 -0500

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

	-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:
		 
		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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 31 Jan 2006 13:55:12 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Susan Thomson (sethomso)
Sent: Tuesday, January 31, 2006 12:33 PM
To: Sanchez, Mauricio (PNB Roseville); [email-masked]
Cc: Steve Hanna
Subject: RE: [Nea] Draft NEA WG charter: Please review

		 
		Good beginning...

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

			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:
			 
			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

---

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Tue, 31 Jan 2006 17:50:05 -0500

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Blumenthal, Uri
	Sent: Tuesday, January 31, 2006 1:55 PM
	To: [email-masked]
	Subject: RE: [Nea] Draft NEA WG charter: Please review

	Sue,  do you expect that the protocol (IF-PT) would be different
depending on what carrier it's traveling over?
	[Susan] 
	When you say IF-PT do you mean the EAP method layer (e.g. an EAP
tunneling method), versus the EAP underlying transport (e.g. 802.1x)? If
this is your question, my answer is no. But I'm not sure this is your
question!
	 
	I get the feeling we are stumbling over terminology again here.
Please clarify.
	Thanks
	Sue
	 
	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.

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

			Good beginning...

			-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)?

			- 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