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

[Stephen Hanna <shanna at juniper.net>]

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

> -----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)? 
> 
> - 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. 
> 
>  
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www.ietf.org/mailman/listinfo/nea
>