Subject: [Nea] comments on draft-ietf-nea-requirements-03

From: Tim Polk <[email-masked]>
Date: Thu, 9 Aug 2007 17:27:15 -0400

Folks,

I have a number of comments on the nea-requirements draft.  Overall, I
believe this is a strong document but I did have a number of issues/ 
questions.
Many are purely editorial, including a few fussy writing quirks of mine,
but there are some technical issues as well.

The issues are presented in the order I encountered them in the  
document...

Section 1.0 Overview

One nit in the last paragraph.  Security Considerations are last in
the document, but the text implies that they precede the requirements
for protocols.  I would prefer to see this text parallel the actual
document structure.

Section 2.0 Terminology

Numerous terms are defined in terms of Posture Collectors and Posture
Validators, but these terms are not defined until section 5.

Component - I think this definition is weak, particularly when you
consider the use of Posture Collector.

Section 4.0 Problem Statement

Editorial nit: The first paragraph of this section should probably be
separated into two paragraphs.  The first sentence presents an idea
that applies to all remaining paragraphs.  The remaining sentences
present the first of the "several purposes".

Bigger Editorial nit: Upon reading the problem statement, I found it
difficult to determine how many different purposes were being presented.
Clearly text as each distinct purpose is introduced might be helpful.

I interpreted the text as defining five purposes:
(1) facilitate endpoint compliance [described in the first three
paragraphs];
(2) re-assessment [described in the fourth paragraph];
(3) verify asset information [fifth paragraph];
(4) provide posture assessment for network connection [first sentence
of the sixth paragraph]; and
(5) provide posture assessment for application access [second sentence
of the sixth paragraph].

Is this correct?  Perhaps the sixth paragraph should become two
paragraphs to more clearly delineate there are two purposes.  If these
are variants, we need an introductory sentence.

5.1.1.1 Posture Collector

paragraph 2, sentence 3:  The example given for a dynamic identifier
is "assigned by the Posture Broker client upon registration".   The
example for static identifier is "provided during registration".
What is the difference?  Provided by whom/what?  Perhaps the static
identifier example should be "provided upon installation"?

5.1.1.2 Posture Broker Client

This is a nit, but I believe that the posture broker client must
generate error messages when no posture collector exists on the
system to handle a particular attribute request.  Perhaps this is
implied elsewhere, but I think it is worth stating...

Question 1: Section 9.2 introduces the concept of interrogating an
endpoint to determine the OS, etc.  Are these types of global
information requests handled by the posture collector or the
posture broker client?  I couldn't sort it out from the text, and
I believe this is an important issue.

Question 2: Does the WG envision a set of result attributes that
are mandatory to support for a posture broker client?  This is
implied by the fourth bullet...

5.2.2 Posture Broker Protocol

The PB protocol does not include a requirement for cryptographic
protection of posture attributes, since this can be handled by the
PA protocol when they are transmitted between the posture collector
and posture validator.  However, the global assessment decisions are
transmitted from PB Server to PB Client... and there is no discussion
of protecting its own information.  Has the working group considered
whether this information needs protecting, or is this assumed to be
the role of the PT protocol?

5.3.1, second bullet

Editorial nit: The second sentence has a lot of clauses, and it is
easy to lose the thread.  It might be clearer if it was reworded to
explicitly state the two cases.  I would suggest something like:

These attributes consist of either (a) NEA Server provided attributes
(state) describing a prior evaluation (e.g. opaque to
endpoint, signed, time stamped items stating specific results)
or (b) NEA Client identity information used by
the NEA Server to locate state about prior decisions (e.g.
system-bound cookie).

The text above assumes that these are the only types of assertion
attributes.  If that may not be the case, then we should state them
as examples:

Examples of assertion attributes include a) NEA Server provided
attributes (state) describing a prior evaluation (e.g. opaque to
endpoint, signed, time stamped items stating specific results)
and (b) NEA Client identity information used by
the NEA Server to locate state about prior decisions (e.g.
system-bound cookie).

