While the work done on updating this proposed charter has helped, I still don't think this charter is ready.   Charter language should be concise and precise.

I support Gunter's comments and suggestions.

In addition: 
para 2 and sentence 2:  What is the point of this sentence?  It doesn't appear to drive any work in this wg.  Either explain the working group action or remove it.

# Internet AD comments for charter-ietf-iotops-01-03
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Nits

* "IOTOPS provides IoT [...] and other interested parties to engage in
   discussions"

  ->

  "IOTOPS provides IoT [...] and other interested parties a [forum|venue]
   to engage in discussions"

I found that one section can use some clarifications:

"
The IETF defines a number of standards related to IoT. This includes, but is not limited to, work done in ACE,
ANIMA, CBOR, CORE, DRIP, LAKE, ROLL, SCHC, SUIT, TEEP, 6LO, and other working groups. IOTOPS
is intended to be a venue to discuss how various IoT-related technologies fit together. Specifically, IOTOPS
provides a venue for IoT experts and other interested parties to
engage in discussions of operational IoT requirements, as well as approaches for new uses
of IP technology related to IoT devices and network operations.
"

GV> What about the following alternate text blob:

The IETF has developed a range of standards relevant to the Internet of Things (IoT), including, but not limited to, work produced by the ACE, ANIMA, CBOR, CORE, DRIP, LAKE, ROLL, SCHC, SUIT, TEEP, and 6LO working groups, among others.

The IOTOPS working group serves as a forum to discuss how these various IoT-related technologies interoperate and align. It provides a venue for IoT practitioners, operators, and other interested parties to engage in discussions around the operational requirements of IoT deployments. The group also explores emerging use cases and deployment models that may benefit from IP-based technologies in the context of IoT devices and networks.

GV> The current charter states:

"Likewise, the IOTOPS working group welcomes presentations from operators sharing issues and experience, and other work within scope for the working group."

To avoid ambiguity in the term “operators,” which may be commonly interpreted as referring only to network service providers or data center operators, it may be clearer to revise this to:

"Likewise, the IOTOPS working group welcomes presentations from IoT operators, including service providers, enterprises, and other organizations deploying or managing large-scale IoT systems, who wish to share operational experience, challenges, and lessons learned, as well as other work within scope for the working group."

This textblob may better reflect the broad range of stakeholders relevant to the group, including large enterprises and other non-traditional network operators involved in IoT deployments.

GV> Next, the text reads slightly unnatural:

"
Where other new work may be needed, IOTOPS will help identify candidate venues within the IETF for their development.

IOTOPS is chartered with the following scope:

Standard track/BCP specifications that cover:

Manufacturer Usage Description (MUD) solutions
Configuration backup and recovery solutions
Software/firmware upgrade solutions, focusing on discovery and distribution
Informational/BCP documents are restricted to:

Documenting requirements and terminology.
Taking input and discussing issues related to the operational management of IoT devices. This includes (but is not limited to):

Factory provisioning of devices
Onboarding of devices
Access control of devices to network resources
Administrative control of devices
Software/firmware upgrades
Isolation/quarantine of devices
Remediation of broken devices
End of life management of devices
Taking input and discussing issues related to IoT operational security.

Publishing operational practices and guidance. 
"

What about the following alternative for your consideration:

"
Where new work is identified, the IOTOPS working group may assist in evaluating and directing such efforts to appropriate existing IETF working groups or other venues, as appropriate.

Scope of Work

The IOTOPS working group is chartered to produce the following:

Standards Track and BCP Documents:

* Specifications related to Manufacturer Usage Description (MUD) solutions.
* Solutions for configuration backup and recovery.
* Mechanisms for software and firmware upgrades, with a particular focus on discovery and distribution aspects.

Informational and BCP Documents (Non-Standards Track): These documents are restricted to:

* Documenting operational requirements and relevant terminology for IoT deployments.
* Addressing operational challenges associated with the management of IoT devices, including but not limited to:
 ** Factory provisioning of devices
 ** Onboarding processes
 ** Access control to network resources
 ** Administrative control and lifecycle management
 ** Software and firmware upgrade procedures
 ** Device isolation and quarantine
 ** Remediation of misbehaving or compromised devices
 ** End-of-life procedures for devices
* Discussing and documenting operational security issues specific to IoT environments.
* Publishing best practices and operational guidance to assist the broader community in deploying and managing IoT systems securely and effectively.
"

"IOTOPS", paragraph 6
> ## Scope of Work
> 
> IOTOPS is chartered with the following scope:
> 
> * Standards Track and BCP Documents:
> 
>      - Manufacturer Usage Description (MUD) solutions
>      - Configuration backup and recovery solutions
>      - Software/firmware upgrade solutions, focusing on discovery and
>      distribution
> 
> * Informational and BCP Documents:
> 
>     - Documenting requirements and terminology.
>     - Taking input and discussing issues related to the operational management
>     of IoT devices. This includes (but is not limited to):
> 
>         + Factory provisioning of devices
>         + Onboarding of devices
>         + Access control of devices to network resources
>         + Administrative control of devices
>         + Software/firmware upgrades
>         + Isolation/quarantine of devices
>         + Remediation of broken devices
>         + End of life management of devices
> 
>     - Taking input and discussing issues related to IoT operational security.
>     - Publishing operational practices and guidance.


I offered similar comments in an earlier review, but now realize that I was probably not very clear. The issue seems to be with trying to understand how this work is being broken down. I believe Gunter offered a suggestion but I do not think it was incorporated. There is "Standards Track and BCP Documents" and then there is "Informational and BCP Documents". But we publish three types of documents - Standards Track, BCP, and Informational. As such, I would have expected three sections, one for each type of work/document. That does not seem to be the case. 

Rather than trying to be prescriptive about what kind of work each line item would be, could it be reworded to say:

"IOTOPS is chartered with the following work items:"

And then just list all the items that are currently there. That way, if you decide tomorrow that the work item, e.g., Access control of devices to network resources needs to be a Standards Track document, you do not have to recharter.

** Per the standards track documents for “Software/firmware upgrade solutions, focusing on discovery and distribution”, will that build-on or be compatible with SUIT protocols?

As discussed at the telechat ...

** In the “Informational and BCP Documents” list of document, there is:

“Taking input and discussing issues related to the operational management of IoT devices. This includes (but is not limited to):
•	Factory provisioning of devices”

Consider if you really need the "taking input ... IoT devices" clause, instead of just listing the topics.  By definition if the topics can have documents written about them, then they are in scope.

(roughly) New
Operational management of IoT devices:
...

** Similarly, Per "Taking input and discussing issues related to IoT operational security”, 

(roughly) New
Guidance on IoT Operational Security