Barry, Les > From: Barry Leiba <barryleiba@xxxxxxxxxxxx> > Sent: Saturday, March 16, 2024 1:05 AM > > 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. Thanks for your comments and feedback. I'm reverting to the original text: <t>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.</t> Thanks --Bruno > 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%2Fda > > > ta%2F&data=05%7C02%7Cbruno.decraene%40orange.com%7C5f1993bcf219469df > > > 88808dc454cb26b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384614 > > > 42909928096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yciJrdc6kkPK0A > > > nYxylYSed89YvvvHWOtEAmK%2BHQXxY%3D&reserved=0 > > > > > 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
