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.