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

["Paul Sangster" <Paul_Sangster at symantec.com>]

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

> -----Original Message-----
> From: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On 
> Behalf Of Susan Thomson (sethomso)
> Sent: Wednesday, March 18, 2009 7:51 AM
> To: nea at ietf.org
> Subject: [Nea] Comments on PA-TNC and PB-TNC I-Ds
> 
> 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)? 

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.

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

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 
> protocol as
> well.

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.

> 
> Section 4.2.8.2 Version Not Supported Error Code
> 
> - 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?

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

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