John - Work on the version update has started - please give us time to edit/review among the co-authors.
If Zahed can give us an indication on SHOULD/should that would be helpful - but otherwise we will use our best judgment. FYI I am inclined to use "SHOULD" - but if Zahed feels strongly we can change that. Les > -----Original Message----- > From: John Scudder <[email protected]> > Sent: Tuesday, April 9, 2024 10:31 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Zaheduzzaman Sarker <[email protected]>; The IESG > <[email protected]>; [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: Re: Zaheduzzaman Sarker's Discuss on > draft-ietf-lsr-isis-fast-flooding- > 08: (with DISCUSS and COMMENT) > > 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) > <[email protected]> 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 <[email protected]> > >> Sent: Tuesday, April 9, 2024 8:28 AM > >> To: Zaheduzzaman Sarker <[email protected]> > >> Cc: Les Ginsberg (ginsberg) <[email protected]>; The IESG > <[email protected]>; > >> [email protected]; [email protected]; > >> [email protected]; > >> [email protected] > >> 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 > >> <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
