Re: [Iotops] Alvaro Retana's No Objection on charter-ietf-iotops-00-09: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 20 January 2021 18:16 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 4D8D13A11AD; Wed, 20 Jan 2021 10:16:18 -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 k14cZeGMwyv4; Wed, 20 Jan 2021 10:16:15 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDEB3A11AF; Wed, 20 Jan 2021 10:16:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4105938B94; Wed, 20 Jan 2021 13:18:09 -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 AthjZwkRkCAI; Wed, 20 Jan 2021 13:18:08 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AFBE538B93; Wed, 20 Jan 2021 13:18:08 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30D08D2C; Wed, 20 Jan 2021 13:16:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alvaro Retana <aretana.ietf@gmail.com>
cc: "The IESG" <iesg@ietf.org>, iotops-chairs@ietf.org, iotops@ietf.org
In-Reply-To: <161115947751.21755.6306155717554025962@ietfa.amsl.com>
References: <161115947751.21755.6306155717554025962@ietfa.amsl.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, 20 Jan 2021 13:16:09 -0500
Message-ID: <9288.1611166569@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/1kSmyZ8zahvizYXO8Xyz8uFLr58>
Subject: Re: [Iotops] Alvaro Retana's No Objection on charter-ietf-iotops-00-09: (with COMMENT)
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: Wed, 20 Jan 2021 18:16:18 -0000

Alvaro Retana via Datatracker <noreply@ietf.org> wrote:
    > (1) "within (e.g., RFC 8799) limited domains"

    > While I like rfc8799 a lot, it is not an IETF consensus document.
    > Making reference to it in a charter, even as an example, seems
    > problematic to me.  Taking the reference out should still be clear
    > enough.

As it's just an "e.g.", is it really a problem?
If we write "limited domains" without any reference, I think someone else
will be upset?

    > (2) 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.

    > What about revisions, updates, or extensions to technology related to
    > closed WG -- or where new protocols are not needed?  I assume the
    > answer is the same (IOTOPS will help identify...); it would be nice for
    > it to be explicit.

    > (4) "Publish operational practice and document requirements."  It is
    > not clear to me whether the expectation is to publish (in an RFC) the
    > requirements or just document them (in a draft) so they can be passed
    > on to where solutions will be worked on.

to be parsed, I think, as:
   (Publish operational practice) and (document requirements).

so there is no charter *mandate* to publish requirements.

I think though, that the answer to both is that it's up to the discretion of
the WG chairs, in consultation with the responsible AD as to what to do with
closed WGs.  I feel certain that once a clear requirement for a protocol
document is established, that the IESG will hear about the problem.

The IESG is mostly not into requirements-only documents, but sometimes that
makes sense.   No single answer will apply to all situations.

    > (3) "Discussing issues related to IoT operational security."  It seems
    > to me that "operational security" could be added as another bullet in
    > item 1 without any loss in meaning.  Is there a specific reason for it
    > to be called out separately that is not obvious from the text?

IoT operational security is part of the lifecycle of the device.
Point (1) is about lifecycle issues, although that word seems to gotten lost
from that part of the text.
IoT Operational Security is often about the environment in which the device
lives, not about the device itself.
(For instance, DNS vs DNSSEC in a local recursive resolver, is not a
lifecycle issue with the device itself)

But, your point is well taken in the greater scheme of things.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



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