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
Hi Steve,
I support these changes.
Regards,
kaushik
On 4/6/09 7:20 AM, "Stephen Hanna" <shanna at juniper.net> wrote:
> 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.