Subject: [lp-wan] Warren Kumari's No Objection on draft-ietf-lpwan-overview-07: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Jan 2018 14:48:01 -0800

Warren Kumari 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:
----------------------------------------------------------------------

Overall I liked this document -- I do however have some suggestions/nits which
I think would improve the document.

1: I think it would be helpful to explain in the introduction how an LPWAN is
different (other than the obvious "it's bigger") than a low power LAN / PAN --
after reading the document I'm still not quite sure if there is a fundamental
difference.

2: A few examples of the sorts of devices that might be LPWAN devices would be
helpful as well - this document is an overview - this means that many of the
readers will be unfamiliar with the concepts; I ended up searching for some of
the technologies discussed and found things like railway track monitors and
parking sensors, and having these sorts of things as example devices helped me
understand why the technologies are useful.

Nits:
1: Section 2.1.2:
O:   o  - Join Server: The Join Server (JS) is a server on the Internet
C: stray '-'

O: o  Uplink message: refers to communications from end-device to
      network server or application via one or more gateways.
C: I think 'from an end-device' (or possibly 'end-devices') - same for server,
etc.

O:  o  Downlink message: refers to communications from network server or
C: Same as above.

I found Section 2.2 much harder to read - the document says that it assumes
familiarity with numerous 3GPP terms -- perhaps if I were familiar with there
it would have made more sense, but I basically just skipped over it.

Section 2.3. SIGFOX
   Text here is largely from [I-D.zuniga-lpwan-sigfox-system-description] which
   may have been updated since this was published.

A comma after the bracket, or putting the "which may..." would improve
readability. (Hey, I did say these were nits!).

Section 2.4.2.  Characteristics
O: o  Coverage The range of
C: Missing colon after "Coverage".

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jan 2018 10:45:59 +0000

Hi Warren,

Thanks for the review.

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

Fair point. I'll try find some text and get back.

> understand why the technologies are useful.

Andy Malis made a similar point in the rtgdir review, so
I'll also try get some text for that and get back.

For this and the above, I'll wait 'till I've seen the
collected set of IESG comments if that's ok.

> O:   o  - Join Server: The Join Server (JS) is a server on the Internet

Fixed in editor's copy. [1]

  [1] https://github.com/sftcd/lpwan-ov

> O:  o  Downlink message: refers to communications from network server or

As above x 2.

> it would have made more sense, but I basically just skipped over it.

Yep, that's been a challenge. I don't see ways to fix that
easily though without importing a boatload of text which'd
not solve the problem. Suggested text improvements are
welcome from WG participants. (Ideally as PRs to [1])

> readability. (Hey, I did say these were nits!).

Comma, added:-)

> C: Missing colon after "Coverage".

Fixed.

Cheers,
S.

> 
> 
> _______________________________________________
> 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: Edgar Ramos <[email-masked]>
Date: Tue, 23 Jan 2018 14:05:32 +0000

Hi Stephen and Warren,
With respect to the 3GPP terminology, please let me know what do you think are hard-to-chew terminology and I will try to suggest you either a suitable replacement or a light definition 😊

Cheers

Edgar

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, January 23, 2018 12:46
To: Warren Kumari <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lp-wan] Warren Kumari's No Objection on draft-ietf-lpwan-overview-07: (with COMMENT)

Hi Warren,

Thanks for the review.

On 22/01/18 22:48, Warren Kumari wrote:
> 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
> Overall I liked this document -- I do however have some 
> suggestions/nits which I think would improve the document.
> 
> 1: I think it would be helpful to explain in the introduction how an 
> LPWAN is different (other than the obvious "it's bigger") than a low 
> power LAN / PAN -- after reading the document I'm still not quite sure 
> if there is a fundamental difference.

> 
> 2: A few examples of the sorts of devices that might be LPWAN devices 
> would be helpful as well - this document is an overview - this means 
> that many of the readers will be unfamiliar with the concepts; I ended 
> up searching for some of the technologies discussed and found things 
> like railway track monitors and parking sensors, and having these 
> sorts of things as example devices helped me understand why the technologies are useful.

Andy Malis made a similar point in the rtgdir review, so I'll also try get some text for that and get back.

For this and the above, I'll wait 'till I've seen the collected set of IESG comments if that's ok.

> C: I think 'from an end-device' (or possibly 'end-devices') - same for 
> server, etc.
> 

As above x 2.

> 
> I found Section 2.2 much harder to read - the document says that it 
> assumes familiarity with numerous 3GPP terms -- perhaps if I were 
> familiar with there it would have made more sense, but I basically just skipped over it.

Yep, that's been a challenge. I don't see ways to fix that easily though without importing a boatload of text which'd not solve the problem. Suggested text improvements are welcome from WG participants. (Ideally as PRs to [1])

Comma, added:-)

Fixed.

Cheers,
S.