Subject: Iotdir early review of draft-ietf-lpwan-overview-08

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 05 Feb 2018 21:08:47 -0800

Reviewer: Samita Chakrabarti
Review result: Almost Ready

Hi Stephen,
First of all, thank you for writing up the comprehensive overview of LPWAN
technologies and their characteristics. I have read the document and the
following are my comments for IOT-DIR review.

General : Please fix the formatting and paging of the document. Some of the
figures are split between pages. The document uses loads of acronyms from
multiple technologies. A glossary of terms are useful for reference in the
beginning of the decument. Section 2:  :”Note that some…. Of this document” –
please make sure that only RFC and WG approved documents are referenced in the
reference section and remove any reference that are still individual document
at the time of publication/IESG review.

Section 2.4 – Please move the acknowledgement texts to the ACKNOWLEDGEMENT
section at the end of the draft Section 2.1.2 – Table 1 records data rate for
LORA .3 – 5Kbps. For 868MHZ band; Later Table 2 records 50,000 kbps data rate
for the same band.  Is this a typo ? If not please provide explanation Table 4
and page 9 talks about DEVEUI – how are they obtained/configured/assigned on
the end-device? I suggest adding definition of terms for each technology at the
beginning of the document for easy reference. Page 12 calls out PSM, eDRX etc.
– please add their definition in the definition of terms Fig 3: labels eNB but
the document talks about eNodeB. Please make them consistent

Page 14 – describes control function and RRC function. Please provide the RRC
description/definition when RRC is first referenced in page 12. [ move this
description to earlier sections ] Also notr that section 2.2.2 is extremely
long; I would suggest breaking the section into different subsections such as
“network components”, “Network Architecture”, “Control plane” etc. Remove
section 3 and combine the content of section 3 with section 2.1.2. They seem to
have duplicate information. Fig 8 may be moved in section 2.1.2  as well.
Combine fig 9 with fig 1.

Pg 26 – refers to I.D-hong-6lo-use-cases – but I did not find it in the
reference section. Please fix. What is “Very low layer tow payload…. “ – please
fix Note ID-hong-6lo-use-case document not only support 6lowpan, but it
supports 6lo use-cases as well. Section 4.2,2 – The statement  Header
compression and privacy address IID is not quite true. There is guideline for
supporting privacy in 6lo. Please refer to RFC 8065. Section 4.3 -implies that
6lowpan and 6lo support star topologies only. That is NOT true. Both 6lowpan
and 6lo can support both star and mesh topologies. Besides 6lo supports many
different constrained networks including NFC and PLC. Please fix the section
4.3 .

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 5 Feb 2018 21:18:02 -0800

I see the formatting of the sent text is meesed up, here is another try:

Hi Stephen,

General : Please fix the formatting and paging of the document. Some of the
figures are split between pages. The document uses loads of acronyms from
multiple technologies. A glossary of terms are useful for reference in the
beginning of the decument.

Section 2:  :”Note that some…. Of this document” – please make sure that
only RFC and WG approved documents are referenced in the reference section
and remove any reference that are still individual document at the time of
publication/IESG review.

Section 2.4 – Please move the acknowledgement texts to the ACKNOWLEDGEMENT
section at the end of the draft

Section 2.1.2 – Table 1 records data rate for LORA .3 – 5Kbps. For 868MHZ
band; Later Table 2 records 50,000 kbps data rate for the same band.  Is
this a typo ? If not please provide explanation

Table 4 and page 9 talks about DEVEUI – how are they
obtained/configured/assigned on the end-device?

I suggest adding definition of terms for each technology at the beginning
of the document for easy reference.

Page 12 calls out PSM, eDRX etc. – please add their definition in the
definition of terms

Fig 3: labels eNB but the document talks about eNodeB. Please make them
consistent

Page 14 – describes control function and RRC function. Please provide the
RRC description/definition when RRC is first referenced in page 12. [ move
this description to earlier sections ] Also notr that section 2.2.2 is
extremely long; I would suggest breaking the section into different
subsections such as “network components”, “Network Architecture”, “Control
plane” etc.

