Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

[[e-mail]]

Hello Joe, all,

First of all, my sincere thanks to Joe and to all who took the time to
read the SCHC drafts and provide comments on them. I mean it.
Through our emails exchanges over the last two days, I think the
co-authors of ietf-lpwan-ipv6-static-context-hc now have a clear
understanding of the potential issues with the UDP length compression with
SCHC.


Second, let me be transparent.
My goal is to publish the specification of the * generic * SCHC mechanism
as soon as possible.
Frankly, I wish Section 10 (the application of the generic SCHC mechanism
to UDP/IPv6) were a separate draft, so I would not have to worry about it
* right now *.
Since Section 10 shall remain a part of the generic SCHC draft, I’m trying
to find the quickest exit route from the issues the draft currently has.
I’d rather not being dragged into specifying the details of what SCHC must
do in the presence of a UDP Length that cannot be straightforwardly
recomputed out of the IPv6 Length.
I’d rather just state clearly that Section 10, as currently written,
*only* applies to the case where the UDP Length can be straightforwardly
recomputed out of the IPv6 Length, and leave for another draft to deal
with the opposite case.
(Why am I saying this? I’m guessing that there are situations where a
protocol analyser understands all the fields/options/bytes between the
IPv6.Length pointer and the UDP.Length pointer and SCHC conveys all these
fields/options/bytes to the receiver. Then, UDP.Length might still be
recomputed, admitedly not straightforwardly, out of IPv6.Length and the
received fields/options/bytes.)
Therefore, I would rather not write in this draft that “it MUST NOT be
compressed as computable otherwise”, as Joe suggests in his email March
18th 14:6 UTC, included below.

If you agree with this premise, here are the proposed changes in
ietf-lpwan-ipv6-static-context-hc (RFC8724-to-be)

In a nutshell
- clean up the “generic SCHC” specification from any hint that UDP Length
can be recomputed. These hints are not necessary to understand the generic
SCHC algorithm anyway.
- In Section 10 and Appendix A, which are the only ones pertaining to UDP,
specify that these recommendations/examples only apply when the UPD length
can be straightforwardly recomputed out of IPv6 length.

Proposed edits, in order of appearance in the draft

Abstract
OLD_TEXT
This document defines a generic header compression mechanism and its
application to compress IPv6/UDP headers.
NEW_TEXT
This document defines a generic header compression mechanism and its
application to compress basic IPv6/UDP headers.

Section 7.3.8
OLD_TEXT
Because the field is uniquely identified by its Field ID (e.g., UDP
length),
NEW_TEXT
Because the field is uniquely identified by its Field ID (e.g., IPv6
length),

OLD_TEXT
Examples of fields that know how to recompute themselves are UDP length,
IPv6 length and UDP checksum.
NEW_TEXT
An example of fields that know how to recompute themselves is IPv6 length.

Section 10
OLD_TEXT
10.  SCHC Compression for IPv6 and UDP Headers
NEW_TEXT
10.  SCHC Compression for basic IPv6 and UDP Headers

OLD_TEXT
This section lists the IPv6 and UDP header fields and describes how
they can be compressed.  An example of a set of Rules for UDP/IPv6
header compression is provided in Appendix A.
NEW_TEXT
This section shows an application of the generic SCHC C/D mechanism (see
Section 7)
for compressing basic IPv6 and UDP headers.
This section only applies to UDP/IPv6 packets where the UDP length can be
straighforwardly recomputed from the IPv6 length. An example of such a set
of Rules is provided in Appendix A.
Sytems MUST NOT apply compression Rules implemented with the
recommendations from Section 10 unless they verify that the UDP length can
be straighforwardly recomputed from the IPv6 length.

Section 10.10 UDP Length Field
OLD_TEXT
The UDP length can be computed from the received data.  The TV is not
set, the MO is set to "ignore", and the CDA is set to "compute-*".
NEW_TEXT
Providing the condition described at the beginning of Section 10 is met,
the UDP length can be computed from the received data.  The TV is not set,
the MO is set to "ignore", and the CDA is set to "compute-*".

Section 12.1.1
OLD_TEXT
This property is true for IPv6 Length, UDP Length, and UDP Checksum, for
which the compute-* CDA is recommended by this document.
NEW_TEXT
This property is true for IPv6 Length, UDP Length, and UDP Checksum, for
which the compute-* CDA is recommended by this document, under the
conditions described at the beginning of Section 10.

Appendix A
OLD_TEXT
This section gives some scenarios of the compression mechanism for
IPv6/UDP headers.
NEW_TEXT
This section provides an example of a Rule set for compressiing basic
IPv6/UDP headers, where the UDP length can be straightforwardly recomputed
out of IPv6 length.

Would this work for you? Comments welcome.
Thanks

Dominique



Le 18/03/20 16:03, « Mirja Kuehlewind » <[e-mail]> a écrit :

>That’s the better wording!
>
>
>> On 18. Mar 2020, at 15:55, Joseph Touch <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <[e-mail]>
>>>wrote:
>>> 
>>>> Indeed, the protocol parser and the SCHC rules need to know about the
>>>>UDP
>>>> TLVs if one wants to compress them.
>>>> But the same is true of all the other fields. I don't think this one
>>>> warrants a special notice.
>>>> What I insist on is that, if an implementation does not know of the
>>>>UDP
>>>> TLVs, it will not reconstruct an erroneous UDP Length, even for a
>>>>packet
>>>> that contains these TLVs, assuming that the protocol parser checks
>>>>the UDP
>>>> and IPv6 lengths for consistency.
>>> 
>>> I think this last statement (“protocol parser checks the UDP
>>> and IPv6 lengths for consistency”) is the important point that needs
>>>to be explicitly mention in the document!
>> 
>> That way of phrasing it is dangerous - it implies that when the values
>>differ there is some sort of error.
>> 
>> It would be more in line with current TSV efforts to standardize UDP
>>options to say “UDP length can be compressed when it *can* be computed
>>from the IP length” and that “it MUST NOT be compressed as computable
>>otherwise”.
>> 
>> Joe
>


_________________________________________________________________________________________________________________________

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.