Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-12

I support the experiment being proposed in this document and appreciate the author's responsiveness to my DISCUSS points.

I'm supporting the other DISCUSSes which cover the issues of the draft.

I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems a bit odd. The document doesn't describe the circumstances under which you would want to experiment and why you wouldn't want to let this out on the Internet as a proposed standard. I think some more explanation, and perhaps an adjustment to status, is needed.

I've cleared my Discusses.  Thanks for addressing those points.

1. (fixed in rev -11)

2. (addressed in response from author)

3. (fixed in rev -11)

4. (was Discuss 1) I think some text is needed in section 6.4.7 to
allow for the scenario suggested in this text from the Introduction:

   For example, when an ingress link neighbor accepts an ordinary
   redirection message, it has no way of knowing whether the egress link
   neighbor is ready and willing to accept packets directly without
   involving an intermediate router

The text in section 6.4.7 seems to assume that the egress node will
always be willing to accept traffic from the ingress node.  Fred
explained in e-mail that the egress node can passively ignore the
Predirect message by not sending a response Redirect message.
However, section 6.4.7 does not explicitly note that the egress node
can implement this behavior.

5. (was Discuss 2) I suggest s/involving/forwarding through/ for
clarification.

6. (was Discuss 3) In section 6.4.8, what is the advantage to the
intermediate router snooping the Redirect response and "relaying" the
Redirect on to the ingress node without decrementing the hop count,
rather than what would seem to be a less unusual method in which the
egress node sends the Redirect to the intermediate router, which
receives and processes the Redirect, and then sends a corresponding
Redirect on to the ingress node?

7. (was Discuss 4) Fixed in rev -11.

I like Stephen's suggestion for s4.4.

FWIW, I (still) agree with a bunch of the the other discusses on this.

You've now stated that the signature scheme is for future study,
which is ok for me for an experimental document like this. However,
as a comment, I'm still not keen on how 6.4.4 is written right now.
It says: you're ok if one of 4 things, but how to achieve the last 
one (signatures) is not defined here, yet you say "may be 
obliged" for that. 

I'd suggest getting rid of the 4th bullet entirely and making the
following change (or similar) at the end:

OLD

   Note that on links in which link-layer address spoofing is possible,
   AERO nodes may be obliged to require the use of digital signatures
   applied through means outside the scope of this document.  In that
   case, only the fourth of the above conditions can be accepted in
   order to ensure adequate data origin authentication.

NEW

   Note that on links in which link-layer address spoofing is possible,
   (which is common) AERO nodes will not be very secure since 
   the data origin authentication defined here is easily spoofed. To 
   address this, future work might define a strong data origin 
   authentication scheme (such as the use of digital signatures) to 
   address this problem.