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
- To: Mohsen BANAN <mohsen@neda.com>
- Subject: Re: Putting ESRO (RFC-2188) on the IETF standards track
- From: Vern Paxson <vern@ee.lbl.gov>
- Date: Wed, 04 Nov 1998 00:25:57 PST
- Cc: Scott Bradner <sob@harvard.edu>, iesg-secretary@ietf.org, Keith Moore <moore@cs.utk.edu>, Patrik Faltstrom <paf@swip.net>, Pean Lim-mit <pean@alum.mit.edu>, RFC Editor <rfc-ed@isi.edu>, records@neda.com
- Content-Length: 1937
- In-reply-to: Your message of Mon, 26 Oct 1998 14:59:13 PST.
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
- Follow-Ups:
- Re: Putting ESRO (RFC-2188) on the IETF standards track
- From: Mohsen BANAN <mohsen@neda.com>
- Re: Putting ESRO (RFC-2188) on the IETF standards track
- Prev by Date: Re: Putting ESRO (RFC-2188) on the IETF standards track
- Next by Date: Re: Putting ESRO (RFC-2188) on the IETF standards track
- Prev by thread: Re: Putting ESRO (RFC-2188) on the IETF standards track
- Next by thread: Re: Putting ESRO (RFC-2188) on the IETF standards track
- Index(es):