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

[Gorry Fairhurst <[e-mail]>]

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 [e-mail]. 
> 
> 


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.