[Nea] Comments on draft-sangster-nea-pa-tnc-00..txt

[Gary Tomlinson <gtomlinson at SonicWALL.com>]

The following comments are regarding the individual submission
draft-sangster-nea-pa-tnc-00.txt of a PA protocol for consideration by the
NEA WG as a base to develop the PA protocol from.

Again, I am impressed (like I was with the PB submission from TNC) with the
level of completeness in this proposal (no doubt due to the maturity of the
TNC work) and think it warrants strong consideration by the WG as a starting
point.

As usual, I do have a number of specific comments.

First, I have a general comment regarding the IETF Vendor Id value 0 as it
is applied in this document.  I found having repeated per IETF name space PA
subtype (all those defined in this specification) qualification to the IETF
Vendor Id to be redundant and make it harder to get to the chase of each PA
subtype structure.  Given section 2.4 clearly states all PA subtypes defined
in this document are applicable to only the IETF vendor ID, I think it would
be good to simplify the prose per PA subtype and eliminate the
interpretation of name space qualification to Vendor Id 0. This comment does
not apply to Vendor ID usage within attribute types as there is a need to
distinguish at this level in cases such as page 36, section 3.2.8.

Page 10, section 2.4.  I can't find any definitions for the PA subtypes in
this document nor in any of the references.  Given these are being defined
in the IETF name space, I think it is necessary to eliminate ambiguity as
I'd guess not everyone in the WG has a consistent definition of them let
alone people outside this work group.  Ideally from my point of view, a set
informative references can be found that address this.

Page 12, section 2.5 Message Identifier.  Why is the PA protocol state
machine not required to check for duplicate identifiers if this is a
protocol violation?  Not requiring this seems like a recipe for trouble.

Page 30, section 3.2.6.  Why is the Port Filter attribute support
restriction applied to VPN subtypes?  I can see it being applied to layer 4
firewall collectors, but find VPN a little muddy.  I realize many VPN
clients do provide layer 4 port filtering, however I see that as a firewall
service that is being provided in addition to VPN, and as such would think
these components should register themselves as both a VPN and a Firewall
subtype.

Page 32, section 3.2.6.  Why is there a restriction on mixed blocked and
non-blocked protocol/port pairs in a single port filter list attribute?
Each protocol/port element has its own flags field and thus is capable of
being unambiguously qualified as blocked or non-blocked in the protocol.

Pages 40-43, section 3.2.8.1. Just a nit here, but there is inconsistency in
the labeling of copied fields in the diagrams.  Some are labeled "Copy of
..." and other and simply "...".  All of them that are copies should be
labeled "Copy of...".

Page 46, section 4.8.  What is the definition of typical here?  Is it an
observation from systems deployed in the field today; and if so are they
using a protocol similar to PA-TNC?  Also, given PA-TNC allows vendor
defined attributes with who knows how much size, like say X.509 chains, I
suggest any mention of typical be qualified by use of PA-TNC defined IETF
name space attributes.

Page 60, reference 8.  Why is this informative and not speculatively
normative?

Gary

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www.ietf.org/mailman/listinfo/nea