Re: [lp-wan] Mirja Kühlewind's No Objection on draft-ietf-lpwan-ipv6-static-context-hc-21: (with COMMENT)

[<[e-mail]>]

Hello Mirja,

Thanks for having taken the time to review our draft and to provide your
comments.
We have just published -22, which should be a big step closer to an RFC.
See our responses to your comments inline.
Best regards

Dominique

Le 21/08/19 18:38, « Mirja Kühlewind via Datatracker » <[e-mail]>
a écrit :

>Mirja Kühlewind has entered the following ballot position for
>draft-ietf-lpwan-ipv6-static-context-hc-21: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Thanks for the well-written document!
>
>A few quick comments:
>
>1) This text on ECN in sec 10.3:
>    " ECN functionality depends on both bits of the ECN field, which are
>      the 2 LSBs of this field, hence sending only a single LSB of this
>      field is NOT RECOMMENDED."
>probably belongs in section 10.2 instead, no?
[DB] Indeed, good catch, thanks! Moved to 10.2.

>
>2) If I understand the protocol correctly, I believe it should be a
>normative
>requirement that the Inactivity Timer is always larger than the
>Retransmission
>Timer? Related to this, Appendix F says: "The initial value of the
>Inactivity
>timer is
>   expected to be greater than that of the Retransmission timer, in
>   order to make sure that a (buffered) SCHC Fragment to be
>   retransmitted can find an opportunity for that transmission.  One
>   exception to this recommendation is the special case of the All-1
>   SCHC Fragment transmission."
>I think this section should be moved into the body of the document.
>Further, if
>you need a different timer value for the All-1 SCHC Fragment, you should
>give
>this timer a distinct name and value.
[DB] We went a different way of thinking. Remembering that this is the
specification of the generic SCHC mechanism, we simply stated that the
ACK-Always and ACK-on-Error are bidirectional protocols that require
bi-directional links. Some LPWANs only provide quasi-bidirectional links
(Sigfox, LoRaWAN Class A), some others provide full bidirectional links
(NB-IoT).
They are many ways the quasi-bidirectional links can be made bidirectional
(keep-alive uplink messages at the application layer or other protocol
stack layers, etc.).
Rather that trying in this draft to solve specificities of some use-cases
over some LPWAN technologies, we just deferred it to the schc-over-foo
draft to specify how quasi-bidirectional links (if they exist in the
technology considered) can be made bidirectional. We kept the prior text
as an example that schc-over-foo draft can copy-paste from.
And yes, we gave the new timer a distinct name!

>
>3) I also agree with Alvaro that appendix E should be moved into the body
>of
>the document if you intent to specify something normatively there.
[DB] the capitalised MUST that remained in App E was a mistake.
We rewrote Appendix E such that it is clearly non-normative, but purely
educational.

>
>4) Editorial in Sec 10.11:
>"...with a strength that is identical or better to the UDP
>   checksum."
>Not sure what you mean by "better"...?
[DB] by "identical or better strength", we mean "no weaker", i.e. that it
catches all errors that the UDP checksum does catch.
Do you have a clearer description in mind, that we could use?

>
>5) I wondering if you want to say maybe something about pacing out
>different
>fragments (mostly when a window is used). I know that any recommendation
>would
>be technology dependent but in some cases sending a burst of packets e.g.
>could
>overload some network queues; therefore it could be good to at least
>mention
>it...?
[DB] Thanks for you suggestion.
Following the same line of thinking than for App F, we thought this would
be a good thing to do in a schc-over-foo document, and not in this one.

>
>6) Without having thought too hard about it: is it possible with this
>compression scheme to specify a rule that increases a counter/sequence
>number
>by 1 (given the initial value is known)? Would maybe be nice to say
>something
>about this in the document...
[DB] SCHC was really designed to use a static context. Being able to
compress an incrementing counter field would mean maintaining a dynamic
context, which leads to many difficulties in case of transmission errors,
etc. This is a Pandora box we don't feel like opening.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.