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

["Eric Vyncke (evyncke)" <[e-mail]>]

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, "[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.