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

[Jari Arkko]

Yes, I've felt the same problem as Charlie has. And
I'm now more cautious about using components from other
WGs than I used to be. I would add that even if
the other WGs would be very willing to co-operate,
the chances are that there's a schedule mismatch.
The extensions would be needed sooner than they
can be delivered.

However, I think the solutions for this problem are harder
than you Charlie indicate. Like it or not the net is
getting more complicated. We have more applications.
We have infrastructure components such as various kinds
of agents, AAA servers, security devices, and so on.
We have more transport services and associated security
mechanisms to go with them. There is *bound* to be more
interactions between the various pieces.

And the world is bigger, with more SDOs than we had to deal
with before. Pretty much everything runs over IP, so its no
wonder we'll have to deal with various needs to build new
things on top of IP.

I can see several issues associated with this situation:

  - Interactions with the results of some other WG, or IETF->SDO
    dependencies are not inherently bad. A well-designed dependency
    is a good thing. But you have to have a good design, its bad to
    depend on all sorts of other stuff that isn't strictly speaking
    essential.

  - One way to measure whether you are having a good dependency
    is to ask whether you are expecting a lot of modifications
    to the protocol that you depend on. If no, its good. If yes,
    its bad. If the protocol needs some new general purpose
    extensions (many of the SIP extensions needed by 3GPP were of
    this sort), this can be still be OK. But if you are starting to
    need specific support for your application, you are on thin ice.

  - If you find that the thing the other WG has developed does
    exactly match your requirements, it may be a good idea to
    design your own.

    Of course, we need to apply some common sense with this
    rule. If we need some small feature to a large, co-operating
    set of protocols (SIP + RTP + SDP, etc to give one example),
    designing your own set of protocols may not be wise.

    On the other hand, you might be better off developing your
    own (even if tweaking an existing component is possible) if
    it would create many new dependencies or APIs. We
    had this case with SEND and AH; it would have been
    possible to use AH but it would have resulted in quite SEND-specific
    AH extensions as well as a number of internal APIs that would
    have been needed. So we decided to build our own authentication
    scheme for SEND instead.

So, here's my tentative set of rules to follow:

R1. REUSE. Where a component exists (or is being developed) by someone
     else, and it matches your requirements, always reuse that component
     in your design.

R2. FOLLOW THE RULES. You must follow the component designer's rules
     (e.g. SIP RFC) when using the component in your own system.

R3. DO NOT TWEAK. If there is no component that exists and suits
     your requirements exactly, you should in most cases develop
     your own mechanisms.

R4. PRODUCE GENERAL RESULTS. In your own work, ensure that what you
     do is readily usable in many environments without a need for
     extensions.

R5. LEAVE ROOM FOR OTHERS (corollary of R4). Don't try to solve
     everything. Your component should perform a function, and deliver
     some information to the layers above. Don't dictate what the
     layers above do. A good example to follow here is TLS, it
     performs a communications security function and delivers
     some information about the endpoints to the application layer.
     The application layer can still make use of that information
     in some application specific way, e.g., match the TLS identities
     to application layer identities.

R6. EXPLICIT APPLICATION RULES. Make it very clear what others
     can and can not do with your protocol components. Can they
     add header fields? Can they specify a particular algorithm
     for deciding when to initiate a specific event?

     We pretty much have IANA considerations in all protocols
     by now, which is good. We also have more specific extensibility
     documents, a good example is the SIP document which talks
     about the process for adding new header fields. (I like the
     fact that such a document exists, I'm not sure if the IETF
     went overboard with the strict requirements for adding header
     fields.)

     We also have some protocol applicability statements, which should
     tell whether the component can be applied in the situation that
     you think of.

     This rule is particularly important when working with other SDOs.

--Jari