Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction
RFC 5778

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

(Dan Romascanu) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-04-20 for -)
No email
send info
Should RFC 4285, "Authentication Protocol for Mobile IPv6" be a normative reference?

(Lisa Dusseault) No Objection

Comment (2009-04-23 for -)
No email
send info
Figure 2 could be much better explained and referenced.  It's clear there are conventions for such diagrams but the conventions are slightly mixed  --  different for IKE and for EAP so different for left and right side of the same diagram!
 - On the left side, every message contains an HDR but that's just part of the list of what the message contains
 - on the right side, every message begins with its type (DER/DEA)
 - SK{xxx} indicates signing?
 - (xxx) indicates payload in DER and DEA messages
 - CP(xxx) indicates an IKE config payload?
 - is the order of messages required -- must the HA wait for a DEA before sending the next message to the MN

An explicit reference that the abbreviations and conventions in the left side come from RFC4306 would be good.  There is a reference to 4306 shortly after the diagram but it is worded as if it explains only a small point.  Better would be  "Conventions and abbreviations for the MN/HA interactions in this diagram are from RFC4306" (plus an explanation for SK(xxx) which is not there.)

I'm not sure what the reference for the right side would be. 

Similar, for the tables in section 6, it's unclear that the conventions and meaning of the columns comes from, for example, RFC3588 (though the specifics differ -- in RFC3588, the last column is not considered an AVP Flag Rule)

(Lars Eggert) No Objection

Comment (2009-04-20 for -)
No email
send info
Section 6., paragraph 2:
>                     AVP  Defined             |    |    |SHLD| MUST|MAY |

  I'd prefer SHLD->SHOULD. (Here and elsewhere.)

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2009-04-20 for -)
No email
send info
Page 20
"[ Multi-Round-Time"
Is there a missing close square bracket?

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-04-23 for -)
No email
send info
Use of EAP methods that do not establish a shared key is discouraged but permitted
(a SHOULD NOT in section 4.1).  

That seems to conflict with goal G4.3 from ietf-mext-aaa-ha-goals...

(Robert Sparks) No Objection