-----Original Message-----
Date: Mon, 23 Jan 2006 13:53:26 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez at hp.com>
Subject: [Nea] Comments on NEA Problem statement
To: <nea at ietf.org>
Cc: Steve Hanna <shanna at juniper.net>, THardjono at SignaCert.com
Finally had some time to look through the problem statement. It's a
good start. Look forwarding to working with the team to get this one
going...
Substantive comment #1:
------------------------
We may want to reconsider the problem statement of NEA [section 3].
While I do agree there's a general endpoint integrity/posture problem
and solution, I don't agree that it is NEA's goal to solve this. I
see
the problem that NEA is trying to solve as one of interoperability,
not
of functionality. Customer's already have a functional solution
for the
endpoint integrity/posture problem. There is actually more than one
solution - I can think of three: Trusted Computing Group's Trusted
Network Connect, Cisco's Network Admission Control, and Microsoft's
Network Access Protection. The problem with these solutions is that
they are not at all interoperable. This is where I see NEA providing
value by making some strides towards interoperability.
We have to be careful on pinning down the scope of NEA. The document
tends to mix together the desire to make existing architectures more
interoperable through common protocols, but also takes the stance that
NEA *will* support a number of diverse goals [section 4] that may
or may
not already be supported in existing architectures (i.e.). My opinion
is the NEA should focus on assisting interoperability of what has
already been defined in existing architectures and leave the rest
for a
different effort (or at least as a future goal and not an immediate
one).
Moreover, the document spends a substantial amount of time creating
new
nomenclature and describing a new generalized architecture, even
though
it states up front [section 1] that it is not the intention of NEA to
create a new framework. It seems that sections 2 through 6 have just
done that and do not reference in any implicit or explicit manner
existing architectures/efforts. My suggestion on these sections would
be that they be more inclusive of existing architectures and discuss
from the perspective that we have existing solutions to the endpoint
integrity/posture problem, but they are currently incompatible and
non-interoperable due to differing use of protocols and protocol
bindings.
What I see to be the real aim of NEA only shows up until section 7
(scope of standardization). This section is good and could be
improved
by describing how existing architectures would benefit from having
these
interfaces standardized.
Speaking of interfaces... It is probably a misnomer to call NEA a
standardization of various interfaces. I see the work being more
one of
standardization of protocol and/or protocol bindings. The term
interface
may be construed as meaning API's , which should not be the intention.
Substantive comment #2:
-----------------------
Role of trusted computing technology is not highlighted in any form.
Although it shouldn't be mentioned as a normative reference, it should
be brought in a way that has it as an informative reference.
<snip>
Cheers,
MS
--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557
916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez at hp.com
--------------------------------------------
------------------------------
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
End of Nea Digest, Vol 3, Issue 4
*********************************
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
