ietf
[Top] [All Lists]

Re: ESRO (RE: WAP and IP)

2000-06-27 08:00:02

On Mon, 26 Jun 2000 08:23:41 +0200, Harald Tveit Alvestrand 
<Harald(_at_)Alvestrand(_dot_)no> said:

  Harald> At 05:30 26.06.2000 +0000, Mohsen BANAN-Public wrote:
  >> The current status, state and beginning date of that example
  >> makes my point.
  >> 
  >> After 7 months of delay, caused by the IESG, ESRO was published
  >> as an RFC in Sept. 1997.

  Harald> History note:

  Harald> ESRO (RFC 2188) was delayed, as far as I remember, because of lack of 
  Harald> response from the authors to IESG comments; this turned out to be 
because 
  Harald> the author either didn't get them or didn't think/understand that a 
  Harald> response was needed.
  Harald> I remember some apologies at the time, and the document was published 
  Harald> without making the changes that the comments (some mine) had asked 
for.

Completly Wrong!  

One wonders how much of this ("as far as I remember") is intentional.

The complete record of my interactions with the IESG regarding ESRO,
INCLUDING ALL DATES, is on public record.

The entire communication record between the Authors, RFC-Editor and IESG
regarding ESRO are at: http://www.esro.org/communicationRecord/index.html

Also, the full text of the Complaint against the IESG and the RFC-Editor is
available at: http://www.esro.org/complaint-2188/one/main.html

Anyone may review these records to determine very quickly exaclty who
was responding promptly, and who was causing the delay. I invite Mr.
Alverstrand to refresh his memory by reviewing these records.

He will quickly discover the following incontrovertible and historical
facts:

The ESRO RFC was submitted to the RFC-Editor on Jan 11, 97. Harald
Tveit Alvestrand's *ONLY* e-mail forwarded to the Authors was dated
8/18/1997. I responded to his e-mail on the same day I received it. In
all cases I responded promptly and as required to all comments and
queries from the IESG and the RFC Editor. As the record shows, it is
they who were the cause of the delay.

The fact that a lot went wrong in the case of publication of RFC-2188
is well-known. Steve Coya and Scott Brander have acknowledged that
there were a number of problems and have apologized for them:


  Scott Bradner> ... the iesg fucked up and I'm trying to fix the issue  ...

  Steve Coya> You DO have a valid complaint, but not with the RFC Editors.

  Scott Bradner> ...  As I said things slipped through
  Scott Bradner> the cracks and I am sorry that happened. ...

And then after all this, at the very last minute, without my knowledge
or approval, the IESG inserted their critical note in RFC-2188.


  Harald> ESRO was published without significant input from the IETF community, 
and 
  Harald> has some aspects that I consider rather stupid (tied to a single UDP 
port 
  Harald> number (4.6.3), use of a THREE-bit transport selector (4.4.1) and 
total 
  Harald> lack of discussion of congestion control), but did not face 
significant 
  Harald> opposition in the IESG.

An inability to understand the design of ESRO might be characterized
as rather stupid.

Other UDP ports can be used. There is nothing in the design of ESRO
that limits UDP port usage. This much is obvious. In fact EMSD uses
its own UDP port. Other Efficient Applictions can use other UDP ports
with ESRO. That was part of our design. There is no shortage of UDP ports. 

On a per application basis, 8 transport selectors is more than
adequate. Look at EMSD to learn how that can be done.

Those are not scalability limitations. You simply did not understand
our design.

Discussion of congestion control in the ESRO context is
a complicated issue.

However, if we want to have a meaningful discussion of these technical
issues, the general IETF mailing list is not the right place. I have
gone over these issues with you and others several times before. If
you want to learn more, please subscribe to
mailto:esro-spec(_at_)lists(_dot_)esro(_dot_)org and ask your questions there.


  Harald> It's EMSD (RFC 2524) that was considered by the IESG to be bad enough 
that 
  Harald> it was labelled with an IESG warning containing sentences like "makes 
EMSD 
  Harald> completely unsuitable for end-to-end use across the public Internet", 
and 
  Harald> seemingly earned the IESG the permanent enmity of Mohsen Banan.

The entire communication record between the Authors, RFC-Editor and IESG
regarding EMSD are at: 
http://www.emsd.org/communicationRecord/2524Publication/maillist.html

Based on a severe case of Not-Invented-Here, the IESG attempted to
prevent the publication of EMSD (RFC-2524).  Despite their efforts to
quash it, I successfully demonstrated to the RFC-Editor that EMSD
meets the requirements of RFC-2026 and should therefore be
published. The RFC-Editor's own characterization of the IESG note is
that it was "punitive." The insertion of the IESG note in RFC-2026 has
no legitimate or procedural basis whatsoever, and is in complete
violation of the scope and purpose of IESG's role.

To say I have "permanent enmity" towards the IESG is absurd. When
someone experiences delay, double-dealing, misrepresentation and
mistreatment by an organization, it is hardly surprising that they
complain loudly. Based on logic similar to yours, one can then claim
that I seemingly earned the permanent enmity of the IESG and the IESG
Note in RFC-2524 is the IESG's way of dealing with my complaint.

At this point I have no compelling reason to interact with the IESG at
all. My protocol specifications have been published, and I intend to
continue moving forward with their implementations regardless of what
the IESG does or claims. I'll keep you posted as more and more
implementations of LEAP become widespread.


...Mohsen.



<Prev in Thread] Current Thread [Next in Thread>