Skip to main content

Last Call Review of draft-ietf-mpls-tp-temporal-hitless-psm-12
review-ietf-mpls-tp-temporal-hitless-psm-12-secdir-lc-kivinen-2017-03-02-00

Request Review of draft-ietf-mpls-tp-temporal-hitless-psm
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-03-03
Requested 2017-02-17
Authors Alessandro D'Alessandro , Loa Andersson , Satoshi Ueno , Kaoru Arai , Yoshinori Koike
I-D last updated 2017-03-02
Completed reviews Rtgdir Early review of -09 by Dave Sinicrope (diff)
Opsdir Last Call review of -12 by Jon Mitchell (diff)
Secdir Last Call review of -12 by Tero Kivinen (diff)
Genart Last Call review of -12 by Stewart Bryant (diff)
Genart Telechat review of -13 by Stewart Bryant (diff)
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-ietf-mpls-tp-temporal-hitless-psm by Security Area Directorate Assigned
Reviewed revision 12 (document currently at 14)
Result Has nits
Completed 2017-03-02
review-ietf-mpls-tp-temporal-hitless-psm-12-secdir-lc-kivinen-2017-03-02-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 seems to be problem statement and requirements document
for new MPLS path segment monitoring tool. The title does not really
reflect to that and from there it would look more like that this would
define that actul hitless path segment monitoring mechanism. As this
only provides problem statement and requiremens for it, the title
should be changed to say so.

The security considerations section just refers to rfc5921 and 5860.
As this is problem statement and requirements document, I do not think
there is real security considerations in this document, the protocol
document based on this might then have more considerations.

Nits: The OAM term in the document should be expanded both in the
abstract and in the first use.

Summary: Ready with nits.
-- 
kivinen@iki.fi