[Iotops] Re: WG Last Call: draft-ietf-iotops-7228bis-03 (Ends 2026-01-08)

[Esko Dijk <[e-mail]>]

Thanks Carsten for making the updates.

>> - Abstract: it focuses heavily / exclusively on 'constrained-node networks' and it looks like it forgets to mention we also define terms for the domain of "constrained networks". These are equally important to "constrained-node networks" so worth mentioning in the abstract.
>>    Currently it says: ... of basic terms that have been useful in research and standardization work for constrained-node networks.
> That was actually the scope for 7228 and the intended scope for 7228bis, too.
> Should we expand the scope?
> What would be the effect on the document?

Turns out my editorial comment was an existential one :)

Simply put my initial thought was that we update the abstract to also 
cover "constrained networks" terminology because Section 2.2 has that as 
core terminology, distinct from 2.3.
This would be a better solution than the reverse: deleting Section 2.2 
because it's not in scope of "constrained-node networks".

I see that Section 2.1 at the end nicely explains why "constrained 
networks" terminology is following, and in the given scope. "The use of 
constrained nodes in networks often also leads to constraints on the 
networks themselves."

Can be worded in the abstract like:

The Internet Protocol Suite is increasingly used on small devices with 
severe constraints on power, memory, and processing resources, creating 
constrained-node networks. This document provides a number of basic 
terms that have been useful in research and standardization work for 
constrained-node networks. *It also defines the related concept of 
constrained networks.*

So that hints that the full scope of "constrained networks" and 
terminology for that is not in scope. We define very little terms on it, 
mostly  introducing the basic concept.

For example a constrained network that's then out of that scope is 
unconstrained powerful PCs using a low-bandwidth radio technology to 
form a backup (emergency) mesh network.
In scope is low-cost sensors forming a 6LoWPAN mesh network.

The proposed abstract text IMO better captures what the document 
contains. Without increasing the scope (I think).

> Jargon again.
> There are now a lot of devices in that class, so it felt difficult to single one out.
> Do you have a favorite one?
> Mentioning the newer ESP32 chips would need a discussion of architectures that load code to a Flash cache (vs. execute in place).
> I went for STM32F746/767 for now.

No favorite from my side ...  looks good now.

All other changes look ok to me!

Esko