Re: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt

[Donald Eastlake <[e-mail]>]

Hi Sue,

The -11 version just posted is intended to resolve your comments.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Thu, Jan 12, 2017 at 1:23 PM, Donald Eastlake <[e-mail]> wrote:
> Hi Sue,
>
> Thanks for the review.
>
> On Sun, Jan 8, 2017 at 6:02 PM, Susan Hares <[e-mail]> wrote:
>> Donald, Yizhou, Linda, and Radia:
>>
>> Thank you for your work on draft-ietf-trill-directory-assist-mechanisms.
>> Each draft improves the readability and nails down some of the potential
>> edge cases.   I believe we are nearing the end of this journey toward IESG
>> approval. I am joining with you on this journey by doing a shepherd review
>> at the end of IETF LC.
>>
>>
>> Status: Ready to publication, with some editorial nits you should consider
>>
>>
>>
>> Here’s my editorial nits on the latest version.   Please address #2 – that
>> deals with the “SEND” functionality and #6
>>
>>
>> #1, p. 5 paragraph 1, list item 3.   – simple spelling error
>>
>> Old:/MAC addresses “nomrally” /
>> New: /MAC Addresses normally/
>
> OK.
>
>> #2. p. 17-22 – section 3
>>
>> #2.a Overall – I think you need to include SEND messages in this Query
>> messages.
>
> OK.
>
>> #2.b p17, section 3.0 paragraph 5  specific text change
>>
>> Old:/The requests to Pull Directory servers are typically derived from
>> ingressed ARP [RFC826], ND [RFC4861],  RARP [RFC903], or
>> data frames with unknown unicast destination MAC addresses, intercepted by
>> an ingress TRILL switch as described in Section 1.1/
>>
>> New:/ The requests to Pull Directory servers are typically derived from ARP
>> [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or data
>> Layer 2 frames with unknown unicast destination MAC addresses intercepted by
>> an ingress TRILL switch as described in Section 1.1/
>>
>> Reason: SEND mechanisms need to be clearly specified in the draft.  Suresh
>> Krishnan mentioned this on the ARP optimization draft.
>
> OK.
>
>> #3 p. 19, section 3.2.1 paragraph 1, sentence 3
>>
>> Old: /The priority of the channel message is a mapping of the
>>    priority of the frame being ingressed that caused the query with the
>>    default mapping depending, per Data Label, on the strategy (see
>>    Section 4) or a configured priority (DirGenQPriority, Section 3.9)
>>    for generated queries./
>>
>> New:/ The priority of the channel message is a mapping of the
>>    priority of the ingress frame which caused the query combined with the
>>    default mapping per Data Label depending on the strategy for generated
>>    queries (see Section 4) or a configured priority (DirGenQPriority,
>> Section 3.9/.
>>
>> Reason: Clarify sentences.
>
> I agree this could use clarification. How about:
>
>    The priority of the channel message is a mapping
>    of the priority of the ingressed frame that caused the query.
>    The default mapping depends, per Data Label, on the strategy
>    (see Section 4) or a configured priority (DirGenQPriority, Section
>    3.9) for generated queries.
>
>> #4, p. 33 section 3.5.1 paragraph 3
>>
>> Old:/ The Bridge shown might be a complex bridged LAN or might be absent
>>    if, as shown for End Station 1, End Station 2 was dual ported with
>>    point-to-point Ethernet links to RB1 and RB2./
>>
>> New:/The Bridge shown might be a complex bridged LAN, a LAN without a bridge
>> (as shown in End station 1), or connected via point-to-point links (as shown in
>> End Station 2’s which is connected through a bridge with point-to-point
>> Ethernet links to
>> RB1 and RB2./
>>
>> Reason: Clarify the sentences
>
> OK.
>
>> #5, p. 33 section 3.5.1 paragraph 4 sentence 1.
>>
>> Old:./
>>    Because an indirect Pull Directory server discards information it has
>>    cached from queries to an end station Pull Directory server if it
>>    loses adjacency to that server (Section 3.7), if it knowns that such
>>    information may be cached at RBridge clients and has no other source
>>    for the information, it MUST send Update Messages to those clients
>>    withdrawing the information/
>>
>> New: /Since an indirect Pull Directory server discards information it has
>>      cached from queries to an end station Pull Directory server if it
>>      loses adjacency to the server (Section 3.7), if it detects that
>>      information may be cached at RBridge clients and has no other source
>>      for the information, it MUST send Update Messages to those clients
>>      withdrawing the information/
>>
>> Words changed – in bold
>>
>> Why: anthropomorphism – TRILL switches do not know.  TRILL switches detect
>> based on logic.
>>
>> Why: Because/since – both indicate causes, but “since” seems to indicate an
>> ordering that this paragraph suggests.
>
> OK.
>
>> #6: p. 43, 4th paragraph beginning with Although some …
>>
>> Current text:
>>    /Although some of the ports sending TRILL ES-IS PDUs are on end
>>    stations and thus not on routers (TRILL switches), they nevertheless
>>    may make use of the Router Capability (#242) and MT-Capability (#222)
>>    IS-IS TLVs to indicate capabilities as elsewhere specified./
>>
>> It would be good to indicate where these capabilities are specified.
>
> OK, we can add a reference to RFC 7176
>
>> #7 p. 44, section 6 – Security considerations
>>
>> After the SEC-DIR review comes in, consider if the end-system engage
>> requires some extra text on privacy related to the end-systems.
>>
>> Since Donald and Radia are much better at all types of security, please
>> consider this as a “please check”.   Kathleen and Stephen are focused on
>> this work.
>
> We could add something about edge RBridges being more aware of what IP
> addresses are being used.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]