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

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

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