Subject: [Nea] More non-substantive comments on nea-requirements-03

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 10 Aug 2007 18:21:08 -0400

Here are some more non-substantive comments on the latest
version of the NEA requirements document (-03). Please take
these in the constructive manner in which they are intended.

Thanks,

Steve

------------

In the second paragraph of section 3.2, change "Network"
to "network". There's no reason for this word to be
capitalized.

At the end of the fourth paragraph of section 3.2, change
"its policies" to "the company's policies". Otherwise,
it's hard to figure out what the word "it" refers to.

Throughout the specification, there are MANY places where
you insert a hyphen into words that begin with "re". For
example, "re-assessment", "re-usable", "re-use", "re-join",
"re-activate", etc. There's no reason to have a hyphen in
these words. In fact, it's incorrect. Feel free to consult
a dictionary on this one. I used Merriam-Webster and the
OED. I suggest that you just do a global search and replace
changing "re-" to "re".

In the first sentence of section 5.1.1, "comprises" should
be "comprised". You can say the NEA client "comprises the
following components" or "is comprised of the following
components". But "comprises of the following components"
isn't correct.

We should decide whether to use "a NEA" or "an NEA".
Right now, the document is about evenly divided.
I prefer the former because I often pronounce NEA as
"nee-ah" but I know that some people pronounce it as
"en-ee-ay". Either way, let's decide and be consistent.

In the second sentence of the first paragraph of section
5.1.1.2, I don't think the Posture Broker Client actually
de-multiplexes the posture information request from the
NEA Server. I think it receives the request from the
NEA Server and then de-multiplexes it. There are two
steps here and I think we should reflect that in the
text. Also, I think it would be more accurate to call
the thing received a "PB message" than to call it a
"posture information request". It's really a PB message
and it may or may not have a posture information request
in it. If we do make this change, we should probably
make another change later in that sentence: change
the text "distributing each request to the corresponding
Posture Collector(s)" to "distributing each PA message
to the corresponding Posture Collector(s)." This should
clarify what request is what.

After the bullets at the start of section 5.1.2, I think
"The Posture Validator" should be "Posture Validators".
There will often be several Posture Validators.

In the third paragraph of section 5.1.2.1, I don't think
we have any documented requirement for a NEA Server to
handle several Posture Validators. So I think the phrase
"is required" should be changed to "may need".

At the top of page 17, "Results Attribute" should be
"Result Attribute" to match the term defined in the
Terminology section on page 7.

In the third sentence of the first paragraph of section
5.1.2.2, I think you actually want to say the Posture
Broker Server "parses the PB messages received from
the NEA Client and de-multiplexes into PA messages
which it passes to the associated Posture Validators".
Why? Because the Posture Broker Server doesn't receive
PA messages. It receives PB messages that contain
PA messages.

In the first bullet at the bottom of page 17, change
"register/unregister" to "register and deregister".
This removes any ambiguity about whether the slash
represents "or" or "and" and replaces "unregister"
with a real word. ;-)

In the first bullet of section 6, remove the colon.
This is a perfectly fine sentence without it.

At the end of the second bullet of section 6, change
"its" to "the endpoint's". Otherwise, it can be hard
to figure out what "its" refers to.

The second sentence of the first paragraph in section 6.1
is hard to understand. There are tons of words before
you get to the verb. I suggest rephrasing it to say
"Endpoints do not qualify for this category of use case
if the have been recently assessed and the NEA Client
or Server has maintained state (or proof) that the endpoint
is compliant and therefore does not need to have its
posture evaluated again."

I agree with Tim that Figure 2 could use some work.
Here are my pet peeves. ;-) The current diagram shows
the whole sequence as being started by the event "client
requests network access". Actually, the Initial Assessment
Use Case can be triggered by the client or the server
so I think it would be better to say "endpoint assessment
triggered". Another peeve is that the arrows in the
diagram have all sorts of different labels, none of
which correspond to anything in the terminology section.
Oh, well! ASCII art is hard!

