Skip to main content

Early Review of draft-ietf-idr-bgp-gr-notification-05
review-ietf-idr-bgp-gr-notification-05-rtgdir-early-chen-2016-06-15-00

Request Review of draft-ietf-idr-bgp-gr-notification
Requested revision No specific revision (document currently at 16)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-06-15
Requested 2016-06-06
Authors Keyur Patel , Rex Fernando , John Scudder , Jeffrey Haas
I-D last updated 2016-06-15
Completed reviews Rtgdir Early review of -03 by Mach Chen (diff)
Rtgdir Early review of -05 by Mach Chen (diff)
Rtgdir Early review of -07 by Emmanuel Baccelli (diff)
Rtgdir Telechat review of -15 by Bruno Decraene (diff)
Opsdir Last Call review of -15 by Qin Wu (diff)
Secdir Last Call review of -15 by Yoav Nir (diff)
Assignment Reviewer Mach Chen
State Completed
Request Early review on draft-ietf-idr-bgp-gr-notification by Routing Area Directorate Assigned
Reviewed revision 05 (document currently at 16)
Result Has nits
Completed 2016-06-15
review-ietf-idr-bgp-gr-notification-05-rtgdir-early-chen-2016-06-15-00
Hi Authors,

I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-07. For
more detail what's is RtgDir QA review, please refer to

https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

Overall, the document is well-written and clear, after review, I have the
following comments.

1.  Abstract
s/BGP NOTIFICATION Message/ BGP NOTIFICATION message;

2.  Section 2:
"
    Flags for Address Family:

            This field contains bit flags relating to routes that were
            advertised with the given AFI and SAFI.

                0 1 2 3 4 5 6 7
               +-+-+-+-+-+-+-+-+
               |F|N| Reserved  |
               +-+-+-+-+-+-+-+-+

   The usage of second most significant bit "N" (which was defined in a
   previous draft version of this specification) is deprecated.  This
   bit MUST be advertised as 0 and MUST be ignored upon receipt.
"
The "N" bit was firstly introduced in a previous version of this document, but
deprecated in later version. I don't understand why a document need deprecate a
functionality introduced by itself, why not just remove it? If we really want
to keep this history, maybe a better way is to move above text to an appendix.

If you agree above, then the last sentence of the first paragraph of section 2
should be changed as bellow:

OLD:
"the Restart flags field and the Flags field for Address Family are augmented
as follows:"

New:
"the Restart flags field are augmented as follows:"

3.  Section 3.1

"Subcode is a BGP Error Subcode (as documented in the IANA BGP Error
   Subcodes registry) as appropriate for the ErrCode.  Similarly, Data
   is as appropriate for the ErrCode and Subcode."
This is just an introduction to the Subcode itself, it's better to explicitly
state that the subcode should be set to the Hard Reset (9).

Hope you find above review useful.

Best regards,
Mach