Ownership and "cross-licensing" of protocols by working groups

James Kempf kempf at docomolabs-usa.com
Tue Oct 7 09:50:51 CEST 2003


> What happens, is that WG-A can, and does, refuse to ratify
> even the most minor changes needed by WG-B.  Then, WG-B
> has to go back to the drawing boards, losing valuable time and/or
> features.
>
> Specific areas where I have seen this occur include:
> - security(IPsec), and
> - neighborhood determination in IPv6
> I would be amazed if these are the only examples.
>
> Therefore for self-preservation, an IETF working group
> should _never_ try to use a protocol for which it does not
> own complete change control.
>
> Or else, we could have a statement by the IAB that mandated
> more flexibility by working groups whose outputs MIGHT be
> useful by someone else in the universe.  I exaggerate.  mea culpa.
> I get aggravated thinking about it.
>

A recent counterexample is the router certificate profile for SEND. The PKIX
WG has standardized an X.509 profile for routers that was originally
intended for SBGP but will work for SEND as well. The SEND WG has adopted
it, so the IETF now has an integrated certificate hierarchy for routers.

The downside, of course, is that the SEND draft is now dependent on the PKIX
draft, since the PKIX draft is normative. My personal opinion is that it is
this which primarily acts as an incentive for WGs to try to minimize
dependencies with other WGs. Success for a WG is getting your documents
published as an RFC, and if you write in a dependency with ongoing work,
essentially you've handed the keys to your succes to the other WG.

But I agree that this is a problem that results in designs which are less
clean and less integrated than could be the case.

            jak



More information about the Problem-statement mailing list