Subject: [Gen-art] review of draft-eastlake-ip-mime-09.txt

From: Mark Allman <[email-masked]>
Date: Tue, 22 Nov 2005 09:00:06 -0500

I read through this draft this morning.  I flagged a couple of nits and
something I think ought to be explained a bit better.

Nits:

  + Abstract: "standardized" -> "specified"

  + Section 1: "This document specified" -> "This document specifies" (I
    only imagine it will continue to do so!)

The larger bit I flagged is a note in section 2 that says:

         Note: Although IP and TCP are defined as timing independent
         protocols, many implementations actually have timeouts built
         in.

I think this statement is just wrong and it needs a little massaging. 

  + IPv4 was defined with a TTL that is measured in seconds -- even
    though it's generally implemented as a hop count, that is not the
    way it was specified.  I think this document should at least note
    that there is something to think about here when designing tunnels
    in this way.  (I don't track this stuff closely and maybe we have
    since redefined this as a hop count, ala IPv6.  Regardless, some
    more explanation is needed, I think.)

  + TCP is not and cannot be "timing independent".  TCP relies on a
    retransmission timer for reliability (and, arguably *must* rely on
    such a timer).  It's clearly beyond the scope of this document to
    figure out what to do in this area.  But, a simple note that
    highlights the issue and that one may want to take into account the
    "dilation" parameter when calculating the RTO would seem like a
    useful addition to me.

The draft is easy to read and pretty complete.  I think with a few more
sentences in this "timing" area and the document would be ready for
publication.

allman

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 22 Nov 2005 21:35:44 +0100

> something I think ought to be explained a bit better.

for a document that started out as an April 1 RFC and then got flagged as 
"hey, this can actually be useful", this is certainly not bad.....

(it's been kicking around since August 1999.... people kept on coming up 
with new reasons not to publish it, pushing back on its standards-track 
target, forgetting about it because it was obviously not important.... it's 
been considerably changed from -08 to -09, so the author has obviously not 
given up yet....)