Re: [XCON] AD review: draft-ietf-xcon-examples-06

Robert Sparks <rjsparks@nostrum.com> Tue, 07 December 2010 19:29 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3213A689C for <xcon@core3.amsl.com>; Tue, 7 Dec 2010 11:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.481
X-Spam-Level:
X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BREecpASUy0L for <xcon@core3.amsl.com>; Tue, 7 Dec 2010 11:29:04 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F14043A6996 for <xcon@ietf.org>; Tue, 7 Dec 2010 11:28:58 -0800 (PST)
Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB7JUMmG051291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 13:30:23 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <AANLkTikmScQSK94nOKzGc8xd56tRzyiXhhLhCpmDmZ4K@mail.gmail.com>
Date: Tue, 7 Dec 2010 13:30:22 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <595854C3-1F72-43B6-B884-6EC28A30AC7F@nostrum.com>
References: <F487BB01-8783-466E-AD5A-00FD926FD089@nostrum.com> <AANLkTikmScQSK94nOKzGc8xd56tRzyiXhhLhCpmDmZ4K@mail.gmail.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism)
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-examples-06
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 19:29:13 -0000

I've reviewed -07 - all my concerns have been addressed.

I would prefer to send this, ccmp, and the data-model document to IETF LC together - hopefully
we can resolve the last of my concerns on those quickly. If it doesn't look like we'll converge on those
by later this week, I'll send this into IETF LC ahead of the others.

RjS

On Oct 26, 2010, at 3:54 PM, Mary Barnes wrote:

> Robert and WG,
> 
> We have updated the document to address the issues raised below:
> http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-07.txt
> 
> As well, there are some updates to the call flows themselves.  The
> diff is a useful way to review the changes:
> http://tools.ietf.org/wg/xcon/draft-ietf-xcon-examples/draft-ietf-xcon-examples-07-from-06.diff.html
> 
> I have a few responses inline below [MB] clarifying some of the changes made.
> 
> Regards,
> Mary.
> 
> On Tue, Sep 14, 2010 at 11:02 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
>> Summary: There are a few issues to address before moving this document
>>         to IETF Last Call
>> 
>> * This document is not as easy to read as the ccmp and data model
>>  documents. I suggest an additional editorial pass focusing on
>>  tightening the prose.
> [MB] A fair number of editorial clarifications have been done per the
> diff, hopefully addressing this concern. [/MB]
>> 
>> * Section 4 (Working with CCMP) states the document has "recommendations
>>  from an implementation point of view". I'm not finding those. Could
>>  they be called out in a separate "Advice to Implementers" section, or
>>  did they all move to the CCMP document already (in which case, the above
>>  statement should be removed)?
> [MB] Per the diff, this has been changed to "implementation considerations"
>> 
>> * The end of 4.1 talks about a "placeholder wildcard". It should explicitly
>>  mention AUTO_GENERATE_X and point to the definition of the mechanism in
>>  the CCMP document.
>> 
>> * The end of section 4.3 moves into the realm of speculation, particularly
>>  around Figure 3. This needs to be more clearly labeled as speculation, and
>>  not recommendation or specification. The section is motivating different
>>  standards work rather than showing examples of implementing what's already
>>  been specified. I strongly suggest removing it from the draft and
>>  re-introducing one or more concrete proposals separately, calling out
>>  at most in this draft that other mechanisms are possible and are the
>>  subject of future standardization discussions.
> [MB] The text has been removed and the section just discusses the use
> of the SIP Event notifications per CCMP. [/MB]
>> 
>> * Figure 5 is redundant with Figure 4 - all of the anchors for the
>>  annotations are already in Figure 4. I suggest deleting Figure 5.
>> 
>> * Why doesn't the example in section 6.2 use the mute control?
>>  If that's inappropriate, it would be good to add text to this
>>  section explaining why. If it is a valid alternative, please call
>>  that out.
> [MB] Mute control is a valid alternative and I've added a note
> reflecting such. The example was actually changed from one using MUTE
> control to give an example of the media manipulation in general
> (waaaay long ago this was brought up (by
> Cullen I think)  - this is a scenario from the XCON FW. [/MB]
>> 
>> * Section 6.5 calls out a situation as a "(first-party join)". Where
>>  is this phrase defined?
> [MB] The definition for this term and third-party have been added to
> the ccmp document. [/MB]
>> 
>> * Can Section 7.2 better motivate why a sidebar is being used here instead
>>  of a separate new conference?
>> 
>> _______________________________________________
>> XCON mailing list
>> XCON@ietf.org
>> https://www.ietf.org/mailman/listinfo/xcon
>>