I am the assigned Gen-ART reviewer for draft-FOOBAR.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other Last Call comments
you may receive.
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
More detail: This draft is in good shape. None of what I list below
is a showstopper, but I believe some of the things listed could
tighten it up, and I believe in very clear writing even in
informational RFCs, especially because framework documents like this
one are becoming more important. I'm leaving small editorial things
to the RFC editor ...
Abstract
- "evaluate the posture of a system"
For clarity please use "endpoint" (as you do throughout the rest
of the document) instead of "system". A naive reader can't tell
if "system" refers to the entire system dealt with in the
reference model (just discussed, so in the reader's mind) or a
client end system, a home network or what. Maybe "system" is a
relict.
2. Terminology
- "Attribute - Data element including any requisite meta-data
describing an observed, expected or operational status of an
endpoint feature (e.g. anti-virus software). Attributes are
I understand the difference between observed and expected, but
what's the difference between observed and operational? If there
is one, maybe you could use a few more words to make the
difference clear.
- "Endpoint - Any host computing device that can be connected ..."
Delete "host". This isn't the 1970s anymore, or even the 1980s.
Most endpoints don't host anything.
Make this a global change except where well-established protocols
or concepts have "host" in their name.
- "The owner may permit user override or augmentation of control
policies or may not assert any policies limiting use of asset."
"may not" is almost always dangerously ambiguous regardless of
capitalization. It could mean that the owner is not allowed to
assert any policies. How about: "or may not" -> "and need not".
- "Posture Attributes - Attributes describing a quality or status
(posture) of an feature of the endpoint."
Above, in "posture", you said "configuration or status", which
makes sense. Here you have "quality or status of an feature".
"Quality" is undefined here. I would avoid it. By the way change
"an feature" -> "a feature" if you don't delete it.
4. Problem Statement
- "Endpoints that are not NEA-capable or choose not to share
sufficient posture to evaluate compliance may be subject to
different access policies."
They are subject to the same *policies*, but the result of
*applying* those policies may be different (e.g. limited access).
Perhaps you can say "... subject to different application of
access policies", or if you don't like that perhaps "... subject
to different access policy rules".
5. Reference Model
- I would expand the PA and PB acronyms the first time they are used
here. They are expanded up at the beginning of Scope, but not
here, where they discussed for a while before being expanded.
- "The specific methods of referencing the configuration and
establishing the communication channel are out of scope for the
NEA reference model and should be covered in the specifications of
candidate protocols for the Posture Transport (PT) protocol."
I would delete "and should be ... ". Just say it's out of scope,
not which draft it should be covered in. Give yourself the
freedom to cover the issue in other drafts any way you like.
5.1.1 NEA client
- "Endpoints lacking NEA Client software (which is out of NEA scope)
or choosing not to provide the attributes required by the NEA
Server could be considered non-compliant and subject to different
access policies."
Same comment on Section 4. To me, the access policies seem to be
the same, but different rules within policies apply. For clarity
I would end the sentence at "could be considered non-compliant".
That's all you need to say. Stop there.
6.1.1.1 example
- "The NEA Server determines that the system is lacking a recent
security patch designed to fix a serious vulnerability and the
system is placed on a restricted access network. ... Later, the
desktop requests again to join the network and this time is
allowed on the enterprise network ..."
Could you be clearer about "the enterprise network" etc.? When
you say placed on a restricted access network, are you talking
about an L2 VPN? Obviously the endpoint is "on the network",
perhaps even "the enterprise network", or you wouldn't be able to
do the assessment in the first place. (This is a global, but not
straightforward, change.)
7.2 PA requirements
- "PA-1 The PA protocol MUST support communication of an extensible
set of NEA standards defined attributes. These attributes will be
uniquely identifiable from non-standard attributes."
"uniquely identifiable from" -> "distinguishable from"
- "PA-2 The PA protocol MUST support communication of an extensible
set of vendor-specific attributes. These attributes will be
segmented into uniquely identifiable vendor specific name spaces."
"uniquely identifiable" -> "uniquely identified".
"vendor specific" -> "vendor-specific".
7.3 PB requirements
- "PB-2 The PB protocol MUST NOT interpret the contents of PA
messages being carried, i.e., the data it is carrying must be
opaque to it."
Do you really care if PB happens to interpret PA, perhaps for some
kind of monitoring? Is there a confidentiality issue between PA
and PB? Or is the real requirement that there can't be a
dependency -- the PB protocol MUST NOT depend on interpreting PA
messages in order to meet the requirements of supporting PA.
7.4 PT requirements
- Same comment as for 7.3 on "must not interpret".
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
