Now: A Lesser IESG Is A Better IETF -- Was: RE: WAP and IP
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Now: A Lesser IESG Is A Better IETF -- Was: RE: WAP and IP
- To: Patrik Fältström <paf@xxxxxxxx>
- Subject: Now: A Lesser IESG Is A Better IETF -- Was: RE: WAP and IP
- From: Mohsen BANAN-Public <public@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: 27 Jun 2000 15:26:52 -0000
- Cc: Mohsen BANAN-Public <public@xxxxxxxxxxxxxxxxxxxxxxxxx>, Vernon Schryver <vjs@xxxxxxxxxxxxxxxxxxxx>, ietf@xxxxxxxx, emsd-spec@xxxxxxxxxxxxxx, esro-spec@xxxxxxxxxxxxxx
- Content-type: text/plain; charset=US-ASCII
- In-reply-to: <p04320404b57c9d265752@[192.168.124.95]>
- References: <200006222310.RAA15677@calcite.rhyolite.com><20000624003117.298.qmail@tooran.byname.net><p04320412b57a070c8adf@[10.0.1.2]><20000626053015.10590.qmail@tooran.byname.net><p04320404b57c9d265752@[192.168.124.95]>
>>>>> On Mon, 26 Jun 2000 08:04:34 +0200, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@xxxxxxxx> said: >> After 7 months of delay, caused by the IESG, ESRO was published >> as an RFC in Sept. 1997. Patrik> There have already been enough discussions on the IETF list about Patrik> ESRO. See the archives. Patrik> You seem to (once again) ignore the problems with making protocols Patrik> interoperate. Patrik> The rest of this discussion exists in the IETF mailing list archives. There is one remaining issue relating to ESRO which is worth pointing out. On Nov 10 1998, the IETF Chair -- Fred Baker <fred@xxxxxxxxx> -- said: ------- From: Fred Baker <fred@xxxxxxxxx> To: Mohsen BANAN <mohsen@xxxxxxxx> Cc: IETF Mailing List <ietf@xxxxxxxx>, iesg-secretary@xxxxxxxx, iesg@xxxxxxxx, RFC Editor <rfc-ed@xxxxxxx>, Internet Architecture Board <iab@xxxxxxx>, records@xxxxxxxx Subject: Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Date: Tue, 10 Nov 1998 06:50:00 +0000 Message-Id: <4.0.2.19981109080326.032fb560@xxxxxxxxxxxxxxxxx> This is to advise you that I have received your note, and expect to rep= ly for the IESG. The basis of that reply will be RFC 2026. Fred Baker IETF Chair ------- I expected the IETF Chair, as representative of the IESG, to be as good as his public word. However, more than a year and a half later, I have yet to receive a reply. Did I miss something? Where is the promised reply? >> - Equal access to RFC Publication Service Patrik> This is not possible, as a review process is guaranteeing the quality Patrik> of the work published. For the various tracks, different reviews are Patrik> done. For informational (such as ESRO) the RFC-Editor is deciding Patrik> whether something is good enough, and asks for input from the IESG. Patrik> Issues which were discussed heavily regarding your two protocols are: Patrik> - Congestion control Patrik> - Ability to gateway to/from existing standards Patrik> - Internationalization issues Patrik> - Security If you want to understand the design of EMSD and contribute to its evolution, join mailto:emsd-spec@xxxxxxxxxxxxxx Patrik> See IESG note in the beginning of RFC 2524. Patrik> All new protocols have to address those issues, as the experience we Patrik> have with the protocols we have today gives that those issues Patrik> (probably) were not addressed enough in those. Because we made that Patrik> mistake once, we don't want to make the same mistake again. So, the Patrik> IESG asks all people which write new protocols to address the issues Patrik> above (and some others). In his e-mail Fred Baker said that IESG's response to my complaint would be based on RFC-2026. In other words, the IETF Chair is stating that the IESG operates according to RFC-2026. With respect to Non-IETF Informational RFCs the purpose and scope of the IESG review and "IESG Note" is well defined in RFC-2026. Untill this is changed, as an IESG member you are obligated to follow those procedures. What you have written above is in conflict with those procedures. I design my protocols my way. I don't need to be told by the IESG what is the right way and what is the wrong way and what requirements my protocols should be addressing. You and the rest of the IESG may not understand my design and may not like my design. With respect to Non-IETF Informational RFC publication, the scope of your involvement is limited to the situation in which there is conflict with existing IETF work. Because the IETF has nothing to offer in the area of Efficient Application Protocols, no conflict exsist. And therefore, according to RFC-2026 you had no legitimate authority to insert that IESG Note. The notion that the IESG/IAB has any sort of authority to guard the health of the "Internet" is simply bogus. When such self-proclaimed guardianship becomes the basis for obstructionism in the Non-IETF Informational RFC process, we have a serious problem. Over the past week, my goal has been to focus on "The WAP Trap", "The Search For Efficient Mobile Messaging Protocols", "LEAP: One Alternative To WAP" and "The Free Protocols Foundation". There has been a great deal of interest on the part of the Internet Technical Community in all of the above. Part of the above topics may have been considered a challenge of sorts to IETF/IESG/IAB's monopoly on protocols. The model that I and many others have adopted for working outside the IETF/IESG/IAB, but based on RFC publication, use of IANA, and patent-free Working Groups, is demonstrating certain deep problems. These problems are deep rooted. Others on this list have said that IETF stands for Innovation Extermination Task Force. That IETF is a Cult ... Many are concerned that IESG/IAB have become instruments of big business and standards politicians. Part of the cure lies in the notions of "Separation of Powers", "Independence Of Protocol Support Organizations", "Competition", and "Checks and Balances". The model proposed in the Free Protocols Foundation Policies and Procedures provides more detail on our thinking. Some starting points for improvement include: - Complete and total independence for the RFC-Editor function. My experience has been that this is simply not the case. - Containment of IESG obstructionism in the RFC publication process. - Promotion of competition amongst RFC-published protocols. At this time, it is not my goal to actively champion such reforms. Therefore my near term active participation in this mailing list is likely to be limited. However, I do want to present the LEAP Development Model as a case study that others may wish to consider and emulate. To that end, it is likely that when we are ready, I will play a more active role in this cause. In the meantime I'll remain hopeful that positive change can come from within IETF/IESG/IAB and will be watching the IESG/IAB evolution towards real responsibility with interest. ...Mohsen.
- Prev by Date: ADMINISTRATIVE NOTE: esro-spec@lists.esro.org Periodic List Information Update
- Previous by thread: ADMINISTRATIVE NOTE: esro-spec@lists.esro.org Periodic List Information Update
- Index(es):