Subject: Re: [Nea] Verifying NEA WG Consensus from Dublin

From: "Stephen Hanna" <[email-masked]>
Date: Sat, 11 Oct 2008 09:26:01 -0400

I didn't see any responses to this email. We did have
consensus in favor of these items at IETF 72. I guess
that people are too busy to confirm this on the list.

We'll have the NEA editors make these changes. WG
consensus will be confirmed on the list when we have
the WG LC on the specs.

Thanks,

Steve 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephen Hanna
> Sent: Tuesday, September 23, 2008 10:45 AM
> To: [email-masked]
> Subject: [Nea] Verifying NEA WG Consensus from Dublin
> 
> I'd like to verify WG consensus on a few items that
> were discussed at the NEA WG meeting at IETF 72.
> All of these seemed to have consensus among those who
> attended the meeting but I would like to verify that
> consensus on the NEA email list since only consensus
> on the email list is true WG consensus in the IETF.
> Therefore, please send email to the list to indicate
> if you agree with these items and, if not, which ones
> you disagree with and why.
> 
> Please respond within two weeks (by October 7)
> so that the PA-TNC and PB-TNC editors can complete
> the next revisions of these drafts promptly.
> 
> I will send out another email in a minute on a
> topic that did not seem to have consensus at the
> NEA meeting in Dublin: IANA Considerations.
> 
> Thanks,
> 
> Steve
> 
> PB-TNC Changes
> --------------
> Ravi Sahita proposed moving the PB-Batch-Type to the PB-TNC header.
> This is a 16 bit integer with enumerated values that indicate
> the type of the batch. It's currently carried in a PB-TNC message
> of type PB-Batch-Type but we require that there be one and only
> one such message in each batch so it seems that it would just
> be simpler and more efficient to move this field into the PB-TNC
> header. We already have 24 reserved bits in that header so
> there's no problem with making this change.
> 
> When a full-duplex PT is being used, we'd like to allow either the
> NEA Client or NEA Server to request a retry at any time. Right now,
> PB-TNC is strictly half-duplex even if the PT is not and that tightly
> restricts when the NEA Client and NEA Server can request retries
> (only when it's their turn to send). That causes problems if one side
> detects a problem such as a change in policy or in endpoint
> configuration. They might have to wait a long time to be able to
> signal this problem and request a retry. In fact, they might have to
> wait indefinitely. This change is not a big one but it does modify
> the state machine to indicate that whenever SRETRY is allowed,
> CRETRY is also allowed and vice versa.
> 
> A PB-TNC RESULT batch currently includes an Access-Recommendation
> that contains one of the values Access Allowed, Quarantined, or Access
> Denied. There's currently no way in PB-TNC to indicate whether the
> NEA Client was found to be compliant with policy. So we suggest adding
> posture assessment that could have values like Compliant, 
> Non-Compliant,
> Non-Compliant Major Issue, Error, and Don't Know.
> 
> PA-TNC Changes
> --------------
> 
> First, we propose changing how attribute correlation is handled.
> Currently, a Correlation ID is used to handle the case where a
> single Posture Collector is able to gather information on
> several products. This is somewhat unusual but it causes problems
> since that Posture Collector might send a single PA-TNC message
> with multiple Product Information, Numeric Version, and Operational
> Status attributes, for example. Which Product Information attribute
> goes with which Numeric Version Attribute? Today, we solve this
> problem by tagging the attributes with an optional Correlation ID.
> The proposed new solution to this problem is to have a Posture
> Collector that wants to report on several products use a different
> Posture Collector ID for each product that it reports on. This removes
> the need to have a special protocol feature to handle this case.
> Effectively, it pushes the tagging up the stack into PB where we
> already have a field that can be used to solve this problem.
> The main advantage is that it simplifies the protocol. The main
> disadvantage is that it complicates the Posture Broker Client
> and Posture Collector implementation if they want to handle this
> case since they need to handle "virtual" Posture Collector IDs.
> 
> The second suggested change in PA-TNC is the addition of an Assessment
> Result attribute that would allow a Posture Validator to inform a
> Posture Collector about the compliance decision for a component, just
> like the similar proposal for PB-TNC above but specific to a 
> component.
> 
> The third suggested change in PA-TNC is the addition of a Remediation
> attribute that would allow a Posture Validator to send remediation
> instructions to a Posture Collector. This is a valuable feature since
> the Posture Collector is the best place to do automated remediation.
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
> 
_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea