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

From: The IESG <[email-masked]>
Date: Mon, 01 Jan 2018 16:34:07 -0800

The IESG has received a request from the IPv6 over Low Power Wide-Area
Networks WG (lpwan) to consider the following document: - 'LPWAN Overview'
  <draft-ietf-lpwan-overview-07.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-01-16. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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.  This memo is an informational overview of the set of
   LPWAN technologies being considered in the IETF and of the gaps that
   exist between the needs of those technologies and the goal of running
   IP in LPWANs.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 19 Jan 2018 18:59:52 +0200

Thanks for the draft and hard work, and is very intersting. IMHO, the draft
needs more details to better overview, I don't think it is up to date, or
covers most gaps, we still need more references that are related more than
the  draft's references used. The terminology needs to be well defining
terms for the different technologies of lpwan. The draft language needs to
be more sure, as to delete the words as possible/maybe/probable/etc.

I don't think wireless technologies are better to be fixed to a star
topology. Why does the draft make LPWAN tech or the WG only for STAR
topology? please answer me. IMO wireless WAN should not be fixed to STAR
topologies. usually LPWAN has advantage over the wired WAN because it can
use some different topologies not fixed.

The draft needs to clarify the control plane and data plan issues. The
draft mixes them without focus on their implications or technology needs or
use-cases requirements.

The draft should present the reasons for lack of IPv6 use in the available
technologies, but also the advantages of using IPv6 in such network.

The draft needs to be sure is this LPWAN using both IPv4 and/or IPv6, and
IMO it should be only IPv6 , if so then please delete the old references of
protocols related with IPv4 (as first reference is related to IPv4). The
draft MUST reference IPv6 rfc8200 and other related technologies to the
LPWAN in gap analysis sections.

The Goal stated in the draft:
The goal of the IETF LPWAN working group is to, where
   necessary, adapt IETF-defined protocols, addressing schemes and
   naming to this particular constrained environment.

IMO the adaptation needs to be by both parts/directions, the environment
technologies and the IP technologies. The adaptation direction/approach
needs good reasons for best practice. Usually the draft needs to show the
use-cases or the lpwan technologies purposes or services to users. The
draft needs to reference some work in IETF or IRTF related to network
purpose (I am not sure which now but can find..)  as the TCP/IP was
developed for host to host network communication and new networks are
developed with different purposes and needs IPv6 adaptations. This
explanation needs to be solved in gap analysis.

There are some protocols in page 13 or in the figure which is related to ip
but not discussed. IMO what can be missing the each lpwan technology under
IP what does it provide to IPv6/upper-layer and what does the IPv6 provides
to the under lpwan-technology? I think the answers is not clearly covered.

However, this work is a great work as informational, thanks

AB

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Jan 2018 12:57:02 +0000

Hiya,

Thanks for the review.

On 19/01/18 16:47, Abdussalam Baryun wrote:
> A Review for the draft
> 19/01/2018 sorry for sending later than the required date.
> 

If you have specific errors you'd like to highlight or changes
you'd like to suggest, as editor, I'd be happy to look those over,
but for now the above isn't actionable.

> topology? please answer me. 

The task of the WG is not to re-invent or change LPWAN lower layers,
but to figure out how to run IP over those. A star topology is what
is used by some of these technologies as is mentioned in the WG
charter [1] so it is IMO correct that the overview draft describes
that.

   [1] https://tools.ietf.org/wg/lpwan/charters

> IMO wireless WAN should not be fixed to STAR

Sorry, again that's not actionable. If you have specific wording
changes to suggest, or text to criticise I'll be happy to look at
such comments.

> technologies, 

That is there already, see section 4.1, paragraph 1. If that is not
sufficiently obvious I'd be happy to see suggested additional text.

> but also the advantages of using IPv6 in such network.

I don't believe there is text for that in the document, I guess due
to WG participants considering that obvious. There is text like that
in the charter where it says:

 "To unleash the full power of LPWA technologies and their ecosystems,
  there is a need to couple them with other ecosystems that will
  guarantee the inter-working by introducing a network layer, and enable
  common components for management and security, as well as shared
  application profiles. The IETF can contribute by providing IPv6
  connectivity, and propose technologies to secure the operations
  and manage the devices and their gateways."

I'd be fine if a variant of that were included in the introduction,
if that's considered useful. I guess the argument to include it is
that it might make the RFC more long self-contained after the WG has
finished up. OTOH, it is obvious for IETF participants, so maybe
it's redundant. I'll be guided by subsequent mails, the WG chairs
and AD as to whether to add such text.

> LPWAN in gap analysis sections.

I don't believe it'd be a good plan to remove the references
to IPv4 protocols in this draft. If there are specific ones that
you want to argue ought not be present feel free to offer
specific arguments for each.

Good catch on RFC8200, I'd added that as the reference for
IPv6 in section 4.1. (I believe 2460 is likely still needed as
I'm guessing the FAN profile is based on that and not on 8200
but I'm open to correction on that.) That change is made in
the editor's copy at [2], I'll post version -08 including
that when the WG chairs/AD figure it's time for that.

   [2]
https://github.com/sftcd/lpwan-ov/blob/master/draft-ietf-lpwan-overview.txt

> needs good reasons for best practice. 

You may be correct, but any adaptation of lower layers will take
place elsewhere (outside the IETF) and so isn't a proper subject
for this draft.

> Usually the draft needs to show the
> use-cases or the lpwan technologies purposes or services to users. 

I'd argue that more is not really needed here and that the readers
of this draft are sufficiently aware of use-cases for LPWANs. But
as always I'd be happy to consider suggested text.

> The

Sorry, but I don't understand what point you're making above.
If you're asking that we document why we're doing IP/<foo> work
for this <foo> then I don't think that's specifically needed,
as defining how to run IP/<foo> seems like a core IETF thing
that doesn't need justification (once we've chartered a WG for
the specific <foo> thing). I'd be happy to copy text used in
similar documents for previous cases where the IETF defined
IP/<bar>, though I don't think that's needed or would be that
useful.

