Re: [Last-Call] Genart telechat review of draft-ietf-6lo-fragment-recovery-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Many thanks for your review Peter!

I applied all your typo fix suggestions that are not discussed below.

> Page 14, 3rd paragraph, 1st sentence: change “a same” to one of “any”, “any
> single”, or something similar.  These suggestions are based on the assumption
> that fragments from disparate datagrams are not intermingled, otherwise
> you’ll need some other description of what you want to do in order to allow
> fragments to get a few hops away.

You're right, that can be any frame. Proposed change to:
"
 When a single frequency is used by contiguous hops, the sender should insert a delay between the frames (e.g., frames carrying fragments) that are sent to the same next hop. The delay should cover multiple transmissions so as to let a frame progress a few hops and avoid hidden terminal issues.
"

> Page 18, section 7.1, inter-frame gap, 2nd sentence: change “a same” to “the
> same” in both places in the sentence.  Overall, I couldn’t quite parse this
> sentence.  “may be subject to receive while transmitting” left me guessing as
> to what exactly you wanted to convey here.  Please rewrite this sentence.

Actually I did a few lines ahead but forgot to erase those : ) There's also section 4.2.
So why nit just erase the weird sentence? We then get

"
   An implementation must control the rate at which it sends packets
   over the same path to allow the next hop to forward a packet before
   it gets the next.  In a wireless network that uses the same frequency
   along a path, more time must be inserted to avoid hidden terminal
   issues between fragments (more in Section 4.2).

   This is controlled by the following parameter:

   inter-frame gap:  Indicates the minimum amount of time between
      transmissions.  The inter-frame gap protects the propagation of
      one transmission before the next one is triggered and creates a
      duty cycle that controls the ratio of air time and memory in
      intermediate nodes that a particular datagram will use.
"



> Page 19, OptFragmentSize
Delete “of” before “the Hop Limit”.

Unsure: The Hop Limit is a field that can be compressed at the first hop and will need to be expanded later.


Many thanks for your care, Peter. I looked up and fixed other occurrences of the similar French and I hope the doc reads better now. 

If you agree with the points above I'll submit a new round asap, maybe together with another review.

All the best,

Pascal

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux