Secdir review of Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 Do not be alarmed. 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. The document intends to specify "requirements for ongoing work" in handling errors in BGP-4 protocol messages. The document says that it will not define the protocol mechanisms for implementing solutions. A lot of experience and thought has gone into writing this document. Nonetheless, I had a great deal of trouble finding the requirements because the writing is narrative and overly wordy. I would like to see the requirements stated clearly and separated from the rationalization. There are many requirements that seem to be dictated (not to be the subject of "ongoing work", apparently) and others that are quite vague: There is a requirement that where subsets of the RIB on a device are no longer reachable from a BGP speaker, or indeed an AS, that some visibility of this situation, alongside a mechanism to determine the cause is available to an operator. Whilst, to some extent, this can be solved by mandating a sub-requirement of each of the aforementioned requirements that a BGP speaker must log where such errors occur, and are hence handled, this does not solve all cases. It's difficult to untangle this sort of thing into analyzable requirements. From a security standpoint, the requirement that offending BGP messages be returned to the sender is problematic. BGP has a lightweight cryptographic mechanism for protecting message integrity and providing authentication. The returned erroneous messages might help an attacker undermine the protection and thus insert bogus messages into a channel. The security considerations should point out that any new form of error handling requires cryptanalysis. Some minor editorial comments: "Whilst" is rarely used in American English. The synonym "while" is preferred, but in this document the word "although" would be a better replacement. In many cases omission altogether would improve the sentence. In this introductory paragraph "... numerous incidents have been recorded due to the manner in which [RFC4271] specifies errors in routing information should be handled." we do not learn why the "incidents" require any changes to error handling. The very term "incident" appears to be a pejorative in the mind of the author. Grammo: "It should, however, be noted" replace with "It should be noted, however" or "Note that ..."