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

[Michael Richardson <[e-mail]>]

Alvaro Retana via Datatracker <[e-mail]> 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [



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