Re: [trill] Genart telechat review of draft-ietf-trill-smart-endnodes-08

Robert: 

Thank you for the review and a big thanks for catching the "F" Bit issue  in
section 4.3.   I apologize for letting that slip through my shepherd filter.
I suspect I've been reading this draft so often, that I'm starting to miss
the obvious. 

Your point is valid about expanding the security considerations.   I'll
check in with Fangwei, Donald, and other co-authors to spin a revision to
address your points. 

I'm glad you read through this draft as GEN-ART reviewer. 

Cheerily, Sue 

-----Original Message-----
From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: Tuesday, February 27, 2018 3:25 PM
To: gen-art@ietf.org
Cc: ietf@ietf.org; draft-ietf-trill-smart-endnodes.all@ietf.org;
trill@ietf.org
Subject: [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
https://www.ietf.org/mailman/listinfo/trill