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

[[e-mail]]

Hi Barry,

Thanks for your review, comments and proposed resolution. Much appreciated.

Please see inline [Bruno]
 
 
> From: Barry Leiba via Datatracker <[e-mail]> 
> Sent: Thursday, March 14, 2024 6:21 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07
> 
> Reviewer: Barry Leiba
> Review result: Has Issues
> 
> Only some minor things here:
> 
> — Section 3 —
> 
   > Although modern implementations have not strictly adhered to the 33
   > millisecond interval, it is commonplace for implementations to limit
   > the flooding rate to the same order of magnitude similar as the 33 ms
   > value.
> 
> This sentence seems ungrammatical.  I think I know what you’re saying, so perhaps this will work?:
> 
> NEW
   > Although modern implementations have not strictly adhered to the 33
   > millisecond interval, it is commonplace for implementations to limit
   > the flooding rate to the same order of magnitude: tens of milliseconds,
   > and not the single digits or fractions of milliseconds that are needed today.
> END
> 
> If that’s not quite right, please riff on it as appropriate.

[Bruno] Thanks. Done.
 
> — Section 4 —
> 
   > For a parameter which
   > has never been advertised, an IS SHOULD use its local default value.
   > That value SHOULD be configurable on a per-node basis and MAY be
   > configurable on a per-interface basis.
> 
> Nit: I think the first SHOULD here ought not to be a BCP 14 key word, and only the second is.  I would write the first part of the sentence as a fact, and only have the second be a directive:
> 
> NEW
   > For a parameter that
   > has never been advertised, an IS uses its local default value.
   > That value SHOULD be configurable on a per-node basis and MAY be
   > configurable on a per-interface basis.
> END

[Bruno] Thank. Done.
 
> — 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://datatracker.ietf.org/doc/html/rfc8919#name-application-identifier-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")

 
> — Section 6 —
> 
> Just a “thanks” comment here: I found Section 6 and its subsections to be clear and informative.

[Bruno] Thank you. And that's good news.

> 
> — Section 8 —
> 
> I think the additional implications of having the new TLV have been well thought out, and I don’t see anything missing.

[Bruno] Thank you. Excellent news for us, especially coming from the security directorate  😉 

Thank you again for your time.

This will be reflected in the next version (-08) hopefully published on Monday. (when submission re-opens)

--Bruno
> 
> 
> 
>
____________________________________________________________________________________________________________
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.