> 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...
Summarizing my views:
- "Specification Required" is an unacceptably low bar for this sort of
security protocol due to the possibility of security flaws.
- I prefer "IETF Review" to "Expert Review" for this sort of security
protocol as "IETF Review" should yield higher-quality results.
Thanks,
--David
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Tero Kivinen
> Sent: Wednesday, March 28, 2012 9:04 AM
> To: Dan Harkins
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods
> (Value 3) registration
> policy
>
> 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...
> --
> kivi...@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
