Re: [lp-wan] I-D Action: draft-ietf-lpwan-schc-over-lorawan-04.txt

[<[e-mail]>]

Dears authors,

I have read draft-ietf-lpwan-schc-over-lorawan-04. I'm glad to see it
progressing the way it does.
In order to accelerate the convergence, here is a list of comments. Worry
not, most of them are just editorial nits.
A few ones are more significant, they are listed in the first section
below. I'd be happy to setup a call/meeting to discuss them at your
convenience.
Best regards,

Dominique


==== significant comments ====
Section 4.5
“As IPv6 is also a multicast technology this
feature MAY be used to address a group of devices.”
inappropriate use of MAY.

Section 5.1

“Ports can use arbitrary values inside the allowed FPort range “
—> inside the FPort range allowed by LoRaWAN

“An application
MAY reserve some FPort values for other needs as long as they don’t
conflict with FPorts used for SCHC C/D and SCHC F/R.”
That would be an application that does not use SCHC.
Therefore, this specification has no control over that application.
Therefore, the uppercase MAY is inappropriate.

Section 5.6.2

“(i.e. the
reverse representation of the polynomial used e.g. in the Ethernet
standard [RFC3385]) as suggested in
[I-D.ietf-lpwan-ipv6-static-context-hc].”
the SCHC draft has improved this sentence. Please update it. Maybe just
refer to the generic SCHC draft as opposed to copying from it.

“LoRaWAN end-devices do not
implement a "retransmission timer”.”
—> “ MUST not … This changes the specification of schc-draft…”

“it sends an all-0 (or
an all-1) fragment with no payload”
The old “empty All-0 and empty All-1” messages no longer exist, neither in
terms of terminology nor in terms of functionality.
See 8.2.1 of the SCHC draft for the list of SCHC F/R messages.
The one you want here is “SCHC ACK REQ”.
—> “it sends a SCHC ACK REQ”

“The last tile can be carried in the All-1 fragment.”
MUST or MUST NOT, pick one. Section 8.4.3 of the SCHC draft says "Each
Profile, for each Rule ID value, MUST define … if the last tile is carried
in a Regular SCHC Fragment or an All-1 SCHC Fragment".
We can't leave it to the implementation or to runtime, this would be an
interop issue.

Section 5.6.2.2.
“Last tile, if any”. MUST be present, or MUST NOT be present. Pick one.


Section 5.6.3.1
Payload is x bytes. You not using the full capacity of x bytes + 6 bits.
Are you sure you want to waste this space?
SCHC tried hard to avoid double-padding (padding at compression and
padding at fragmentation), so this looks underoptimal.
You already have to bit-shift through your compression payload anyway, so
there is no codesize issue and little compute time issue with the idea of
sending x bytes + 6 bits.


Section 5.6.3.2
“Last tile, if any”
—> Pick among “Last tile” or no payload.

Section 5.6.3.5
“The fragmentation receiver (device) does not implement
retransmission timer and inactivity timer.”
—> “MUST NOT …. This changes [schc-draft].”

Section 9.2
[I-D.ietf-lpwan-ipv6-static-context-hc] is a normative reference.
It will have to have become an RFC before this draft becomes an RFC, which
should be ok.



==== editorial nits ====

Section 3
“Static Context Header Compression (SCHC) avoids context
   synchronization, based on the fact that the nature of data flows is
   highly predictable in LPWAN networks, some static contexts may be
   stored on the Device (Dev).”
incorrect grammatical construct.
“either or or “ incorrect grammatical construct.

Section 4
the LPWAN-AAA server is no longer in the generic SCHC specification, you
can remove it from this one.


Section 4.2
“However, that address
   might be reused several times on the same network at the same time”
-> should be rewritten

Section 4.4
o Data
section is empty. I suppose you want to add some description here.


Section 5.1
“The FPort field is part of the SCHC Packet or the SCHC Fragment, as
   shown in Figure 5”.
—> “The FPort field is part of the SCHC Message, …”

“ruleID”—> RuleID (three occurrences in the document)

“Fig. 5 SCHC payload in LoRaWAN” —> “SCHC Message in LoRaWAN”


Section 5.2
“thus
   the packet SHOULD be sent to C/D layer.”
Why the SHOULD? Could it be otherwise? Also, mention that this is when
such a message is received.
“thus, on reception, the SCHC Message MUST be sent to the C/D layer”.

