[Nea] Operations Directorate Review of draft-ietf-nea-pt-tls-05

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi, 

This is an OPS-DIR review for draft-ietf-nea-pt-tls-05. Although this is
not an easy reading for a non-expert, it's a well written specification,
based upon wide field experience with proprietary protocols, and I do
not expect major obstacles in operational deployment. 


A few issues triggered by the checklist in RFC 5706: 

1.        'Does the new protocol need supporting services (e.g., DNS or
          Authentication, Authorization, and Accounting - AAA) added to
          an existing network?'

The protocol stacks atop of TLS. Section 3.4.3 (TLS requirements)
includes a SHOULD requirement for TLS 1.2, but neither here nor in other
parts of the document I could find a requirement that PT-TLS
implementations MUST support TLS 1.0 and TLS 1.1. The authors may want
to add this.

I believe that mentioning the fact that the protocol is layered atop of
TLS in the title and Abstract would make this key design issue more
clear to the readers.

2. The protocol uses the Vendor PEN, but assumes it is limited to
24-bit. 

In Section 3.5 - Message Vendor ID - .  

      Consistent with PA-TNC and PB-
      TNC, we depend on the PEN fitting in 24 bits, so if IANA were to
      register a wider PEN than that PEN could not be used with NEA.
      IETF namespace PT-TLS Message Types MUST use zero (0) in this
      field.  


However, discussions triggered by draft-liang-iana-pen-00 may end by
that document recommending that new protocols define at least 32-bit PEN
fields. Is this impossible in this case? What are the 8 bits preceding
the Message Type Vendor ID Reserved for?

3. 'Have suggestions for verifying correct operation been discussed?'

Not really. How are assessment results communicated to the operators?
Are they public? Maybe they MUST NOT be public (because of privacy
concerns for example)? The document says nothing about this. Same
question about errors, authentication failures, or other error counts.  

4. 'Has management interoperability been discussed?'

As with many other security-related protocols this document offers
little to none information about manageability, so interoperable
management does not seem to be an issue, or maybe these aspects are
discussed in another document. In any case, this could be explained in
text. 

5. Editorial observation - Readability could be improved if acronyms
like MITM (Man-in-the Middle) would be expanded at their first
occurrence. 

Regards,

Dan