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

[[e-mail]]

Sent from my iPhone

> On Jun 1, 2016, at 3:32 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 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:-)

I had the same trouble and agree with  your discuss point.

Thanks,
Kathleen 

> 
>