I think it would be good to add a sentence after Figure 2
to remind people what they're about to see since they have
probably spent some time puzzling over Figure 2. Something
like "Several Initial Assessment use cases are described in
sections 6.1.1 and 6.1.2" should do it.

At the end of the first paragraph of section 6.1.1,
I think you should remove the word "such". I don't
think there's really anything for that word to
refer to.

The flows in section 6.1.1.2 are not definitive. I suggest
replacing the first sentence of section 6.1.1.2 with this:

> This section describes typical message flows through the
> NEA Reference Model for this use case.

Step 4 of section 6.1.1.2 seems to combine a bunch of steps
into one. Maybe it would be better to break those out, at
least into separate sentences in one step. For instance,
you could write:

> The Posture Broker Server aggregates the PA messages from
> the Posture Validators into a PB message. The Posture Broker
> Server passes this message to the Posture Transport Server,
> which uses the PT protocol to send the PB message to the
> NEA Client on the desktop computer.

The first sentence of step 11 of section 6.1.1.2 is a bit
confusing. It sounds like it (what?!) is compliant to the
Posture Broker Server. I think this problem could be solved
by rephrasing the first part of that sentence to this:

> The Anti-Virus and Firewall Posture Validators return  
> attributes to the Posture Broker Server stating that the
> desktop computer is compliant, but [...]

I don't think we should capitalize Anti-Virus, Firewall,
and OS Patch. The fewer capitalized terms the better,
especially since these are not terms defined in the
Terminology section.

Step 12 in section 6.1.1.2 omits the role of the Posture
Transport Server and Posture Transport Client. I would
add this phrase to the end: "via the Posture Tranport
Server and Posture Transport Client".

At the end of step 13 in section 6.1.1.2, I think the
phrase "potentially while quarantined" is incidental
so I recommend that we place a comma before it.

In step 14 of section 6.1.1.2, it's not clear what the
phrase "upon completion" refers to. I suggest that we
change it to say "Upon completion of the remediation
instructions".

Step 15 of section 6.1.1.2 says that the OS Patch Posture
Validator returns a compliant status. Actually, ALL the
Posture Validators do so in this reassessment. I think
we should say that. Also, I don't think that we should
refer to step 11 in step 15. This step replaces step 11
but we don't need to say so.

The first sentence of section 6.1.2 says that the
reassessment is "possibly caused by a user". I think
you mean "possibly at the request of a user". If I'm
right that this is the main focus of this comment,
please say so. Otherwise, it leaves the reader
imagining all the ways that a user might cause a
reassessment (many of which are unpleasant to consider
and none of which are very relevant to this use case).

Step 2 of section 6.1.2.2 says the Posture Broker Client
"establishes a session ...". I think this is getting
into too many internal details of how the NEA Client
works (or might work). Wouldn't it be better and simpler
to just say the Posture Broker Client "requests a
new assessment" and end the step there?

Again in step 3 of section 6.1.2.2, we get into a lot
of detail about "causing a new protocol context exchange
to be initiated". I don't know what that means and I
don't see how it's relevant to PA, PB, or PT. Let's
just delete it.

In step 4 of section 6.1.2.2, we say the Posture Broker
Server "contacts" several Posture Validators. Actually,
they may well have been in contact for some time. I think
the more relevant statement is that the Posture Broker
Server "decides to employ" several Posture Validators
for this assessment.

In step 8 of section 6.1.2.2, "PA message" should be
plural not singular.

In step 12 of section 6.1.2.2, "active" should be
"activate".

In step 13 of section 6.1.2.2, I think it would be
clearer to say "the Validators'" instead of "each
Validators'".

In step 19 of section 6.1.2.2, we should change "his/her"
to "her" since we said "her" at the end of section 6.1.2.1.

At the end of the first paragraph of section 6.2,
I think it would clarify things if we added the
words "on the NEA Server". Also, I think we should
combine the first and second paragraphs of this
section since the second one is just a slight
elaboration of the first one.

