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



I agree with these changes.
Thanks for the clear proposed change report Steve.

-Ravi 

-----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.