Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension

Note: This ballot was opened for revision 09 and is now closed.

(Alia Atlas) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-07-05 for -10)
No email
send info
The reference to RFC 5869 is a normative downref. It's, not mentioned in the last call announcement, nor in the downref registry. I leave it to the AD and authors to decide if that is okay.

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-07-06 for -10)
No email
send info
- The write up for this and the other trill docs on this
telechat talks about "directory services" but that's not
mentioned in any of the drafts. Pointers to RFC7067 would
probably have saved me a few minutes:-)

- That RFC5869 is not in the downref registry is odd.  I'd
say we should just add it there. It's true though that I
think this seems to be the first stds track doc with it as
normative [1] but I figure it's safe to add with no new LC


(Apologies that there's no TLS for [1] :-)

- 4.3: Can the verifier deterministically tell from the
context that the keyid here refers to the derived key as
defined in 4.1 and not to (what I guess is) a "bare" key as
per RFC5310? Do you need to say that? 

- 4.4 or section 7: Do we know that there are no issues with
DTLS packets exceeding the MTU but where implementations
won't work, perhaps with a cert chain. DTLS does support
that, but do implementations that are likely to be used
here? If not, maybe a warning is needed. Or, do you need to
warn against cert based ciphersuites on the basis that
nobody knows what to put in certs for trill? Given that you
are (wisely) punting on group communication, maybe you could
also say that only PSK ciphersuites are to be used here for
now, and then also address cert based ciphersuites when you
get around to figuring out group keying?

- section 7, 3rd para: I do worry a bit about that, but
you've called out the risk I guess. If it were possible to
add more guidance as to how to defend in depth that'd be
good I guess.

(Joel Jaeggli) No Objection

Comment (2016-07-07 for -10)
No email
send info
ron bonica provided the ops dir review

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2016-07-04 for -09)
No email
send info
One question: Why are there no IANA registries for tables 3.1 and 4.1?

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-07-06 for -10)
No email
send info
Thanks for addressing the early SecDir review:

Alvaro Retana (was Discuss) No Objection