Subject: RE: [Nea] REQ: section 6 comments

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 5 Mar 2007 05:54:31 -0000

Paul wrote...

> 
> One of the goals of the spec was to broadly describe the problem space
> in the use case (examples.)  We carefully allocated different aspects
> of
> the problem space to each of the 5 use case areas.  We recognized that
> the 1st use case was pretty complex (but is likely a well understood
> scenario) so you'll note step 14 doesn't go into the re-assessment
> details.  If we separated out the remediation it wouldn't make this
> much
> simpler (removes steps 14-16 only.)

Given that re-assessment appears to be covered by other use case examples,
the design team may want to consider stripping out 14-16 out.  As you point
out, the use case is already complex as it is. 

> > 2.	 Section 6.1.1.2 - I don't believe step 14 is true.
> > After the OS
> > Patch validator signals success it's highly unlikely the user
> > will physically re-connect to the network to get a
> > re-assessment started.  I suspect the NEA components have
> > some facility to request global re-assessment, right?
> 
> Correct, we'll try to fix the wording.  Note however that step 1
> doesn't
> mention booting or user interaction just that: "The IT employee's
> desktop computer connects to the network...".  If it helps we could
> address this comment.

Ok.  I await the new wording. 

> > 3.	Section 6.1.1.3 - Not sure what this section is trying
> > to say.  This
> > section does highlight some characteristics of the example
> > scenario, but I don't see how this translates into impact on
> > requirements.  Consider adding additional discussion to clarify.
> 
> Ok.  These are "different aspects of the problem space" mentioned above
> that could impact the requirement definitions.  Some text to explain
> this would be helpful.

Agree.

> 
> >
> > 4.	Section 6.1.2 - What is meant by network service?  Isn't the
> > scenario described by section 6.1.1 essentially also an
> > example of a request for a network service?  Please
> > compare/contrast somewhere initial network connect and
> > request for network service.
> 
> I presume the example given in 6.1.2 wasn't sufficent (detailed
> enough)?
> One could imagine this being a request to a protected service like the
> Financial Portal server which contains very sensitive and mission
> critical data.  We used the example of VPN to show an L3 (instead of
> L7)
> service request but as you mention this smells similar to the L2
> initial
> network connect example.  We could switch it if others feel this is
> important.

Having clearly differentiated use cases and adjoining examples is extremely
desirable.  

> > 5.	Section 6.1.2.1 - This example triggered in my mind a
> > new derivative
> > use case.  Namely, what about a use case that involves the
> > need to pass multiple [concurrent] assessments?  For example,
> > what if I'm a guest at a company that provides guest LAN
> > network connectivity as long as I pass muster via NEA.  What
> > if then I desire to connect back via VPN to my company's
> > network that also requires passing security muster via NEA.
> > This seems like a realistic and probable use case.  Would NEA
> > protocols support this?
> 
> Certainly more complicated and I'm not sure this introduces an aspect
> of
> the problem space that we didn't already cover.  I presume this would
> just be 2 independent assessments without knowledge of each other (?).

Hypothetically speaking, if on describes use case A and use case B, does
this mean that use case A+B is automatically supported?  I would say that
it's not automatic in most cases. You make the valid point that in the (A+B)
case that I postulate there's a need to have 2 independent assessments with
knowledge of each other.  In which of the existing use cases does this
requirement get covered?

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 5 Mar 2007 21:16:47 -0800

Comments below... 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, March 04, 2007 9:55 PM
> To: Paul Sangster; [email-masked]
> Subject: RE: [Nea] REQ: section 6 comments
> 
> Paul wrote...
> 
> > 
> > of the problem space to each of the 5 use case areas.  We 
> recognized 
> > that the 1st use case was pretty complex (but is likely a well 
> > understood
> > much simpler (removes steps 14-16 only.)
> 
> Given that re-assessment appears to be covered by other use 
> case examples, the design team may want to consider stripping 
> out 14-16 out.  As you point out, the use case is already 
> complex as it is. 

We'll discuss this.

> > > Patch validator signals success it's highly unlikely the 
> user will 
> > > physically re-connect to the network to get a 
> re-assessment started.  
> > > I suspect the NEA components have some facility to request global 
> > > re-assessment, right?
> > 
> > doesn't mention booting or user interaction just that: "The IT 
> > employee's desktop computer connects to the network...".  
> If it helps 
> > we could address this comment.
> 

Its in -01

> > > section does highlight some characteristics of the 
> example scenario, 
> > > but I don't see how this translates into impact on requirements.  
> > > Consider adding additional discussion to clarify.
> > 
> > Ok.  These are "different aspects of the problem space" mentioned 
> > above that could impact the requirement definitions.  Some text to 
> > explain this would be helpful.
> 
> Agree.
> 
> > 
> > >
> example of a 
> > > request for a network service?  Please compare/contrast somewhere 
> > > initial network connect and request for network service.
> > 
> > initial network connect example.  We could switch it if others feel 
> > this is important.
> 
> Having clearly differentiated use cases and adjoining 
> examples is extremely desirable.  
> 
> 
> > > use case.  Namely, what about a use case that involves 
> the need to 
> > > pass multiple [concurrent] assessments?  For example, 
> what if I'm a 
> > > guest at a company that provides guest LAN network 
> connectivity as 
> > > long as I pass muster via NEA.  What if then I desire to connect 
> > > back via VPN to my company's network that also requires passing 
> > > security muster via NEA.
> > of the problem space that we didn't already cover.  I presume this 
> > would just be 2 independent assessments without knowledge of each 
> > other (?).
> 
> Hypothetically speaking, if on describes use case A and use 
> case B, does this mean that use case A+B is automatically 
> supported?  I would say that it's not automatic in most 
> cases. You make the valid point that in the (A+B) case that I 
> postulate there's a need to have 2 independent assessments 
> with knowledge of each other.  In which of the existing use 
> cases does this requirement get covered?

Not sure it's a requirements specific to PA, PB or PT.  This seems like
a property of the architecture and an implementation.