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

Thank you Dominique

This clears all my DISCUSS, I am updating my ballot

-éric

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

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