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.

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.)

(Dan Romascanu; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

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

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection (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)

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection (2009-04-28)
No email
send info

(Ralph Droms; former steering group member) No Objection

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

(Robert Sparks; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection (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...