Hi Bruno, please see inline.
> Am 26.02.2018 um 15:12 schrieb <bruno.decra...@orange.com> > <bruno.decra...@orange.com>: > > Mirja, > > Thanks for your review and comments. > Sorry for the 1 week delay. > Please see inline [Bruno] > > >> -----Original Message----- >> From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Mirja Kühlewind >> Sent: Monday, February 19, 2018 4:36 PM >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-rtgwg-backoff-algo-07: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-backoff-algo/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1) Probably an editorial issue: "... SPF_DELAY to be restored to >> INITIAL_SPF_DELAY. e.g., 3 seconds." 3 seconds? The previous text says >> INITIAL_SPF_DELAY should be very short, e.g. 0 milliseconds...? > > [Bruno] > Text is: > "3. Definitions and parameters" > [...] > "HOLDDOWN_INTERVAL: The time required with no received IGP events > before considering the IGP to be stable again and allowing the > SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds." > > First sentence is the definition of the HOLDDOWN_INTERVAL. > Second sentence "e.g., 3 seconds." is an example of a typical value. In think > that the example is useful for the reader to get the order of magnitude of > each timers. Also, this presentation is aligned with the definition of other > parameters. > > I'm not seeing any editorial issue per see, however I can see that a reader > may associate the example value with the closest timer name. > I could propose the following editorial change, if it works for everyone: > > OLD: > HOLDDOWN_INTERVAL: The time required with no received IGP events before > considering the IGP to be stable again and allowing the SPF_DELAY to be > restored to INITIAL_SPF_DELAY. e.g., 3 seconds. The HOLDDOWN_INTERVAL MUST be > defaulted or configured to be longer than the TIME_TO_LEARN_INTERVAL. > > NEW: > HOLDDOWN_INTERVAL: The time required with no received IGP events before > considering the IGP to be stable again and allowing the SPF_DELAY to be > restored to INITIAL_SPF_DELAY. e.g. a HOLDDOWN_INTERVAL of 3 seconds. The > HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than the > TIME_TO_LEARN_INTERVAL. > > Yes, I misread that. > > >> 2) Also editorial: it would be helpful to show the state diagram right at the >> beginning. > > [Bruno] I'm not sure what you mean by "beginning". > It can't be before §3 which defines the definitions. Nor before §4 which > present the high level principles of the algorithm. > Then we have the §5 defining the FSM. > - Currently the state diagram is in §"5.3 States transition" > - I don't think we can move it before the presentation of the states in > §"5.1. States" > - I could propose to move the diagram from §5.3 to 5.2. > > > I'll apply the 2 proposed changes in the latest revision (-08) but please > feel free to further comment / propose alternative text. > I was thinking of stating with the diagram at the beginning of section 5. I see no problem to show the diagram first and then explain the states. Actually that would be preferred! Mirja > Thanks, > Regards, > --Bruno > > >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > _________________________________________________________________________________________________________________________ > > 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. > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
