Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
draft-ietf-mip6-whyauthdataoption-07

First of all, I should say that after working on the DSMIPv6
document, I'm rather sympathetic to arguments that perhaps using
IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and
the authentication option can be valuable in some deployments.

However, much of the text in Sections 2/3/4 is written in way that
makes it difficult to distinguish when it's describing the history
(why RFC 4285 was originally done, before IKEv2 and RFC 4877 existed),
and when it's describing why it's still a good idea today. It seems
the energy needed to rewrite this text doesn't exist, however, and
I'm grudgingly changing this from discuss to comment.

Also, somewhat surprisingly for a document defending RFC 4285, the
document also doesn't mention what's IMHO the *main* advantage of RFC
4285 over IPsec: implementation complexity. Especially with new MIPv6
features like DSMIPv6, the interface between IPsec stack and MIPv6
stack is getting complex, and the IPsec stack needs more
MIPv6-specific functionality (so you can't necessarily use just any
off-the-shelf IPsec stack). However, it seems not everyone agrees
about this topic, so perhaps it can be omitted, too.

I'd be happier if the text discussing overhead of IPsec/IKE reminded
folks that IKE overhead is usually one time (e.g. once a day), not 
something that happens when doing handover -- currently it does
give an impression that IPsec/IKE is a bandwidth hog, which isn't
really that accurate.

I understand (more or less) the history of this document, and its goals, but I wish this
document had evolved into a more even treatment of the applicability of RFC 4285 and
RFC 4877.   The document reads more as a defense of 3gpp than was necessary imho.
Documenting the process more generically, then using 3gpp as an example would have
made the document easier for future system architects to apply the information
when architecting their own solutions.

Addressing this comment directly would require major surgery that is probably
innapropriate at this stage of the document lifecycle, but I think implementing Pasi's
proposals or something similar would certainly be helpful.