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

From: "Susan Hares" <[email-masked]>
Date: Sun, 8 Jan 2017 18:02:03 -0500

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/ 

#2. p. 17-22 - section 3 

#2.a Overall - I think you need to include SEND messages in this Query
messages. 

#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 

Draft 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 draft
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.  

#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
<https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10
#section-4> ) or a configured priority (DirGenQPriority, Section 3.9
<https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10
#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
<https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10
#section-4> ) or a configured priority (DirGenQPriority, Section 3.9
<https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10
#section-3.9> /.
 
Reason: Clarify sentences. 
 
#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 

#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
<https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10
#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. 

#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. 

#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.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 Jan 2017 13:23:40 -0500

Hi Sue,

Thanks for the review.

On Sun, Jan 8, 2017 at 6:02 PM, Susan Hares <[email-masked]> wrote:
> 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” /

OK.

> #2. p. 17-22 – section 3
>
> #2.a Overall – I think you need to include SEND messages in this Query
> messages.

OK.

> data frames with unknown unicast destination MAC addresses, intercepted by
> [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or data

OK.

>    Section 4) or a configured priority (DirGenQPriority, Section 3.9)
>    for generated queries./
>
>    queries (see Section 4) or a configured priority (DirGenQPriority,
> Section 3.9/.
>

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.

> (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./
>

OK.

>    loses adjacency to that server (Section 3.7), if it knowns that such
> 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

OK.

> #6: p. 43, 4th paragraph beginning with Although some …
>
> Current text:

OK, we can add a reference to RFC 7176

> #7 p. 44, section 6 – Security considerations
>
> 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-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 13 Jan 2017 13:59:53 -0500

Hi Sue,

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

Thanks,
Donald