RE: [Nea] REQ: Section 5, why is this here?

["Paul Sangster" <Paul_Sangster at symantec.com>]

Comments below... 

> -----Original Message-----
> From: Alan DeKok [mailto:aland at deployingradius.com] 
> Sent: Thursday, January 11, 2007 8:40 AM
> To: nea at ietf.org
> Subject: [Nea] REQ: Section 5, why is this here?
> 
>   I think the document is out of order.  The reference model 
> is described BEFORE the requirements in Section 7.  And the 
> requirements in Section 7 use the terminology and model from 
> Section 5.

The reference model described is provided to establish context and
additional terminology (some terms can't be described in a few
sentences.)  This model is not an implementation model nor architecture.

I believe the NEA WG showed support for this model at the San Diego
meeting (and was discussed at the BOFs) so was adopted to help establish
context for the requirements.

If the model is found to be overly restrictive for describing the
context we could change it.  I'll note that this model is sufficently
general that it seems to accommodate the existing NAP, NAC and TNC
approaches collectively which have very different implementations.

> 
>   My understanding of a requirements document is that it 
> would detail requirements, rather than a detailed model.  The 
> charter does have a limited architecture description, but it 
> is significantly simpler than what is in Section 5.
> 
>   In addition, the charter says:
> 
>    The NEA Requirements document will include a problem statement,
>    definition of terms, requirements for the PA and PB 
> protocols, and an
>    overall security analysis.
> 
>   I read this to mean that the requirements document should 
> list the requirements to solve the problem statement, and not 
> include a detailed solution.  Instead, the requirements 
> document lists the requirements for implementing a particular 
> solution to the problem statement.

I don't believe the document provides a detailed solution (see above.)
If we find that the model is so detailed it interferes with our ability
to express and describe the desired requirements we could change it to
be more general.  We wouldn't want the model to cause confusion to the
WG during candidate protocol selection (based on the requirements.)

> 
>   In other words, the problem statement is about network 
> administrators, machines, and end users.  I would expect that 
> the document cover at least requirements that those parties 
> have.  I see no such list of requirements in the document.  
> We therefore have no idea whether or not the model described 
> in section 5 actually satisfies the problem statement.

As per chair direction, we'll get to the requirements after we better
clarify the context setting sections.  I will point out that we're
expressing requirements for protocols in those sections so one might
expect those requirements to reflect things visible at the those
protocol layers.

> 
>   Alan DeKok.
> --
>   http://deployingradius.com       - The web site of the book
>   http://deployingradius.com/blog/ - The blog
> 
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www1.ietf.org/mailman/listinfo/nea
> 

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