Subject: [lp-wan] Quick comments on draft-ietf-lpwan-ipv6-static-context-hc

From: C Ad <[email-masked]>
Date: Tue, 14 Nov 2017 01:18:54 +0800

Dear all,

After reading parts of this draft, I would have the following
comments/questions:

I'm using lines numbers as in
https://raw.githubusercontent.com/adjih/SCHC/numbered-draft/draft-ietf-lpwan-ipv6-static-context-hc-07-lines.txt,
here are comments on:

   946    been received or not.  FCN set to All-0 and All-1 fragments are
set
-> Slightly confusing with "All-0" and "All-1";
-> in general, maybe it is possible to differentiate in the text between
the true fragment counter (that never takes the value "All-1") and
something like an "advertized FCN field" that could be "All-1" ? (or
"fragment index in window" vs "FCN").

   880    fragments format this field has a size of R - T - N - 1 *** bits
when

-> computations on R,T,N are presented before R,T,N are defined
-> moreover these names may not be obvious: R=<header size>,  T=<DTag
size>, N=<FCN size>
-> is there a reason to introduce and use R (<header size>) instead of:
using <rule-id size>, and compute 'R' when needed (which is actually maybe
not needed in the current draft)?
-> does the draft specifies constraints for R,T,N (such as >0 orw >=0)?

  1188    one with FCN set to MAX_WIND_FCN.  Also note that, in Window mode,

-> how is MAX_WIND_FCN defined ?

   547       Otherwise, the next rule is tested.  If no eligible rule is
found,
   548       then the header must be sent without compression, in which case
   549       the fragmentation process must*** be required.

-> minor question: "must" or "is likely to" ? If the packet is small, it
might still fit without compression ?

   903    field is an unsigned integer, with a size of N bits.  In the No
ACK
   904    mode it is set to 1 bit (N=1). [...]

-> minor question: isn't it still possible (even if it makes little sense),
to keep larger FCNs in No ACK mode ?
in which case that could be written as: "In the No ACK mode, it SHOULD be
set to 1 bit (N=1)"

..................................................

Possible typos (noted by ***):

   817    the fragment receiver after a window of fragments have*** been
sent.  A

   877    the fragmentation mode used, also to idenitfy*** fragments from
ACK and

   878    Abort frames.  The*** also allows to interleave non-fragmented
IPv6

   890    value when all the bits equals*** 0 (all-0) denotes the last
fragment of

   891    the windonw*** in any window mode or the fragments in No ACK
mode.  The

  1390       case an all-0 fragmet*** is sent and the timer is set.  The
sender

  1386    bitmap is set.  The send*** state can be leaved*** for different
reasons
  1387    (for both reasons it goes to WAIT BITMAP STATE):
-> "The SEND state is left, always for the WAIT BITMAP STATE, in the
following two cases:"

   919    same value for all fragments carrying the same IPv6 datagram,
allows***
-> "and allows"

   823    by the fragment sender, the latter retransmits an all-1 empty
   824    fragment, which serves as an ACK request.  [...]
-> "the latter sends an ACK request (which as the format of an "all-1"
empty fragment).

Spurious "newlines" at lines: 907, 1367

..................................................

thank you,
regards,
-- Cedric Adjih

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 21 Nov 2017 12:13:16 +0100

Thanks for your comments, I've integrated most of them, as the text is
changing and we are adding missing things

Ana

On Mon, Nov 13, 2017 at 6:18 PM, C Ad <[email-masked]> wrote:

> I'm using lines numbers as in https://raw.githubusercontent.com/adjih/
> SCHC/numbered-draft/draft-ietf-lpwan-ipv6-static-context-hc-07-lines.txt,
> here are comments on:
>
>    880    fragments format this field has a size of R - T - N - 1 ***
> bits when
>
> -> minor question: isn't it still possible (even if it makes little
> sense), to keep larger FCNs in No ACK mode ?
>   1386    bitmap is set.  The send*** state can be leaved*** for
> different reasons
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>