Re: [clue] WGLC for draft-ietf-clue-protocol-10

Christian Groves <Christian.Groves@nteczone.com> Fri, 06 January 2017 12:59 UTC

Return-Path: <Christian.Groves@nteczone.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 C1284128AC9 for <clue@ietfa.amsl.com>; Fri, 6 Jan 2017 04:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com
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 xM2AORVbV6h7 for <clue@ietfa.amsl.com>; Fri, 6 Jan 2017 04:59:05 -0800 (PST)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 02088129B03 for <clue@ietf.org>; Fri, 6 Jan 2017 04:59:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FoN9xXV3z8+d0OKB05Xo8GLkkgW6zhbiHMPZxbxs3fQ=; b=CK4tvGJwdPuur7gZJ8sW4j9lA9 CE5N2v3Kwqs54CLamK+CClLa7JU0tJZwdc/Geu9qedrKQXdF5Rb2PtrFPH+MicVdjZZNCgGajMB+V WTbeTDc7/b9IOMNT6IIfkxx1in3uBfNs+ZyPl2pxdeWAAlRHW5y6ZjzGhKi71X1ETLZXi+oxZBiL5 eqC0qqs0i1rcWxtfhGAenaKhBDdRJdiZGyMUZNcO+ZJWHSbDtALqAEiZjRbNoJ8g69mASD9i+jN5P PdrYoFmHDbIKwc2hLoBLPlL7+s+rS3BJ4kn1A/O1Qwy23/H0WQ/Fa6+djz8WD9gO0i1DNDVWQsNcA D3nS6dcg==;
Received: from [116.6.65.160] (port=56478 helo=[172.31.1.51]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <Christian.Groves@nteczone.com>) id 1cPU6Z-003twW-5C; Fri, 06 Jan 2017 23:58:47 +1100
To: Simon Pietro Romano <spromano@unina.it>
References: <ac44e23d-061b-5d1b-b6e5-24e8f5ef0ffc@alum.mit.edu> <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <e220de50-db77-e021-c824-1d246f2eb2dd@nteczone.com>
Date: Fri, 06 Jan 2017 23:58:06 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/0hfphok81ypDBlR3Whm0ZvERHT0>
Cc: clue@ietf.org
Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 06 Jan 2017 12:59:07 -0000

Hello Simon,

Sorry about the slow response. I've been travelling. Please see my 
responses below.

Regards, Christian


..snip
>> General: The document talks about extensions and options. Are they different? if not should we use one term.
> The difference is indeed a subtle one. The idea should be that an option is a predefined capability of the protocol that is not mandatory, whereas an extension is a brand new feature one might be interested in defining for their own purpose. Technically speaking, they look exactly the same, as section 8 clearly illustrates.
[CNG]I think we need to separate whether something is an optional 
capability or not from extending the protocol/data model. Extensions I 
see are additions to the protocol.

..snip
>
>> Cl.5.2: Is there a reason why we indicated that both the response code AND string are mandatory? It seems like an unnecessary duplication. Its not clear that text other than what has be defined may be sent.
> OK. We made the "reasonString” element become optional in version-11 of the schema (minOccurs=“0”).
[CNG] OK

..snip
> Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising how each message section describes this.
> We replaced “picture” with “schema excerpt”. Does this look ok?
[CNG] OK

..snip
> Cl.5.6/General: Do we need some text indicating that there's no partial execution of commands. E.g. If a MP is able to understand all the selected capture encodings bar one. The whole command fails and nothing is instantiated.
> We added the following sentence at the end of the section:
>
> "We remark that there is no partial execution of commands. As an example, if a MP is able to understand all the selected capture encodings except one, then the whole command fails and nothing is instantiated."
[CNG] That's OK except that i'd remove "We remark that..." and just keep 
it at "There is no....".
>
>> Cl.5.7: It says future protocol version can introduce error codes? How about options? It seems like an option could introduce a specific error code.
> Based on the discussion in section 8, a new response code might indeed be added through the “extension” mechanism. Though, the “cleanest” way for achieving such a task in a formal way is by adding
> the new response code to the list of codes published in the dedicated IANA registry (see section 12.4.2 fo the draft). In the mentioned section, we refer to future versions of the standard.
[CNG] By saying that error codes can be designed in future versions 
seems to preclude them being defined by extensions. (BTW 5.7 uses 
"designed", I think "defined" would be better).

I agree one could simply update the IANA registry with the new code but 
I was thinking more of how an end point would know that it would be 
used. That's where registering an extension would make sense. Of course 
if you made a new version you wouldn't need an extension.

..snip
> Cl.6 para 5: "Otherwise <if> ("channel error")…"
> Should we add an "if" between “Otherwise” and the parenthesis? Please advise on that.
[CNG] If doesn't need to be in parentheses just "Otherwise if ..."

..snip
> Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport.
> Namely, we state that the CLUE (application layer) protocol relies on timeouts and retransmissions. Our interpretation is that we do need timeouts and retransmissions for application-layer errors.
[CNG] OK.
> Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message.
> The idea here is that the MC avoids entering a loop where the MP keeps on sending an erroneous ADV hence forcing the MC to respond with a NACK. If this situation iterates for a while (# of retries), the MC terminates the ongoing CLUE “session”.
[CNG] OK that makes sense.

..snip
> Cl.8 I think it would be very helpful to include an example syntax showing the definition of a new capture attribute that could be used by future people as a template. Its still not clear if there's any distinction between "option" and "extension”.
> See our answer above regarding extensions vs options. If we all agree that they are practically the same thing, we can properly re-word things in the document.
>
> About the example, a new capture attribute could be defined in a separate schema to further describe, e.g., a video capture.
> Indeed, looking at the data model XML definition of a video capture, it is possible to see that there is an <any> element allowing for the introduction of a new XML field in the XML description of the capture, by keeping the compatibility with the CLUE data model schema:
>
> <!-- VIDEO CAPTURE TYPE -->
>     <xs:complexType name="videoCaptureType">
>      <xs:complexContent>
>       <xs:extension base="tns:mediaCaptureType">
>        <xs:sequence>
>         <xs:any namespace="##other" processContents="lax" minOccurs="0"
>         maxOccurs="unbounded"/>
>        </xs:sequence>
>        <xs:anyAttribute namespace="##other" processContents="lax"/>
>       </xs:extension>
>      </xs:complexContent>
>     </xs:complexType>
>
>
> That means that a video capture might have, after the set of the generic media capture attributes, a set of new attributes defined elsewhere, i.e., in an XML schema defining an extension.
> Such a schema might look like the following:
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <xs:schema
> version="1.0"
> targetNamespace="clue-info-extension-myVideoExtensions"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="clue-info-extension-myVideoExtensions"
> elementFormDefault="qualified"
> attributeFormDefault="unqualified">
>
> <!-- this is the new element to be put in place of the <any>
> element in the video capture definition
> of the CLUE data model schema -->
>
> <xs:element name="myVideoExtension">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="newVideoAttribute1"/>
> <xs:element ref="newVideoAttribute2"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> <xs:element name="newVideoAttribute1" type = "xs:string">
> </xs:element>
>
> <xs:element name = "newVideoAttribute2" type = "xs:boolean">
> </xs:element>
>
> </xs:schema>
>
> The video capture could be further described in the advertisement  using the <myVideoExtension> element containing two extra information (<newVideoAttribute1> and <newVideoAttribute2>) besides using the attributes envisioned for a generic media capture.
> As stated in this document, both the CP must be aware of the extension schema and related semantics to use such an extension and negotiate it via the OPTIONS and OPTIONS RESPONSE mechanism.
[CNG] I think its valuable to have such an example on extending the 
clue-info and clue-protocol schemas.

..snip
> Thanks 1k for your precious review!
[CNG] No problem.
>
>