Hi Mahesh, > 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 would suggest that we get on a call to discuss this. I have attempted to address the issues that have arisen with the wording. Being clear about the intent and the future of the document seems like it was necessary. If there is still a problem, I am still unclear on what it is. > 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. I posted proposed text to address Luigi’s comments. I have not heard any feedback as to whether that revision is acceptable. Tony _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
