Subject: [lp-wan] 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;-)

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 6 Feb 2018 17:24:29 +0000

Hi Stephen/Samita,

(Removed the IETF Discussion list)

On Feb 6, 2018, at 10:10 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Samita,

Yep. I think this review was due 2017/12/01 and the draft has already gone through IESG evaluation. At this point I would not like to make changes unless they are errors or obvious typos. Depending on the type and amount of changes made, I can recycle the document through the IESG if needed. Stephen’s accepted changes look fine to me and if they are fine with you Samita you can submit a new revision.

Alex/Pascal,
  Any thoughts on this?

Regards
Suresh

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Feb 2018 17:39:31 +0000

Same here, Suresh.

Samita ‘s recommendations all make sense but arrive too late in the process.

Maybe We could ask the group or the IOT dir to work out a glossary and add it as reference at publish time?

Pascal

Le 6 févr. 2018 à 18:24, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Stephen/Samita,

Hi Samita,

Alex/Pascal,
  Any thoughts on this?

Regards
Suresh

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 6 Feb 2018 21:37:01 +0100

Hi Suresh, Pascal, all,

First, I’d like to thank Samita for the review, which once more reinsures that the document is at an excellent level and with excellent quality. Thanks, Samita, for catching some final minor details, and thanks to Stephen for fixing them right away.

Then again, nothing is perfect, and there always will be place for improvement. My impression is that at this stage the document fulfills its goal, so getting it back to make it more perfect would seem like counter-productive. I like the idea of having a glossary document published.. but then again, I don’t think a glossary will actually suffice to describe what RRC does, or the different aspects of 3GPP technology (or any other for that matter). Maybe this will be the start for a new book on LPWANs?

So, back to the point, I agree with Suresh that at this stage, unless there are obvious typos or errors, we should continue with the process.

Best,
Alexander

> Le 6 févr. 2018 à 18:39, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Same here, Suresh. 
> 
> Le 6 févr. 2018 à 18:24, Suresh Krishnan <[email-masked] <mailto:[email-masked]>> a écrit :
> 
>> Hi Stephen/Samita,
>> 
>>> On Feb 6, 2018, at 10:10 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> Hi Samita,
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Feb 2018 20:51:39 +0000

Hi all,

Grand so - based on Suresh's and the chairs' mails, I've
submitted -09. If there are editorial tweaks we can do
those during auth-48 I guess. If something substantive
comes up, I guess we'd discuss that here on the WG list.

So I think this one's ready to shoot off the RFC editor.

Cheers,
S.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Feb 2018 10:28:06 +0000

Thanks Steve!

In preparation of rev 10, I see that we can already add Charlie -pending Suresh's confirmation- and remove appendix A, what do you think?

Pascal

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: mardi 6 février 2018 21:52
To: Alexander Pelov <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Cc: Suresh Krishnan <[email-masked]>; iot-dir <[email-masked]>; Samita Chakrabarti <[email-masked]>; [email-masked]; [email-masked]; Suresh Krishnan <[email-masked]>
Subject: Re: [lp-wan] [IoT-DIR] Iotdir early review of draft-ietf-lpwan-overview-08

Hi all,

Grand so - based on Suresh's and the chairs' mails, I've submitted -09. If there are editorial tweaks we can do those during auth-48 I guess. If something substantive comes up, I guess we'd discuss that here on the WG list.

Cheers,
S.

On 06/02/18 20:37, Alexander Pelov wrote:
>>>> 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.
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Feb 2018 14:29:40 +0000

Hiya,

On 07/02/18 10:28, Pascal Thubert (pthubert) wrote:
> Thanks Steve!
> 
> In preparation of rev 10, I see that we can already add Charlie
> -pending Suresh's confirmation- and remove appendix A, what do you
> think?