In step 1 of section 6.2.1.2, we don't say where the
PB message comes from. I suggest we change "This PB
message contains [...]" to "The Posture Broker Client
creates a PB message that contains [...]".

The second sentence of step 2 of section 6.2.1.2 says
that "The Posture Broker Client will create a new session
for the re-assessment." I think that the Posture Broker
Client may often reuse an existing session and I don't
think that makes much difference so I think we should
delete this sentence.

At the end of step 7 in section 6.2.1.2, we say that
The Posture Validator "instructs [the Posture Broker
Server] to respond back to the NEA Client." I don't
think that's likely to be true. The Posture Broker
Server will probably know when it's time to respond
back to the NEA client and may wait for other Posture
Validators. So I suggest we drop that clause.

In the third bullet of section 6.2.1.3, "interact"
should be "interacts".

In the first sentence of the second paragraph of section
6.2.2.1, "it" should be "them". In the second sentence
of that paragraph, "what" should be "which". In the
fourth sentence of that paragraph, the word "explaining"
(or something similar) is needed after the word "employee".

In step 2 of section 6.2.2.2, the word "for" is extraneous.

In step 3 of section 6.2.2.2, "become" should be "becomes".

In step 8 of section 6.2.2.2, we should simply say "OS Patch
Posture Collector" instead of "the Posture Collector responsible
for handling OS Patch Request Attribute(s)." Although I like
the idea of not implying that each Posture Collector has one
function, we have been doing this everywhere else in these
examples so we should probably be consistent.

In step 15 of section 6.2.2.2, I think it would be clearer
to say "along with its PA message" instead of "and its PA
message".

In step 20 of section 6.2.2.2, "how" should be "now".

In step 21 of section 6.2.2.2, "step 13" should be
"in step 13". Also, the reusable attributes don't need
to be signed and dated. They could be a cookie or other
reference to server-side state. Therefore, I suggest
that we put "e.g." before the words "signed and dated"
to indicate that this is just one way this could be done.

The end of step 22 in section 6.2.2.2 is not grammatical.
I suggest that we change it to "[...] compliance, it caches
those attributes for future use."

In step 23 of section 6.2.2.2, "step 9-10" should be
"step 9".

In the first paragraph of section 7, I think it would be
clearer to say "decide whether to make use of that feature"
instead of just "decide to make use of that feature". There's
really a yes/no decision for the deployer here.

In the second paragraph of section 7, we should change
"from each" to "for a" since we no longer require all
the protocols to provide cryptographic security. For
the same reason, we should change "require that a deployer
make use of all or even any of them" to "require that
a deployer must make use of these protections".

In requirement C-5, I suggest that we place "i.e. PT"
in parentheses since it's really a parenthetical comment.

In requirement PA-5, "Results" should be "Result Attributes"
for consistency with the Terminology section.

In the first paragraph of section 7.3, the meaning of "to/from"
is not clear. This is often true when using a slash to separate
two words. I suggest that we remedy the problem be replacing
"to/from" with "and" and adding "(in either direction)" at the
end of the sentence.

In the second paragraph of section 7.3, I think a "patch reference"
is a kind of remediation instruction so I suggest that we remove
the words "and patch references" from this sentence.

In requirement PB-2, I think that "(de)registation" is supposed
to mean "registation or deregistation". If I'm right, please
change the first phrase/word/ambiguous thing into the second
clear phrase. At least, I think the second one is clearer!

In PB-3, the phrase "each party" is ambiguous. I think we mean
"Posture Collectors and Posture Validators". If I'm right, let's
please say so. Also, I think it would be good to add a phrase at
the end of this requirement: "while maintaining state associated
with the dialog". That should help explain why we need PB-3.

In the second sentence of the second paragraph of section 8,
the first "it" should be "it is". Later in that sentence is
another of those odd and ambiguous slash constructions. Let's
change that to "out of date, inactive, or absent". In the next
sentence, it's not clear what "be present" means. I suggest we
change this to "have this endpoint present".

