Re: [lp-wan] Last Call: <draft-ietf-lpwan-overview-07.txt> (LPWAN Overview) to Informational RFC

[Abdussalam Baryun <[e-mail]>]

Hiya,

I don't mind any decision made by IESG, I know that most WGs and many
authors in IETF don't prefer to change any thing, this is always
comments/discussions send to IESG/IETF and its members will make the final
decision. I still think the draft needs changes and it can be better (it
can and will cause misunderstanding), and it seems quickly written.
However, I always wish the IETF/RFCs the best decision not the easiest. My
final comments below,


On Tue, Jan 23, 2018 at 1:42 PM, Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> Thanks for the suggested text. In my reactions below, I'm
> generally going for no/minimal change, given that the draft
> has been through the WG process etc. In other words, if I
> think that your suggested changes don't make a noticeable
> improvement (e.g. if I figure they're neutral) then I'd
> like to not make changes unless someone else agrees your
> suggested change is worth making. I hope that's ok given
> where this draft is in the overall process.
>
> On 22/01/18 23:10, Abdussalam Baryun wrote:
> > Hi Stephen,
> >
> > My final comments for the draft, I found a good overview which I suggest
> to
> > add,
> >
> > My comments [cm] and suggestions  [sg],
> >
> > [cm] IMHO, Rfc4919 is easy to read and I prefer this draft to have
> similar
> > structure. Long pages with no sections and subsections makes it difficult
> > to read or see characteristics. please make some subsections with a
> number
> > or with a point.
> >
> > [Sg] The title should not be in letters, however the draft does not cover
> > all LPWAN technologies available, so I suggest
> >
> > [sg] replace title to > Low Power Wide Area Networks technology overview
>
> I don't object but slightly prefer the current title. If someone
> else likes expanding the acronym, I'd be ok with that but for now
> I think leaving it as-is is fine.
>

I don't think it should be done that way. We may say here, we need another
participant out of LPWAN WG that likes your title, in that way we can leave
it :-)
However, I agree with any decision the IESG takes, but still think the
title should be changed.


> >
> > [Sg] to delete the dollar costs in the draft's body, only in the
> > introduction we may mention that as to give a feeling of cost, but if we
> > put per technology, that seems like writing marketing or business
> > information, and not writing engineering informational.
>
> The WG did chat about that way-back and IIRC I think the consensus
> was to leave the information there as it's about design goals for
> the various technologies. I think the only one with a US$ amount
> mentioned is in 2.2.2 and that's stated as a target and not as an
> achieved result.
>
> WGs usually like less/no changes even if confusions appear, but now draft
is with IESG, so I think they don't follow WG consensus otherwise there is
no point of reviews out of WGs.

> >
> > In Abstract>
> >
> > Low Power Wide Area Networks (LPWAN) are wireless technologies with
> >
> > characteristics such as large coverage areas, low bandwidth, possibly
> >
> > very small packet and application layer data sizes and long battery
> >
> > life operation.
> >
> >
> >
> > cm> The draft must state exactly the Low Power characteristic as defining
> > it with wireless wan. IMO we don't use the bandwidth to represent bit
> rate
> > while discussing in the layers under ip. Furthermore, some LPWAN use
> spread
> > techniques LoRa which are not low BW or not NB.
> >
> > cm> In page 21 the draft contradicts the low BW by mentioning high BW,
> but
> > that is spreading BW not speed.
>
> I think the text on p21 is fine. Wi-SUN does differ from the
> other described technologies in this way, so it's correct to
> provide the information I think.
>
> > Old edit> Low Power Wide Area Networks (LPWAN) are wireless technologies
> > with characteristics such as large coverage areas, low bandwidth,
> possibly
> > very small packet and application layer data sizes and long battery life
> > operation.
> >
> > New edit>
> >
> > Low Power Wide Area Networks (LPWAN) are wireless networks with low power
> > and long range transmission technologies, with characteristics such as
> low
> > transmission bit rate, high receiver sensitivity, possibly very small
> > packet and application layer data sizes and long battery life operation,
> > and large number of end devices distributed over large geographical areas
> > for a low cost.
>
> I don't find your suggested text clearer, sorry, so unless
> someone agrees with you I think leaving it as-is is better.
>
>
You ask me in previous messages to edit and now I did do the editing,
and now you say unless someone agrees with you.

