[clue] Ben Campbell's No Objection on draft-ietf-clue-data-model-schema-15: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-clue-data-model-schema-15: No Objection

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/



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

Substantive:

I cleared my discuss on 11.2. My original point was as follows:  "I would
like to discuss whether it's a good idea to allow arbitrary values for
mediaType, beyond those types registered in IANA. The text seem to
encourage proprietary values. Did the working group consider requiring
IANA registration of some sort for new values?"

I cleared because discussion showed that the working group thought about
this, and made a conscious choice. I think it might still be helpful to
add a sentence or two about the motivation for this particular balance
between customization and interoperation. For example, do people expect
new media-type values to be rare? Are there any concerns about
value-collisions?

-11.10 - I have a similar question for <policy> as for mediaType. I
didn't put it in the discuss because I think <policy> will have an
overall smaller impact on interoperability. But I's still like to see
discussion about why arbitrary values do not create an interop problem. 


- 15, 2nd and 3rd paragraph: Would it be reasonable to promote the SHOULD
to a MUST when privacy sensitive or individually identifiable information
is carried?


Editorial and Nits:

- The shepherd mentions a hope for an xml review during IESG processing.
has that occurred? (If so, an update to the shepherd write up would be
helpful.)

-1, third paragraph, first sentence - I don't understand what the
sentence means.

-3, "CLUE Participant" - It seems a bit odd to repeat all the framework
definitions here, but not repeat the one definition from the protocol
doc.

- 4, last sentence : "As a general remark, please notice that optional
elements that don’t define what their absence means are intended to be
associated with undefined properties."

I'm not sure what that means. Can you elaborate?

-11, first paragraph : "The features that are common to all media types
   appear within the media capture type, that has been designed as an
   abstract complex type."
   
s/that/which

-11.6: "...no <spatialInformation> MUST be provided."

Consider promoting the negation into the 2119 keyword. E.g., "...
<spatialInformation> MUST NOT be provided."

- 11.7: "A multiple content capture is made
   by different captures"
   
Should "made by" be "made up of"?

-- "MAY show in its XML data model
   representation the <content> element."
   
Hard to parse. Consider " ... MAY show the <content> element in its XML
data model representation."

-- "It is composed by a list of
   media capture identifiers"
   
What is the antecedent of "It"?

- 11.6: s/highly-dinamic/highly-dynamic

- 13: "It has been conceived only for data model testing purposes..."
What is the antecedent for "It"?

- 15, 2nd paragraph: "Data model information carried within CLUE messages
SHOULD be
   accessed only by authenticated endpoints."

should "accessed" be "accessible"? (As it stands, it seems to depend on
good behavior of endpoints, which I assume is not the intent.)

-- "There might be more exceptions...
More than what?

- Normative References:
It seems a bit odd to see these second (although I don't know if there is
an actual "rule" about that.) Also, the shepherd write up said that there
were only informative references. I assume these were added after the
fact. It would be very helpful if shepherds would update the write ups
when things are overtaken by events.