Section 6.

The example seems to assume that the OS is known.  Stating that up
front would be helpful.

Figure 2 and the text in 6.1.1.2 should be tightly coupled.  The text
contains 13 numbered steps, but the figure has either 14 or 17
steps (depending on how I count the flows between the pt client and
pt broker server).

Section 7.1

Requirement C-1

Are updates to previously reported posture information actually
part of the same dialog?  This would seem to be a separate protocol
run to me. IMHO, sentences 1 & 2 seem to specify a different
requirement than sentences 3 & 4.

Requirement C-3

Why is this a SHOULD instead of a MUST?  This document includes
scenarios initiaited by the server and by the client.  Isn't is a
requirement for the NEA protocols to support both?

7.3

Requirement PB-4

If the posture broker needs to protect global assessment information
(see comments on 5.2.2), then MAY is too weak.  MUST or possibly MAY
would be needed...

8.1.2

The last sentence in this section seems to establish a requirement for
the NEA protocols.  This material needs to be presented earlier and
represented as a section 7 requirement.

Section 9.2, next to last paragraph:

     "For example, an enterprise might ask about the OS
     version in the initial message dialog and after learning the
     system is a Linux system, ask for a different/smaller set of
     attributes specific to Linux then it would if the endpoint was a
     Windows system. "

This text answered a nagging question for me, when I encountered it.
While I was glad to learn how the wg intended to address the OS
identification problem, page 48 was a little too late.  I believe
the possibility of a bootstrapping ought to be addressed earlier, and we
should clearly state which component (PB Client or PC?) resolves
this type of question...

Thanks,

Tim Polk

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

---

From: "todd glassey" <[email-masked]>
Date: Thu, 9 Aug 2007 16:24:51 -0700

----- Original Message ----- 
From: "Tim Polk" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 09, 2007 2:27 PM
Subject: [Nea] comments on draft-ietf-nea-requirements-03

> for protocols.  I would prefer to see this text parallel the actual

Violates the RFC document format template. If this is OK then its OK, but 
the Security Considerations are where they are based on the templates 
design.

> Validators, but these terms are not defined until section 5.

Agreed but here again - this is a writing style issue.

---

From: Tim Polk <[email-masked]>
Date: Fri, 10 Aug 2007 13:26:09 -0400

Todd,

On Aug 9, 2007, at 7:24 PM, todd glassey wrote:

>
> ----- Original Message ----- From: "Tim Polk" <[email-masked]>
> To: <[email-masked]>
>> believe this is a strong document but I did have a number of  
>> issues/ questions.
> Violates the RFC document format template. If this is OK then its  
> OK, but the Security Considerations are where they are based on the  
> templates design.
>

Thanks for pointing this out, since I was unintentionally vague  
here.  I am not asking
for any change in document structure, or departures from the normal  
RFC structure.
I just want the front matter to parallel the document structure as it  
exists...

[rest of quoted text deleted.]

Thanks,

Tim

---

From: "todd glassey" <[email-masked]>
Date: Fri, 10 Aug 2007 11:14:20 -0700

Actually Tim you were right in noticing that the IETF Template is the 
culprit and that NEA and many security specific standards need those 
sections "up front" as it were. I just wanted to point out that 'one size 
doesn't fit all' per se.

Perhaps also we should think of the Notation Style that the Court use when 
they allow Terms of Art (TOA) to be defined in their filings. This is 
neither overly complex nor painful, its just a minor style rule that says 
that any and all TOA's need to be defined in their first use in any 
document, and that any and all external references to TOA's also need to be 
defined PRIOR to their use in any standards process docs or IETF operations 
docs.

This type of notation style would bring the IETF documents in-line with 
other standards processes and define one of the key tasks that the 
editor-service-provider is to render to the IETF for their booty.

T.

----- Original Message ----- 
From: "Tim Polk" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 10, 2007 10:26 AM
Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03

