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

From: Charlie Perkins <[email-masked]>
Date: Mon, 06 Oct 2003 19:17:42 -0700

Hello again folks,

While reading section 2.3, I remembered a terrible problem
with cross-working-group interactions.  Suppose that working
group A standardizes protocol A, and that working group B
needs the functionality of protocol A for the operation of the
protocol that is to become protocol B.  One would think it should
be natural for WG-B to build on the work within WG-A.  In fact,
one would think that WG-A would actively encourage the work
of WG-B.  Unfortunately, this obvious strategy fails in practice,
for reasons that are unreasonably tedious and counterproductive
to the point of daffiness.

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.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 7 Oct 2003 08:50:51 -0700

> 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