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

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

Also inline,

On 1 Jun 2016, at 12:41, Roni Even wrote:

> Inline
> Roni
>
>> -----Original Message-----
>> From: Ben Campbell [mailto:[e-mail]]
>> Sent: Wednesday, June 01, 2016 5:23 PM
>> To: The IESG
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Ben Campbell's Discuss on 
>> draft-ietf-clue-data-model-schema-15:
>> (with DISCUSS and COMMENT)
>>
>> Ben Campbell 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:
>> ----------------------------------------------------------------------
>>
>> - 11.2: 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?
>
>
> [Roni Even] ] I think that the meaning was to allow the media types 
> from the IANA registry 
> http://www.iana.org/assignments/media-types/media-types.xhtml . The 
> issue will be about the usage of other media types in the CLUE 
> environment and not about the values themselves.
> Alissa also suggested that we clarify it

I'm not sure I understand your response. When you say "other media 
types", do you mean other types that are registered in the media-type 
registry, but not described in RFC6838? Or other arbitary media types 
that are not registered or otherwise publicly documented?

>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Substantive:
>>
>> -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.)
> [Roni Even] An XML review was done by Henry Thompson 
> https://mailarchive.ietf.org/arch/msg/clue/1WeFBrIo17CLL_t_6anoHAHMwqg

Thanks, I saw that shortly after sending.

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