Re: [Nea] Re: use of a design team to develop requirements

[Alan DeKok <aland at deployingradius.com>]

Keith Moore wrote:

> I also think that is is contrary to good engineering practice and common
> sense to try to define requirements of a solution before the problem
> itself is well understood.  the chairs and the design team may believe
> that they understand the problem well, but they haven't bothered to get
> much input from the larger group before starting to draft requirements.

  Then let's discuss the requirements here.

  Personally, I think that there are many kinds of endpoint assessment
that can be done simply by leveraging information in existing protocols.
 e.g. MAC address filtering in DHCP, to allow only known hosts onto the
network.  None of those steps to a full-blown NEA are perfect, but NEA
won't be perfect, either.

  I would like to see the requirements stated as a series of stages,
from "anyone is allowed on the network with no checks", to "you must
submit to invasive probes", with a graduated range of assessments in
between.

  The main problem I see with that approach is the extremes are easy to
document, but the grey area in the middle is difficult to quantify.
Maybe even before requirements, we should discuss what information
exists where, and who is willing to exchange what information.

  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