Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-17.txt

From: Charlie Perkins <[email-masked]>
Date: Mon, 5 Nov 2018 17:33:48 -0800

Hello Dominique,

I have gone through a bit more than half of the main body of the text 
(not including Appendices).

I have a lot of editorial suggestions for your consideration that I will 
send in another email.

But before the meeting today, I'd like to mention the following:

  * - 'T' is used to signify both the number of bits in DTag and in the
    MIC.  This could be confusing.

  * - According to the discussion in the text, the
    fragmentation/reassembly module for SCHC does not have to be
    colocated with the compression/decompression module.  But, they are
    shown as co-located in Figure 5, which is the main architectural
    diagram in the document.

  * - In section 6.1, there is the following text:
       "This Rule ID identifies a rule that provides the closest match
    to the original packet values."
    However, to my understanding, the matching operators have to match
    *exactly* in order to return TRUE.  It could be that something else
    was meant by this wording, for instance, a "most specific" match,
    but I am not sure about this.

  * Section 7.5.1 specifies processing for variable-length fields.  I
    think this means that a bit is needed in Figure 6 to indicate
    whether or not the Compression Residue is preceded by a length field.

  * Does it make sense to have some well-known Rule-IDs for certain
    well-known message types as illustrated in Figures 12 - 20?

Regards,
Charlie P.

On 10/22/2018 8:38 AM, [email-masked] wrote:
> Dear all,
>
> A new version of the SCHC draft has been submitted.
> The fragmentation/reassembly underwent a major rework.
> It notably contains the much-improved ACK-on-Error mode that was initiated
> at Montreal and designed over the summer.
> We'll present the changes at the meeting in Bangkok.
> Please read it ahead of the meeting if you are interested and want to get
> the best out of the meeting time.
> Best regards
>
> Dominique, on behalf of all the co-authors
>
> Le 22/10/18 22:30, « lp-wan on behalf of [email-masked] »
> <[email-masked] on behalf of [email-masked]> a écrit :
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IPv6 over Low Power Wide-Area Networks
>> WG of the IETF.
>>
>>         Title           : LPWAN Static Context Header Compression (SCHC)
>> and fragmentation for IPv6 and UDP
>>         Authors         : Ana Minaburo
>>                           Laurent Toutain
>>                           Carles Gomez
>>                           Dominique Barthel
>>                           Juan Carlos Zuniga
>> 	Filename        : draft-ietf-lpwan-ipv6-static-context-hc-17.txt
>> 	Pages           : 79
>> 	Date            : 2018-10-22
>>
>> Abstract:
>>    This document defines the Static Context Header Compression (SCHC)
>>    framework, which provides both header compression and fragmentation
>>    functionalities.  SCHC has been designed for Low Power Wide Area
>>    Networks (LPWAN).
>>
>>    SCHC compression is based on a common static context stored in both
>>    the LPWAN device and the network side.  This document defines a
>>    header compression mechanism and its application to compress IPv6/UDP
>>    headers.
>>
>>    This document also specifies a fragmentation and reassembly mechanism
>>    that is used to support the IPv6 MTU requirement over the LPWAN
>>    technologies.  Fragmentation is needed for IPv6 datagrams that, after
>>    SCHC compression or when such compression was not possible, still
>>    exceed the layer-2 maximum payload size.
>>
>>    The SCHC header compression and fragmentation mechanisms are
>>    independent of the specific LPWAN technology over which they are
>>    used.  This document defines generic functionalities and offers
>>    flexibility with regard to parameter settings and mechanism choices.
>>    Technology-specific and product-specific settings and choices are
>>    expected to be grouped into Profiles specified in other documents.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-17
>> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context
>> -hc-17
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-
>> 17
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: <[email-masked]>
Date: Fri, 9 Nov 2018 06:07:07 +0000

Hello Charlie,

Thanks for your comments and sorry for not having acknowledged earlier amidst this busy week.
Points well taken, we'll make sure to address them.
I'm responding to the last two right away:

> Section 7.5.1 specifies processing for variable-length fields.  I think this means that a bit is needed in Figure 6 to indicate whether or not the Compression Residue is preceded by a length field.
Actually the Rule knows what field is being processed, and it knows that this field is of variable length or not. Therefore, if the same Rule is used at both ends (which MUST be the case), the receive end knows to expect a length before the Compression Residue for that field. Pretty much the same way that the receive end knows which Compression Residue bits pertains to which Field, even though there are no delimiters between them.

> Does it make sense to have some well-known Rule-IDs for certain well-known message types as illustrated in Figures 12 - 20?
The whole collection of well-known message types illustrated in Figures 12-20 is separable by direction of flow, value of FCN and overall length.
Therefore, there is no need to assign different Rule-Ids to them. (However, if fragmentation is to take place in both directions, (at least) two different Rule-IDs are needed, one for each direction.)
Forward messages: Regular SCHC Fragment, All-1 SCHC Fragment, ACK REQ, Sender-Abort.
Backward messages: ACK, Receiver-Abort.
Total: 6 messages, all sharing the same Rule-ID.

Best regards,
Dominique

De : Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 6 November 2018 08:33
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : Pascal Thubert <[email-masked]<mailto:[email-masked]>>, Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>, Laurent Toutain <[email-masked]<mailto:[email-masked]>>, ana minaburo <[email-masked]<mailto:[email-masked]>>, Alexander Pelov <[email-masked]<mailto:[email-masked]>>, Carles Montenegro <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-17.txt

Hello Dominique,

I have gone through a bit more than half of the main body of the text (not including Appendices).

I have a lot of editorial suggestions for your consideration that I will send in another email.

  *   - 'T' is used to signify both the number of bits in DTag and in the MIC.  This could be confusing.

  *   - According to the discussion in the text, the fragmentation/reassembly module for SCHC does not have to be colocated with the compression/decompression module.  But, they are shown as co-located in Figure 5, which is the main architectural diagram in the document.

  *   - In section 6.1, there is the following text:
  "This Rule ID identifies a rule that provides the closest match to the original packet values."
However, to my understanding, the matching operators have to match *exactly* in order to return TRUE.  It could be that something else was meant by this wording, for instance, a "most specific" match, but I am not sure about this.

  *   Section 7.5.1 specifies processing for variable-length fields.  I think this means that a bit is needed in Figure 6 to indicate whether or not the Compression Residue is preceded by a length field.

  *   Does it make sense to have some well-known Rule-IDs for certain well-known message types as illustrated in Figures 12 - 20?

Regards,
Charlie P.

On 10/22/2018 8:38 AM, [email-masked]<mailto:[email-masked]> wrote:

Dear all,

Le 22/10/18 22:30, « lp-wan on behalf of [email-masked]<mailto:[email-masked]> »
<[email-masked] on behalf of [email-masked]><mailto:[email-masked]@ietf.org> a écrit :

Abstract:

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-17https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context
-hc-17

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/lp-wan