Skip to main content

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 revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-28
Requested 2014-10-02
Authors Kiran Agrahara Sreenivasa , Stephan Emile , Quintin Zhao , Daniel King , Jonathan Hardwick
I-D last updated 2014-10-30
Completed reviews Genart Last Call review of -10 by Peter E. Yee (diff)
Genart Telechat review of -10 by Peter E. Yee (diff)
Secdir Last Call review of -10 by Carl Wallace (diff)
Assignment Reviewer Carl Wallace
State Completed
Request Last Call review on draft-ietf-pce-pcep-mib by Security Area Directorate Assigned
Reviewed revision 10 (document currently at 11)
Result Has issues
Completed 2014-10-30
review-ietf-pce-pcep-mib-10-secdir-lc-wallace-2014-10-30-00
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.