Asymmetric Extended Route Optimization (AERO)
RFC 6706

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

(Adrian Farrel; former steering group member) (was Discuss) Yes

Yes (2012-06-14 for -11)
No email
send info
Thanks to the author for providing some cocrete examples and motivation, and for moving the experiment to operate over UDP. This addresses my Discuss and I am happy to ballot "yes" and encourage this experiment.

I would be interested to hear from the author how he sees the applicability of this work to data centers and the NVO3 working group.

(Stewart Bryant; former steering group member) Yes

Yes ( for -10)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2012-06-21 for -11)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (2012-06-21 for -11)
No email
send info

(Brian Haberman; former steering group member) (was Discuss) No Objection

No Objection (2012-06-14 for -11)
No email
send info
I support the experiment being proposed in this document and appreciate the author's responsiveness to my DISCUSS points.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection (2012-04-25 for -10)
No email
send info
I'm supporting the other DISCUSSes which cover the issues of the draft.

(Pete Resnick; former steering group member) No Objection

No Objection (2012-04-22 for -10)
No email
send info
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.

(Ralph Droms; former steering group member) (was Discuss) No Objection

No Objection (2012-06-20 for -11)
No email
send info
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.

(Robert Sparks; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Ron Bonica; former steering group member) (was Discuss) No Objection

No Objection ( for -11)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ( for -11)
No email
send info

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

No Objection (2012-06-20 for -11)
No email
send info
I like Stephen's suggestion for s4.4.

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2012-06-13 for -11)
No email
send info
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.