>> Violates the RFC document format template. If this is OK then its  OK, 
>> but the Security Considerations are where they are based on the 
>> templates design.
>>
>
> Thanks for pointing this out, since I was unintentionally vague  here.  I 
> am not asking
> for any change in document structure, or departures from the normal  RFC 
> structure.

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 10 Aug 2007 12:18:25 -0700

Hi Tim,

Thanks for your comments. Please find my response inline.

> for protocols.  I would prefer to see this text parallel the actual

<Kaushik> 

Fair comment. The last sentence in the Overview section needs a bit of an
edit to clarify the order.

</Kaushik>

> Validators, but these terms are not defined until section 5.

<Kaushik> 

The definitions currently cover all terms expect for the components of the
NEA client and NEA server stack defined in the reference model. There might
not be sufficient context before Section 2.0 to properly define terms such
as Posture Collector, Posture Broker etc. We could certainly try to add
these definitions for the sake of completeness.

Did you find lack of these definitions in Section 2.0 as effecting the
readability of the document.

</Kaushik>

> consider the use of Posture Collector.

<Kaushik>

Agreed. We do plan to address the definition of Component in the next
revision, the ambiguity of the current definition has been pointed out by
other reviewers as well.

</Kaushik>

> Clearly text as each distinct purpose is introduced might be helpful.

<Kaushik>

Good comment. By and large one or more paragraphs try to elaborate on each
purpose but there is clearly scope of further clarification.

</Kaushik>

