Re: [clue] AD Review: draft-ietf-clue-protocol-13

[Adam Roach <[e-mail]>]

Thanks for all the work you've done here; things are looking to be in 
good shape. I just went over all the changes from -13 to -16, and they 
look good to me. I believe that my initial review feedback has been 
addressed, and I have only a small handful of nits that you should 
address when you fix the <sceneViewIDREF> problem you describe below. (I 
see no problem with your proposed solution, but I don't claim to fully 
understand the ramifications).

I'm ready to put this document (and the signaling document) into IETF 
last call as soon as the issue you've identified below has been resolved.

My list of nits with the -16 version follows.

---------------------------------------------------------------------------

Please update the reference to RFC 5226 to instead indicate RFC 8126.

---------------------------------------------------------------------------

Please update the reference to RFC 5117 to instead indicate RFC 7667.

---------------------------------------------------------------------------

§10.2: The title of this section should refer to 'options', not 'option'

---------------------------------------------------------------------------

Figure 15:

 > targetNamespace="http://example.extensions.com/myVideoExtensions"
  ...
 >  xmlns="http://example.extensions.com/myVideoExtensions"

The domain "extensions.com" is owned by the company "Hair Extensions 
Solutions,
LLC" and not appropriate for use in an RFC. Please change to, e.g.,
"extensions.example.com".

---------------------------------------------------------------------------

§12.1:

 >   This section registers a new XML namespace,
 >   ""urn:ietf:params:xml:ns:clue-protocol"".
      ^                                    ^

This line still has too many quotation marks.

---------------------------------------------------------------------------

§12.1:

 >  This section registers the ""application/clue+xml"" MIME type.
                               ^                      ^

This line still has too many quotation marks.

---------------------------------------------------------------------------

/a


On 8/6/18 5:09 AM, Simon Pietro Romano wrote:
> Hello Adam!
>
> version -16 of the draft had just been posted. You’ll find there a 
> whole new section (section 10) about the requested call flow. We have 
> added validated excerpts of all of the messages.
> You’ll notice that we put the following note at the end of the 
> introductory part of section 10:
>
> [[NOTE TO IANA/RFC-EDITOR: For sections 10.1 through 10.9, please 
> replace the clue-protocol xsi:schemaLocation URL (which is currently 
> set to 
> http://wpage.unina.it/spromano/clue-protocol-15-schema-file.xsd) with 
> the right (and final) URL for this specification. The URL ib question 
> is a temporary one, which was published on-line in order to allow for 
> proper validation of the XML excerpts contained in the call flow 
> sections.]]
>
> This was needed because we had to refer to the clue protocol schema 
> file in order to validate the messages.
>
> Please read below for a further (minor) issue we encountered…
>
> ****************************************************************************************************************************************
> NOTE TO THE GROUP, DATA MODEL RELATED:
>
> While doing the call flow homework, we realized there’s a minor 
> modification that would be desirable inside the data model schema. 
> Namely, there is a “sceneViewIDREF” field that we defined ad IDREF (In 
> terms of XML datatypes). This seemed OK at that time. Though, we now 
> realized that it prevents correct validation of CONFIGURE messages, An 
> example of the mentioned issue can be found in the (NOT currently 
> valid) “Conf+Ack” excerpt I am attaching g below (where the culprit is 
> in bold):
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <ns2:configure xmlns="urn:ietf:params:xml:ns:clue-info"
>  xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol"
>  xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>  xsi:schemaLocation="urn:ietf:params:xml:ns:clue-protocol 
> http://wpage.unina.it/spromano/clue-protocol-15-schema-file.xsd"
>  protocol="CLUE" v="2.7">
>     <ns2:clueId>CP2</ns2:clueId>
>     <ns2:sequenceNr>22</ns2:sequenceNr>
>     <ns2:advSequenceNr>11</ns2:advSequenceNr>
>     <ns2:ack>200</ns2:ack>
>     <ns2:captureEncodings>
>         <captureEncoding ID="ce123">
>            <captureID>AC0</captureID>
>            <encodingID>ENC4</encodingID>
>         </captureEncoding>
>         <captureEncoding ID="ce223">
>            <captureID>VC3</captureID>
>            <encodingID>ENC1</encodingID>
>            <configuredContent>
> * <sceneViewIDREF>SE1</sceneViewIDREF>*
>            </configuredContent>
>        </captureEncoding>
>     </ns2:captureEncodings>
> </ns2:configure>
>
> In order to sort this issue out, it would be sufficient to modify the 
> above mentioned IDREF type and let it become a simpler xs:string. With 
> this modification, we might seamlessly reuse such a data model 
> structure inside CLUE Configure messages (and not just inside 
> Advertisements when describing MCC captures). Do you all agree on this 
> proposal?
>
> ****************************************************************************************************************************************
>
> Cheers,
>
> Simon
>
>
>
>
>          _\\|//_
> ( O-O )
> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> Simon Pietro Romano
>  Universita' di Napoli Federico II
>    Computer Engineering Department
>            Phone: [phone] -- Fax: [phone]
>                                            e-mail: [e-mail] 
> <mailto:[e-mail]>
>
>   <<Molti mi dicono che lo scoraggiamento è l'alibi degli
>   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                    oooO
>        ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                \ (            (   )
>                                 \_)          ) /
>              (_/
>
>
>
>> Il giorno 18 mag 2018, alle ore 04:54, Adam Roach <[e-mail] 
>> <mailto:[e-mail]>> ha scritto:
>>
>> [re-sending due to an IETF mailing list server outage]
>>
>> On 4/11/18 12:31 PM, Simon Pietro Romano wrote:
>>> Hello Adam!
>>>
>>> We finally managed to get our review done. Please find our answers 
>>> in-line, [SPR]-prefixed, as usual.
>>>
>> ...
>>
>>> [SPR] We have not yet added this consideration to the draft. I 
>>> personally believe this makes sense. Do you think we should add this 
>>> as a general consideration when introducing the overall state machines?
>>
>> That would probably be an improvement, yes.
>>
>> ...
>>
>>> [SPR] We will keep this as an Action Point for us, to be fulfilled 
>>> before submitting the very last version of the draft.
>>
>>
>> Just a heads up that I'm waiting for the document to 
>> incorporate these two open items before progressing it. Thanks!
>>
>> /a
>