Hi John, Zahed, all We have posted -09 which includes text that has been agreed upon on the list. If needed we can continue the discussion from this new version.
> There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-09 > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-09 Thanks, --Bruno, Les -----Original Message----- From: John Scudder <j...@juniper.net> Sent: Tuesday, April 9, 2024 7:31 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Zaheduzzaman Sarker <zahed.sarker.i...@gmail.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) -------------------------------------------------------------------------------------------------------------- CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. -------------------------------------------------------------------------------------------------------------- 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
