Telechat Review of draft-ietf-trill-smart-endnodes-08
review-ietf-trill-smart-endnodes-08-genart-telechat-sparks-2018-02-27-00
Request | Review of | draft-ietf-trill-smart-endnodes |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Telechat Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2018-03-06 | |
Requested | 2018-02-19 | |
Authors | Radia Perlman , fangwei hu , Donald E. Eastlake 3rd , Ting Liao | |
I-D last updated | 2018-02-27 | |
Completed reviews |
Rtgdir Early review of -02
by Julien Meuric
(diff)
Genart Telechat review of -08 by Robert Sparks (diff) |
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Request | Telechat review on draft-ietf-trill-smart-endnodes by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 08 (document currently at 11) | |
Result | Ready w/issues | |
Completed | 2018-02-27 |
review-ietf-trill-smart-endnodes-08-genart-telechat-sparks-2018-02-27-00
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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-trill-smart-endnodes-08 Reviewer: Robert Sparks Review Date: 2018-02-27 IETF LC End Date: 2018-03-06 IESG Telechat date: 2018-03-08 Summary: Ready with issues Major issues 1) In section 4.3 the bullet describing the F bit does not parse. There are two instances of "Otherwise" that do not work together. 2) All of section 4.3 is confusing as to what the length of the TLV really is. Row 3 in the diagram says 2 bytes or 4 bytes, but the number of bits called out in bullets 4 and 5 below it don't seem to add up to those things. Maybe it would be better to draw a diagram with F=0 and a separate diagram with F=1 3) I think the security considerations section should call out again what an RB should do if it gets message that looks like it's from a SE, containing the right nickname, but the RB hasn't done the right Smart-Hello handshaking with that SE already. What would keep a lazy implementation (or one driven by product managers picking and choosing features) from just forwarding a message from a malicious element that just happened to know the RB's nickname? Nits Terminology: The definition of Transit RBridge says it's also named as a Transit Rbridge?