Last Call Review of draft-ietf-trill-irb-13

Request Review of draft-ietf-trill-irb
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-06-24
Requested 2016-06-16
Authors Hao Weiguo, Li Yizhou, Andrew Qu, Muhammad Durrani, Ponkarthick Sivamurugan
Draft last updated 2016-06-22
Completed reviews Genart Last Call review of -13 by Francis Dupont (diff)
Secdir Last Call review of -13 by Shawn Emery (diff)
Opsdir Last Call review of -10 by Scott Bradner (diff)
Rtgdir Early review of -09 by Russ White (diff)
Rtgdir Early review of -09 by Susan Hares (diff)
Rtgdir Early review of -09 by Hannes Gredler (diff)
Assignment Reviewer Francis Dupont 
State Completed
Review review-ietf-trill-irb-13-genart-lc-dupont-2016-06-22
Reviewed rev. 13 (document currently at 14)
Review result Ready
Review completed: 2016-06-22


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-trill-irb-13.txt 
Reviewer: Francis Dupont
Review Date: 20160618
IETF LC End Date: 20160624
IESG Telechat date: 20150630

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - you have 6 (with a soft limit of 5) authors

 - 1 page 3: please expand the first occurrence of the FGL abbrev

  (in theory you should expand the TRILL abbrev and in the Abstract too
   but IMHO it is unlikely to get a reader of this document who does
   not know the TRILL abbrev meaning and raises a concern. BTW VLAN
   is well known (*) so doesn't need to be expanded)
   (* starred in


 - 1 page 3: i.e. -> i.e.,

 - 3.1 page 5: IMHO the title should be on the next page (page 6).
  This will be fixed by the RFC Editor anyway.

 - 3.1 pages 6 and further: congratulations, you use IP addresses
  from blocks reserved for documentation.

 - 5.2 page 12: dependant -> dependent

 - 5.4 pages 14 and 15: I have an academic question: did you find
  some cases of external redirects? This term is not common
  (nor use cases :-) so I copy a definition I gave during a discussion
  about SEND (the secure IPv6 neighbor discovery):
   - give the link-layer address of an off-link destination which is
     in fact on-link. This "external redirect" is used for IPv6 over
     ATM to implement NHRP short cuts for instance.

 - 6 page 15: another example of strange page layout that should be
  fixed by the RFC Editor.

  (cf 9 IANA Considerations page 22 )


Francis.Dupont at