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

From: <[email-masked]>
Date: Tue, 7 Oct 2003 09:49:29 +0100

Charlie,

I agree;  but this problem doesn't just apply to internal IETF WG relationships.  The more that IETF protocols are used for applications that are not strictly within the scope of the Internet, the more important this issue becomes.  

Think about SIP and 3GPP.  I now hear that the OMA is planning extensions to SIP, which it has no intention of referring back to the IETF.  The IETF has to become more accommodating to the requirements of other organisations, or this sort of thing will happen more and more - and that's bad for ( nearly ) everyone.

	Regards,

	Graham Travers

	International Standards Manager
	BT Exact

	e-mail:   [email-masked]
	tel:      +44(0) 1359 235086
	mobile:   +44(0) 7808 502536
	fax:      +44(0) 1359 235087

	HWB279, PO Box 200,London, N18 1ZF, UK

	BTexact Technologies is a trademark of British Telecommunications plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no. 1800000

	This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: 07 October 2003 03:18
To: Problem Statement Working Group
Subject: Ownership and "cross-licensing" of protocols by working groups

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: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Oct 2003 07:12:00 -0500

Dear Graham,

In my opinion, the real danger isn't another standards body planning
extensions to IETF protocols, it's another standards body dorking with
IETF protocols. The problem with SIP and 3GPP wasn't that 3GPP
extended SIP, it was that one group had headers classified as
mandatory that the other did not, so that an application that was
conformant for one group might send a request that an application
conformant for the other group would consider malformed.

Don't get me wrong - I agree that if we solve some of the IETF
problems, we'll probably get more work than if we don't, and that's
especially true of the problem of committed interdependencies. I'm
saying that the problem with interdependencies isn't just that
interdependencies are harder, it's that interoperability is
jeopardized.

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 07, 2003 3:49 AM
Subject: RE: Ownership and "cross-licensing" of protocols by working
groups

Charlie,

I agree;  but this problem doesn't just apply to internal IETF WG
relationships.  The more that IETF protocols are used for applications
that are not strictly within the scope of the Internet, the more
important this issue becomes.

Think about SIP and 3GPP.  I now hear that the OMA is planning
extensions to SIP, which it has no intention of referring back to the
IETF.  The IETF has to become more accommodating to the requirements
of other organisations, or this sort of thing will happen more and
more - and that's bad for ( nearly ) everyone.

Regards,

Graham Travers

This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or
entity named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of
this information is prohibited. If you have received this electronic
message in error, please notify us by telephone or email (to the
numbers or address above) immediately.

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: 07 October 2003 03:18
To: Problem Statement Working Group
Subject: Ownership and "cross-licensing" of protocols by working
groups

Hello again folks,

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Oct 2003 16:33:18 +0300

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Oct 2003 15:46:41 +0200

Getting back to Charlie's point (because we *can't* reform other bodies,
but we *can* reform the IETF), isn't this in fact the same point that
is made in section 2.3:

>    o  The IETF is not consistently effective at resolving issues that
>       cross WG or area boundaries.
> 
>    o  The IETF does not posess effective formal mechanisms for inter-WG
>       cooperation, coordination or communication, including the handling
>       of dependencies between deliverables and processes specified in in
>       WG charters.
> 
>    o  The IETF does not have an effective means for defining
>       architectures and frameworks that will shape the work of multiple
>       WGs.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK