Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
> Sent: Tuesday, April 9, 2024 10:31 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Zaheduzzaman Sarker <[e-mail]>; The IESG
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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)
> <[e-mail]> 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 <[e-mail]>
> >> Sent: Tuesday, April 9, 2024 8:28 AM
> >> To: Zaheduzzaman Sarker <[e-mail]>
> >> Cc: Les Ginsberg (ginsberg) <[e-mail]>; The IESG
> <[e-mail]>;
> >> [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]
> >> 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
> >> <[e-mail]> 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
>