Re: [TERNLI] Request for review -NiTS rev -07

"Bernard Aboba" <bernard_aboba@hotmail.com> Thu, 15 February 2007 22:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpSs-00059x-Cr; Thu, 15 Feb 2007 17:52:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHmK4-0004rg-Tu; Thu, 15 Feb 2007 14:31:16 -0500
Received: from bay0-omc2-s41.bay0.hotmail.com ([65.54.246.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHmJz-0001hw-Gy; Thu, 15 Feb 2007 14:31:16 -0500
Received: from hotmail.com ([207.46.8.96]) by bay0-omc2-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 15 Feb 2007 11:31:11 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Feb 2007 11:31:10 -0800
Message-ID: <BAY117-F16A1D7A80302CA9DD517DB93960@phx.gbl>
Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 15 Feb 2007 19:31:06 GMT
X-Originating-IP: [71.217.44.143]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
In-Reply-To: <45D433CF.6080501@erg.abdn.ac.uk>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: gorry@erg.abdn.ac.uk, aboba@internaut.com
Bcc:
Subject: Re: [TERNLI] Request for review -NiTS rev -07
Date: Thu, 15 Feb 2007 11:31:06 -0800
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
X-OriginalArrivalTime: 15 Feb 2007 19:31:10.0705 (UTC) FILETIME=[D8E16610:01C75137]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
X-Mailman-Approved-At: Thu, 15 Feb 2007 17:52:32 -0500
Cc: ternli@ietf.org, iab@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

Thank you!

Revisions to the document (in progress) will be available here:
http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-08.txt


>From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
>Reply-To: gorry@erg.abdn.ac.uk
>To: Bernard Aboba <aboba@internaut.com>
>CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, ternli@ietf.org, iab@ietf.org
>Subject: Re: [TERNLI] Request for review -NiTS rev -07
>Date: Thu, 15 Feb 2007 10:19:59 +0000
>
>
>Here are some NiTs to be considered by the authors in their next revison,
>
>Best wishes,
>
>Gorry
>
>
>Bernard Aboba wrote:
>
>>The IAB is considering publication of "Architectural Implications of Link 
>>Indications", and would interested in feedback from the transport 
>>community.
>>
>>The latest version of the document can be found here prior to appearance 
>>on the I-D archive:
>>http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-07.txt
>>
>>Feedback can be sent to iab@ietf.org.
>>
>>
>
>
>NITS
>
>---
>1.1 Routable Address
>     /In this specification, the term "routable address" refers to any
>      IPv4 address other than an IPv4 Link-Local address./
>- Why so IPv4 centric?
>- I don't see why the discussion in the document does not also relate to
>IPv6 addresses, and if we can we should make general guidance for IP,
>rather than version-specific guidance, please provide IPv6 reference.
>- Many of the later examples are taken from IPv4, which is fine, but it
>would be good to see up-front that these issues also apply to IPv6 (which 
>they seem to).
>---
>1.1
>/characteristics which/
>should be:
>/characteristics that/
>                  ^^^^
>----
>/Link indication/
>should be:
>/Link Indication/
>       ^
>---
>/Operable address/
>should be:
>/Operable Address/
>           ^
>---
>/Routable address/
>should be:
>/Routable Address/
>           ^
>---
>/In this specification,/
>          ^^^^^^^^^^^^^
>- In this document? - this is not a protocol spec.
>---
>/sent out an interface/
>       ^^^^^^
>- The English here does not read well for a british reader, could this be
>"by an interface"?
>/sent on an outgoing interface/
>      ^^^^^^^^^^^^^^^
>---
>Section 1.4.1
>/indications may not result in a/
>- can be misread by some English-speaking readers as MUST NOT...
>I suggest:
>/indications do not necessarily result in a/
>                ^^^^^^^^^^^^^^^^
>---
>    /Link indications such
>    "Link Up"/"Link Down" or changes in rate/
>- insert "as" after "such".
>---
>Section 1.4.2 Transport Layer
>/bottleneck bandwidth is already/
>- It's not clear which bottleneck here.
>should be:
>/bandwidth of the bottleneck on the end-to-end path is already/
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>---
>1.4.2.  Transport Layer
>- I prefer adding the word "received"
>/The Transport layer processes link indications differently for/
>Could it be:
>/The Transport layer processes received link indications differently for/
>                                ^^^^^^^^
>---
>Section 2.1
>/avoid use of link models/
>- insert 'the'
>/avoid the use of link models/
>        ^^^
>---
>Section 2.3.2,
>/The problem was caused by an invalid /
>- This paragraph break seems to be wrong - perhaps this is part of the
>previous para?
>---
>Section 2.6
>/   Duplicate Address Detection (DAD)./
>- cite?
>[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
>IPv6", RFC 4429, April 2006.
>---
>Section 2.7
>/  transport parameters for the original interface (MTU, congestion state)/
>- the MSS (derived from link MTU, or PMTU)...
>---
>A.1.2 Smart Link Layer Proposals
>
>Consider adding?:
>
>    [RFC3366] provides advice to the designers of digital
>    communication equipment and link-layer protocols employing link-layer
>    Automatic Repeat reQuest (ARQ) techniques for IP. It discusses the use
>    of ARQ, timers, persistency in retransmission and the challenges that
>    arise from sharing links between multiple flows and in differentiation
>    transport flow requirements.
>
>