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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 21 Aug 2019 06:18:02 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-lpwan-ipv6-static-context-hc-21: Discuss

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/

----------------------------------------------------------------------
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 3.2 --
What is the expected behavior when the "link identifier data item" does not
match the length of this field?

-- 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.

-- 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.

----------------------------------------------------------------------
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 3.1 --
Is there any use of the "link identifier length data item" as in section 3.2
the link identifier has a field for its length?

-- 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) ?

-- 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.

-- section 10.8 --
If you refer to 'extension headers', then use the complete wording 'extension
headers' rather than 'extensions'.

== NITS ==

-- Section 8.4 --
Multiple figures are referred to but do not appear on the same page as the
reference. This hinders the reading.

-- section 10.9 --
s/port/ports/ in the title

---

From: <[email-masked]>
Date: Wed, 21 Aug 2019 16:24:10 +0000

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 » <[email-masked]> a

>https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
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.

>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.

DB: thanks for this suggestion. I'll look into it.

>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?

>headers' rather than 'extensions'.
DB: thanks, will do.

>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)

>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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Aug 2019 06:35:58 +0000

Dominique,

Thank you for your prompt reply and fixing most of my DISCUSSes & COMMENTs. Two are remaining open though.

About my section 10.7.2 comment about sharing the information for RFC 7217, while the 'shared secret' can obviously be shared out-of-band, I am no clue how the value of 'DAD Counter'  could be shared as it can vary from peer to peer and over time... For info, in case the hash algorithm generates a IID collision for one peer, this DAD Counter is incremented only on this peer to try another hash, and so on... If the authors have a way to share this DAD counter, then please explain it.

I am afraid that I am keeping my DISCUSS open on this point. Sorry.

About fragmentation & interleave in section 8, my point if that:
- subsection 8.2.4 comes a little late and only indicate the interleaving of fragments
- nothing is said about interleaving of fragments (even with DTag == 0) and non-fragmented packets.

-éric
PS: and indeed, I made some cut & paste error for my DISCUSS on section 3.2, sorry about that.

On 21/08/2019, 18:24, "[email-masked]" <[email-masked]> wrote:

    Hello Eric, all,

    Dominique

    

    
    DB: thanks, will do.

    DB: will do

---

From: <[email-masked]>
Date: Thu, 22 Aug 2019 10:08:24 +0000

Hello Eric,

Thank your for this reply.
See my comments below regarding section 10.7.2, and specifically on
alleged use of RFC7217.
Best regards

Dominique 

Le 22/08/19 08:35, « Eric Vyncke (evyncke) » <[email-masked]> a écrit :

>About my section 10.7.2 comment about sharing the information for RFC
>7217, while the 'shared secret' can obviously be shared out-of-band, I am
>no clue how the value of 'DAD Counter'  could be shared as it can vary
>from peer to peer and over time... For info, in case the hash algorithm
>generates a IID collision for one peer, this DAD Counter is incremented
>only on this peer to try another hash, and so on... If the authors have a
>way to share this DAD counter, then please explain it.
DB: having thought about it, I want to step back a little on this topic.
This draft is about a generic header compression mechanism, a generic
fragmentation mechanism and the application of the header compression
mechanism to compress UDP and IPv6 headers.
This draft is not about allocating IPv6 addresses to IoT devices.
This draft introduces two special CDA functions (called Dev IID and App
IID) that are intended to enable eliding IIDs generated out of the L2
address. The actual implementation of these functions is
technology-specific (e.g. LoRaWAN, Sigfox, etc.)

What we want to say in 10.7.2 is that there is a range of options for
compressing the IPv6 IID fields.
- IPv6 IIDs that are generated out of the L2 address are elided using the
Dev IID or App IID functions (similar to RFC4944 in 6LoWPAN).
- other static IPv6 IIDS can be elided like any other constant header field
- IPv6 IIDs that are not constant for the lifetime of the "static context"
are to be transmitted in extenso.
At this point I suggest we remove the sentence "[RFC7217] provides some
methods to derive this static identifier" from the draft, as it is totally
out of scope.
However, you opened a very interesting discussion, which belongs to an
architecture document, I believe.
For future benefit, and venturing into that discussion, I would risk the
following opinion:
- SCHC establishes a point-to-point communication between the SCHC
compressor and the SCHC decompressor.
- LPWANs have a star topology, with extensive resources on the "network
side"
- I therefore expect the "network side" to do the RFC7217 IID computation
on behalf of the device, including any needed DAD, and install the
resulting IID into the device as part of the context provisioning.
Therefore, the DAD counter is not in the device and there is no
synchronisation issue. I don't envisage the device to do ND or DAD by
itself. We can further discuss what happens when the device moves between
LPWAN networks, if you are interested, but again we are way out of scope
for this draft.

>I am afraid that I am keeping my DISCUSS open on this point. Sorry.
DB: no worries. I love the good technical conversation anyway!

>    >Thank you for the hard work put into this extensive document. I have
>a
>    >couple
>    >depends on both bits of the ECN field,..." is at the right place?
>Section
>    >10.2
>    >Thank you for the hard work put into this extensive document. I have
>a
>    >couple
>    >Is it worth repeating that the 'out-of-band' initialization of
>devices
>    >include
>    >the selected mode(s) ?
>    >It is unclear to me whether multiple fragmented packets can be sent
>in
>    >parallel
>__________________________________________________________________________
>_______________________________________________
>    
>    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,
>    This message and its attachments may contain confidential or
>privileged information that may be protected by law;
>    If you have received this email in error, please notify the sender
>and delete this message and its attachments.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Aug 2019 13:05:03 +0000

Dominique,

Indeed removing the RFC 7217 sentence would be enough to clear my remaining DISCUSS.

And interesting discussion to have about the RFC 7217 in the gateway ;-)

-éric

On 22/08/2019, 12:08, "[email-masked]" <[email-masked]> wrote:

    Hello Eric,

    Dominique

---

From: <[email-masked]>
Date: Thu, 22 Aug 2019 16:11:17 +0000

Hello Eric,

Please see our proposed resolution of your comment about interleaving in
Section 8.
I believe we have now addressed all your DISCUSSes and Comments.
You can see the proposed changes on our github repo at
https://github.com/lp-wan/ip-compression/compare/df85983113ec9bcefe9ba3782a
e8a07edd1e6ef6...a1b49f480181986282694f0d02c7c6c569ee8c00
Best regards,

Dominique

>and non-fragmented packets.
DB: in the same Section 8.2.4, under the Rule ID bullet point, we state
      "The Rule ID allows SCHC F/R interleaving non-fragmented SCHC
      Packets and SCHC Fragments that carry other SCHC Packets, or
      interleaving SCHC Fragments that use different SCHC F/R modes or
      different parameters."
It seems to me this describes interleaving of fragments and non-fragmented
packets.
Anyway, we propose to add in Section 8.1 Overview
NEW TEXT
This specification provides protocol elements that make it possible to
interleave the transmission of non-fragmented SCHC Packets and fragmented
SCHC Packets, as well as interleave the transmission of fragmented SCHC
Packets. A Profile MAY restrict this behaviour.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Aug 2019 21:46:19 +0000

Thank you Dominique

This clears all my DISCUSS, I am updating my ballot

-éric

On 22/08/2019, 18:13, "[email-masked]" <[email-masked]> wrote:

    Hello Eric,

    Dominique