Re: [clue] WGLC for draft-ietf-clue-protocol-10
Christian Groves <Christian.Groves@nteczone.com> Mon, 07 November 2016 18:03 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 A5F351294E7 for <clue@ietfa.amsl.com>; Mon, 7 Nov 2016 10:03:10 -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 DBqB0W6YUqU4 for <clue@ietfa.amsl.com>; Mon, 7 Nov 2016 10:03:08 -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 E8B4112945E for <clue@ietf.org>; Mon, 7 Nov 2016 10:03:07 -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:References:To:Subject:Sender: Reply-To:Cc: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=vX/5JlBA4SdODnzN/Jd5exOA7XawbqAXmBnNAz6JiE0=; b=EK/w4eeEqtcBWrTLm9m7YOtOGV VExopl+SsWWwfvBxW85J4T/XJuqVLCrx4Zhy/7HG1xdJmR09+NF8PIWsPhkgStpyl1EQzokWa5qEH lriaApRWOA6K4jkKWMHdTLWFUi1Bk6VqfeziNHHV03LaYxc0qHCYiyhQZUQuA2n5FlfI5wHiNkHo3 hvW+cFo/BbbkzbtI9KxP1TsxnNWAKTW4AZ3zO5+9HVqI4c5dmcpHJkxeiiyM0y8k1NfhQH09VZiwt t0lTDYmcY2DP5/tm3ER9fo/lanwt9gDlL4Z++xGdm3fGPz+8l/cXU9QX6P45aPVFe4g3AEEKhHg+a v7UQh1cg==;
Received: from ip-90-186-178-159.web.vodafone.de ([90.186.178.159]:49845 helo=[192.168.8.101]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <Christian.Groves@nteczone.com>) id 1c3oG9-004MQd-28 for clue@ietf.org; Tue, 08 Nov 2016 05:03:06 +1100
To: clue@ietf.org
References: <ac44e23d-061b-5d1b-b6e5-24e8f5ef0ffc@alum.mit.edu> <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <d3cff715-2b67-aa32-1dd7-ac2cc00dd16a@alum.mit.edu>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <d98a1888-30fa-da57-9636-31bdfb6b394b@nteczone.com>
Date: Tue, 08 Nov 2016 05:02:38 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <d3cff715-2b67-aa32-1dd7-ac2cc00dd16a@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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/JX-hF408JaJH0G504BzUgtsbKGs>
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: Mon, 07 Nov 2016 18:03:11 -0000
Hello Paul, Pretty sure I reviewed v10. What makes you think its v9? Regards, Christian On 8/11/2016 4:13 AM, Paul Kyzivat wrote: > Christian, > > Thanks for the detailed comments. This doc really needs that level of > scrutiny by a variety of people. I'll leave it to Simon to respond in > detail. But some of your comments suggest to me that you were > reviewing -09 rather than -10. Please double check and update your > comments if needed. > > Thanks, > Paul > > On 11/7/16 6:53 AM, Christian Groves wrote: >> Hello Paul, >> >> Here are my comments: >> >> Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't >> some future thing. >> >> Cl.1 para 2: Change "upon" to "over". There's other instances in the >> draft also. >> >> Cl.1 para 3: The section says "Participant state machines" whereas the >> referred to section 6 is called "Protocol state machines". >> >> Cl.2 Endpoint: "...and exactly one [RFC4353 >> <https://tools.ietf.org/html/rfc4353>] Participant (which, in turn, >> includes exactly one SIP User Agent)." Can we make the SIP aspect more >> as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. >> How about something like "...and exactly one participant (e.g. a >> [RFC4353] paricipant)." >> >> Cl.4 para 1: change "...we are not able..." -> "...it is not >> possible..." >> >> Cl.4 para 1: change "Such information is designed...." -> "Such >> information is contained..." >> >> Cl.4 para 2: "Three main communication layers" would it be better to say >> "phases" instead of "layers"? >> >> Cl.4 bullet 2: "The version and options negotiation can be performed >> once and only at this stage." clarification "... can be performed once >> during the CLUE session and ...." >> >> Cl.4 para 3: "is is", delete one. >> >> Cl.4 para 4:"After that negotiation..." -> "After the negotiation..." >> >> Cl.4 para last: "Such messages will be..." -> "Such messages are..." >> >> Cl.5: "The basic structure determines the mandatory information that is >> carried within each CLUE message. Such an information is made by:" >> can this be simplified to say "The mandatory information contained in >> each CLUE message is:"? >> >> Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", etc." >> change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the values >> are normative. >> >> General: The document talks about extensions and options. Are they >> different? if not should we use one term. >> >> Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a >> mandatory..." >> >> 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. >> >> Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode is >> of type "xs:short" in section 9 its type "type="responseCodeType". >> >> Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon >> reception of the OPTIONS RESPONSE the version to be used is provided in >> the <version> tag of the message."? >> >> Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE >> dialogue are those" >> >> Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP sends >> an ADV to the MC as soon..." >> >> Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> "its >> CLUE telepresence media capabilities change" >> >> Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be better? >> >> Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising >> how each message section describes this. >> >> Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode is >> of type "xs:short" in section 9 its type "type="responseCodeType". >> >> Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode is >> of type "xs:short" in section 9 its type "type="responseCodeType". >> >> 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. >> >> 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. >> >> Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303. >> >> Cl.6 para 5: "Otherwise <if> ("channel error")..." >> >> Cl.6 para 1: "the MP is preparing" -> "the MP prepares" >> >> 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. >> >> Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC >> stays in..." >> >> Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV processing..." >> >> 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. >> >> Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an >> error response code) to the MP describing the problem via a proper >> reason phrase." Isn't the reason code enough? >> >> Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares". >> >> Cl.6.2 para 5: "the MC is waiting" -> "the MC waits". >> >> Cl.7 para 3: "The version of the XML schema contained in the standard >> document deriving from this draft will be 1.0." -> "This document >> defines XML schema version 1.0". >> >> Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields >> may be added" >> >> 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". >> >> Cl.9: <xs:import namespace="urn:ietf:params:xml:ns:clue-info" >> schemaLocation="data-model-schema-12.xsd"/> Should this be "17" instead >> of "12" to match the version number? Does this get updated to the >> relevant RFC number? >> >> Cl.10.1: "The associated Media Provider's telepresence capabilities are >> described in [I-D.ietf-clue-data-model-schema], Section "Sample XML >> file"." I'm a bit confused because the example in 10.1 doesn't match >> the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of >> the attribute values are different. Some of the syntax has different >> names. e.g. capturePoint->captureOrigin. >> >> Cl.10.1/10.2: protocol="CLUE" v="0.4" should this be "1.0" given this is >> going for WGLC? >> >> Cl.12. Do we need to establish IANA registry for clue options/extensions >> to manage the option names? >> >> Regards, Christian >> >> >> >> >> >> >> >> >> On 5/11/2016 3:26 AM, Paul Kyzivat wrote: >>> This message announces the start of a WGLC for >>> draft-ietf-clue-protocol-10. >>> >>> The last time we had a WGLC on this document was -04. Since then there >>> have been substantial changes: >>> >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt >>> >>> >>> >>> I have the sense that I have been the only one reviewing and >>> commenting on this document along the way. It is important that we >>> have thorough review by others in the wg. So please give careful >>> attention to this document and comment back. Note that this is the >>> last piece of CLUE. Once this one is done we can declare victory and >>> close down the wg. >>> >>> Unfortunately this review is starting at a busy time: the Seoul IETF >>> meeting is coming in a week, and so some people will be busy with >>> that. And the week after that is Thanksgiving in the US, so some >>> people won't be off some of that week. As a result, I'm giving a >>> longer duration for this review, so that everyone will have an >>> opportunity to fit the work into their schedule somewhere. >>> >>> Starting Date: Friday, November 4, 2016 >>> Ending Date: Wednesday, Novemeber 30, 2016 >>> >>> Please do this so we can wrap things up. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >
- [clue] WGLC for draft-ietf-clue-protocol-10 Paul Kyzivat
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Christian Groves
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Paul Kyzivat
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Christian Groves
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Paul Kyzivat
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Simon Pietro Romano
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Christian Groves
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Simon Pietro Romano
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Paul Kyzivat
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Christian Groves
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Paul Kyzivat
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Christian Groves
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Paul Kyzivat
- Re: [clue] WGLC for draft-ietf-clue-protocol-10 Simon Pietro Romano