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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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.