Remove section 3 and combine the content of section 3 with section 2.1.2.
They seem to have duplicate information. Fig 8 may be moved in section 2.1.2
as well. Combine fig 9 with fig 1.

Pg 26 – refers to I.D-hong-6lo-use-cases – but I did not find it in the
reference section. Please fix.

What is “Very low layer tow payload…. “ – please fix

Note ID-hong-6lo-use-case document not only support 6lowpan, but it
supports 6lo use-cases as well.

Section 4.2,2 – The statement  Header compression and privacy address IID
is not quite true. There is guideline for supporting privacy in 6lo. Please
refer to RFC 8065.

Section 4.3 -implies that 6lowpan and 6lo support star topologies only.
That is NOT true. Both 6lowpan and 6lo can support both star and mesh
topologies. Besides 6lo supports many different constrained networks
including NFC and PLC. Please fix the section 4.3 .

On Mon, Feb 5, 2018 at 9:08 PM, Samita Chakrabarti <[email-masked]>
wrote:

> _______________________________________________
> IoT-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-dir
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Feb 2018 15:10:05 +0000

Hi Samita,

Thanks for the review. As this document has at this stage been
through IESG evaluation, I think it's best to avoid changes if
possible, but I'll be guided by the responsible AD, (i.e. if
Suresh tells me he thinks some change is needed, I'll do it.)
For such cases below I just say I think it's a bit late for
the change suggested.

On 06/02/18 05:18, Samita Chakrabarti wrote:
> figures are split between pages. 

That's for the RFC editor to do. (And doing it now wouldn't help,
as the pagination will change as the RFC editor do their work.)

> The document uses loads of acronyms from

I think it's a bit late for such a change.

> and remove any reference that are still individual document at the time of

It's fine to include informational references to drafts in a
document such as this when those drafts provide useful background,
which I think is the case here.

> section at the end of the draft

I think it's a bit late for such a change.

> this a typo ? If not please provide explanation

Good catch! Table 1 is based on the join-req channel list
(DR0-DR5) whilst the 50000 from table 2 is for DR7 and I
guess only applies after an end-device has joined a n/w.
(Those numbers are in different tables in the LoRa spec,
so I guess I screwed up reading those:-)

I propose to change table 1 to say 50000bps.

If someone more familiar with LoRa wants to tell me that's
wrong (e.g. if DR7 is rarely usable) I'll gladly fix it
to better match reality.

That change is made in my editor's copy. [1] If I don't
get feedback from the WG or AD that that's wrong, I'll
push out -09 in a day or so with that change and the
ones below.

> obtained/configured/assigned on the end-device?

Those need to be provisioned. IIUC, that's done by the
device makers in whatever way they choose.

> of the document for easy reference.

I think it's a bit late for such a change.

> Page 12 calls out PSM, eDRX etc. – please add their definition in the

I think it's a bit late for such a change.

> Fig 3: labels eNB but the document talks about eNodeB. Please make them

Fair enough. Done in editor's copy.

> this description to earlier sections ] 

RRC is expanded on p11.

> Also notr that section 2.2.2 is

I think it's a bit late for such a change.

> as well. Combine fig 9 with fig 1.

I think it's a bit late for such a change.

> reference section. Please fix.

Good catch again. Fixed in editor's copy. (It's always amazing
how such things make it past so many eyeballs!)

> What is “Very low layer tow payload…. “ – please fix

s/very low/tiny/ in editor's copy.

> is not quite true. There is guideline for supporting privacy in 6lo. Please

I think that's a good addition to make, thanks. I've
added this to the end of 4.2.2 in the editor's copy:

 "[RFC8065] provides guidance on better methods for
   generating IIDs."

> including NFC and PLC. Please fix the section 4.3 .

I don't see that implication in 4.3, but would be happy
to consider better wording if you want to offer some.

The editor's copy for a pre-09 is at [1], the diff vs.
-08 is at [2].

Cheers,
S.

[1] https://github.com/sftcd/lpwan-ov/
[2]
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-lpwan-overview-08.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-lpwan-overview.txt

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

-- 
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;-)