Subject: [lp-wan] Mirja Kühlewind's No Objection on draft-ietf-lpwan-overview-07: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 24 Jan 2018 10:27:35 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lpwan-overview-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

What's the relation of this document to draft-ietf-lwig-energy-efficient-08?

Some minor, mostly editorial comments:

1) While this document provides a good overview, I find section 2 more
extensive than needed for the gap analysis; on the other hand section 2.2
(NB-IoT) does not really talk about security functions/encryption while the
other sections do that.

2) "Text here is largely from [I-D.farrell-lpwan-lora-overview]" and " Text
here is largely from [I-D.ratilainen-lpwan-nb-iot]" and so one I would suggest
to remove these sentences with references to expired drafts (given the
contributions are listed in sec 7 again).

3) In sec 2.2.2 there is this fragment that can potentially be removed: "User
plane protocol stack"

4) Section 2.4.2: "The Transport service is based on User Datagram Protocol
(UDP)
   defined in RFC768 or Transmission Control Protocol (TCP) defined in
   RFC793."
  Does this mean one can only use UDP or TCP over IPv6 over 6LoWPAN over FAN
  but no other transport protocols? I assume that's not the case and would
  recommend to just remove this sentence (and the reference in the table).

5) Seems slightly weird to me that TLS is mentioned in a section called "4.1. 
Naive application of IPv6"

6) I guess another challenge regarding security might be to update/upgrade such
devices over a low bandwidth network, but that might a topic on its own...

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Jan 2018 13:13:38 +0000

Hiya,

Sorry for the slow response, just getting to this now.

> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/

Personally, I've not read that draft 'till now so I guess
there's no direct relationship:-) I'd say these drafts are
complementary basically. I don't think this one needs a
reference to that one.

> (NB-IoT) does not really talk about security functions/encryption while the

Yep, as I understand it, NB-IoT (almost entirely) inherits LTE's
security model. Describing enough of LTE security to be meaningful
would likely take too much text to be useful. How much LTE stuff
to include is a general issue with 2.2 that we've struggled with.
TBH, I don't see us improving that so much that the effort is
overall worthwhile. (I'll give 2.2 another read over and see if
I can find any easy clarifications as I handle remaining comments.)

> contributions are listed in sec 7 again).

Sure. Done.

> 3) In sec 2.2.2 there is this fragment that can potentially be removed: "User

Done.

>   recommend to just remove this sentence (and the reference in the table).

I don't know if there's some reason one cannot use a different
transport, but perhaps the Wi-SUN/FAN folks can clarify?

> Naive application of IPv6"

I think it fits ok with that paragraph.

> devices over a low bandwidth network, but that might a topic on its own...

Yep, and mentioned by others too. I'll be suggesting adding a
sentence pointing at RFC8240 (in a subsequent mail to WG list).

Cheers,
S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: "d.sturek" <[email-masked]>
Date: Tue, 30 Jan 2018 08:01:47 -0800

Hi Stephen,
For Wi-SUN FAN, the use of TCP is optional.  If you search on TCP congestion control in wireless networks you will find lots of material describing solutions to FTP congestion control in wireless lossy networks.  We opted to make these solutions deployment options.
Don Sturek

Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Stephen Farrell <[email-masked]> Date: 1/30/18  5:13 AM  (GMT-08:00) To: Mirja Kühlewind <[email-masked]>, The IESG <[email-masked]> Cc: [email-masked], [email-masked], [email-masked], Alexander Pelov <[email-masked]> Subject: Re: [lp-wan]  Mirja Kühlewind's No Objection on draft-ietf-lpwan-overview-07: (with COMMENT) 

Hiya,

Sure. Done.

Done.

Cheers,
S.

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Jan 2018 16:09:29 +0000

Hiya,

On 30/01/18 16:01, d.sturek wrote:
> Hi Stephen, For Wi-SUN FAN, the use of TCP is optional. 

