Re: Remove private-use values from IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 3:42 PM -0800 3/14/02, Dan Harkins wrote:
>How can you do a tunnel discovery protocol *in* a vendor ID payload?

Like Jan said, using the first part as the ID and the rest of the 
payload as a TLV list (or ASN.1 or whatever).

>The only reason to try to test interoperability of implementations using
>private use values is because the thing they are doing with private use
>values cannot be done in a standard fashion and that thing is important
>enough that multi-vendor interoperability is important.
>
>But if it is that important then why don't we come up with a standard way
>to do it? Politics is one. Bureaucracy and WG inertia is another (that
>it takes longer for the WG to decide something than for huge companies
>to go through two complete product cycles is sad).
>
>If a solution to a problem that people are demanding a solution to is
>either politically forbidden or only likely to to come out in 3-5 years
>then vendors are going to bypass the process.
>
>Taking away private use values because people are misusing them (how to
>standardize something outside of the standardization process) will only
>cause the workarounds they devise to be more novel and problematic. We
>should fix the problem that is causing them to misuse the private use
>values in the first place.

We completely agree here. Any you have already covered it in Section 
10.3: new payload numbers are allocated when getting an RFC 
published, not by waiting around for the WG. That is the right way to 
do things, particularly because at some point this WG is supposed to 
shut down.

--Paul Hoffman, Director
--VPN Consortium