Re: [secdir] Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07

[Barry Leiba <[e-mail]>]

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)
<[e-mail]> wrote:
>
> Bruno -
>
> Inline.
>
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Friday, March 15, 2024 11:17 AM
> > To: Les Ginsberg (ginsberg) <[e-mail]>; Barry Leiba
> > <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: RE: Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07
> >
> > Les, Barry,
> >
> > > From: Les Ginsberg (ginsberg) <[e-mail]>
> > > 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.