> (1) facilitate endpoint compliance [described in the first three

<Kaushik>

Paragraphs one & two describe the broader problem of checking endpoint
compliance and why it is important for an IT organization. The second part
of paragraph two delves into the ability to check compliance while trying to
gain network access.

Paragraph three talks about a couple of aspects that important to NEA
technology but are currently out-of-scope of the document. These are the
ability to remediate non-compliant endpoints and the use of network access
technology to control access based on the level of compliance.

</Kaushik>

> (3) verify asset information [fifth paragraph];

<Kaushik> 

This is correct

</Kaushik>

> (5) provide posture assessment for application access [second sentence

<Kaushik> 

This is correct.

Paragraph six actually tries to elaborate on the types of network access
such as Layer2 (wired/wireless) & Layer 3 (IPSec & SSL VPNs). The second
part of paragraph six talks about assessment during application access. It
is a good suggestion to split the paragraph

</Kaushik>

> identifier example should be "provided upon installation"?

<Kaushik>

You are right. Static identifiers are assigned to specific Posture
Collectors prior to the software being installed. The Posture collectors
pass up these identifiers to the Posture Broker Client during registration.
In case of Dynamic identifiers, they are generated during the registration
process.  

We will update the text to clarify this.

</Kaushik>

> implied elsewhere, but I think it is worth stating...

<Kaushik>

This is implicit and should probably be described in the protocol
specification since there are a multitude of PA, PB & PT  error conditions
that have not been described since this is a requirements document.

</Kaushik>

> I believe this is an important issue.

<Kaushik>

The thinking has been that there would be a core/standard schema which would
contain attributes such as OS type. Although it is not clearly spelt out the
thinking has been that collection of attributes including the OS type would
be a PA function and would be handled by a collector.

We will add text to the reference model to clarify this.

</Kaushik>

> implied by the fourth bullet...

<Kaushik>

Yes. The document talks about the global posture assessment attribute which
is mandatory to support for posture broker clients and servers.

</Kaushik>
 
> the role of the PT protocol?

<Kaushik>

The PB protocol does include cryptographic protection but it is not
mandatory (the requirement is a MAY). The assumption is that crypto
protection provided by the PT protocol would be sufficient for most
implementations but implementations may decide to implement crypto
protection at the PB layer as well. This is especially relevant when the
Posture Transport Server and Posture Broker Server are not co-located and
need to communicate over-the-wire.

As far as need for protection for the PB attributes, the global assessment
decision is an attribute that needs to be both integrity and confidentiality
protected and there could additional PB attributes in the future that need
protection.

</Kaushik>

> the NEA Server to locate state about prior decisions (e.g.

<Kaushik>

Good suggestion. We will edit the text. I agree that the usage of assertion
attributes are better stated as examples to allow for additional types of
assertions to be included in the future.

</Kaushik>
> steps (depending on how I count the flows between the pt client and

<Kaushik>

Figure 2 is common to both examples of initial assessment, i.e. Section
6.1.1 & 6.1.2. We did not intend a co-relation to a specific example and
that's why you notice the difference in steps.

We will add text before Figure 2 to make this clear.

</Kaushik>

> requirement than sentences 3 & 4.

<Kaushik>

The confusion stems from the use of the term dialog since it can cover
several transactions. We plan to edit C-1 to essentially clarify that the
requirement to support multiple round trips to complete a single assessment.

A single assessment could include re-evaluation of the posture after
remediation.

</Kaushik>

> requirement for the NEA protocols to support both?

<Kaushik>

This was the issue that was raised on the mailing list by Steve Hanna and
discussed during the last IETF meeting. This stems from the fact that the
current charter calls for one PT protocol as mandatory to implement whereas
we have requirements that a single PT might find difficult to satisfy

The requirements in question are

A. Ability for PT to run over existing network access protocols such as
802.1x or Ipsec (requirement C-2 re-stated for clarity)

B. Ability to perform client or server triggered assessment (requirement
C-3)

Both these requirements need to be a SHOULD to enable PT protocol selection
that can conform to the charter. We plan to edit requirement C-2 in the next
revision.

</Kaushik>

> (see comments on 5.2.2), then MAY is too weak.  MUST or possibly MAY

<Kaushik>

You mean MUST or SHOULD. This was discussed at the Prague IETF meeting and
moved from a SHOULD to a MAY.

We certainly open this discussion within the WG.

</Kaushik>

> should clearly state which component (PB Client or PC?) resolves

<Kaushik>

Would this be a requirement or update to the reference model to state that
the OS discovery would be handled by the Posture Collector. I am not sure
about the motivation to special case the OS type different from any other
standard attribute.

Regards,
 kaushik

</Kaushik>

---

From: Tim Polk <[email-masked]>
Date: Fri, 10 Aug 2007 16:52:14 -0400

Hi Kaushik,

Thanks for the prompt and enlightening response.  In general, I
am fine with your responses, so I deleted most of the quoted
conversation.  Responses on the remaining issues are inline.

> readability of the document.

Personally, I thought the definitions would be cleaner if the Posture  
Collector,
Posture Broker, and Posture Validator were not addressed in the  
terminology
section.

This is a stylistic question, though; the effect on readability was  
negligible.

> is mandatory to support for posture broker clients and servers.

That makes sense to me, but it doesn't seem to be clearly specified as a
requirement.  I don't think that is a significant problem, but if the  
WG has
consensus on this maybe we should clearly state it.

> We will add text before Figure 2 to make this clear.

If a tight coupling between the figure and examples is not intended,  
more
information may be needed in Figure 2.  For example "Pos Req" or a  
variant
of that is the label on five arrows.  Those five arrows correspond to

(1) Posture validator(s) send PA messages containing the desired  
attributes
to the Posture Broker Server.
(2), (3) Posture Broker Server aggregates the PA messages and sends them
to the NEA client via the Posture Transport Server.
(4) The Posture Transport Client sends the aggregated PA messages to the
Posture Broker Client.
(5) The Posture Broker Client de-mulitplexes the PA messages and  
delivers
them to the appropriate Posture Collector(s).

We are asking a lot from the reader to sort all this out on their own!

> We certainly open this discussion within the WG.

No need to reopen discussion on this item.  MAY is consistent with  
the rationale
provided for my comment on 5.2.2.  I am satisfied that the WG has  
considered the
issue.

> about the motivation to special case the OS type different from any  

Once again, I was unintentionally vague....

Interrogating an endpoint with respect to its OS seems inconsistent  
with the
definitions of posture and posture attribute in 2., so I couldn't  
figure out how the
posture validator(s) knew which OS a system ran.  Without that  
knowledge, the
posture validator(s) can't know which attributes to request.

There are a couple of solutions: (1) request all possibly interesting  
posture
attributes for all recognized OSes, and sort out the results; or (2)  
interrogate the
endpoint and request teh attributes that make sense.

 From the text in the security considerations, I deduced that  
discovery may be
performed by requesting posture attributes that describe the OS,  
etc.  but that
this step was omitted from the example since multiple round trips  
complicate
the base concepts.  This also implies the definitions of posture and  
posture
attribute could be expanded...

So, maybe it isn't a new requirement, its just an extra clause in the  
definition
of posture.

Thanks again,

Tim Polk

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 10 Aug 2007 15:01:50 -0700

Hi Tim,

Please find some responses inline tagged with <Kaushik-Response>

<snipped>

> This is a stylistic question, though; the effect on readability was

<Kaushik-Response>

I guess the "not addressed" is typo. We will try to see if we can get
meaningful definitions of Posture Broker, Posture Collector etc.  prior to
the explanation in the reference model.

</Kaushik-Response>

> consensus on this maybe we should clearly state it.

<Kaushik-Response>

We have avoided defining requirements that specify functional behavior of
the PA, PB & PT layers. The computation of the global posture assessment
decision and delivery of that attribute is a key function of the Posture
Broker Server and we will probably emphasize that in the reference model.

</Kaushik-Response>

> We are asking a lot from the reader to sort all this out on their own!

<Kaushik-Response>

You are right. We will either update Figure 2 to make it self explanatory or
more likely bind the figure to the example in 6.1.1.2.

</Kaushik-Response>

> So, maybe it isn't a new requirement, its just an extra clause in the

<Kaushik-Response>

That's a good suggestion. We will add text to the definition of
posture/posture attribute to clarify OS-type as a standard/core attribute.

Regards,
 kaushik

</Kaushik-Response>

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 13 Aug 2007 15:08:43 -0700

Catching up on this thread and doing the discussed editing ...

Some additional comments in-lined with [PS] prefix: 

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]] 
> Sent: Friday, August 10, 2007 1:52 PM
> To: Kaushik Narayan
> Cc: [email-masked]
> Thanks for the prompt and enlightening response.  In general, 
> I am fine with your responses, so I deleted most of the 
> quoted conversation.  Responses on the remaining issues are inline.
> 
> > The definitions currently cover all terms expect for the 
> components of 
> > the NEA client and NEA server stack defined in the reference model.
> > There might
> > not be sufficient context before Section 2.0 to properly 
> define terms 
> > such as Posture Collector, Posture Broker etc. We could 
> certainly try 
> > to add these definitions for the sake of completeness.
> >
> Personally, I thought the definitions would be cleaner if the 
> Posture Collector, Posture Broker, and Posture Validator were 
> not addressed in the terminology section.

[PS] Presume you would prefer we not mention those components in the
terminology but instead try to be descriptive.  We could try this or
create terminology entries for the couple that we use.  The challenge is
several folks have asked for more precise term definitions so we used
those names.  We could also include references "Posture Collector (see
section 5.1.1.1)"...

> 
> This is a stylistic question, though; the effect on 
> readability was negligible.

[PS] Sounds like its not worth a big change but we'll try to make a
minor change to improve the situation.

> consensus on this maybe we should clearly state it.

[PS] We currently defined just the protocol capability (normative)
requirements as these affect the WG protocol selection process (e.g.
PB-1 says protocol must be able to carry the result attributes).  We
didn't define NEA Client/Server processing requirements such as what the
Posture Broker Client must be able to do with different types of
error/success result attributes.  Hopefully this was the right decision
as we didn't want to state requirements for all the semantics that NEA
components would need to provide.  When a PB protocol is selected and
the result attributes defined they will describe their syntax and
semantics.

> We are asking a lot from the reader to sort all this out on their own!

[PS] As Kaushik mentioned the diagram was supposed to be generic
covering all initial assessment cases but as a result don't correspond
well with the detailed use cases defined.  We included the illustrations
with the understanding that if they caused confusion we would consider
removing them.  We didn't feel strongly that they were needed but until
now noone had mentioned that they were confusing.  Do folks believe we
should try to repair them or just drop both form the document (saving a
page)?

> provided for my comment on 5.2.2.  I am satisfied that the WG has  

[PS] Ok, their hasn't been strong support to move this back to SHOULD
yet but if this occurs we could consider it.  Note this is a requirement
that applies to our protocol selection (the WG can still select a PB
protocol that has strong security capabilities) even with a MAY in this
requirement.

> 
> >
> >> 8.1.2
> >>
> >> The last sentence in this section seems to establish a 
> requirement  
> >> for
> > about the motivation to special case the OS type different 
> from any  
> > other
> > standard attribute.
> >
> > Regards,
> >  kaushik
> >
> >
> > </Kaushik>
> 

We could add a couple clauses in the examples to make it more clear that
the OS version is treated like other component (e.g. firewall) versions
on the endpoint.

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Aug 2007 12:57:14 -0400

I'm in favor of dropping the diagrams. I agree it's hard
to match up the diagrams to the steps in the text. Using
ASCII art, I think it will be hard to make this work. And
without this correspondence, I don't think the diagrams
add very much. In fact, they confuse things.

That's just my personal opinion, BTW.

Thanks,

Steve

---

From: "Paul Sangster" <[email-masked]>
Date: Tue, 14 Aug 2007 17:50:17 -0700

Would anyone like to argue that the diagrams (figure 2 and 3) are
important to remain (justifying their use of nearly 1 page of the spec)?

> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2007 9:57 AM
> To: Paul Sangster; Tim Polk; Kaushik Narayan
> Cc: [email-masked]
> I'm in favor of dropping the diagrams. I agree it's hard to 
> match up the diagrams to the steps in the text. Using ASCII 
> art, I think it will be hard to make this work. And without 
> this correspondence, I don't think the diagrams add very 
> much. In fact, they confuse things.
> 
> > Thanks for the prompt and enlightening response.  In general, I am 
> > fine with your responses, so I deleted most of the quoted 
> > Collector, Posture Broker, and Posture Validator were not 
> addressed in 
> > the terminology section.
> 
> [PS] Presume you would prefer we not mention those components 
> in the terminology but instead try to be descriptive.  We 
> could try this or create terminology entries for the couple 
> that we use.  The challenge is several folks have asked for 
> more precise term definitions so we used those names.  We 
> could also include references "Posture Collector (see section 
> 5.1.1.1)"...
> 
> > 
> [PS] Sounds like its not worth a big change but we'll try to 
> make a minor change to improve the situation.
> 
> > 
> > >
> > > </Kaushik>
> > >
> > >>
> > > Yes. The document talks about the global posture assessment 
> > > attribute which is mandatory to support for posture 
> broker clients 
> > > and servers.
> > >
> > > </Kaushik>
> > >
> > 
> > That makes sense to me, but it doesn't seem to be clearly 
> specified as 
> > a requirement.  I don't think that is a significant problem, but if 
> > the WG has consensus on this maybe we should clearly state it.
> 
> [PS] We currently defined just the protocol capability 
> (normative) requirements as these affect the WG protocol 
> selection process (e.g.
> PB-1 says protocol must be able to carry the result 
> attributes).  We didn't define NEA Client/Server processing 
> requirements such as what the Posture Broker Client must be 
> able to do with different types of error/success result 
> attributes.  Hopefully this was the right decision as we 
> didn't want to state requirements for all the semantics that 
> NEA components would need to provide.  When a PB protocol is 
> selected and the result attributes defined they will describe 
> their syntax and semantics.
> 
> > 
> > >>
> > >>
> > >> Section 6.
> > >>
> > > 6.1.1 & 6.1.2. We did not intend a co-relation to a 
> specific example 
> > > and that's why you notice the difference in steps.
> > >
> > more information may be needed in Figure 2.  For example 
> "Pos Req" or 
> > a variant of that is the label on five arrows.  Those five arrows 
> > correspond to
> > 
> > attributes to the Posture Broker Server.
> > (2), (3) Posture Broker Server aggregates the PA messages and sends 
> > them to the NEA client via the Posture Transport Server.
> > (4) The Posture Transport Client sends the aggregated PA 
> messages to 
> > the Posture Broker Client.
> > delivers them to the appropriate Posture Collector(s).
> > 
> [PS] As Kaushik mentioned the diagram was supposed to be 
> generic covering all initial assessment cases but as a result 
> don't correspond well with the detailed use cases defined.  
> We included the illustrations with the understanding that if 
> they caused confusion we would consider removing them.  We 
> didn't feel strongly that they were needed but until now 
> noone had mentioned that they were confusing.  Do folks 
> believe we should try to repair them or just drop both form 
> the document (saving a page)?
> 
> > 
> > >
> > >
> > >> 7.3
> > >>
> > >> Requirement PB-4
> > >>
> > > You mean MUST or SHOULD. This was discussed at the Prague IETF 
> > > meeting and moved from a SHOULD to a MAY.
> > >
> > No need to reopen discussion on this item.  MAY is 
> consistent with the 
> > rationale provided for my comment on 5.2.2.  I am satisfied 
> that the 
> > WG has considered the issue.
> 
> [PS] Ok, their hasn't been strong support to move this back 
> to SHOULD yet but if this occurs we could consider it.  Note 
> this is a requirement that applies to our protocol selection 
> (the WG can still select a PB protocol that has strong 
> security capabilities) even with a MAY in this requirement.
> 
> > 
> > >
> > >> 8.1.2
> > >>
> > >> the possibility of a bootstrapping ought to be addressed 
> earlier, 
> > >> and we should clearly state which component (PB Client or PC?) 
> > >> resolves this type of question...
> > >
> > >
> > > <Kaushik>
> > >
> > > Would this be a requirement or update to the reference model to 
> > > state that the OS discovery would be handled by the Posture 
> > > Collector. I am not sure about the motivation to special 
> case the OS 
> > > type different
> > from any
> > > other
> > > standard attribute.
> > >
> > > Regards,
> > >  kaushik
> > >
> > >
> > > </Kaushik>
> > 
> > with the definitions of posture and posture attribute in 2., so I 
> > couldn't figure out how the posture validator(s) knew which OS a 
> > system ran.  Without that knowledge, the posture validator(s) can't 
> > know which attributes to request.
> > 
> > posture attributes for all recognized OSes, and sort out 
> the results; 
> > or (2) interrogate the endpoint and request teh attributes 
> that make 
> > sense.
> > 
> > discovery may be performed by requesting posture attributes that 
> > describe the OS, etc.  but that this step was omitted from 
> the example 
> > since multiple round trips complicate the base concepts.  This also 
> > implies the definitions of posture and posture attribute could be 
> > expanded...
> > 
> > definition of posture.
> We could add a couple clauses in the examples to make it more 
> clear that the OS version is treated like other component 
> (e.g. firewall) versions on the endpoint.
> 
> > 
> > Thanks again,
> > 
> > Tim Polk
> > 
> > 
> >

---

From: "TS Glassey" <[email-masked]>
Date: Fri, 17 Aug 2007 07:29:10 -0700

FYI -
In the US and in many other countries the DoE does a number of key things 
with what are called SCADA systems. SCADA is "Systems Control and Data 
Acquisition" & fwiw NEA would be a good qualification tool for SCADA and 
other types of control/analytical systems. This opens a new opportunity 
which I hadnt looked at myself, but which would support NEA's deployment at 
a national level.

Tim Polk may want to investigate this as well within NIST as there was just 
a new push in Congress to expand NIST's budgets as well as set up a eDARPA 
(for energy and energy control related technologies) enetity to push 
research there.

Just a thought.

Todd