I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-grow-mrt-13
Reviewer: Eliot Lear
Review Date: 13 September 2010

Summary:

This draft is not yet ready for publication, but will require at least a
review of the issues mentioned below.

Major Issues:

This specification suffers from two complicating effects:

    * The fact that it already deployed, and hence is attempting to
      document existing practice; and
    * there is substantial "feature creep" in an attempt to continue to
      use the same collector, while extending capabilities.

Consideration should be given to breaking this effort into two: an
informational document that explains what is going on today, and a new
clean specification for standardization.

This specification could perhaps benefit from review of those who
developed IPFIX and PSAMP.  In particular, consistent terminology would
be nice.

Specific issues:

   1. Section 3.  There is no versioning information in the packet
      header.  This means that format upgrades will require external
      information to identify their changes.
   2. Section 3. There are several 32-bit timestamp values, which will
      mean that a wrap will occur in 2038.  For most *protocols* this is
      not a problem because one can manage with wrap conditions. 
      However, this is a data export format meant for researchers. 
      Researchers tend to want to do longitudinal studies, and as such,
      it may prove difficult to use conventional wrapping mechanisms.  
      (The 32bit value also varies from the POSIX time_t definition; a
      nit to be sure, but an annoying one).
   3. Sections 5.2 and 5.3.  There are  two table dump mechanisms
      (TABLE_DUMP and TABLE_DUMP_V2) defined.  This  complicates
      implementations without any justification.  Very limited guidance
      is given as to when one is needed versus the other.  The authors
      are advised to strongly consider deprecating TABLE_DUMP in favor
      of TABLE_DUMP_V2, or in the alternative, providing much clearer
      guidance as to when one should be used by an exporter.  This
      problem replays itself throughout the document in other
      circumstances (c.f.., BGP4MP_MESSAGE & BGP4MP_MESSAGE_AS4).
   4. In Section 5.4.1 & 5.4.2 it appears that IANA-specified values are
      listed, and are as such limited.  This seems unnecessarily
      restrictive, and would force updates of this document when work is
      done on BGP.  That might prove necessary anyway becasue there may
      be insufficient length information to ignore a single table entry.
   5. The TABLE_DUMP_V2 subtypes are not sufficiently specified.  A good
      example of how to specify something sufficiently is the MRT
      header, where all fields are defined and explained.  For instance,
      in the case of TABLE_DUMP*, is a single entry encoded with format
      specified in Figures 3-5?  the use of records versus messages
      isn't clear.  In part this is due to inconsistent or poorly
      defined use of terminology (record versus message) A diagram or
      example should be included in the text that says:

>    The MRT records which follow the PEER_INDEX_TABLE MRT record contain
>    the RIB entries and include a header which specifies a sequence
>    number, NLRI, and a count of the number of RIB entries which follow.

   6. There is not a single example in the document.  This further
      hinders implementation of an already unclear specification.


Minor issues:

   7. Section 4.  There seems to be a desired to deprecate START and
      I_AM_DEAD from the outset.  While I can easily envision uses for
      this information, and for archival purposes, it seems useful to
      indicate start and end collection times (e.g., it may be useful to
      know when someone thought they were collecting routing updates but
      had in fact none), perhaps a bit more discussion and guidance
      should be given to implementors.
   8. The document really should have a glossary of terms.


Nits:

   9. NLRI is not defined.


Other (not within Apps charter):

  10. Section 8: Security Considerations do not describe data privacy
      concerns (consider the case where information being exported might
      indicate connectivity of specific individuals or systems, as could
      be possible with IGP information).  A fuller review is recommended.