This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Summary: This document is almost ready for publication as a Proposed
         Standard document. but I believe it will be better to address
         the following points.


1: It would be better to clarify the following points in the protocol for
   registering Map Version number.

   * How many versions of mapping should be maintained by routers and servers?
     Only the latest one or else?
   * Are we allowed to send a new Map-Register message while waiting for
     another Map-Register message?
   * What will be the action when Map-Server receives the version number
     that they are not expecting? Discard or else?
   * What will be the action when Map-Register message reaches retransmission
     limits?

2: Page 3 Section 1:
   "If this is not the case, the ETR can directly send a Map-Request containing
    the updated mapping to the ETR,"

      -> could it be "to the ITR"?

3: Page 6 Section 6:
   "An update in the version number (i.e., a newer version) consists of
    incrementing by one the older version number"

      -> This seems to be an integral part of the protocol.
         I think using MUST here would be preferable.

4: Page 6 Section 6:
   I am wondering what is the use case for comparing two version numbers.
   I might miss something, but it seems to me that we just need to check
   whether the version number is the expected one or not.
   It might be better to explain the use case for it if there is any.

--
Yoshi