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

[John Scudder <[e-mail]>]

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. 

> - 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. 

Thanks,

—John