“(ex ACKs)”.
Do you mean “(for example, SCHC ACKs).”?

Section 5.3
TODO privacy respecting IID.

Section 5.5 Compression
“SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the
   SCHC packet as per Section 5.1.”
This is more about decompression than compression. —> Change section title?
SCHC Packet is a keyword in the SCHC draft. —> capitalize “SCHC Packet”.

Section 5.6
L2 word size —> L2 Word Size

“This means that
   only a single fragmented IPv6 datagram may be transmitted and/or
   received by the end-device at a given moment.”
Because of the and/or, this sentence does not add clarity. The previous
sentence is better and self-sufficient, I would think.

Section 5.6.2
“SCHC F/R MUST concatenate FPort and LoRaWAN payload to
   retrieve the SCHC fragment “
—> the SCHC Message


Section 5.6.2.3
Figure 8 : SCHC formats
—> SCHC ACK format
0 to 127 bits —> 0 to 63 bits.

Section 5.6.3
“SCHC F/R MUST concatenate FPort and LoRaWAN
   payload to retrieve the SCHC fragment”
ditto

“(i.e. the
      reverse representation of the polynomial used e.g. in the Ethernet
      standard [RFC3385]), as per
      [I-D.ietf-lpwan-ipv6-static-context-hc].”
ditto

“Figure 12: All-1 SCHC ACK detailed format for the last fragment.”
Caption is incorrect.

"The fragmentation receiver (device) does not implement
   retransmission timer and inactivity timer."
ditto

Section 5.6.3.4
“following an all-1 packet with incorrect RCS”
—> an All-1 SCHC Fragment
In addition, there might be other reasons for replying with a SCHC
Receiver Abort.
—> for example, as a response to an All-1 SCHC Fragment which leads to an
RCS check failure.

Section 5.6.3.5
“until it receives a downlink, on SCHC
   FPortDown from the SCHC gateway different from an ACK-request”
couldn’t it also receive a SCHC Sender Abort?

Section 5.6.3.6
“ACK-request” —> SCHC ACK REQ

“in-case” —> in case

Section A.1
37 bytes (in the text and in Fig 15) or 38 bytes (in the un-named
drawing)? I believe is’s 38.

Section A.2
“is representing”—> “represents”

"An applicative payload of 478 bytes is passed to SCHC compression layer
using rule 1"
Sounds like application directs which RuleID SCHC C/D should use.


					
				
			
		
	
Section A.3

“is passed to SCHC compression layer
 using rule 1”
ditto

“| RuleID | Compression residue |  Payload  |”
Maybe the term “SCHC Packet” could be added on top of this header line.


50 bytes | 6 bits
In the first downlink, the tile could be of 50 bytes and 6 bits, no
padding. 
Similarly, the second downlink could have a tile of 48 bytes and 6 bits,
no padding.

In the SCHCH ACK drawing, RuleID could show “=21” as in the Fragments.

Generally speaking, in Appendices A.1, A.2 and A.3,
- the explanations could be made clearer by using the terms “SCHC Packet”
“SCHC Fragment” and “SCHC ACK”.
- the SCHC ACK should be displayed with LoRaWAN headers much like SCHC
Fragments, otherwise it looks like they are not encapsulated in a LoRaWAN
frame.
- each drawing could have its own caption so that it can be referred to in
the text.





Le 04/11/19 23:13, « lp-wan on behalf of [e-mail] »
<[e-mail] on behalf of [e-mail]> 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           : Static Context Header Compression (SCHC) over
>LoRaWAN
>        Authors         : Olivier Gimenez
>                          Ivaylo Petrov
>	Filename        : draft-ietf-lpwan-schc-over-lorawan-04.txt
>	Pages           : 24
>	Date            : 2019-11-04
>
>Abstract:
>   The Static Context Header Compression (SCHC) specification describes
>   generic header compression and fragmentation techniques for LPWAN
>   (Low Power Wide Area Networks) technologies.  SCHC is a generic
>   mechanism designed for great flexibility so that it can be adapted
>   for any of the LPWAN technologies.
>
>   This document provides the adaptation of SCHC for use in LoRaWAN
>   networks, and provides elements such as efficient parameterization
>   and modes of operation.  This is called a profile.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-lorawan/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-lpwan-schc-over-lorawan-04
>https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-lorawan-0
>4
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-lorawan-04
>
>
>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
>[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.