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

[[e-mail]]

Hello all,

This is the response by the ietf-lpwan-ipv6-static-context-hc co-authors
to the observation below by Joseph Touch.
You are right that Section 10 of ietf-lpwan-ipv6-static-context-hc only
shows how to compress IPv6/UDP packets that have no extensions.

However, the SCHC specification in Section 7.1 states
"It is assumed that
   there is a protocol parser alongside SCHC that is able to identify
   all the fields encountered in the headers to be compressed, and to
   label them with a Field ID."

Furthermore, Section 7.3 states
"If any
         header field of the packet being examined cannot be matched
         with a Field Description with the correct FID, the Rule MUST be
         disregarded.  If any Field Description in the Rule has a FID
         that cannot be matched to one of the header fields of the
         packet being examined, the Rule MUST be disregarded."

It follows that, if an IPv6 packet does contain the new UDP TLVs
introduced by draft-tsvwg-udp-options, it will not match a Rule destined
to compress the IPv6/UDP headers and that does not have these TLVs as part
of the Field Descriptors.
Therefore, it will no be compressed by that Rule and will not be
decompressed with a wrong UDP Length at the receive end.

By contrast, if a Rule destined to compress the IPv6/UDP headers does have
these UDP TLVs as part of the Field Descriptors, it is responsible for
reconstructing the UDP Length properly. This can be achieved by means
already provided by SCHC, such as sending the value over the wire or
matching it to an expected constant, etc.

In conclusion, the SCHC compression mechanism, if properly implemented, is
fully compatible with draft-tsvwg-udp-options.

Best regards,

Dominique


Le 12/02/20 16:08, « lp-wan on behalf of Joseph Touch via Datatracker »
<[e-mail] on behalf of [e-mail]> a écrit :

>Reviewer: Joseph Touch
>Review result: Almost Ready
>
>This document has been reviewed as part of the transport area review
>team's
>ongoing effort to review key IETF documents. These comments were written
>primarily for the transport area directors, but are copied to the
>document's
>authors and WG to allow them to address any issues raised and also to the
>IETF
>discussion list for information.
>
>When done at the time of IETF Last Call, the authors should consider this
>review as part of the last-call comments they receive. Please always CC
>[e-mail] if you reply to or forward this review.
>
>I found no transport issues with this document.
>
>However, this document normatively cites
>ietf-lpwan-ipv6-static-context-hc,
>which does have some transport issues of concern. I am listing them here
>because of the dependency between the two documents.
>
>In particular, ietf-lpwan-ipv6-static-context-hc overlooks the case where
>the
>IP header indicates a packet longer than the UDP header, a case that is
>currently being developed for UDP header options in TSVWG. This other
>document
>claims that both UDP and IPv6 length fields can be computed from the
>received
>data, but this is not the case when the IP header indicates a packet end
>after
>that of the UDP header. See draft-tsvwg-udp-options for more information.
>
>There are no changes needed to this document to address this length
>issue, but
>the normative dependency in this doc is the reason for indicatin this
>document
>as "Almost Ready".
>
>_______________________________________________
>lp-wan mailing list
>[e-mail]
>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.