Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04

["John G. Scudder" <[e-mail]>]

Hi Matthew and all,

Thanks for the review. Some comments below.

> From: "Bocci, Matthew (Nokia - GB)" <[e-mail]>
> Date: 6/21/2016 6:10 AM (GMT-05:00)
> To: [e-mail], Susan Hares <[e-mail]>, [e-mail], [e-mail], [e-mail]
> Subject: [Idr] Routing directorate QA review of	draft-ietf-idr-ext-opt-param-04
...

> 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.

Is your proposal to use the diagram verbatim from 4271, but say in the prose that the type and length are 0xFF? I'm fine with whatever seems clearer to folks.

> 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?

This is a good question, and TBH I don't recall why we specified a value for the legacy length field instead of simply saying it should be ignored.
Maybe Enke remembers? Right now I'm inclined to say it should be ignored on receipt, but I'm open to discussion. I guess even if we make that change we can still spec it be sent as 0xFF, for purposes of debuggability, but this is not a big deal.

> 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'.

Good point, will fix.

> 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]. 

Good point, will change.

Thanks,

--John