WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
[Removed iana etc from the CC list, as there is no point of keeping
them spammed by our WG discussion, I will contact back to them when we
have some kind of resolution about this.]
Paul Hoffman writes:
> On Feb 9, 2012, at 9:59 AM, Yaron Sheffer wrote:
> > Hi Pearl, Tero,
> > Regarding the first change (IPsec Auth Methods), I prefer the
> > existing language. Even though IKEv1 has been obsoleted, I think
> > change control of this central piece of the protocol needs to
> > still require a higher bar than just "specification required".
> > I'm afraid my co-chair disagrees, but he can surely speak for himself...
> I do, and I can. The overhead of requiring IETF and RFC Editor
> process for extensions to a popular-but-obsolete protocol is not
> worth it. If someone publishes a new authentication mechanism for
> IKEv1 that has significant flaws (and they certainly will), they
> publish a new document and it gets a new identifier. This will damp
> out fairly quickly, and auth mechanism developers will get more
> input before publishing.
I think I agree with Paul, but I am not completely sure I understood
what he was saying above... :-)
Anyways, I think Specification required should be enough for that
registry. Other option would really be "Obsoleted protocol, no
allocations allowed", but that would upset even more people...
I do not really see that much point of requiring people to try to get
standard track RFC out just to update the registry, when otherwise the
document could be informational or just specified in some other
standards body etc.
The end result will most likely going to be that people pick number
and start using it without bothering to allocate number for it all, if
the allocating number is too hard. And getting standards track
document to update already obsoleted protocol is going to get other
people complaining (including me).
As this is the last item in the iana ipsec-registry cleanup, I would
like to get this to agenda for example for the Paris meeting and
discuss this there and make decision (one way or other) and solve this
after the Paris meeting.
So my question to working group chairs, would that be ok to discuss
this in Paris IETF meeting (depending of course whether we have
session there or not), and I would like people to hear any other
comments about this here in the mailing list anyways.
IPsec mailing list