Re: [Nea] Verifying WG consensus on spec changes

[Stephen Hanna <shanna at juniper.net>]

I saw six emails supporting these changes. No concerns
were raised. Therefore, I declare WG consensus to make
these changes.

Editors, please make these changes and post revised
drafts of PA-TNC and PB-TNC. At that point, we should
be ready to send those drafts to the IESG since we have
addressed all the comments that came up during WGLC.

Thanks,

Steve

> -----Original Message-----
> From: Stephen Hanna 
> Sent: Monday, April 06, 2009 10:20 AM
> To: nea at ietf.org
> Subject: Verifying WG consensus on spec changes
> 
> PA-TNC and PB-TNC recently completed WG LC. The
> only comments received were from Susan Thomson.
> These comments have been discussed on the email
> list and the NEA WG F2F meeting at IETF 74.
> So far, the WG seems to have consensus for the
> changes listed below.
> 
> I'd like to verify this consensus on the mailing
> list. Please review the changes listed below and
> respond within one week (by 11 AM EDT on Monday,
> April 13). Indicate in your response whether you
> support the changes. If you support the changes,
> a one word response ("Support") is sufficient.
> If not, please explain your concerns and suggest
> how they could be resolved.
> 
> Thanks for your prompt and careful attention to
> this matter. Once we agree on changes, we can
> revise these specs and send them to the IESG.
> 
> Thanks,
> 
> Steve
> 
> ----------
> 
> Proposed Changes to PA-TNC
> 
> In the description of the Version field in section 3.7,
> change the text that says "Implementations responding
> to a PA-TNC message containing a supported version SHOULD
> use the same Version number" to say MUST instead.
> 
> Remove the first two sentences of the next paragraph.
> These describe using version 0 for version discovery.
> The WG has decided to remove that feature. Merge the
> remaining sentence of this paragraph with the previous
> paragraph and emphasize that the Version Not Supported 
> error code must go in a PA-TNC message with version 1.
> This point is already mentioned in section 4.2.8.2 but
> it's a good idea to mention it here, too.
> 
> In section 4.2.8.2, change both instances of SHOULD to
> MUST in the fourth paragraph to remove needless ambiguity.
> 
> In the description of the Message Identifier field in
> section 3.7, change the second sentence to be "This value
> can be included in the payload of a response message to
> indicate which message was received and caused the response."
> Change the third sentence to say "This value is included
> in the payload of PA-TNC error messages so the party who
> receives the error message can determine which of the
> messages they had sent caused the error."
> 
> Proposed Changes to PB-TNC
> 
> In section 3.1, clarify the second sentence of the second
> paragraph by changing "batches of messages" to "a single
> batch of messages". The resulting sentence will read
> "In this mode, the Posture Broker Client and Posture
> Broker Server take turns sending a single batch of messages
> to each other."
> 
> Change version handling to match PA-TNC. Among other changes,
> the Version field will become one byte long and a Version
> Not Supported error code will be added. Some differences
> will remain. For example, certain PB-TNC version numbers
> are reserved to ensure that PB-TNC batches can be distinguished
> from similar protocols previously defined by other parties.
> The version number defined for the initial version of PB-TNC
> will remain 2. Reserved version numbers will be listed.
> 
> In section 4.6, say that the Posture Broker Server MUST NOT
> include a message of type PB-Assessment-Result in a batch
> whose type is not RESULT. This was a SHOULD NOT. Also, fix
> a typo in this section where PB-Access-Recommendation should
> be PB-Assessment-Result.
> 
> In section 4.7, say that the Posture Broker Server MUST NOT
> include a message of type PB-Access-Recommendation in a batch
> whose type is not RESULT. This was a SHOULD NOT. Also, say
> that the Posture Broker Server MAY include one  message of
> this type in any batch of type RESULT. That was a SHOULD.
>