>
> >
> >
> > Add>  Applicability Statement: (add in one section number)
>
> Note that I do not agree an applicability statement is called
> for by our process. If you want to have a discussion about
> that aspect of IETF process, feel free to have that chat with
> the responsible AD.
>
>
I just commented and suggested to IESG, so I did discuss now in their list,

> >
> >
> > The objective of LPWAN technologies is to achieve a long range with low
> > power consumption and low cost different from other wireless WAN
> > technologies for which achieving higher data rate, lower latency and
> higher
> > reliability. LPWAN technologies are used in various emerging smart city
> and
> > machine-to-machine (M2M) applications like: tracking physical objects,
> > detecting or monitoring data about environment/industry/system, metering
> > reporting for water, electricity, etc. Furthermore, in some applications
> > the end-devices may be dependent or independent within the network, and
> the
> > end-devices are either part in the data analysis or just data reporting.
> > Mostly in LPWAN the end-devices are used as data reporting  with low
> > processing and the gateways as the access point. Some applications can
> use
> > the end-devices as transmitters only without receivers, or with very
> short
> > listening periods.
>
> I'll consider your suggested text when I address Warren's IESG
> ballot comment and Andy's rtgdir review as they were asking for
> some similar kinds of text. So I expect we'll end up adding
> something along these lines. (Note that I plan to do that after
> I've seen other IESG comments on the draft.)
>
> ok

> >
> >
> > Add>  LPWAN uses star topology to eliminates many overhead associated
> with
> > the use of meshing such as forwarding or routing overheads.
>
> I'm not sure that's fully accurate. If someone else wants to
> support adding that then I'd like to hear from them, but for
> now I don't think that addition would be useful.
>

at least we need show why current technologies are using STAR topology,
 and that does not mean LPWAN is about only star topology. However, saying
the disadvantages of one topology is important to give the reason.

>
> >
> > SG> Rfc7452 should be referenced because mentions the Architectural
> > Considerations in Smart Object Networking which is related in covering
> the
> > gap for LPWAN.
>
> Being "related" isn't a good enough reason to add a reference.
> But see below.
>
> >
> >
> > [cm] the LoRA gateways use IP, but end devices have no.
> >
> >
> >
> > Sg>delete> As of today, essentially no LPWAN devices have IP
> capabilities.
> >
> > Replace> As of today, essentially no LPWAN end-devices have IP
> capabilities.
> >
>
> Sure. Fixed in editor's version.
>
> >
> > [cm] there are redundancy in the draft, needs to be deleted. Example when
> > draft defines LPWAN, then RoLa is simply defined that it is a LPWAN, we
> > don't have to repeat LPWAN definition again.another example is repeating
> > the life of 10 year for each technology, which can be defined once for
> > LPWAN. However, that life time was not an important characteristic for
> the
> > specific technology, so I think we should specify subsections for
> character.
> >
> >
> >
> > [Cm] the draft does not mention the MAC mechanisms used for each LPWAN
> > technologies, which is very important when we want to make IP over LPWAN.
> > It needs to mention ALOHA and CSMA which are used in LPWAN. I think RoLa
> > and SIGFox use ALOHA, and NB-IoT uses TDMA.
> >
> > [cm] as we are in IETF can contact those vendors of these technologies of
> > LPWAN, we can get the information easily confirmed.
> >
> >
> >
> > Suggest> each technology within the characteristic section needs to
> clarify
> >  the uplink (UL) and downlink (DL) data/control messages or channels, and
> > symmetrical or/and asymmetric, for each subsection of the following:
> >
> > -ranges (for rural, urban, they maybe with different ranges)
> >
> > -band (licensed or unlicensed) and with region/country
> >
> > -data rate and duty cycle
> >
> > -channels
> >
> > -end-devices memory/processing needs
> >
> > -link budget target
> >
> > -MAC mechanism used for up and/or down
> >
> > -Modulation/coding
> >
> > -max number of devices served
> >
> > -roaming/handover availability
> >
> > -localization
> >
> > -synchronized of synchronized network
> >
> > -main application other possibility.
> >
> > -operation
>
> I don't agree with that suggestion. The text describing each
> of the technologies is more-or-less what was contributed by
> some folks who are proponents of those technologies, and is
> IMO sufficiently clear to be useful. The WG discussed the
> idea of trying to provide the kind of comparisons you
> suggest above and had consensus to *not* do that, as it
> could lead to a pointless bun-fight between the proponents
> of different technologies. I don't believe there is any
> indication that the WG might change it's mind on that.
>
> not comparison, but just fulfilling the draft objectives. I know the WG
submitted the work and don't like to change.

> >
> >
> >
> >
> > [sg]
> >
> > Old> section 2.1.1>
> >
> > LoRaWAN is an ISM-based wireless technology for long-range low-power
> >
> > low-data-rate applications developed by the LoRa Alliance, a
> >
> > membership consortium. <https://www.lora-alliance.org/> This draft
> >
> > is based on version 1.0.2 [LoRaSpec] of the LoRa specification. That
> >
> > specification is publicly available and has already seen several
> >
> > deployments across the globe.
> >
> >
> >
> > New> section 2.1.1>
> >
> > LoRaWAN is an ISM-based LPWAN developed by the LoRa Alliance, a
> >
> > membership consortium. <https://www.lora-alliance.org/> This draft
> >
> > is based on version 1.0.2 [LoRaSpec] of the LoRa specification. That
> >
> > specification is publicly available and has already seen several
> >
> > deployments across the globe.
>
> I don't see any benefit in that change so unless someone else
> also likes it and can explain why I think we're fine with the
> current text.
>
> >
> >
> >
> > [cm] the RFC7452 is very interesting because it mentions the tricky
> issue I
> > mentioned in my previous email for this overview, also theis RFC refered
> > that some technologies may be rebuild, similar to what I was mentioning
> in
> > my email regarding adaptations by both IP protocols and the
> > under-technologies. I suggest that should be mentioned also in the draft.
> >
> >
> >
> > [Sg] The LPWAN is used/applied within the IoT and M2M environment, so we
> > need to consider the recommendations of RFC7452.
> >
> >
> >
> > [Sg] The gap analysis should include some issues/analysis in RFC7452 (or
> > reference and point to it), because rfc7452 makes important protocol
> design
> > considerations related to LPWAN technologies, also this RFC mentions some
> > IP challenges for such smart environment.
>
> I'll look back over 7452 and see if there are issues there that
> need to be reflected in the gap analysis. But if there are, then
> we'll want specific text about those issues, and not general
> statements such as the two you offer above.
>
> I'll also look over 8240 and see if there are specific points
> from that that need discussing in the gap analysis.
>
> For both cases, if there is text that I think is needed I'll
> first raise that on the WG list. And again, given where we
> are in the process, I'll be aiming to not add new text unless
> it makes a substantive improvement to the overall draft.
>
> IMHO, we in IETF make all kind of changes not only for substantive/overall
improvement. We make all kind of changes to our draft, small changes and
big, for the best of the user's understanding, and the best reading without
misunderstanding.

The draft is difficult to read in my opinion, please check other IETF RFCs
overviews and you may understand my argument. I gave an example of RFC4919
from the beginning of my comments as a reference to best readings as
informational draft.

I thanks you for your time and messages, and I wish the draft all the best
within the process,

take care,
AB