Sure. I think Mirja's question was more if it's possible to
use some other transport e.g. SCTP, or, in future, QUIC. I
don't think she's asking if that'd be effective or wise, but
just whether or not there's something that limits one (for
now) to only UDP or TCP. (If I've gotten that wrong, I guess
she'll correct me:-)

Cheers,
S.

> If you
> search on TCP congestion control in wireless networks you will find
> lots of material describing solutions to FTP congestion control in
> wireless lossy networks.  We opted to make these solutions deployment
> options. Don Sturek
> 
> 
> Sent from my T-Mobile 4G LTE Device -------- Original message
> --------From: Stephen Farrell <[email-masked]> Date:
> 1/30/18  5:13 AM  (GMT-08:00) To: Mirja Kühlewind
> <[email-masked]>, The IESG <[email-masked]> Cc: [email-masked],
> [email-masked], [email-masked], Alexander
> Pelov <[email-masked]> Subject: Re: [lp-wan]  Mirja Kühlewind's No
> Objection on draft-ietf-lpwan-overview-07: (with COMMENT)
> 
> Hiya,
> 
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found
>> here: https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/
>> 
>> 
>> 
> 
> Personally, I've not read that draft 'till now so I guess there's no
> direct relationship:-) I'd say these drafts are complementary
> basically. I don't think this one needs a reference to that one.
> 
>> 
>> 1) While this document provides a good overview, I find section 2
>> more extensive than needed for the gap analysis; on the other hand
>> section 2.2 (NB-IoT) does not really talk about security
>> functions/encryption while the other sections do that.
> 
> would likely take too much text to be useful. How much LTE stuff to
> include is a general issue with 2.2 that we've struggled with. TBH, I
> don't see us improving that so much that the effort is overall
> worthwhile. (I'll give 2.2 another read over and see if I can find
> any easy clarifications as I handle remaining comments.)
> 
>> 
>> 2) "Text here is largely from [I-D.farrell-lpwan-lora-overview]"
>> and " Text here is largely from [I-D.ratilainen-lpwan-nb-iot]" and
>> so one I would suggest to remove these sentences with references to
>> expired drafts (given the contributions are listed in sec 7
>> again).
> 
> Sure. Done.
> 
>> 
>> 3) In sec 2.2.2 there is this fragment that can potentially be
>> removed: "User plane protocol stack"
> 
> Done.
> 
>> 
>> 4) Section 2.4.2: "The Transport service is based on User Datagram
>> Protocol (UDP) defined in RFC768 or Transmission Control Protocol
>> (TCP) defined in RFC793." Does this mean one can only use UDP or
>> TCP over IPv6 over 6LoWPAN over FAN but no other transport
>> protocols? I assume that's not the case and would recommend to just
>> remove this sentence (and the reference in the table).
> 
>> 5) Seems slightly weird to me that TLS is mentioned in a section
>> called "4.1. Naive application of IPv6"
> 
>> 6) I guess another challenge regarding security might be to
>> update/upgrade such devices over a low bandwidth network, but that
>> might a topic on its own...
>> 
> 
> Cheers, S.
> _______________________________________________ lp-wan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 30 Jan 2018 19:03:31 +0100

Hi everyone,

One topic that appears to be important (based on feedback from the
reviewers) is to better clarify the different stages and ordering of the
operations defined by SCHC (for a sender, it is first compression, then 
fragmentation, if needed). This would be basically introductory material.

Also there are terminology issues (e.g. how do we call the data unit after
compression?).

So here are some proposals.

1.- We may define that SCHC comprises two sublayers (i.e. compression
sublayer and fragmentation sublayer, as shown in the figure. Would there
be any (hidden) issues involved by adding this to the document?

                  +----------------+ \
                  |   Compression  |  \
                  +----------------+   > SCHC
                  |  Fragmentation |  /
                  +----------------+ /

2.- Two terms are proposed below:

- “SCHC packet”: a packet (e.g. an IPv6 packet) whose header has been
compressed per the header compression mechanism defined in this document.
If the header compression process is unable to actually compress the
packet header, the packet with the uncompressed header is still called a
SCHC packet (in this case, a Rule ID is used to indicate that the packet
header has not been compressed).

- “SCHC fragment”: a data unit that carries a subset of the bytes of a
SCHC packet. Fragmentation is needed when the size of a SCHC packet
exceeds the available payload size of the data unit of the layer
underlying SCHC.

3.- Would the following diagram (for a sender) provide further clarity
regarding what SCHC defines?

                          IPv6 packet
                              |
             /                V
             |         +--------------+
             |         |  compression |
             |         +--------------+
             |                |
     SCHC   <            SCHC packet
             |                |
             |                V
             |        +----------------+
             |        |  fragmentation |  (if needed)
             |        +----------------+
             |                |
             \                V
                        SCHC fragment    (if needed)

We may include content such as the one above in the next revision of SCHC,
so please do not hesitate to provide your feedback.

Thanks!

Carles

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 31 Jan 2018 14:30:01 +0900

Hi,

This clarification is fine to me.  If I would say more, #3 should have the diagram for the incoming processing.

I think that the fragmentation should be more clarified.  If both compression and fragmentation take place to a IPv6 packet, the SCHC packet is fragmented into some SCHC fragments which have another Rule ID.  Correct ?

Best,
Shoichi