Re: Dave Crocker's Appeal - goal and request for positions
Bob Hinden <hinden@ipsilon.com> Tue, 21 March 1995 22:40 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15565; 21 Mar 95 17:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15561; 21 Mar 95 17:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18751; 21 Mar 95 17:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15526; 21 Mar 95 17:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15522; 21 Mar 95 17:40 EST
Received: from NIC1.BARRNET.NET by CNRI.Reston.VA.US id aa12981; 21 Mar 95 13:12 EST
Received: from ipsilon.com by nic1.barrnet.net (8.6.10/BARRNET-RELAY.1) id KAA04505; Tue, 21 Mar 1995 10:11:37 -0800
Received: from [204.160.240.224] (acacia.ipsilon.COM) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA02343; Tue, 21 Mar 95 10:10:08 PST
X-Sender: hinden@servo.ipsilon.com
Message-Id: <v02110102ab94c0640f69@[204.160.240.224]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 21 Mar 1995 10:09:47 -0800
To: iab@isi.edu
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bob Hinden <hinden@ipsilon.com>
Subject: Re: Dave Crocker's Appeal - goal and request for positions
Cc: dcrocker@networking.stanford.edu, hinden@ipsilon.com, pvm@isi.edu, The ISOC President <0001050002@mcimail.com>, iesg@CNRI.Reston.VA.US, isoc-trustees@linus.isoc.org, amr@linus.isoc.org, raj.srinivasan@eng.sun.com
Christian, Thank you for the opportunity to participate in the review of the complaint regarding the ONCRPC working group. I have been involved in this matter while I worked for Sun Microsystems and think I could provide some insight into what went wrong. Overall I think that it is very important that the IETF be able to accept technology developed outside of the IETF. This ranges from complete protocols such as XDR and RPC and to specific techniques which are patented. If the IETF is unable to accept outside technology it will be doomed to try to recreate everything. An official "not invented here" policy would be very unfortunate. In the case of patented technology given the rate that industry is patenting network related technology, the inability of the IETF to create a reasonable agreement with a patent holder could stop all forward progress in all of the IETF working groups. There are a number of issues which I believe caused the agreement between the IETF and Sun Microsystems to get into trouble. They all raise issue with our current process. These include: 1) The text in RFC1622 which defines the conditions under which the ISOC can accept outside technology is not workable. It was written to completely protect the ISOC and is in my opinion unacceptable to all commercial organizations. A donor is required to assume blanket liability for the ISOC. This goes well beyond what any donor would accept. Until the RPC/XDR agreement was written, the procedures covering this topic in RFC1622 had never been used. The RPC/XDR agreement is the first implementation. I think that the text in 1622 should be revised based on what was learned in the implementation process. Assuming the agreement with Sun is completed, it should be used as input to this process. 2) There is not clear owner of an agreement in the IETF/IESG/ISOC who has the authority to negotiate with a technology donor. In the case of RPC/XDR, Sun Microsystems was told at different times to negotiate with a number of different people. This included the IESG executive director, ISOC lawyer, and IESG Chair. In each case an agreement was written but was later rejected by someone else for different reasons. I was personally told by the IESG chair on two separate occasions (each with a new draft agreement) that he would sign the document. This was later retracted. Each time a new person got involved new negotiations started. This process seems to be continuing. Now Sun is negotiating with Vint Cerf, the ISOC president. Certainly we can not expect every agreement to be signed by the ISOC president. An agreement needs to have an owner who is empowered to sign it. It could be one of the above or someone else such as the appropriate IESG area director (this would be my choice). It needs to be one person and a person who is willing to sign the agreement. This person needs to have the time available to do this work. 3) The IESG as an organization did not want to take responsibility for this agreement even after it had chartered the RPC/XDR working group. They could not come to any consensus to sign an agreement or who should sign. The IESG chair also did not want to sign the agreement. Everyone (except for Marshall Rose who did offer to sign for the IESG, but the IESG rejected his offer) wanted someone else to sign it. There seemed to me to be a great fear in the IESG about someone taking legal action against them as an organization or as individuals. This fear in the IESG is ironic given their non-action may make them just a liable as if they had signed an agreement. Sun Microsystems might have cause to claim damages. The ISOC was supposed to have provided liability insurance for the IESG. This has not happened. Either this needs to be done quickly or the relationship between the IETF and the ISOC needs to be reviewed. It is unclear to me what value the ISOC is providing to the IETF. My overall conclusion in this matter is that the formal complaint filed by Dave Crocker is valid. The IESG did mishandle the Sun RPC/XDR agreement. The IESG did not fulfill its contract with the community it made when it chartered the RPC/XDR working group. This includes the IESG as a whole, the area director who was responsible for RPC/XDR working group, and the IETF chair. The IESG needs to be held responsible for its actions (and inactions). Robert Hinden