Skip to main content

Last Call Review of draft-ietf-ccamp-flexible-grid-ospf-ext-07
review-ietf-ccamp-flexible-grid-ospf-ext-07-secdir-lc-meadows-2017-01-26-00

Request Review of draft-ietf-ccamp-flexible-grid-ospf-ext
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-01-31
Requested 2017-01-17
Authors Xian Zhang , Haomian Zheng , Ramon Casellas , Oscar Gonzalez de Dios , Daniele Ceccarelli
I-D last updated 2017-01-26
Completed reviews Rtgdir Telechat review of -07 by Ben Niven-Jenkins (diff)
Opsdir Telechat review of -07 by Bert Wijnen (diff)
Secdir Last Call review of -07 by Catherine Meadows (diff)
Genart Last Call review of -07 by Pete Resnick (diff)
Genart Telechat review of -08 by Pete Resnick (diff)
Assignment Reviewer Catherine Meadows
State Completed
Request Last Call review on draft-ietf-ccamp-flexible-grid-ospf-ext by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 09)
Result Has nits
Completed 2017-01-26
review-ietf-ccamp-flexible-grid-ospf-ext-07-secdir-lc-meadows-2017-01-26-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 extensions to the Open Shortest Path First (OSPF)
Traffic-Engineering (TE) protocol to support GPLS control of networks that
include devices that use the new flexible optical grid introduced by the
International Telecommunication Union Telecommunications Standardization Sector
(ITU-T). It defines GLMPS OSPF-TE extensions that support advertising available
frequency ranges for flex-grid links.

In the Security Considerations section, the authors point out that this
document extends RFCs [RFC3630] and [RFC7580] to carry flex-grid specific
information in OSPF Opaque LSAs. Thus this document does not introduce any new
security considerations beyond previous RFCs  specifying these LSAs, and the
security mechanisms described in [RFC2328] applying to these mechanisms still
apply.

I think this is a valid point, and well expressed.  However, when I looked
through the document (using both manual and automatic search methods) I was
surprised to find that no explicit mention of OSPF Opaque LSAs other than in
the Security Considerations section.  It would be helpful to have a specific
mention of them in the body of the document, and a brief discussion of how they
are used to implement the extensions.  This would give a the reader a better
understanding of how the Security Considerations section relates to the rest of
the document.

Other than that, I think the document is ready.

Cathy Meadows

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil <mailto:catherine.meadows@nrl.navy.mil>