Subject: [Model-t] Document reviews: draft-mcfadden-{smart-endpoint-taxonomy-for-cless, smart-threat-changes}

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Aug 2020 23:45:54 +0300

Again, some observations:

Smart-endpoint-taxonomy-for-cless:
============================

This draft provides a classification of various endpoint types, in an effort to be useful for analysis and discussion. The endpoint cover physical devices and logical concepts such as application endpoints.

In general the categories seemed sensible. Thanks for writing about this!

I feel that this is also useful for our discussions, although I wouldn’t think this level of detail would show up in something like a 3552 text change.

I wasn’t sure why there was a particular distinction between human-sensing and other-sensing devices. Besides, when you wrote about “non-human sensor devices”, I kept thinking that the other class involves humans as sensors...

Anyway, your classification inspired me to think about the various trust/power/control relationships between the parties. I may trust my app, but not entirely the OS that comes pre-packaged from someone. Or I may trust my machine and OS, but not entirely the app that runs inside it, etc. And how I might not have. Any control of a server somewhere else, even if something that I trust (e.g., my browser) communicates with it. Hence the various rights that one gives to different applications, and having the granting of those rights be explicit to the user. Yet, some of those rights grants are less explicit, e.g., we typically have to give pretty blank checks to various websites to use our information, if we to use them at all.

Smart-threat-changes:
=================

This draft sets the stage first, by explaining the model that is currently assumed by RFC 3552.

It then goes on to explain what’s been changing (section 3). Some of the issues brought up include move to mostly multiparty communication, data at rest issues, etc.

I didn’t fully understand what type of middle box you referred to in Section 3.3. One that is an application entity (e.g., conference bridge) or one that is a network level function (like an ISP or corporate firewall)?

Section 4 provides a motivation why current models are inadequate. I thought that was well written.

Section 3 would probably need some further work.