Re: [Iotops] IOTOPS Draft Charter

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 12 November 2020 00:54 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474273A1281 for <iotops@ietfa.amsl.com>; Wed, 11 Nov 2020 16:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqe0MVjmLUBo for <iotops@ietfa.amsl.com>; Wed, 11 Nov 2020 16:54:35 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24AD63A1280 for <iotops@ietf.org>; Wed, 11 Nov 2020 16:54:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E1D8389B6; Wed, 11 Nov 2020 19:55:04 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j63PxrQsJqS3; Wed, 11 Nov 2020 19:55:04 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DF7B5389B5; Wed, 11 Nov 2020 19:55:03 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B739F34A; Wed, 11 Nov 2020 19:54:32 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alexey Melnikov <alexey.melnikov@isode.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "iotops@ietf.org" <iotops@ietf.org>
In-Reply-To: <6A9B1079-86EE-478A-9044-D676471CE1D6@isode.com>
References: <MN2PR11MB4366A96960B97A66D3383045B5110@MN2PR11MB4366.namprd11.prod.outlook.com> <31244.1604425849@localhost> <6A9B1079-86EE-478A-9044-D676471CE1D6@isode.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 11 Nov 2020 19:54:32 -0500
Message-ID: <26359.1605142472@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/V-kkzmBQogqC5tzaCcu5NxmBJpI>
Subject: Re: [Iotops] IOTOPS Draft Charter
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 00:54:37 -0000

Alexey Melnikov <alexey.melnikov@isode.com> wrote:
    >> On 3 Nov 2020, at 17:50, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    >>
    >> To me, the point was to deal with the lifecycle issues of IoT.
    >> That's one the list in point (1) was about.

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

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide