[Nea] Comments on PA-TNC and PB-TNC I-Ds

["Susan Thomson (sethomso)" <sethomso at cisco.com>]

A few comments on the I-Ds below.

Comments pertain to:
- versioning
- miscellaneous comments on choice of MUST, SHOULD, MAY
- editorial

Thanks
Susan
------------------------------

PA-TNC:

Section 3.7 Version field:

- The spec says Implementations SHOULD use the same version number for
communications.  I don't think we want to allow for the possibility that
different protocol versions try to interoperate? Would it be better to
have this as a MUST (with the exception being versioning errors)? 

- The spec currently requires that a special-purpose version 0 be
supported for version discovery.  Since the  currently specified
"version not supported" error message supports similar functionality
using version 1, I am wondering whether the former is necessary and
whether there is sufficient incentive to use it in practice.  Or put
another way, do we really need both, and can the requirements be met
without a special-purpose version 0? One proposal would be to remove the
current version 0 discovery and leave the version 1 processing as is.

- It would also be good to try to ensure consistency with PB protocol as
well.

Section 4.2.8.2 Version Not Supported Error Code

- Similar comment re SHOULD versus MUST as in section above.

Section 3.7 Message Id

This paragraph confused me initially. I think it would help clarify the
intended use with the following minor changes:
- To the following sentence, add words in asterisk: 
  This value can  be included in *the payload of* a response message to
indicate which message was received and caused the response.
- In the next sentence, rather than saying "for example", say "In this
specification", "this  field 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."

 

 
PB-TNC spec:

Section 3.1 Protocol Overview

2nd sentence, 2nd para: Clarify that the protocol carries a single batch
of PB messages within each turn..., i.e. 
"... takes turns sending *a single batch* of messages to each other."

Section 4.1 PB-TNC Header

Re the Version field: The PB spec supports a version error using the
Invalid Parameter error code, and does not support version discovery.

The PA-TNC spec does support this (although the current spec may be a
tad more than is necessary. See comments above). In any event, once we
have consensus on what is needed, I think it would be good to have the
version processing be consistent across the 2 protocols to help minimize
implementation errors.

Section 4.6 PB-Assessment Result

In the following sentence, is there a reason not to be more strict and
say MUST NOT include PB-Assessment Result in a non-RESULT batch type?
"The Posture Broker Server SHOULD include one message of this type in
any batch of type RESULT and SHOULD NOT include a message of this type
in any other type of batch."

In the second paragraph, there is a typo:
PB-Access-Recommendation -> PB-Assessment Result

Section 4.7 PB-Access-Recommendation

Since there may be other ways to indicate the access provided to the
user, I think the spec should say that the PB-Access-Recommendation MAY
be included in a RESULT batch type.

Also, similar to PB-Assessment-Result, I think we can say MUST NOT be
included in any batch type other than RESULT.