Skip to main content

Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
draft-ietf-trill-channel-tunnel-11

Yes

(Alia Atlas)

No Objection

Alvaro Retana
(Alexey Melnikov)
(Alissa Cooper)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

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

Alvaro Retana (was Discuss) No Objection

(Alia Atlas; former steering group member) Yes

Yes (for -09)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -10)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -10)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2016-07-05 for -10)
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; former steering group member) No Objection

No Objection (for -10)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -10)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2016-07-07 for -10)
ron bonica provided the ops dir review

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-07-06 for -10)
Thanks for addressing the early SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06615.html

(Mirja Kühlewind; former steering group member) No Objection

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

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -10)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-07-06 for -10)
- 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
stuff.

   [1] http://www.arkko.com/tools/allstats/citations-rfc5869.html

(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.

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -10)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -10)