[clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-clue-data-model-schema-15: Discuss

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


There may be no change needed here, but I want to check.
This draft defines no security mechanisms and doens't say
how to interoperably use any security mechanisms. For
example, I don't understand how one might (interoperably)
do RBAC or other "advanced" security mechanisms that are
promised in other CLUE documents. [1] Even worse, I don't
get how one could e.g. use XMLENC to encrypt parts of the
schema here, as that'd (I think) almost certainty have to
have been considered in the design of this schema, but
there's no evidence of that. That seems to end up meaning
that the only security mechanisms that one can use with
CLUE and for which one can currently achieve interop are
transport security mechanisms. That all seems to conflict
with text in the security consideration of the CLUE
protocol draft. So my question to discuss is: other than
transport security, what interoperable security
mechanisms are expected to be defined in CLUE, and where
might I find descriptions of those?


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


- section 25 says: "Indeed, authenticated access is
strongly advisable, especially if you convey information
about individuals (<personalInfo>)..." I don't get the
logic there - it seems incorrect actually. Personal data
usually implies  a need for confidentiality and not
authenticated access - what was meant here? Are you using
the term authenticated access to mean more that it does?
(to this reader:-)