On 2018-09-13 03:50, Tom Herbert wrote:
> On Wed, Sep 12, 2018 at 5:39 PM, Amelia Andersdotter
> <[email protected]> wrote:
>> Dear all,
>>
>> Thanks Brian for going through all this work, and Tom and Alexandre for
>> providing interesting feedback.
>>
>> In section 3, it may be more interesting to divide Examples of Limited
>> Domain Requirements into networks containing human end-users and
>> networks that don't contain human end-users (such as industrial systems,
>> sensor networks, IoT, etc, merging the home network and small office
>> network use-cases). It would make the taxonomy a more useful tool for
>> assessing the limited domain requirements, and is better adjusted to how
>> demands for (or requirements/expectations on) these limited domains
>> arise in the real world. That could serve as a basis for elaboration of
>> section 7.
>>
> Hi Amelia,
>
> I'm curious why you think discriminating networks containing end-users
> and those that don't would be helpful here. Until the rise of the
> machines happens, isn't it true that all communication networks exist
> to serve humans in some fashion? For instance, if someone deploys
> radiation sensors in a nuclear power planet and connects them as IoT
> to their network, doesn't that make the workers in the power plant
> effectively end-users of those devices? Or to put a darker spin on it,
> if such devices are breached then couldn't bring harm to people just
> as easily as if a normal "end-user device" is compromised?

I had hoped the following comment would clarify:

"[Standardize mechanisms for identifying and defining boundaries] makes sense, 
and could perhaps even help constructively with some issues (such as 
privacy/security issues discussed in SUIT) that arise when specific limitations 
on node privacy or security as described RFC6973 or RFC8280 aren't relevant[.]"

If these limited domains are already practically (albeit implicitly) assumed -- 
and I think the draft makes a good case that they are -- then the idea of 
having a mechanism for classifying them seems to me helpful in assessing uses 
and effects of features in those domain-limited protocols. 

best regards,

Amelia

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55


_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to