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

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Wed, 18 Mar 2009 10:51:03 -0400

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.

---

From: "Paul Sangster" <[email-masked]>
Date: Thu, 19 Mar 2009 12:00:39 -0700

Susan, thanks for the comments.  Feedback is in-lined... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Susan Thomson (sethomso)
> Sent: Wednesday, March 18, 2009 7:51 AM
> To: [email-masked]
> Subject: [Nea] Comments on PA-TNC and PB-TNC I-Ds
> 

Yes we could tighten up the wording to a MUST if we call out that
version errors be reported in a message using a version supported by the
sender.  I don't think we want responses being sent using a version that
isn't supported by the sender as this would be confusing to the
recipient.  The only question is whether we want to move to MUST for the
other cases.  Doing so should improve interoperability but potentially
at the cost of some flexibility for implementations (e.g. allowing an
implementation to have a policy setting saying it always sends messages
using version X even when it receives a message with version Y).  I'm
fine with your suggestion if others concur.

> current version 0 discovery and leave the version 1 processing as is.

The use of version 0 was to allow a party to inquire about the supported
set of protocol versions supported by the recipient.  We could drop the
version 0 special meaning and have the sender just use its highest (or
configured) version number and expect that this might cause more
'version not supported' type errors in the recipient.  The result is the
same that the  sender will receive the 'version not supported' attribute
and will learn the range of version supported.  I believe the only
reason to keep version 0 is so its not considered an error condition by
the recipient of the message (thus logged and included in an error
database or MIB of some sort).  I'm fine with dropping version 0 if the
WG find the 1 sentence in the spec describing it to be problematic.

> - It would also be good to try to ensure consistency with PB 

Will work with the PB editors to get a consistent approach across specs.
If we decide on something like what is in PA we can apply that to PB.

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

Agreed, this one is a different case then the other and I'm fine with
raising it to MUST.  Any objections?

> which of the messages they had sent caused the error."

Thanks will incorporate some of these wording suggestions.  Not sure why
"for example" is a problem since it is just an example being discussed.

> PB-TNC spec:

Will let the PB editor team respond to these.

<snip>

Paul

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 23 Mar 2009 02:05:58 -0400

I'm fine with the PB-TNC changes suggested by Susan below.
They all seem quite reasonable to me. Let's discuss them at
the NEA WG meeting tomorrow.

Thanks,

Steve

> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
>