I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed:  draft-ietf-grow-bmp-15 Status: Ready with comments Summary: This document defines a protocol, BMP, that can be used to monitor BGP sessions.  BMP is intended to provide a convenient interface for obtaining route views.  Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views.  The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting.  BMP is not suitable for use as a routing protocol. The document is on standards track and defines another monitoring method specifically for BGP. The original draft is dated 2005, long before NETCONF or YANG were defined, and when there was probably no way to view routes. With the advent of NETCONF and specifically the BGP YANG model, which is currently a WG document, it would be helpful to know how BMP stands apart. The NETCONF notification structure allows for notifications described in this draft and the ability to collect stats reports and route monitoring. It would be helpful to know how BMP compliments that capability. In addition, the following nits need to be addressed in the document. Miscellaneous warnings:   ----------------------------------------------------------------------------   == The document seems to contain a disclaimer for pre-RFC5378 work, but was      first submitted on or after 10 November 2008.  The disclaimer is usually      necessary only for documents that revise or obsolete older RFCs, and that      take significant amounts of text from those RFCs.  If you can contact all      authors of the source material and they are willing to grant the BCP78      rights to the IETF Trust, you can and should remove the disclaimer.       Otherwise, the disclaimer is needed and you can ignore this comment.       (See the Legal Provisions document at      http://trustee.ietf.org/license-info for more information.)   Checking references for intended status: Proposed Standard   ----------------------------------------------------------------------------      (See RFCs 3967 and 4897 for information about using normative references      to lower-maturity documents in RFCs)   == Outdated reference: draft-ietf-idr-error-handling has been published as      RFC 7606 Thanks. Mahesh Jethanandani mjethanandani at gmail.com