Re: [Nea] Verifying WG consensus on spec changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nea] Verifying WG consensus on spec changes
The changes look like an improvement to me. I support these
modifications.
> -----Original Message-----
> From: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On
> Behalf Of Stephen Hanna
> Sent: Monday, April 06, 2009 7:20 AM
> To: nea at ietf.org
> Subject: [Nea] 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.
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www.ietf.org/mailman/listinfo/nea
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.