Mobile IPv6 Fast Handovers
draft-ietf-mipshop-fmipv6-rfc4068bis-07

I support most of the discuss issues raised by other area directors, but
did not notice any additional issues after a brief review.

  Based on Gen-ART Review from Ben Campbell...

  There are a large number of editorial errors that have clearly been
  introduced in this draft that were not in the RFC 4068, such as the
  incorrect use of "an" vs "a" occur throughout.  A diff shows that
  there are several paragraphs where the introduction of such errors
  are the only changes from the RFC.  It is possible that the author
  started from the previously approved Internet-Draft text that became
  RFC 4068 instead of the output from the RFC Editor.  If so, there may
  be substantive changes introduced to RFC 4068 during the editing or  
  Auth48 that have been lost.

  The organization of this document difficult. The general operation of
  the protocol is described at least 3 times.  Section 3.1 gives an
  overview, then section 3.2 gives the same description in more detail
  with some more normative language, and then section 4 describes it in
  even more detail with more normative language.  It is common to have
  an overview section and a detailed section, but the presence of the
  half-way-between description is unsettling.  The fact that normative
  language is spread across all of the sections increases the odds of
  implementation errors.

  In section 6, the reader learns that some of the messages are ICMPv6
  extensions and that some of Mobile IPv6 extensions.  This seems like
  very important information, and it should appear earlier.

  Section 3.1, paragraph 5, last sentence, says:
  >
  > Otherwise, it should send it immediately after
  > detecting attachment to NAR.
  >
  The use of "it" in two places causes confusion.

  Section 3.2, paragraph 1, says:
  >
  > The protocol begins when a MN sends RtSolPr to its access router...
  >
  Which access router? PAR or NAR? Please be specific.

  Section 3.2, paragraph 2, says:
  >
  > With the information provided in the PrRtAdv message, the MN
  > formulates a prospective NCoA and sends an FBU message."
  >
  To where? Please be specific.

  Section 4, paragraph 5, 1st list item, says:
  >
  > ... it responds indicating that the new access point is unknown.
  >
  How is this indicated?

  Section 4, paragraph 6, 2nd list item, says:
  >
  > PAR responds with a Code value indicating that the new access
  > point is connected to the current interface ...
  >
  What is the specific code value?

  Section 4, paragraph 7, 3rd list item, says:
  >
  > ... PAR responds indicating that the new access point is known ...
  >
  How is this indicated?

  Section 4, paragraph 16, 4th list item, says:
  >
  > ... provides the status of handover request in Handover Acknowledge
  > (HAck) message.
  >
  To where?

The following editorial typos were identified in Alexey Melnikov's secdir review:

In section 7:

  The protocol specified here, as a design principle, introduces no or
  minimal changes to related protocols.  For example, no changes to the
  base Mobile IPv6 protocol are needed in order to implement this
  protocol.  Similarly, no changes to the IPv6 stateless address
  autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are
  introduced.  The protocol specifies an optional extension to Neighbor
  Discovery [rfc4861] in which an access router may send a router
  advertisement as a response to the UNA message (see Section
  Section 6.4).  Other than this extension, the specfication does not

typo: specification

  modify Neighbor Discovery behavior (including the procedures
  performed when attached to the PAR and when attaching to the NAR).

In Section 9:

  The following security vulnerabilities are identified, and suggested
  solutions mentioned.

     Insecure FBU: in this case, packets meant for one address could be
     stolen, or redirected to some unsuspecting node.  This concern is
     the same as that in a MN and Home Agent relationship.
     Hence, the PAR MUST ensure that the FBU packet arrived from a node
     that legitimately owns the PCoA.  The access router and its hosts
     may use any available mechanism to establish a security
     association which MUST be used to secure FBU.  The current version
     of this protocol relies on a companion protocol [rfc-ho-send]. to

An extra dot after "[rfc-ho-send]".

     establish such a security association.