In the first sentence of the next paragraph, "endpoint" should
be plural.

I think the second sentence of section 8.1 should be worded
more firmly. I suggest changing the start of this sentence
to "Therefore, there must be an implied distrust [...]"
In the next sentence, I think it is clearer (and certainly
more grammatical) to say "to not misuse" instead of "not
to misuse". Later in that sentence, I think it would be
more specific and accurate to say "any remediation instructions
provided to the endpoint" instead of "any remediation necessary
to join the network".  And in the next sentence I think it
would be best to insert the word "also" between "The NEA Client"
and "normally needs". This is an additional kind of trust.

We could tighten up the first sentence of the next paragraph
by changing its start from "In between the NEA Client and Server
exists a network" to "Between the NEA Client and Server there
exists a network".

In the second paragraph of section 8.1.1, the last sentence
reference to "comparison" mechanisms. I think it would be
more accurate and more general to replace that word with
the word "evaluation".

In the second paragraph of section 8.1.2, the words "or alike"
are both ungrammatical and unnecessary. I suggest we delete them.
Why unnecessary? Because "e.g" implies this is just a few of
many alternatives.

In the second sentence of the last paragraph of section 8.1.2,
there should be a comma between "network" and "archiving" and
another comma after the parenthetical phrase.

In the first sentence of section 8.1.3, I suggest putting
parentheses around the phrase "including potentially remote
systems providing posture validation". This is really a
parenthetical comment. Marking it as such will make it
easier to understand the sentence.

In the first sentence of the second paragraph of section 8.1.3,
"their" should be "its" since the referent is "the NEA Server".
Later in the paragraph, another phrase should be placed in
parentheses: "particularly those that would change the resulting  
decisions or enforcements". And in the following sentence,
"underlying carrier protocols" should be changed to "NEA protocols".
The NEA Server really needs to trust all the NEA protocols, not
just carrier protocols (which is ambiguous anyway).

The first sentence of the next paragraph describes an example
that ostensibly "combines aspects of both areas". Which areas?
I suggest that we just say "One interesting example is where
some [...]".

In the last sentence of the second paragraph of section 8.2,
I think the word "and" should be replaced with the words
"or so that". Otherwise, the word "and" might be interpreted
as a logical conjunction instead of as a disjunction, which
I think is what's intended.

In the first sentence of the second paragraph of section 8.3.1,
"themselves" should be replaced with "himself" or "itself" since
the referent ("attacker") is singular. In the last sentence of
this paragraph, "the passive MITM" should be "a passive MITM"
since there's no specific MITM being referred to.

In the first sentence of section 8.3.2, it would be clearer and
simpler to replace the phrase "an attacker capable of interception
of a message" with the phrase "an attacker capable of intercepting
a message". Later in that paragraph, we should insert the word "a"
before "malware infested machine". And in the last sentence of
the paragraph, "introduce a malware" should be changed to "would
introduce malware".

In the first sentence of the next paragraph, "this change" should
be changed "any change to a message" since there's no specific
change being referred to.

In the fourth sentence of section 8.3.4, "the all of the" should
be just "all of the".

In the first sentence of the third paragraph of section 9, "specify"
should be "specifying". At the end of that paragraph, "their use"
should be "endpoint use" and "they" should be "the endpoint".
Otherwise, the referents for the pronouns are obscure.

In the bullets at the end of section 9.1, replace the slash
with the word "and".

In the last sentence of the second paragraph of section 9.2,
insert the word "a" before the word "system".

At the end of the next paragraph, change the word "system"
to "systems".

In the next paragraph, remove the text "/smaller" since it's
not clear that the set of attributes sent by a Linux system
will be smaller than the set of attributes sent by a Windows
system and there's no reason to get into religious issues here.
Also, remove the comma a few words earlier. There's no reason
to have it there.

In the Acknowledgements section, Alan DeKok's name has a
capital letter 'K' at the end. It should not, I think.

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