Hi Dominique, Quickly chiming in here. Please see below for one comment. > On 18. Mar 2020, at 00:30, dominique.barthel@xxxxxxxxxx wrote: > > Hello Benjamin, > > See my comment to your point, inlined. > > Dominique > > Le 17/03/20 22:13, « Benjamin Kaduk » <kaduk@xxxxxxx> a écrit : > >> On Fri, Mar 13, 2020 at 11:48:18PM +0000, dominique.barthel@xxxxxxxxxx >> wrote: >>> 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. >> >> This "if properly implemented" seems pretty critical. Do we need to leave >> a reminder that implementations have to know about UDP TLVs in order to >> properly identify all fields in the headers to be compressed? > > 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! Thanks! Mirja > See my example in a separate mail. > >> >> -Ben > > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
