[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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