I just pushed out -10 which adds Charlie as requested (and
apologies for forgetting to do that before). I've left
appendix A in (who knows we might end up with a -11:-) and
the RFC editor will remove it anyway (to be sure, I added
a note asking 'em to).

If anyone named in acks or as a contributor or whatever wants
the RFC editor to fix non-ASCII characters in your name,
please just send me a mail and I'll check that gets done at
auth-48.

Cheers,
S.

> 
> Pascal
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: mardi 6 février 2018 21:52 
> To: Alexander Pelov <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]> Cc: Suresh Krishnan
> <[email-masked]>; iot-dir <[email-masked]>; Samita
> Chakrabarti <[email-masked]>;
> [email-masked]; [email-masked]; Suresh
> Krishnan <[email-masked]> Subject: Re: [lp-wan] [IoT-DIR] Iotdir
> early review of draft-ietf-lpwan-overview-08
> 
> 
> Hi all,
> 
> Grand so - based on Suresh's and the chairs' mails, I've submitted
> -09. If there are editorial tweaks we can do those during auth-48 I
> guess. If something substantive comes up, I guess we'd discuss that
> here on the WG list.
> 
> Cheers, S.
>> First, I’d like to thank Samita for the review, which once more
>> reinsures that the document is at an excellent level and with
>> excellent quality. Thanks, Samita, for catching some final minor
>> details, and thanks to Stephen for fixing them right away.
>> 
>> Then again, nothing is perfect, and there always will be place for
>> improvement. My impression is that at this stage the document
>> fulfills its goal, so getting it back to make it more perfect would
>> seem like counter-productive. I like the idea of having a glossary
>> document published.. but then again, I don’t think a glossary will
>> actually suffice to describe what RRC does, or the different
>> aspects of 3GPP technology (or any other for that matter). Maybe
>> this will be the start for a new book on LPWANs?
>> 
>> So, back to the point, I agree with Suresh that at this stage,
>> unless there are obvious typos or errors, we should continue with
>> the process.
>> 
>> Best, Alexander
>> 
>> 
>>> Maybe We could ask the group or the IOT dir to work out a
>>> glossary and add it as reference at publish time?
>>> 
>>> Pascal
>>> 
>>>>> On Feb 6, 2018, at 10:10 AM, Stephen Farrell
>>>>> <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> Yep. I think this review was due 2017/12/01 and the draft has
>>>> already gone through IESG evaluation. At this point I would not
>>>> like to make changes unless they are errors or obvious typos.
>>>> Depending on the type and amount of changes made, I can recycle
>>>> the document through the IESG if needed. Stephen’s accepted
>>>> changes look fine to me and if they are fine with you Samita
>>>> you can submit a new revision.
>>>> 
>>>> Alex/Pascal, Any thoughts on this?
>>>> 
>>>> Regards Suresh
>>>> 
>>> _______________________________________________ lp-wan mailing
>>> list [email-masked] 
>> _______________________________________________ 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;-) 
> _______________________________________________ lp-wan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 7 Feb 2018 07:12:34 -0800

Hi Suresh, Stephen and all:
My apologies for being late on the reviews from IoT directorate. I was not
aware about its progress already.

I would suggest changing some of the typos and inconsistencies that Stephen
probably has already taken care of.

Also I will provide him a few lines of text on the 6lowpan section which is
minimal change.

The editorial changes would have been easier for reading the document but I
understand the current situation. I am okay with Stephen's response at this
point and Suresh, I am fine with your decision.
Thanks,
-Samita

On Feb 6, 2018 12:24 PM, "Suresh Krishnan" <[email-masked]> wrote:

Hi Stephen/Samita,

On Feb 6, 2018, at 10:10 AM, Stephen Farrell <[email-masked]>
wrote:

Hi Samita,

Yep. I think this review was due 2017/12/01 and the draft has already gone
through IESG evaluation. At this point I would not like to make changes
unless they are errors or obvious typos. Depending on the type and amount
of changes made, I can recycle the document through the IESG if needed.
Stephen’s accepted changes look fine to me and if they are fine with you
Samita you can submit a new revision.

Alex/Pascal,
  Any thoughts on this?

Regards
Suresh