Sorry, this is just the result of bad tooling combined with lack of coffee. When you change a Discuss to a No Objection it keeps the comments. I agree the current text is fine.
On Thu, Nov 9, 2017 at 6:26 AM, Donald Eastlake <[email protected]> wrote: > Hi Eric, > > Thanks for clearing your DISCUSS. See responses below to your > remaining COMMENTs. > > On Thu, Nov 9, 2017 at 8:40 AM, Eric Rescorla <[email protected]> wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-trill-arp-optimization-09: No Objection > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 2. > > > > plane on the edge RBridges, it should be possible to completely > > suppress flooding of ARP/ND messages in a TRILL Campus, When all end- > > station MAC addresses are similarly known, it should be possible to > > suppress unknown unicast flooding by dropping any unknown unicast > > received at an edge RBridge. > > > > Are these "should be possibles" normative? Descriptive? > > The following sentence was added earlier in Section 2 to make it clear > that these were not normative: > "This section is a general discussion of this > problem and is not intended to be normative." > > > S 4. > > This is a sequence of steps, so it would be nice to preface them with > > a list of the steps. It's also odd to have SEND considerations right > > in the middle here. > > > > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP > > Please explain what a non-zero IP is and why it's relevant. > > This graf also needs an introductory sentence or something before > > the bullets. > > Section 4.3 has been re-named. "non-zero" no longer occurs anywhere in > this document. An introductory paragraph was added before the bullets. > > > S 4.4. > > It is not essential that all RBridges use the same strategy for which > > option to select for a particular ARP/ND query. It is up to the > > implementation. > > > > This seems inconsistent with the MUST in arm (b) below, because I > > can just take some other arm. It's also kind of surprising to be this > > non-prescriptive. > > This is not actually inconsistent. The paragraph at the beginning of > Section 4.4 explains that which lettered "arm" you take is fixed by > the situation; it is an implementation choice which numbered sub-arm > to take under each lettered arm. > > > S 8. > > some other location (MAC/VM Mobility) and gets connected to egde- > > > > Nit: edge is mispelled. > > As far as I can see, the misspelling of edge has been fixed in -09. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
