Zahed - First, thanx to John - his replies are on point and I agree with all of them.
As I mentioned in a previous reply to John, my post was simply to get your agreement on the revised text for that section - it was not intended to address other editorial issues (such as revising related section names) - which we will certainly do when generating an updated version. A few more comments inline. > -----Original Message----- > From: John Scudder <j...@juniper.net> > Sent: Tuesday, April 9, 2024 8:28 AM > To: Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; The IESG <i...@ietf.org>; > draft-ietf-lsr-isis-fast-flood...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; > acee.i...@gmail.com > Subject: Re: Zaheduzzaman Sarker's Discuss on > draft-ietf-lsr-isis-fast-flooding- > 08: (with DISCUSS and COMMENT) > > Hi Zahed, > > I’m sure Les will reply as soon as his TZ allows him adequate caffeination > :-). To > jump-start things, though, a couple questions/comments below. > > > On Apr 9, 2024, at 5:49 AM, Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com> wrote: > > > > Thanks for taking the stab, it is a good start but no quite there yet. > > > > - Now 6.3 and 6.3.2 has the same section title. I would rename section 6.3 > to "Transmitter side congestion control considerations" and 6.3.2 to > "Guidelines for transmitter side congestion controls". Note that here > "transmitter side" congestion control would particularly mean that the > transmitter is in sole change of doing congestion congestion control based on > say - performance measurements of any sort. > > - Rest of changes looks good to me, however, I am not sure we should use > normative text to describe guidelines, unless we say those are requirements > and then perhaps also describe how one should fulfill those requirements. My > understanding is we don't want that sort of details here. I would recommend > to remove all the normative SHOULD and relay on implementer doing the right > thing. We are anyway not doing standard algorithm (s) and accepting > implementation details would vary. > > To be clear, your suggestion is s/SHOULD/should/ throughout the text Les > sent? IMO that would be fine, and would not make the document any less fit > for purpose. Once we have accepted that these are guidelines and not a > statement of an algorithm, it’s very difficult to insist that RFC 2119 > keywords > have much power, doubly so when all of them are SHOULD and not MUST. > > One possible counterargument is that SHOULD makes the document more > useful to the future implementor than “should”. I would (and did!) also accept > that position. > > In short, I don’t much care if the SHOULD is changed, or kept, and I hope the > parties to this discussion don’t either. > [LES:] I also am not heavily invested in SHOULD vs should - but as the section is advisory (which is why I changed MUST to SHOULD) it seemed like SHOULD was still appropriate. However, if you feel this distinction is important, we can certainly use lowercase. Please let us know. > > - I am expecting this document to call out the algorithm 1 as the only one > > it is > defining/describing and 6.3.2 are guidelines for other approaches when > Algorithm 1 is not feasible. This should be reflected in the document. > > I didn’t think "when Algorithm 1 is not feasible” was implicit in the > document, > it was just “here are two approaches” with no editorializing about a > preference > between the two. (I haven’t read it recently so I *could* be wrong, but that’s > how I recall it.) > > Assuming my recollection is right, I think it would be unwise to change the > document to state a preference. > [LES:] John is completely correct. The history of this document is that originally there were two competing drafts. Some folks thought that algorithm 1 was the best way forward and some that approach #2 was the best way forward. We eventually decided to write a single draft describing both solutions and allow the user community to decide what they wanted to use. My expectation is that we will see implementations of both - and whether one approach or the other dominates deployments will be based on deployment experience and vendor/operator preference. But it is certainly incorrect to think of approach #2 as only applicable when algorithm #1 is not feasible - that is not the intent of the draft. HTH clarify. Les > Thanks, > > —John _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
