Subject: [Iotops] IOTOPS Draft Charter

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 3 Nov 2020 13:10:23 +0000

Hi,

An updated draft charter for IOTOPS (also inline) has been posted to https://datatracker.ietf.org/doc/charter-ietf-iotops/

This charter has received a couple of rounds of informal review from other IESG members.  Warren and I believe that it is close to the state where we could ask the IESG to ballot on the draft version before it goes out for public review.

Hence, I think that this would be an appropriate time for discussion of the proposed charter on the @iotops alias.

---

The IOTOPS Working Group is for the discussion of operational issues
related to Internet of Things (IoT) devices, in particular related to device
onboarding and lifecycle management.

IoT has a rather nebulous definition with different meanings for different
people.

For the purposes of this WG, its focus is on devices that are:
  - networked - either to the Internet or isolated domain(s),
  - have a very limited end user interface or no end-user interface at all,
  - are deployed in sufficiently large numbers that they cannot easily be
  managed or maintained manually.

The IETF is or has worked on a number of technologies related to IoT. These
include work done in ANIMA, CBOR, CORE, DRIP, LAKE, LPWAN, LWIG, ROLL, SUIT,
and 6TISCH.  IOTOPS is intended to be a discussion venue where people can
discuss how the various technologies developed in these WGs fit together, what
gaps remain, what has been learnt from deploying these, etc.

IOTOPS will solicit input on IoT-device-related operational issues and
practices, and existing and proposed technologies related to the deployment,
operational management, and lifecycle management of IoT devices.  IOTOPS
provides a venue for IoT experts and other interested parties to engage in
discussions of IoT requirements of networking standards, as well as proposals
for new uses of IP technology in IoT specific scenarios.

Revision, updates, and extensions related to existing WGs will be done in those
WGs.  Where new protocols may be needed, IOTOPS will help identify candidate
venues within IETF for their development. In this context, IOTOPS will operate
with a "dispatch" model as described in RFC 7957.

IOTOPS WG charter is restricted to:

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

2) Discussing issues related to IoT operational security.

3) Publish operational practice and document requirements.

---

Regards,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2020 12:50:49 -0500

Hi,

The only actual work that I see the WG having is:
   3) Publish operational practice and document requirements.

Given that the IESG has been clear that it isn't particularly interested in
requirements documents with protocols,  this means that only "operational
practice" documents (BCPs) will wind up here.

The "discuss" points (1) and (2) are things that the more open
IOT-DIRectorate can already do.

I don't really see the point of doing this.

To me, the point was to deal with the lifecycle issues of IoT.
That's one the list in point (1) was about.

There are some serious gaps in the process, and if we can't address those
gaps without a lot of back and forth, then I don't see how it contributes to much.

While I think we need a MOPS-like group (as I understand MOPS, which I
don't really), we also need a place to actually get the work done.

I understand that there has been negotiation within the IESG, but I have no
idea what the objections were, since they haven't been public.

I don't believe that the IESG has much IoT, let alone IoT-security expertise,
so I am skeptical about the objections.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2020 08:48:07 +1300

On 04-Nov-20 02:53, Qin Wu wrote:

> [Qin]: Why limit to talking input and discussing issues, I think IoTOPS could be a better place if there is no good home for some IoT on boarding work, I am not suggest to put all work in this WG,
> But at least some network based solution should be documented here.

What struck me is that the draft charter does not talk about active
coordination between diverse WGs or about the overall architecture
that we should be working towards. By simply listing 10 WGs, the
charter itself tells us that there is an enormous coordination
issue here and a desparate need for a coherent architecture.
Perhaps the coordination is the job of the IOT-DIR and the ADs
involved, but whose job is the architecture? Who writes the
description of how everything fits together?

    Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 8 Nov 2020 10:17:41 +0000

Hi Michael,

> On 3 Nov 2020, at 17:50, Michael Richardson <[email-masked]> wrote:
> 

If the proposed WG to work on lifecycle issues: do you think these would be extensions to protocols done elsewhere in IETF, new protocols or something else?

Thank you,
Alexey

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 19:54:32 -0500

> If the proposed WG to work on lifecycle issues: do you think these
    > would be extensions to protocols done elsewhere in IETF, new protocols
    > or something else?

Well, all three.

I think that the WG should first look for available existing protocols.
Said protocols might need profiles and/or new code points to deal with the
specific situation.  Such a document could occur in an active WG, if one
exists, but it could be that the WG is no longer alive.

I feel it very unlikely that there would be new protocols from scratch.
But, say, some variation of webdav to do configuration management/updates?
Or a YANG module?  Or an extension to the CAPPORT API? (assuming that WG concludes)
A document giving a series of EAT (RATS) claims?

Under "something else", I would include adopting work that has occured in
some industry-specific vertical, under the whole "Informational 1.0",
and "IETF Change-Controlled 2.0" pattern.

Plus, of course, the handful of MUD extensions, and another handful of IoT
focused BRSKI extensions.

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 12 Nov 2020 01:34:37 +0000

+1

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: Iotops [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: Thursday, November 12, 2020 8:55 AM
> To: Alexey Melnikov <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>; [email-masked]
> Subject: Re: [Iotops] IOTOPS Draft Charter
> 
> 
> Or a YANG module?  Or an extension to the CAPPORT API? (assuming that
> WG concludes) A document giving a series of EAT (RATS) claims?
> 
> some industry-specific vertical, under the whole "Informational 1.0", and
> "IETF Change-Controlled 2.0" pattern.
>