Subject: Re: [lp-wan] New Version Notification for draft-barthel-icmpv6-schc-00.txt

From: Ana Minaburo <[email-masked]>
Date: Tue, 7 Nov 2017 15:05:59 +0100

Hello,

I’ve read your draft, just to perhaps answer to some of yours TODO questions:

In 4.1 you say first that :
"TODO: This assumes that all ports that the Device listens to will be
   matched by a SCHC rule.  Is this the basic assumption of SCHC that
   all packets that do not match a rule are rejected?  If yes, why do
   have fragmentation also for uncompressed packets?"

<Ana> Well, the last version of SCHC draft has changed and now we have in section 4.3 
      " If no eligible rule is found,
      then the header must be sent without compression, in which case
      the fragmentation process must be required.”
      So the packets are not rejected they are not compressed but fragmentation is used to sent 
      them.

"TODO: discuss the various Type/Code that are expected to be generated
   in response to various errors.”
<Ana> Are you planning to create a discussion group to go froward with this draft?

In 4.2.1 "TODO: how does one know that the "payload" of a compressed-header
   packet is in fact another compressed header?”

<Ana> This is avery good point to take it out in the WG meetings and ML, I think we have not 
discussed about this possibility. Nevertheless this could happen when the compression allows to reduce the size of the packet in order to have more than one complete compressed packets in one 
L2 frame. In this case the payload is not only a payload but another datagram. For the moment 
the draft does not limit the number of compressed datagrams in a L2 frame. Perhaps an specific 
Rule_id that indicates that there are more than one datagram with the length, this is only one 
idea that need to be discussed

See you
Ana

Ana Minaburo

Research Division

Phone: +33 (0)2.99.12.24.14
ana at ackl.io

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 

www.acklio.com

> On 29 Oct 2017, at 06:23, [email-masked] wrote:
> 
> Dear LPWANers
> 
> This is to let you know that we have submitted a new draft regarding the
> use of ICMPv6 error messages and Echo Request/Reply in LPWANs.
> This is very preliminary draft discusses proxying the Device at the
> infrastructure level and/or compressing the above-mentioned headers using
> SCHC.
> It will be presented at our meeting in Singapore.
> Feel free to comment on the mailing list in the meantime.
> Best regards
> 
> Dominique
> 
> Le 28/10/17 17:50, « [email-masked] » <[email-masked]>
> a écrit :
> 
>> 
>> A new version of I-D, draft-barthel-icmpv6-schc-00.txt
>> has been successfully submitted by Dominique Barthel and posted to the
>> IETF repository.
>> 
>> Name:		draft-barthel-icmpv6-schc
>> Revision:	00
>> Title:		LPWAN Static Context Header Compression (SCHC) for ICMPv6
>> Document date:	2017-10-28
>> Group:		Individual Submission
>> Pages:		12
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-barthel-icmpv6-schc-00.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-barthel-icmpv6-schc/
>> Htmlized:       https://tools.ietf.org/html/draft-barthel-icmpv6-schc-00
>> Htmlized:       
>> https://datatracker.ietf.org/doc/html/draft-barthel-icmpv6-schc-00
>> 
>> 
>> Abstract:
>>  ICMPv6 is a companion protocol to IPv6.  It defines messages that
>>  inform the source of IPv6 packets of errors during packet delivery.
>>  It also defines the Echo Request/Reply messages that are used for
>>  basic network troubleshooting (ping command).  ICMPv6 messages are
>>  transported on IPv6.
>> 
>>  This document describes how to adapt ICMPv6 to Low Power Wide Area
>>  Networks (LPWANs) by compressing ICMPv6/IPv6 headers and by
>>  protecting the LPWAN network and the Device from undesirable ICMPv6
>>  traffic.
>> 
>> 
>> 
>> 
>> 
>> 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.
>> 
>> The IETF Secretariat
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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