[bess] Murray Kucherawy's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I concur with Barry's point about the definitions in Section 2.2.

I can't quite parse the first sentence of Section 3.1.1.  Maybe this will help:

OLD:

   A condition to consider that the status of a P-tunnel is Up is that
   the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
   is reachable through unicast routing tables.

NEW:

   When determining whether the status of a P-tunnel is Up, a condition
   to consider is whether the root of the tunnel, as determined in the
   x-PMSI Tunnel attribute, is reachable through unicast routing tables.

Section 3.1.2 has a similar concern.

Why is that a SHOULD and not a MUST in Section 3.1.6.1?  Same question about
3.1.6.2, and the ones in 4.2.  Or, if they are correctly SHOULDs, you might
consider giving some guidance to the reader about when one might go about
deviating from the advice given, since SHOULD offers a choice.

I think in Sections 7.2 and 7.3, you don't need "this document" references for
unassigned things.