-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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 that had arrived in a more timely manner. I think the document is ready, but I have a couple of nits. Please note that I am not well versed in the subject of network routing, so these nits might be irrelevant due to my naivete. * Section 6.2.6. is written in terms of what an operator ought to do, but I'm not entirely sure what that means to an implementer. Does that mean the implementer MUST provide some sort of mechanism to allow the operator do follow the SHOULD? I admittedly only glanced through RFC 5706 and RFC 4271, so if this is actually covered more generally then please ignore this item. * In Section 8., second paragraph, are there known cases where it might be ok to accept Consumer peer updates, therefore violating the SHOULD NOT? If there are not, I would think MUST NOT is more appropriate. If there are cases where the SHOULD NOT can be ignored, does it makes sense to briefly describe one or two of them? While there are several places in this document where SHOULD (or SHOULD NOT) is used without any such exceptions described, it seems pertinent to me to describe a case or two for such a SHOULD (NOT) in the Security Considerations. Thank you for your consideration, - -- - - m&m Matt Miller < mamille2 at cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVJal9AAoJEDWi+S0W7cO1Dc8H/j9UqCwTn+VecPTnd2b5UQ2W mhFM5SGMc+KRpBjriTmxs/snwoLFtuD+u5aGuEEp+mvebR8C2Tg2wDga4TE1R5cu fs+kmmvzgGkoKtQGcg3MfnAp5F+MEKGRh9iLUt6bBzSEZqMjDvchx+Ha9z+Raxs4 W2Paw6UUr6+RIsKgeioRKYjk+hMQHabtSrb9rdJEjSLgcMcOgXPeLwMz/wlq/pVZ j5qPVSYTnOcfDEhRle6K99HZ/MZucGwxAv0fe8ukc0X5Ate9P0HrA3pW2oNyAVSX 4MdTvkxcIHucbeiWKpWMy8LpK+9e9CeVKBmvEitixnvOjqLq3qmS0SBu5O7P+qI= =8yaG -----END PGP SIGNATURE-----