LGTM. IETF LC requested. —John
> On Sep 3, 2022, at 4:51 AM, Ketan Talaulikar <[email protected]> wrote: > > > [External Email. Be cautious of content] > > > 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
