Dan Harkins writes: > We can't always get what we want and we should be reasonable in > understanding that. If we could wave a magic wand and grant your wish > that would be good; we can't. And given the limits to our power we > have to accept that what will happen is people will continue to use > IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too > much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK > though, so it is likely that by adding SPSK to IKEv1 we could get people > off of XAUTH and that too would be a good thing. > > So if we weigh the improbable stretch goal of forcing people to stop > using IKEv1 with the probable, more easily attainable, goal of getting > people to stop using XAUTH by giving them an alternative that can pretty > easily be implemented, I still come down on settling for an achievable > goal of goodness and not making that be a victim for an unachievable goal > of betterness.
The reason they cannot move to use IKEv1 + SPSK any faster than they can move to use IKEv2 + SPSK is same. Both of them do require new version of both client and server. The client customers always tell that the reason they cannot use IKEv2 as the SGW's they use do not support IKEv2 (or it is not turned on by default). The SGW customers say that the reason they cannot use IKEv2 as they clients do not support it (or it is not turned on by default)... > > Regardless whether it is Specification Required or not, I am still > > objecting if someone tries to add new features to IKEv1. Of course my > > objecting might not have any effect, but I still think it is BAD idea. > > OK, so we're in agreement: "Specification Required." I originally suggested "Specification Required", so yes we are in agreement in that, but we are not only people in the WG, and there has been people saying otherwise. If we do not reach some kind of concensus, then the default action will most likely be "do nothing", which will mean the registry stays what it is now, and I do not want that. I think "IETF Review" would be good compromise for this as it would make it easier than "Standard Track RFC", but would satisfy those who do not want to have it as lower as "Specification Required" is... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
