Hi Samita,
Thanks for your review, but not sure why you say early review in the subject? I send my review earlier [1] but got [2]. However, I support your comments 100% while don't support some replies in the editor's [2].
I tried in my review in the IETF Last call but not much reasonable replies, even the WG chair said [3] in one reply to my review that they don't take my comments because IESG was already processing draft, I was earlier than your comment, but was surprised that IESG had no much involve.
The other problem IMHO is that our IESG may not be following procedures (or maybe one new comer may say the ietf is not serious, which I said sometime maybe). The IESG should consider individual comments mentioned in the RFC, but I got no respond from IESG/ADs. Is that methodology changed maybe?
In my previous experience with the serious-IETF, the past IESG were responding to me, as I can get a respond from the AD saying ok, I will let the author respond, but this IESG/ADs are not replying. I will say most of our RFCs may be not easy to read.
AB
On Mon, Feb 5, 2018 at 9:08 PM, Samita Chakrabarti <samitac.ietf at gmail.com> 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
IoT-DIR at ietf.org
https://www.ietf.org/mailman/listinfo/iot-dir