Hi Sue, Thanks for the review.
On Sun, Jan 8, 2017 at 6:02 PM, Susan Hares <[email protected]> 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 +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
