Indeed; given the explanation and the fact that it's copied from otherwise existing text, I think Les is right: just leave it as is, and thanks for considering and discussing my question. Barry On Sat, Mar 16, 2024 at 6:00 AM Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> wrote: > > Bruno - > > Inline. > > > -----Original Message----- > > From: bruno.decraene@xxxxxxxxxx <bruno.decraene@xxxxxxxxxx> > > Sent: Friday, March 15, 2024 11:17 AM > > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; Barry Leiba > > <barryleiba@xxxxxxxxxxxx> > > Cc: draft-ietf-lsr-isis-fast-flooding.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx; > > secdir@xxxxxxxx > > Subject: RE: Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07 > > > > Les, Barry, > > > > > From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> > > > Sent: Friday, March 15, 2024 4:29 PM > > > > > > Bruno/Barry - > > > > > > In regards to: > > > > > > > > — Section 4.4 — > > > > > > > > > > Length: Indicates the length in octets (1-8) of the Value field. The > > > > > length SHOULD be the minimum required to send all bits that are set. > > > > > > > > > > The SHOULD seems very odd: what would be a good reason to make it > > > > longer than necessary? Is there a real reason not to > > > > straightforwardly say, “The length is the minimum required…”? > > > > > > > > [Bruno] To be honest, that's just verbatim copy from > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > > > > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc8919%23name-application- > > identifier- > > > > > > &data=05%7C02%7Cbruno.decraene%40orange.com%7Ced0ce7f4ef6f4adb > > a5ee08dc > > > > > > 4504b6dc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63846 > > 11337566830 > > > > > > 44%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > > MzIiLCJBTiI > > > > > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Mxn56QB9LdNA%2 > > FBh2bAANCIsky > > > > Xx1zTir%2FIpTtpRsQbM%3D&reserved=0 > > > > bit- > > > > At the time, I had assumed that copying an already agreed upon > > > > sentence from an RFC was simplifier and safer. Looks like I was only 50% > > right 😉. > > > > You have a good point. I can't find a legitimate reason. > > > > I used your proposed wording (although my natural inclination would > > > > have used a "MUST") > > > > > > > [LES:] The reason RFC 8919 uses SHOULD - and why this draft should do the > > same - is that sending additional bits unnecessarily is not incorrect - it is simply > > inefficient. > > > > [Bruno] Agreed that this is only about efficiency. IMO the question is whether > > the sender must be efficient or if there a good reason to allow for inefficiency. > > > > > If you use "MUST" you are stating that receivers are obligated to reject a > > correct advertisement simply because it is unnecessarily long. > > > This is unwise and counterproductive. > > > > [Bruno] In theory, there should be a way to Be conservative in what you send > > and liberal in what you receive. > > That would require more text. e.g. > > OLD: The length SHOULD be the minimum required to send all bits that are > > set. > > NEW: When sent, the length MUST be set to the minimum required to send all > > bits that are set. When received any length below or equal 8 octets MUST be > > accepted. > > > > Would this work? > [LES:] We have already explicitly stated what the sender SHOULD do - and by using "SHOULD" we indicate that the receiver needs to be "liberal" and accept the advertisement even if it is longer than necessary. > I do not see what is being accomplished here. > > An implementation that is optimal is already following the recommended behavior. > Do you think that by saying "MUST" you will get more implementations to be optimal? > I doubt it. > > And you now have to use two "MUST" statements: > > 1)For the transmitter - to be optimal > 2)For the receiver - to be liberal > > A single SHOULD accomplishes the same thing. > > I think this is "much ado about nothing" - or at best "much ado about very little". > > Les > > > > > Regards, > > --Bruno > > > > > > > As a WG member and co-author I object to this change. > > > > > > HTH > > > > > > Les > > > > > > > > ___________________________________________________________________ > > _________________________________________ > > 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
