Ownership and "cross-licensing" of protocols by working groups
Alistair.Urie at alcatel.com
Alistair.Urie at alcatel.com
Mon Oct 13 16:19:56 CEST 2003
Brian,
I tend to agree with you on this. I was very worried about the -03 draft
on this issue and had proposed changes to section 2.2. and 2.3. These are
now, more or less, included in the 04 draft so I think we now need to move
forward on fixing the problem since it is now captured well enough in the
problem-statement I-D.
As far as solving the problem of dependencies (both between WGs and between
IETF and other SDOs) I would be VERY concerned about a solution that is
based on "should _never_ try to use a protocol for which it does not own
complete change control" since this implies that other SDOs should "never
try to work with IETF" and likewise, other SDOs should stop trying to work
with the IETF.
A better, and more scalable, solution should be based on a mutual agreement
on what is needed to be changed, why this is the correct route and when
will the outputs (=RFC publication!) be expected. In other words, a way of
formally agreeing that A is dependent on the work of B and that B both
recognises this dependency and committs to deliver on time.
That is, a "WG should never try to use a protocol for which it hasn't reach
an agreement with the originating group"
By the way, there are really two types of dependencies: Loose and Tight
1) Loose dependencies are ones that simply say the A recommends to use the
next version of B. B agrees to do the extension but A doesn't really need
to know the details of how it is done. This type of dependency is
basically covered by an agreement on release date (in time or not for A)
and reference (what does A write in its output to mean "the next release of
B")
2 ) Tight dependencies are ones where A is building directly on the work of
B and its own output needs to be adjusted after B completes its work. This
type of dependency is more complex and often the work of A can be made more
or less difficult if B choses to implement the extension in one way or
another and so a system level design may be needed if we are to optimise
the overal solution.
- alistair
Brian E Carpenter
<brc at zurich.ibm.com> To: problem-statement at alvestrand.no
Sent by: cc:
problem-statement-bounces at al Subject: Re: Ownership and "cross-licensing" of protocols by working groups
vestrand.no
07/10/2003 15:46
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
Spencer Dawkins wrote:
>
> 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: <graham.travers at bt.com>
> To: <charliep at iprg.nokia.com>; <problem-statement at alvestrand.no>
> 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
>
> International Standards Manager
> BT Exact
>
> e-mail: graham.travers at bt.com
> 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:charliep at iprg.nokia.com]
> 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.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
NEW ADDRESS <brc at zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
More information about the Problem-statement
mailing list