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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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%7Ced0ce7f4ef6f4adba5ee08dc
> > 4504b6dc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384611337566830
> > 44%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Mxn56QB9LdNA%2FBh2bAANCIsky
> > 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?

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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux