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

"Roni Even (A)" <roni.even@huawei.com> Thu, 09 August 2018 10:29 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359D0130E0A for <clue@ietfa.amsl.com>; Thu, 9 Aug 2018 03:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfzv76hBU-9D for <clue@ietfa.amsl.com>; Thu, 9 Aug 2018 03:29:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D13C130E06 for <clue@ietf.org>; Thu, 9 Aug 2018 03:29:29 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 66D19D54E6670 for <clue@ietf.org>; Thu, 9 Aug 2018 11:29:26 +0100 (IST)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 9 Aug 2018 11:29:27 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.158]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0399.000; Thu, 9 Aug 2018 18:29:14 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Simon Pietro Romano <spromano@unina.it>
CC: "clue@ietf.org" <clue@ietf.org>, Adam Roach <adam@nostrum.com>
Thread-Topic: [clue] AD Review: draft-ietf-clue-protocol-13
Thread-Index: AQHULW2bJPs5vaSyWEqV7DTvHAtxIaS3OpWA
Date: Thu, 09 Aug 2018 10:29:14 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8BB398@DGGEMM506-MBX.china.huawei.com>
References: <a30828ea-1db8-fccd-9c2b-ddc0a1dcb08d@nostrum.com> <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> <ac30c041-b269-484f-023a-0e8723133a5c@nostrum.com> <216405E3-5A89-4FF2-9C89-CEDA03BF6A04@unina.it> <3fdd8d7e-fcc6-7bac-0d03-3873973a875d@nostrum.com> <8DAFF0AE-34FC-473E-B9F0-31DA32ED22BF@unina.it>
In-Reply-To: <8DAFF0AE-34FC-473E-B9F0-31DA32ED22BF@unina.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.143]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8BB398DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/BqI7UobaesF1tIzMz-PsngOL5_Q>
Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2018 10:29:32 -0000

Hi Simon,
Are you suggesting a change in the CLUE data model draft the configuredContent?

In this case I was wondering since the configuredContent is of type contentType which also has mediaCaptureIDREF which will not parse in configure message.

Can you please explain?



Roni Even as individual






From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro Romano
Sent: Monday, August 06, 2018 1:09 PM
To: Adam Roach
Cc: clue@ietf.org
Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13

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: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it<mailto:spromano@unina.it>

                            <<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 <adam@nostrum.com<mailto:adam@nostrum.com>> 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