Barry Leiba's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-09: 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-rtgwg-lfa-manageability/



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

I only have a few editorial things to add:

-- Section 4 --

   Implementers SHOULD document their LFA selection algorithms (default
   and tuning options) in order to leave possibility for 3rd party
   modules to model these policy-LFA expressions.

I'm not going to whine about this *too* much, but I don't see this as an
appropriate use of 2119 key words.  I'd be happier if it were changed to
not be a 2119 word.  That said, there's no need for discussion.  Do as
you think best.

-- Section 6.2 --

   3.  If the defined policy does not permit to determine a unique best
       LFA,

The wording here is really awkward English.  The verb "permit" needs a
direct object here, as in "does not permit <someone> to determine
<something>."  You can't just omit the <someone>.  The easiest fix is to
change "to determine" to "the determination of".  (I would also use
"allow" rather than "permit", but that's just a personal wording
preference.)

-- Section 6.2.4.1 --

   When SRLG protection is computed, and implementation SHOULD permit to

Same problem here as in 6.2, above, but because of the list the fix isn't
as easy.  First, "and" should be "an".  Second, the fix should probably
be like this:

NEW
   When SRLG protection is computed, an implementation SHOULD permit the
   following:

   o  Exclusion of alternates violating SRLG.

   o  Maintenance of a preference system between alternates based on
      SRLG violations. [...etc...]
END

In the first sub-bullet, "Preference based on number of violation," both
instances of "violation" should be "violations".

-- Section 7.3 --

   o  MUST be able to display, for every prefixes, the primary next hop
      as well as the alternate next hop information.

"prefixes" should be "prefix".

-- Section 7.4 --
When you say "provide an alert system" here, I think you mean "provide an
alert", or, perhaps better, "trigger an alert" or "generate an alert". 
Presumably, in order to do that, an alert system has to be available. 
But the point here is that you saying when specific alerts should be
triggered/generated.