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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 20 Jan 2021 08:17:58 -0800

Alvaro Retana has entered the following ballot position for
charter-ietf-iotops-00-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-iotops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

(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?

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

[nits]

s/The IOTOPS Working Group is for the discussion/The IOTOPS Working Group is
chartered for the discussion

There's a mismatch between "devices that are:" and the bullets:
"networked...have...are".
s/devices that are/devices that
s/networked/are networked

s/extensions related to existing WGs/extensions to technology related to
existing WGs

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jan 2021 13:16:09 -0500

> 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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