Skip to main content

Early Review of draft-ietf-idr-ext-opt-param-09
review-ietf-idr-ext-opt-param-09-secdir-early-cam-winget-2020-12-17-00

Request Review of draft-ietf-idr-ext-opt-param
Requested revision No specific revision (document currently at 13)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2020-12-07
Requested 2020-11-12
Requested by Susan Hares
Authors Enke Chen , John Scudder
I-D last updated 2020-12-17
Completed reviews Rtgdir Early review of -04 by Matthew Bocci (diff)
Rtgdir Early review of -07 by Joel M. Halpern (diff)
Secdir Early review of -09 by Nancy Cam-Winget (diff)
Opsdir Last Call review of -11 by Al Morton (diff)
Genart Last Call review of -11 by Christer Holmberg (diff)
Comments
The security reviewer should read the following from the shepherd: 

https://mailarchive.ietf.org/arch/msg/idr/I-NJotd8_5TFgJ_kSdcKI-mQim8/
Assignment Reviewer Nancy Cam-Winget
State Completed
Request Early review on draft-ietf-idr-ext-opt-param by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/_tdwi02k1uDsL3dD73kmcaioVro
Reviewed revision 09 (document currently at 13)
Result Ready
Completed 2020-12-17
review-ietf-idr-ext-opt-param-09-secdir-early-cam-winget-2020-12-17-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 the allowance for the extended optional parameters in
BGP to be greater than 255.  As written, the document is straightforward and on
point. I only have an editorial nit and a suggestion.

NIT:
Section 2: 1st sentence of the 7th paragraph "that in the..." Needs to be fixed.
Should it be: "that is in the..."?

Suggestion:
- As new drafts need to include security and privacy considerations, I think it
would be good to just add in the security section (5) that it doesn't change
both underlying security or privacy issues as noted in RFC5272.