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

(Alexey Melnikov; former steering group member) No Objection

(Alissa Cooper; former steering group member) No Objection

(Ben Campbell; former steering group member) No Objection

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

(Deborah Brungard; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

ron bonica provided the ops dir review

(Kathleen Moriarty; former steering group member) No Objection

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

One question: Why are there no IANA registries for tables 3.1 and 4.1?

(Spencer Dawkins; former steering group member) No Objection

(Stephen Farrell; former steering group member) No Objection

- 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

(Terry Manderson; former steering group member) No Objection