Document:           draft-ietf-tcpm-tcp-uto-09.txt
Reviewer:           Scott Brim
Review Date:        24 November 2008
IETF LC Date:       25 November 2008
 
Summary: This draft is basically ready for publication, but has nits
         that should be fixed before publication. 
 
Comments: 

(1) Technical:

  - Since a UTO can apparently be sent at any time, what happens if a
    UTO is received that shortens the timeout and there are
    unacknowledged packets that are already beyond the new timeout
    value?  


  - Is it intended that the ENABLED flag applies to both sending and
    receiving the UTO?  It seems to be, but I want to be sure.  If
    that is the intention, could you make it clearer?

    It certainly applies to a received UTO:

      "This adaptation only happens if the other end of the connection
      has explicitly allowed it (both ENABLED and CHANGEABLE are
      true)."

    but it seems to apply to sending a UTO as well:

      "Before opening a connection, an application that wishes to use
      the UTO option enables its use by setting ENABLED to true."


(2) Editorial:

  1. Introduction

    - "If an end-to-end connectivity disruption lasts longer than the
      user timeout, no acknowledgments will be received for any
      transmission attempt, including keep-alives, and the TCP
      connection will close when the user timeout occurs."

      I would rephrase for clarity:

        If an end-to-end connectivity disruption lasts longer than the
        user timeout, a sender will receive no acknowledgments for any
        transmission attempt, including keep-alives, and it will close
        the TCP connection when the user timeout occurs.


    - "One example of such a scenario is mobile hosts that change
      network attachment points based on current location."

      Drop the last part as redundant:

        One example of such a scenario is mobile hosts that change
        network attachment points.


    - "For example, an orbiting node on a non-geostationary satellite
      might experience connectivity disruptions due to line-of-sight
      blocking by other planetary bodies."

      Let's see, it's orbiting the Earth although not geostationary,
      and experiencing disruption because other planets are blocking
      its transmissions ... it must be communicating with something
      far out in the solar system.  Either it doesn't matter whether
      the orbit is geostationary (or whether it is orbiting at all),
      or disruptions won't be due to planetary bodies.  How about:

        For example, a node in space might experience connectivity
        disruptions due to line-of-sight blocking by planetary
        bodies.