Robert, thanks for your review.

I managed to ballot before reading the rest of this thread (sorry!), but I 
still think the diagram in 4.3 is confusing and not consistent with the text. 
To my eye row 3 shows two bytes’ worth of fields but the label says “4 bytes.” 
RSV is depicted as 2 bits but the text says it is 6 bits. The combination of 
these two inconsistencies makes it hard to know what the actual lengths are 
supposed to be.

Thanks,
Alissa


> On Mar 1, 2018, at 10:46 PM, hu.fang...@zte.com.cn wrote:
> 
> Hi, Sparks
> 
> Thanks for your review and comments.
> 
> A new version(version 10) draft is submitted to fix the issues.
> 
> Regards
> 
> Fangwei.
> 
> 
> 
> 
> 
> A new version of I-D, draft-ietf-trill-smart-endnodes-10.txt
> has been successfully submitted by Fangwei Hu and posted to the
> IETF repository.
> 
> Name:        draft-ietf-trill-smart-endnodes
> Revision:    10
> Title:        TRILL Smart Endnodes
> Document date:    2018-03-01
> Group:        trill
> Pages:        15
> URL:            
> https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-10.txt 
> <https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-10.txt>
> Status:         
> https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ 
> <https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/>
> Htmlized:       
> https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-10 
> <https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-10>
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-10 
> <https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-10>
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-10 
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-10>
> 
> Abstract:
>    This draft addresses the problem of the size and freshness of the
>    endnode learning table in edge RBridges, by allowing endnodes to
>    volunteer for endnode learning and encapsulation/decapsulation.  Such
>    an endnode is known as a "Smart Endnode".  Only the attached edge
>    RBridge can distinguish a "Smart Endnode" from a "normal endnode".
>    The smart endnode uses the nickname of the attached edge RBridge, so
>    this solution does not consume extra nicknames.  The solution also
>    enables Fine Grained Label aware endnodes.
> 
> 
> 
> 
> 原始邮件
> 发件人:RobertSparks <rjspa...@nostrum.com <mailto:rjspa...@nostrum.com>>
> 收件人:gen-...@ietf.org <mailto:gen-...@ietf.org> <gen-...@ietf.org 
> <mailto:gen-...@ietf.org>>
> 抄送人:i...@ietf.org <mailto:i...@ietf.org> <i...@ietf.org 
> <mailto:i...@ietf.org>>draft-ietf-trill-smart-endnodes....@ietf.org 
> <mailto:draft-ietf-trill-smart-endnodes....@ietf.org> 
> <draft-ietf-trill-smart-endnodes....@ietf.org 
> <mailto:draft-ietf-trill-smart-endnodes....@ietf.org>>trill@ietf.org 
> <mailto:trill@ietf.org> <trill@ietf.org <mailto:trill@ietf.org>>
> 日 期 :2018年02月28日 04:24
> 主 题 :[trill] Genart telechat review of draft-ietf-trill-smart-endnodes-08
> Reviewer: Robert Sparks
> Review result: Ready with Issues
> 
> 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?
> 
> 
> _______________________________________________
> trill mailing list
> trill@ietf.org <mailto:trill@ietf.org>
> https://www.ietf.org/mailman/listinfo/trill 
> <https://www.ietf.org/mailman/listinfo/trill>
> 
> _______________________________________________
> Gen-art mailing list
> gen-...@ietf.org <mailto:gen-...@ietf.org>
> https://www.ietf.org/mailman/listinfo/gen-art 
> <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Reply via email to