Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-arp-optimization-09: (with COMMENT)

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>