Skip to main content

Early Review of draft-ietf-idr-ext-opt-param-04
review-ietf-idr-ext-opt-param-04-rtgdir-early-bocci-2016-06-22-00

Request Review of draft-ietf-idr-ext-opt-param
Requested revision No specific revision (document currently at 13)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-06-22
Requested 2016-06-06
Authors Enke Chen , John Scudder
Draft last updated 2016-06-22
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)
Assignment Reviewer Matthew Bocci
State Completed
Review review-ietf-idr-ext-opt-param-04-rtgdir-early-bocci-2016-06-22
Reviewed revision 04 (document currently at 13)
Result Has Issues
Completed 2016-06-22
review-ietf-idr-ext-opt-param-04-rtgdir-early-bocci-2016-06-22-00

Authors,



I have been asked to do a QA review of draft-ietf-idr-ext-opt-param-04.txt.







Summary:



The document is reasonably straight forward and is well written. I have a few
comments below.





Comments:



Minor Issues:



1) Section 2, Protocol Extensions.

You have labelled the existing Length and Type fields as 0xFF. I assume the
meaning of the second is still 'Type' since that is

what any implementation would reasonably interpret it as, and that is the
registry you are using a code point from. So it

might be better to say in the text above the figure at the top of page 3 that
the length and type fields in [RFC4271]

are set to 0xFF.



Also, you don't explicitly define what a receiver should do with the length
field if the type is 0xFF. Does it ignore it,

or does it check that it is 0xFF and treat the OPEN message as malformed if it
is < 0xFF?



Since the document changes the procedures in RFC4271 for BGP Open optional
parameters where length > 255, in that the

original length field is no longer to be interpreted as the actual length, then
I think you should mark this draft as

'Updates: 4271'.



2) Section 5: Security Extensions

The security considerations section seems to be lacking detail and amounts to
one line:

 "This extension to BGP does not change the underlying security issues"

 It might be worth being a little more explicit, or at least use wording
 similar to RFC5492, and saying that it does not

 add any new security issues that are not inherent in BGP [RFC4272].









Regards



Matthew