Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
draft-ietf-grow-mrt-17

Note: This ballot was opened for revision 17 and is now closed.

Lars Eggert No Objection

(Ron Bonica; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-10-05 for -)
No email
send info
Just a couple of small things to consider...

---

A couple of places say things like:
   A number of MRT message types have been documented in some references
It would be nice to state the references (informational).

---

Section 5.1 
Should Remote IP address and Local IP address fields be explained?

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (2010-10-06 for -)
No email
send info
The rule is that acronyms need to be expanded on their first use in the title, abstract, and body of the document.

(Jari Arkko; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2010-10-05 for -)
No email
send info
As Sean Turner noted, please add a normative reference to RFC 3629 for UTF-8 (in Sections 4 and 5.3).

(Ralph Droms; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection (2010-10-06 for -)
No email
send info
Support Sean's point 4 (re: privacy considerations). I also suggest the Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help. 

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2011-05-13)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection (2010-10-06 for -)
No email
send info
"All MRT format messages have a common header which includes a
timestamp, Type, Subtype, and length field.  The header is followed
by a message field.  The MRT common header is illustrated below."

s/includes/consists of/

since includes implies it has other information, or the scope for other information in the future.

also the what you illustrate is the MRT format, not just the common header.

=============

It would have been clearer to have described the microsecond extended common header in it's own right and then call it up in each of the *_ET cases, rather than to have described the IGP _ET modes in terms of the BGP _ET mode.


(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2010-10-07)
No email
send info
Some editorial issues:

Section 4 begins with "The MRT format defines five Informational Type messages." but only lists two types.  After
a little sleuthing I discovered the other three types are deprecated.  Perhaps that is worth mentioning in section 4.

In Annex A, some deprecated types (e.g., RPING in section A.2.4) include information about the format.  In other
cases (e.g., IDRP in A.2.3), this was omitted.  Is there a reason for the inconsistency?  (Mostly just curious...)