Hi John, Thanks for your quick response and please check inline below for response with KT2.
We've also posted an update with the changes discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-07 On Sat, Sep 3, 2022 at 1:03 AM John Scudder <[email protected]> wrote: > Hi Ketan, > > LGTM generally. Regarding your uses of SHOULD, the updates to refer to > Section 7 are helpful. I agree that the other uses are innocuous enough as > to be obvious to “one versed in the art”; we shall see if other reviewers > agree. I personally am not crazy about RFC 2119 keywords directed at > operators rather than implementors (e.g. the first use in Section 10) but I > accept that it’s a common pattern. > > Regarding the “don’t write bugs” text, if I were reviewing the prior RFC I > would also have flagged that one too. I don’t insist that it be removed, > but gosh it doesn’t seem to add anything actionable. > KT2> I agree and I've removed that text. > > Remaining open items — > > Minor: > > For this text: > > For the use case in Section 2.1, it is RECOMMENDED that the network > operator limit the period of enablement of the reverse metric > mechanism only for the duration of a network maintenance window. > > I suggest > > For the use case in Section 2.1, it is RECOMMENDED that the network > operator limit the period of enablement of the reverse metric > mechanism to be only the duration of a network maintenance window. > > KT2> Ack > Nits: > > - I had suggested changing “4 octet” to “4 octets”, was this missed or > deliberately not adopted? > - s/safegaurd/safeguard/ > KT2> Missed and now fixed. Thanks, Ketan > > Regards, > > —John
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
