Last Call Review of draft-ietf-pce-pcep-mib-10
review-ietf-pce-pcep-mib-10-secdir-lc-wallace-2014-10-30-00

Request Review of draft-ietf-pce-pcep-mib
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-28
Requested 2014-10-02
Draft last updated 2014-10-30
Completed reviews Genart Last Call review of -10 by Peter Yee (diff)
Genart Telechat review of -10 by Peter Yee (diff)
Secdir Last Call review of -10 by Carl Wallace (diff)
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-pce-pcep-mib-10-secdir-lc-wallace-2014-10-30
Reviewed rev. 10 (document currently at 11)
Review result Has Issues
Review completed: 2014-10-30

Review
review-ietf-pce-pcep-mib-10-secdir-lc-wallace-2014-10-30

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.


This document describes a MIB that "describes managed objects for modeling
of Path Computation Element communications Protocol (PCEP) for
communications between a Path Computation Client (PCC) and a Path
Computation Element (PCE), or between two PCEs”.

I am not a MIB guy and did not review the definitions.  The security
considerations section mostly addresses SNMP related considerations in
general via references to other specs.  This seems fine.  The only minor
nit here is the following:

	Implementations MUST provide the security features described by the
SNMPv3 framework (see [RFC3410]), including full support for
authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826].

RFC3410 only defines support for use of CBC-DES.  If support for AES is
intended instead of DES, that should be noted more strongly here.  The
requirement for "full support" of RFC3414 could be misinterpreted.