Hi All, I just did a full read-through of -01. Without denigrating any other solutions, I support adoption of this one.
I do have a few comments and nits, below. - Paragraph 2 of section 9 is unclear, IMO; I hope this can be improved in the next version. It reads exactly like a protocol expert writing for another protocol expert; as we know, a good spec has to be written so that as little as possible is left to the creativity of the implementor. This paragraph seems to require creativity. - Please decide whether to do the right thing, and call the protocol “IS-IS”, or the wrong thing, and call it “ISIS”. Whatever the decision, standardize on that one instead of randomly adding and dropping hyphens. - Section 8 mentions “route reflector clients”, probably what was meant was “flood reflector clients”. Thanks, —John > On Jun 10, 2020, at 3:28 PM, Christian Hopps <cho...@chopps.org> wrote: > > [External Email. Be cautious of content] > > > This begins a 2 week WG adoption call for the following draft: > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!WwSo3XAAATjZjcHHk7EGQ6xt6K1-gAsQFmMVapPciPpj41XxzXiyLxQehiD8ew$ > > The draft would be adopted on the Experimental track. > > Please indicate your support or objection by June 24, 2020. > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to this draft. > > Thanks, > Chris and Acee. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
