Re: [lp-wan] [IoT-DIR] Iotdir early review of draft-ietf-lpwan-overview-08

[Stephen Farrell <[e-mail]>]

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:
> I see the formatting of the sent text is meesed up, here is another try:
> 
> 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. 

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
> multiple technologies. A glossary of terms are useful for reference in the
> beginning of the decument.

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

> 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.

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 2.4 – Please move the acknowledgement texts to the ACKNOWLEDGEMENT
> section at the end of the draft

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

> 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

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.

> Table 4 and page 9 talks about DEVEUI – how are they
> 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.

> 
> I suggest adding definition of terms for each technology at the beginning
> 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
> definition of terms

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

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

Fair enough. Done in editor's copy.

> 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 ] 

RRC is expanded on p11.

> 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.

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

> 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.

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


> Pg 26 – refers to I.D-hong-6lo-use-cases – but I did not find it in the
> 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.

> 
> 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.

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."

> 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 .

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

> 
> 
> On Mon, Feb 5, 2018 at 9:08 PM, Samita Chakrabarti <[e-mail]>
> wrote:
> 
>> 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
>>
>> _______________________________________________
>> IoT-DIR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/iot-dir
>>
> 
> 
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> 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;-)