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

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jan 2007 11:40:10 -0500

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.

  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.

  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.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

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

---

From: "Paul Sangster" <[email-masked]>
Date: Thu, 11 Jan 2007 09:50:40 -0800

Comments below... 

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, January 11, 2007 8:40 AM
> To: [email-masked]
> 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.
> 
>   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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jan 2007 13:42:17 -0500

> sentences.)  This model is not an implementation model nor architecture.

  I understand.  Many network protocols involve nothing more than a
client-server relationship, so there's little need for a model or for
architecture diagrams.  NEA is more complicated, so there's more need to
describe the model in detail.

  However, the detail of this model will strongly influence the choice
of architecture.

> context for the requirements.

  The people proposing the model at San Diego supported it, but the
minutes show a number of questions surrounding the model.  Prior
discussion on the mailing list raised a number of questions that this
document does not address.

  The requirements draft authors have *not* been significantly involved
in the detailed discussions, either before or after they were chosen to
be authors of the draft.  This means that there has been little overlap
between discussions on the list, and this document.

  The WG needs consensus, and it needs active participation on the list.

> approaches collectively which have very different implementations.

  My concern is not about the restrictiveness or the utility of the
model.  My concern is that the model has been dropped as-is into the
requirements document, with little discussion or justification.  As
such, there is no reason apparent in the document for choosing that
model.  Anyone reading the document cannot understand why that model was
chosen.

> clarify the context setting sections.

  The model is a presented as a requirement, because there is no
apparent reason for choosing that model.  There is therefore no context
apparent for the model, other than it's self-definition.

>  I will point out that we're

  Yes, however the problem statement does *not* involve the complexity
and number of participants that are presented in the model.  I would
therefore appreciate additional text in the document detailing where the
model came from, and how it satisfies the high-level problem statement.

  I would also appreciate the requirements document addressing the
issues raised on the list in the last few months.  I will try to detail
those in a separate message or document.

  Again, protocols are simply a means to an end.  We can define any
number of complex models and scenarios, and then determine requirements
for the related protocols.  But that doesn't mean those models will be
applicable to the real world, and it doesn't mean the protocols will be
useful to anyone.

  Alan DeKok.