IPv6 over Low Power Wide-Area Networks
charter-ietf-lpwan-03

[Ballot comment]
+1 to Erik's comment that "Seems like another choice is to close LPWAN and charter a new SHCH WG". It makes me slightly sad that if the focus of the group is no longer Low-Power Wide-Area Networks, even though they are one important consumer of the group's output, the group is still called... "Low Power Wide-Area Networks".

But "naming things" is famously one of the two hard problems.

[Ballot comment]
The charter's opening paragraph mentions UDP tunnels but bullet 3 in the new work is missing it, is that intentional?

In the TSV area, we are enabling QUIC tunneling of UDP and IP packets towards proxies. I was wondering if this be related here to consider as SCHC usage is expanding and if TSV area should also be in the collaborator list or not.

[Ballot comment]
# GEN AD review of charter-ietf-lpwan-02-00

CC @larseggert

## Comments

### Section 6, paragraph 2
```
  The LPWAN WG will collaborate with INTAREA WG for the IP protocol type
  definition and with with other WGs for possible Protocols-over-SCHC activities.
  It will work with the relevant Security Area WGs to secure the SCHC session
  appropriately.
```
This statement IMO needs to be a stronger, i.e., that this work will be done in
cooperation with the WGs/SDOs that maintain these other layers, with an emphasis
on nothing will be adopted in LPWAN until there is common agreement.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Paragraph 0
```
- technology to  Low-Power Wide-Area (LPWA) and non-LPWA networks, including Low
-            ^^^
+ technology in Low-Power Wide-Area (LPWA) and non-LPWA networks, including Low
+            ^^
```

#### Paragraph 0
```
- includes but is not limited to UDP tunnels, IP, PPP, and Ethernet.
-        -    ^^
+ include but are not limited to UDP tunnels, IP, PPP, and Ethernet.
+            ^^^
```

#### Paragraph 1
```
- packets. For instance, the INT-AREA WG is working on a SCHC protocol type for
-                              -
```

#### "IP", paragraph 0
```
- provide standard track specifications for a SCHC Header that conveys the SCHC
+ provide standards track specifications for a SCHC Header that conveys the SCHC
+                +
```

### Grammar/style

#### "A", paragraph 0
```
etween the pair of endpoints in a secure fashion. The group will also work on
                            ^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

#### Section 6, paragraph 1
```
e IP protocol type definition and with with other WGs for possible Protocols-
                                  ^^^^^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# Internet AD comments for charter-ietf-lpwan-02-00
CC @ekline

## Comment

### meta

* Seems like another choice is to close LPWAN and charter a new SHCH WG.

### P3, #6

* What does "rule installation" actually mean?  The application of a rule
  by an end node (operation system), or the addition of a new rule in a
  control plane "state machine" negotiation between two (or more) endpoints,
  or ... something else?

[Ballot comment]
The initial focus of the LPWAN Working Group was to enable IPv6 connectivity over the following selection of Low-Power Wide-Area (LPWA) technologies: SIGFOX, LoRa, WI-SUN and NB-IOT. As a result of the first round of chartering, the IETF has contributed to LPWA technologies by allowing IPv6 connectivity with to the SCHC deep compression protocol. SCHC is now becoming an accepted industry standard in that space and is being or was already adopted by major alliances.

The group produced documents providing an overview of the baseline LPWA technologies (RFC8376) as well as a document specifying a Generic Framework for Static Context Header Compression and Fragmentation (SCHC) [RFC8724], SCHC for CoAP [RFC8824], SCHC over LPWA technologies for LoRA, SigFox, and NB-IOT, and the SCHC data model specification. Though the LPWA technologies were used as the baseline technologies for the LPWAN SCHC standard , interest is now rising to employ SCHC in other, non-LPWA environments.

