Personal tools
You are here: Home → communicationRecord → rfc2188OnStdTrack → Re: Putting ESRO (RFC-2188) on the IETF standards track
Navigation
Log in


Forgot your password?
 

Re: Putting ESRO (RFC-2188) on the IETF standards track

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Putting ESRO (RFC-2188) on the IETF standards track

Mohsen,

I have attempted to review RFC 2188 but find it very difficult to read.
This is because it is not written using standard Internet terminology.
I would expect to find most of the following words in the document, but
none of them appear:

        packet
        TCP
        congestion
        flow
        window
        rate
        backoff / exponential / double / doubling
        checksum
        overlap
        fragment
        MTU
        discover / discovery
        adapt / estimate / estimation
        predict

I am sorry to say that if you want ESRO considered for further progression
on the IETF standards track, then the mandatory first step is to rewrite
RFC 2188 using standard terminology.  This is an essential component of
developing a specification that can be used by the Internet community.

Regarding the earlier words of apparent encouragement for RFC 2188,
unfortunately they are rooted in a misunderstanding.  Scott wrote that
the former Transport co-AD "feels that this ID represents a significant
technical contribution," based on her stating that she felt it should
be treated "seriously".  However, I checked with her now and she replied:

> I'm surprised that I came off as a proponent of ESRO.  I recall
> saying something like this RFC should be treated with seriousness,
> by which I meant that it needed just such an IESG note as it
> got, rather than to be published airily (meaning to pun).

As indicated by the terms listed earlier, as far as I can tell (given the
different terminology), RFC 2188 does not address issues of congestion
control (and even perhaps flow control), nor fundamentals such as MTU
discovery, reassembly of out-of-order segments, and adaptive timers.
These may all be in RFC 2188 using different terms, but one requirement
for considering possibly advancing RFC 2188 is that it first be written
in the standard terminology used for discussing IETF protocols.

		Vern
Main Index | Thread Index
Document Actions