Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
draft-kivinen-ipsecme-secure-password-framework-03

This is a comment about the direction of the work in the IPSECME working group. I understand that I'm in the rough on this, we already debated it at the time of the charter being extended.

But I think we chose the wrong direction ,and the problem is only amplified because the working group could not agree on a single password method. We are creating new authentication method negotiation frameworks, and adding those as alternatives in the base IKEv2 exchange. I don't think this will improve interoperability in the long term. I would have chosen to specify small set of new symmetrically operable EAP methods and used the already existing exchanges. The chosen direction will cause IKEv2 implementations to become more complex, as many implementations need to support multiple use cases and therefore in practice support all the authentication frameworks. And if some day we decide to extend configuration support in devices with the new functionality so that shared secret configuration could take place centrally, we'll end up replicating AAA support in addition to the IKEv2 extensions defined here.

- I don't get the point about the specific methods - do they or do
they not use the formats defined here? If not, why not? If so, the
last sentence of the 1st para of the intro is v. confusing.
Do the 3 experimental proposals actually use the values being
registered here? Only one of them (draft-shin...) seems to
reference this draft. Colour me confused.

- Is it ok for an informational doc to add to these registries?

- abstract has typos: 
	s/add new one/add any new ones/
	s/in current connection/in the current connection/

- Intro
	s/and working group/and the working group/
	s/get pick/pick/
	s/make implementation/make an implementation/
	s/a payload formats/payload formats/
	s/co-exists/co-exist/

That's getting tedious. It badly needs an editorial pass.