> to the under lpwan-technology? I think the answers is not clearly covered.

I'm not sure what protocols or services you mean. I'd be happy
to consider specific suggested text though.

> However, this work is a great work as informational, thanks

It is indeed intended to be an informational document. Thanks
again for the review,

Cheers,
S

-- 
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: Abdussalam Baryun <[email-masked]>
Date: Sun, 21 Jan 2018 01:03:03 +0200

Hi Stephen,

How are you doing, it is long time from last time we meet in ietf89, I
thank you for your welcoming. my comments below

On Sat, Jan 20, 2018 at 2:57 PM, Stephen Farrell <[email-masked]>
wrote:

> ok, I will need one day to review with suggests, if you don't mind,

>    [1] https://tools.ietf.org/wg/lpwan/charters
The draft is a work adopted by the WG and IMHO the WG  can make the reason
clear in their draft why STAR topology while we have wireless wan? The
draft is informational,,, but some missing info,

There are reasons why the industry followed such direction, because the
mesh topology overhead while the network is low power and needs less link
budget. It is good to know why because businesses/technologies can be
tricky in future with new ways into switching.

> changes to suggest, or text to criticise I'll be happy to look at

Without suggest text, I think it may be actionable, as a feedback to
author/WG and iesg. Regarding the technologies use-cases, under the RFC2026
section 3.2 the AS is needed, I suggest the draft mentions applicability
statement for the LPWAN applications/use-cases and the usefulness of IPv6
protocols. IMO the applications are mostly for smart cities.

but ok, I will do some suggestions in my next message for you,

AB

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 21 Jan 2018 14:30:33 +0000

Hiya,

On 20/01/18 23:03, Abdussalam Baryun wrote:
> Hi Stephen,
> 
> How are you doing, it is long time from last time we meet in ietf89, 

Yes, time flies.

> I

No problem.

> but ok, I will do some suggestions in my next message for you,

Grand. I'll respond in detail when you send your suggested text.

S.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 23 Jan 2018 01:10:11 +0200

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

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

In Abstract>

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.

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.

Add>  Applicability Statement: (add in one section number)

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.

Add>  LPWAN uses star topology to eliminates many overhead associated with
the use of meshing such as forwarding or routing overheads.

SG> Rfc7452 should be referenced because mentions the Architectural
Considerations in Smart Object Networking which is related in covering the
gap for LPWAN.

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

[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

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

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

Section 5> should reference rfc7452 and 8240, because they make important
security considerations related to this draft.

Add>References>

Raza, U., Kulkarni, P., and Sooriyabandara, M., 'Low Power Wide Area
Networks: An Overview', 2017

H. Tschofenig, J. Arkko, D. Thaler, and D. McPherson, 'Architectural
Considerations in Smart Object Networking', RFC7452, Mar 2015

H. Tschofenig, S. Farrell, 'Report from the Internet of Things Software
Update (IoTSU) Workshop 2016', RFC8240, Sep 2017.

Best Regards

AB

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jan 2018 11:42:24 +0000

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.

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

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

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

> and large number of end devices distributed over large geographical areas

I don't find your suggested text clearer, sorry, so unless
someone agrees with you I think leaving it as-is is better.

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

> the end-devices as transmitters only without receivers, or with very short

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

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

> Considerations in Smart Object Networking which is related in covering the

Being "related" isn't a good enough reason to add a reference.
But see below.

> Replace> As of today, essentially no LPWAN end-devices have IP capabilities.

Sure. Fixed in editor's version.

> -main application other possibility.

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.

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

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

Cheers,
S.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jan 2018 16:40:56 +0000

Dear all:

I'm 100% with Stephen here.

Abdussalam, it is nice that you made this review but you missed that the WGLC was completed long ago and that the document is already submitted. We already collected a number of IESG review and we do not want to void that. Unless we are solving a critical bug, the boat has sailed and we will not change the document anymore.

Cheers,

Pascal

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: mardi 23 janvier 2018 12:42
To: Abdussalam Baryun <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; ietf <[email-masked]>; [email-masked]
Subject: Re: [lp-wan] Last Call: <draft-ietf-lpwan-overview-07.txt> (LPWAN Overview) to Informational RFC

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,
> 
> [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
> 

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.

> 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 

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.

> cm> The draft must state exactly the Low Power characteristic as 
> cm> 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, 
> cm> but

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

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

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

> 
> 
> Add>  LPWAN uses star topology to eliminates many overhead associated 
> Add> with

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.

> Considerations in Smart Object Networking which is related in covering 
> the gap for LPWAN.

> 
> [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.
> 
> 
> 
> 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 
> Suggest> clarify
>  the uplink (UL) and downlink (DL) data/control messages or channels, 
> and symmetrical or/and asymmetric, for each subsection of the following:
> 

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.

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

Cheers,
S.

> 
> Section 5> should reference rfc7452 and 8240, because they make 
> important security considerations related to this draft.
> 
> 
> 
> Add>References>
> 
> 
> 
> H. Tschofenig, S. Farrell, 'Report from the Internet of Things 
> Software Update (IoTSU) Workshop 2016', RFC8240, Sep 2017.
> 
> 
> 
> Best Regards
> 
> AB
> 
> 
>