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

["Susan Hares" <[e-mail]>]

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.