Please treat these as normal last call comments. I found the introduction to draft-ietf-isis-trill inadequate. I'm familiar with the base concepts behind TRILL, roughly understand what was going on and followed the chartering discussions of the WG fairly closely. I have read the requirements document but have not read the protocol document. In an ideal world this document would be significantly easier to follow; I suspect that after reading the protocol document I'd still find this a bit choppy. However, I understand that sometimes you can only spend so much time on a spec and sometimes you reach the point where if someone isn't willing to jump in and volunteer a lot of hours to add clarity, good enough is good enough. This document claims that it adds no new security considerations to IS-IS. That's true. However, TRILL is a new protocol--completely new. It re-uses IS-IS as a building block, but if I were a security AD I'd still insist that TRILL meet our current standards for security, including a strong mandatory-to-implement security mechanism and (where appropriate) automated key management. I definitely think that this specification should at least document how IS-IS+TRILL fall short of standards we'd require for a new protocol today. The big area I can think of is replay handling for hello packets, which I suspect leads to a DOS. If we had more success with multicast key management we'd probably also require automated key management for a protocol like this. However,we don't, so I think that the RFC 4107 analysis would conclude that manual key management is acceptable under the multicast exception. I suspect the sec ADs will not actually require a solution even though it is a new protocol. I think that's a mistake, but I also don't have a lot of time to spend on TRILL, and I'd definitely rather see it get published than bogged down. I think documenting how IS-IS security interacts with TRILL security and IETF security BCPs should only take a relatively short time.