[Lsr] Mahesh Jethanandani's No Objection on draft-ietf-lsr-dynamic-flooding-algorithm-04: (with COMMENT)

[Mahesh Jethanandani via Datatracker <[e-mail]>]

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-lsr-dynamic-flooding-algorithm-04: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding-algorithm/



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

Abstract, third and fourth paragraphs:

24 >    This document discloses the algorithm that we have developed in order
25 >    to make it easier for other developers to implement similar
26 >    algorithms.  We do not claim that our algorithm is optimal, rather it
27 >    is a pragmatic effort and we expect that further research and
28 >    refinement can improve the results.
29 >
30 >    We are not currently proposing that this algorithm be standardized,
31 >    nor that the working group use this as a basis for further
32 >    standardization work, however we have no objections if the working
33 >    group chooses to do so.  This document is published as an
34 >    Experimental RFC to gain operational and implementation experience
35 >    with the specified dynamic flooding algorithm.  The intent is to
36 >    assess the suitability of this algorithm for advancement to the
37 >    Standards Track as a Proposed Standard, pending sufficient deployment
38 >    experience and feedback from the community.

I support Ketan's and Mike's requests to trim this. It's worth adding some
history: Gunter raised essentially the same tension in his shepherding AD
review of -03 back in June -- his major issue #1 was that the draft "claims
the algorithm isn't proposed for standardization yet discusses assessing
suitability for Proposed Standard." Tony's reply said he'd "attempted to
address" the comments, but the paragraphs that survived into -04 read the
same as what triggered that comment. Three ballot positions have now landed
on the identical passage. That suggests the ambiguity isn't obvious to fix
from a general request to tighten the language; a concrete rewrite
suggestion from the responsible AD may get further than a third restatement
of the problem.

---

I thank Luigi Iannone (OPSDIR) for flagging the missing Operational
Considerations section. As draft-ietf-opsawg-rfc5706bis is still a WG
document, I'm not treating this as blocking, but Luigi's specific questions
strike me as exactly right: does every node need to support this algorithm
or can deployments mix it with other computation, can the topology-computation
parameters (DFS depth, tie-breaking) be configured, and what happens to
arc-path integrity when a node on an arc path fails. Section 4 of
RFC 9667 is a reasonable template for the authors to work from.