Re: [lp-wan] Éric Vyncke's Discuss on draft-ietf-lpwan-ipv6-static-context-hc-21: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hello Eric, all,

Thanks for your time reading and commenting on this draft.
Please see my responses/questions inline.
Best regards

Dominique

Le 21/08/19 15:18, « Éric Vyncke via Datatracker » <[e-mail]> a
écrit :

>Éric Vyncke has entered the following ballot position for
>draft-ietf-lpwan-ipv6-static-context-hc-21: Discuss
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>Thank you for the hard work put into this extensive document. I have a
>couple
>of DISCUSSes and COMMENTs, all easy to be fixed except perhaps the DISCUSS
>around secrion 10.7.2.
>
>Regards,
>
>-éric
>
>== DISCUSS ==
>
>
>-- Section 10.3 --
>I am not a transport expert but I wonder whether the text "ECN
>functionality
>depends on both bits of the ECN field,..." is at the right place? Section
>10.2
>would appear better to me but again I am not an transport/ECN expert.
DB: oops, totally right. I made a mistake when adding these lines
(contributed by David Black).
I'll move them to 10.2 where they belong.
Because 10.2 and 10.3 have very similar text, the mistake was not visible
on the diff, which I heavily rely on.

>
>-- Section 10.7.2 --
>It is unclear to me how the gateway and the device can share the required
>'shared secret' and especially the 'DAD counter' of RFC 7217... This
>render the
>2 paragraph confusing at best and possibly impossible to implement.
DB: I believe that the gateway and the device (I would say the SCHC
Compressor and SCHC Decompressor) can share them, because they need to
share a lot of stuff (the "Context") anyway.
Installing the 'shared secret' and 'DAD counter' should be no different
than installing pre-shared network keys or the set of compression rules,
it seems to me. 
I will read RFC7217 again with you question in mind and come back later. I
will also consult among the co-authors.

>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Thank you for the hard work put into this extensive document. I have a
>couple
>of DISCUSSes and COMMENTs, all easy to be fixed except perhaps the DISCUSS
>around secrion 10.7.2.
>
>Regards,
>
>-éric
>
>== COMMENTS ==
>
>-- Section 8 --
>Several F/R modes are defined but none is specified as mandatory to
>implement.
>Is it worth repeating that the 'out-of-band' initialization of devices
>include
>the selected mode(s) ?
DB: thanks for this suggestion. I'll look into it.

>
>-- section 8 --
>It is unclear to me whether multiple fragmented packets can be sent in
>parallel
>with other fragmented or non-fragmented packets (such as fragment &
>interleave
>in order to deliver a small packet with priority). Some text around this
>feature (or lack of feature) would be welcome.
DB: It seems to me that the description of DTag in 8.2.4 provides the
answer to your question.
Maybe you're saying that it arrives late into Section 8, and that a short
mention of the feature would be useful in the intro of Section 8?

>
>-- section 10.8 --
>If you refer to 'extension headers', then use the complete wording
>'extension
>headers' rather than 'extensions'.
DB: thanks, will do.

>
>== NITS ==
>
>-- Section 8.4 --
>Multiple figures are referred to but do not appear on the same page as the
>reference. This hinders the reading.
DB: thanks for the comment. I'll see if/how I can coerce our toolchain to
do better (we're using Mmark https://github.com/miekg/mmark)

>
>-- section 10.9 --
>s/port/ports/ in the title
DB: will do
>


_________________________________________________________________________________________________________________________

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.