A Posture Transport Protocol over TLS (PT-TLS)
draft-ietf-nea-pt-tls-08

Comment updated after discussion of implementation status with
the document shepherd.

---

I think that the protocol is intended to transport Security Postures
not any old postures. I would have benefited from a clear and early
definition of "Security Posture" - probably lifted from RFC 5209 
although a citation might be enough.

I should have liked to see these issues clarified in the Abstract and
at the top of the Introduction.

Version -08 handles all of my comments, and clears the IANA DISCUSS.  Thanks!

In the OPS-DIR Review by Nevil Brownlee on 20-Nov-2012, this comment was provided:

I have performed an Operations Directorate review of
   draft-ietf-nea-pt-tls-08.txt

This is a Standards Track document, describing PT-TLS, "a TLS-based
Posture Transport (PT) protocol.  The PT-TLS protocol carries the
Network Endpoint Assessment (NEA) message exchange under the
protection of a Transport Layer Security (TLS) secured tunnel."

The document is quite long, and assumes that the reader is familiar
with Trusted Computing, Endoint Assessment, and with many acronyms
that I hadn't encountered before.  That meant that I also had to read
(or at least skim) quite a few of the of the Normative-Reference RFCs
before completing this review.  I suggest that an appendix listing
these acronyms and giving a few lines of explanation would be helpful.

The document is clearly intended to describe version 1 of PT-TLS,
but this is implied in section 3.7.1 rather than being explicitly stated.
Perhaps it would help to state this early on in section 3.5?

How will implementors find out that newer versions of PT-TLS exist?

The IANA Considerations section seems odd to me.  It says "This
delegation of namespace is analogous to the technique used for OIDs;"
which existing IANA Registry are you referring to?
Have you asked IANA whether they can support the two-dimensional
tables you're asking for?

a single comment:
It is worth noting in Section 3.1.1 that there can be also firewalls in the network which prevent the server from reaching the client. The text describes only the case where the end device has a firewall.

2119 language in IANA Considerations always gives me the creeps. I don't think the ones in section 6.1 are necessary:

   Instead, designated experts should focus on the following
   requirements.  All values in these IANA registries MUST be
   documented in a specification that is permanently and publicly
   available. IETF namespace values MUST also be useful, not
   harmful to the Internet, and defined in a manner that is clear
   and likely to ensure interoperability.

I think both "MUST"s here could simply be lowercased, or change to "are required to".

   There are several ways to ensure that a specification is
   permanently and publicly available.  It may be published as an
   RFC.  Alternatively, it may be published in another manner that
   makes it freely available to anyone.  However, in this latter
   case, the vendor MUST supply a copy to the IANA and authorize
   the IANA to archive this copy and make it freely available to
   all if at some point the document becomes no longer freely
   available to all through other channels.

Here, better would be "will need to".

  I would really like to see the title of this document updated.
  PT-TLS indicates that TLS must be used, but the title indicates
  that TCP must be used.  I think the title should reflect that
  both TCP and TLS must be used.

I cleared.

I needed to get to the third para of the intro before I could find a reference to the definition of "Posture", it would be useful to quote the definition in this RFC and to move the reference to the first para.