Hi Les, Thanks. AFAICT the only remaining point in question is whether Zahed insists on the s/SHOULD/should/g change. Can you and your coauthors prepare a complete version 09, including the necessary small edits to sections other than 6.3.2? As far as I'm concerned you can post it, which makes it easy for everyone involved to review, and then if there are any residual changes wanted we can always do a version 10. But it’s fine to circulate it some other way if you want a fully-agreed 09, the main point is that it will be easier to close this conversation out once the complete proposed text is available.
Thanks! —John > On Apr 9, 2024, at 12:05 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > 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
