I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is READY WITH NITS. I'm satisfied with its normative content but the Security Considerations section could use a bit of elaboration. I had never heard of TRILL prior to being assigned this review and the tree of normative references is a bit daunting, so these comments will necessarily be based only on an extremely high-level view of the system. draft-ietf-trill-directory-assist-mechanisms proposes to augment TRILL by adding directory servers which cache information about network topology, allowing RBridges to sometimes shortcut the usual learning algorithm that they would use to discover this information. Here are the fundamental points which the Security Considerations section either addresses or ought to address: 1. There are three relevant security goals: a. Availability: packets should reach their intended destination b. Confidentiality: packets should not reach unintended destinations c. Privacy: metadata concerning network presence should not be shared more widely than necessary 2. Access control to directory servers can be enforced using pre-existing cryptographic mechanisms specified in RFCs 5304, 5310, and 7978. 3. Principals authorized (duly or otherwise) to read directory data can violate privacy. 4. Principals authorized to modify directory data can violate availability and confidentiality. 5. Directory servers must therefore take care to implement and enforce access control policies which are not overly permissive. The current text of the Security Considerations section directly addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of the draft obliquely implies points 1c and 3 but I wish they'd be stated more explicitly. But the major omission is point 5: what does a correct authorization predicate look like? What sort of access must necessarily be authorized in order for protocol execution to succeed? What sort of access generally ought *not* be authorized?