On Mon, 26 Jun 2000 08:04:34 +0200, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=
<paf(_at_)swip(_dot_)net> 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(_at_)cisco(_dot_)com> --
said:
-------
From: Fred Baker <fred(_at_)cisco(_dot_)com>
To: Mohsen BANAN <mohsen(_at_)neda(_dot_)com>
Cc: IETF Mailing List <ietf(_at_)ietf(_dot_)org>,
iesg-secretary(_at_)ietf(_dot_)org, iesg(_at_)ietf(_dot_)org,
RFC Editor <rfc-ed(_at_)isi(_dot_)edu>, Internet Architecture Board
<iab(_at_)isi(_dot_)edu>,
records(_at_)neda(_dot_)com
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(_dot_)0(_dot_)2(_dot_)19981109080326(_dot_)032fb560(_at_)flipper(_dot_)cisco(_dot_)com>
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(_at_)lists(_dot_)emsd(_dot_)org
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.