The -07 version of this draft addresses all of the concerns raised by the Gen-ART
review of the -06 version.  I would have preferred to see stronger Security
Considerations text on usage (and non-usage of the Authentication TLV.  That said,
the text in the -07 version is an improvement, and I will leave any further
follow-up to the IESG.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Saturday, March 29, 2014 10:24 PM
> To: zhai.hongjun at zte.com.cn; hu.fangwei at zte.com.cn; Radia at alum.mit.edu; Donald
> Eastlake (d3e3e3 at gmail.com); ostokes at extremenetworks.com; General Area Review
> Team (gen-art at ietf.org)
> Cc: trill at ietf.org; ietf at ietf.org; Black, David
> Subject: Gen-ART review of draft-ietf-trill-esadi-06.txt
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-trill-esadi-06.txt
> Reviewer: David L. Black
> Review Date: March 29, 2014
> IETF LC End Date: April 1, 2014
> 
> Summary: This draft is on the right track, but has open issues
> described in the review.
> 
> This draft revises the ESADI specification for TRILL from its
> original form in RFC 6325.
> 
> Major issues:
> 
> The draft changes ESADI in a non-backwards-compatible fashion from
> its original specification in RFC 6325, but does not explain why this
> is ok.  That explanation needs to be provided, and if implementations
> of ESADI as originally specified in RF 6325 exist, that explanation
> needs to encompass coexistence and interoperability (or lack thereof)
> with such implementations.  That explanation probably belongs in
> Section 1.1, and could be expanded upon in Appendix A.
> 
> Overall, this draft is not self-contained - to a significant extent,
> it is written as if it were effectively a long collection of errata
> to the ESADI specification in RFC 6325.  That makes it difficult to
> understand - it would be better if this draft completely obsoleted
> and replaced the ESADI specification in RFC 6325, describing its
> changes, instead of providing specific text changes to portions
> of the RFC 6325 text.
> 
> Minor issues:
> 
> I don't understand the discussion in section 2 of it being "an
> implementation decision how independent the multiple ESADI instances
> at an RBridge are" in light of the clear statement that "the ESADI
> update process operates separately for each ESADI instance."  The
> example given involves database structure considerations that are
> specific to the node implementation and do not affect the independent
> updates for each ESADI instance.  There may not be an actual
> technical problem here, but at least the first chunk of text quoted
> in this paragraph of the review needs to be rewritten.
> 
> Also in Section 2:
> 
>    ESADI does no routing so there is no reason for pseudo-nodes in ESADI
>    and none are created.
> 
> Need to explain what a pseudo-node is before this sentence.
> 
> p.9, Figure 2 - explain how the receiver determines whether the inner
> Ethernet header contains a VLAN tag or FGL.  This also applies to Figure
> 3 on p.10.
> 
> p.10, Section 2.1:
> 
>    All transit RBridges forward ESADI packets as if they were ordinary
>    TRILL Data packets.
> 
> Need to explain what a "transit" RBridge is.  Between this and the
> above pseudo-node comment, I suggest adding an overview of the
> TRILL protocol to the start of Section 2.
> 
> p.11, Section 2.1:
> 
>    No "routing" computation or routing decisions ever have to be performed
>    by ESADI.
> 
> What is a ' "routing" computation' ??  This should be rephrased to
> contrast to what the non-ESADI TRILL usage of IS-IS does.
> 
> p.12, Section 2.2:
> 
>    If a VLAN or FGL ID
>    field within an ESADI-LSP PDU does include a value, that field's
>    contents is ignored.
> 
> This looks like it's an important requirement, so:
> 	 "is ignored" -> "MUST be ignored"
> 
> p.13, Section 3
> 
>   "SNPA/MAC address"
>    is not considered in this tie breaking and there is no "Port ID".
> 
> This is contrasting ESDI tie-breaking to a tie-breaking
> procedure that I'd guess is specified in another document; that needs to
> be explained, along with a reference to that document, preferably with
> the section number where the other tie-breaking procedure is specified.
> 
> Section 6 - explain where the 1470 byte number in the third paragraph
> comes from.
> 
> Section 8 - more should be said on whether/when the Authentication TLV
> should be used when ESADI conveys information from an authenticated
> registration.  In particular, if this recommendation for usage of the
> Authentication TLV with information from an authenticated
> registration usage is not a "SHOULD" or "MUST", an explanation is in
> order.
> 
> Nits/editorial comments:
> 
> There are lots of acronyms that are not expanded on first use, defined
> in the terminology section, or otherwise explained, e.g., DRB, Sz, CSNP,
> PSNP.  It may be ok to point to terminology/acronym definitions in RFC
> 6325.
> 
> Last sentence on p.8:
> 
> OLD
>    The outer VLAN tag will not be present if it was stripped by
>    an Ethernet port out of which the packet was sent.
> NEW
>    The outer VLAN tag will not be present for a packet on an
>    an Ethernet link that does not use VLAN tags.
> 
> idnits 2.13.01 got confused by the Section 4.6.2.2 reference to
> RFC 6325 in Section 4.1, and thought 4.6.2.2 was an IPv4 address -
> this is not a problem.
> 
> idnits also warned about possible pre-RFC5378 (2008) content.  This
> is probably not a problem, but please check with your AD.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------