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

[<[e-mail]>]

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) » <[e-mail]> a écrit :

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

>
>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, "[e-mail]"
><[e-mail]> wrote:
>
>    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.
>    
>    
>


_________________________________________________________________________________________________________________________

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.