The initial focus of the LPWAN Working Group was to enable IPv6 connectivity over the following selection of Low-Power Wide-Area (LPWA) technologies: SIGFOX, LoRa, WI-SUN and NB-IOT. As a result of the first round of chartering, the IETF has contributed to LPWA technologies by allowing IPv6 connectivity with to the SCHC deep compression protocol. SCHC is now becoming an accepted industry standard in that space and is being or was already adopted by major alliances.

The group produced documents providing an overview of the baseline LPWA technologies (RFC8376) as well as a document specifying a Generic Framework for Static Context Header Compression and Fragmentation (SCHC) [RFC8724], SCHC for CoAP [RFC8824], SCHC over LPWA technologies for LoRA, SigFox, and NB-IOT, and the SCHC data model specification. Though the LPWA technologies were used as the baseline technologies for the LPWAN SCHC standard , interest is now rising to employ SCHC in other, non-LPWA environments.

Added charter milestone "Produce a Standards Track document to enable  operations, administration and maintenance (OAM) to the LPWAN device, including support for delayed or proxied liveness verification (Ping)", due July 2021

Added charter milestone "Produce a Standards Track document to define the generic data models to formalize the compression and fragmentation contexts for LPWANs", due February 2021

[Ballot block]
I think this will be fairly easily to resolve. However, I don't understand what is meant with "baseline technologies" in:

2. Produce Standard Track documents to apply SCHC IPv6/UDP over the baseline
technologies.

Maybe some definition of what is meant with baseline technologies can be added. I could interpret that this would be to apply this to any IPv6 network, which I don't think it is.

[Ballot block]
One question on this point before we move ahead:
"provide a mechanism to improve the reliability of delivering fragmented multicast packets"

Do you mean something like FEC or something like retransmission? If the first I would be better to say that explicitly. If the latter, I think there might be further discussion about cross-relation with other groups needed before we can add something to the charter.

[Ballot comment]
I assume that "baseline technologies" is the list of technologies that the WG will focus on enabling IPv6 connectivity over?

The charter says that traffic tends to be "upstream", but we have a work item for multicast.  Is that multicast usage
expected to be upstream, downstream, or both?

  4. Produce a Standards Track document to define the generic data models to
  formalize the compression and fragmentation contexts.

I assume "the compression and fragmentation contexts" are scoped to something LPWAN-specific and not the generic
senses of compression and fragmentation.

[Ballot comment]
This new charter looks that some interesting work will be done by the WG ;-)

Nothing blocking but I have two comments that can be freely ignored:

- part of the charter (including the previous one) looks quite marketing to me: "To unleash the full power of LPWA technologies and their ecosystems" for example

- should there be a mention of working / liaison with other SDO rather than the vague "other stakeholders" ?

Looking forward to seeing the work produced by this WG!


-éric

[Ballot comment]
I edited out some funny space-like characters that were not actually ASCII spaces, and now the DIFF makes the changes clear, and it's easy to ballot "No Objection".

[Ballot comment]
While I try to review this and before I ballot:

Suresh, can you please reformat this so it's not one huge blob?

Thanks,
Barry

The lpwan WG has successfully completed its initial deliverables. The working group has been interested in a bunch of follow up work that I was gating on the initial items being completed. The charter text remains the same but the work items 1-5 have been added as new work.

The working group has completed its initial deliverables and the new work items (with numbers 1-5 have been discussed for a while in the working group).

[Ballot comment]
No objection to this charter, but I wonder what this sentence means:
    The work will include the
    definition of generic data models to describe the compression and
    fragmentation contexts.
In my world, data models mean YANG. What does it mean in your world? 

Regards, Benoit

[Ballot comment]
I support Alissa's comment. Is the proposed informational document something that will have archival value once the standards track work completes, or just a step towards the standard track work?

[Ballot comment]

Full disclosure: I may be participating in this WG as the
bit of my university currently sponsoring me are building
a LPWA testbed (mainly LoRa initially). I'd have said
yes anyway though:-)

[Ballot comment]
Does the informational document necessarily need to be an RFC? It sounds like this might be a case where the WG could leave its options open as to whether to publish that document or not once it is complete.