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

Reply via email to