Re: [MEDIACTRL] AD review: draft-ietf-mediactrl-mixer-control package-09

"Lorenzo Miniero" <lorenzo@meetecho.com> Fri, 15 January 2010 22:37 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F3C3A69A1 for <mediactrl@core3.amsl.com>; Fri, 15 Jan 2010 14:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.718
X-Spam-Level:
X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, UNPARSEABLE_RELAY=0.001]
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 PKccZWdHFNpk for <mediactrl@core3.amsl.com>; Fri, 15 Jan 2010 14:37:26 -0800 (PST)
Received: from smtp2.aruba.it (smtp2.aruba.it [62.149.128.201]) by core3.amsl.com (Postfix) with SMTP id C5AC63A6828 for <mediactrl@ietf.org>; Fri, 15 Jan 2010 14:37:25 -0800 (PST)
Received: (qmail 15478 invoked by uid 89); 15 Jan 2010 22:37:19 -0000
Received: from unknown (HELO webmaildh2.ad.aruba.it) (lorenzo@meetecho.com@10.10.10.96) by smtp2.aruba.it with SMTP; 15 Jan 2010 22:37:19 -0000
Received: from 79.41.54.99 by HTTP
Sender: lorenzo@meetecho.com
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Spencer Dawkins <spencer@wonderhamster.org>, Lorenzo Miniero <lorenzo@meetecho.com>, Robert Sparks <rjsparks@nostrum.com>, mediactrl@ietf.org
X-Mailer: Quality Web Email v3.1s
X-Originating-IP: 79.41.54.99
Date: Fri, 15 Jan 2010 23:37:20 +0100
Message-id: <4b50ee20.b7.1d08.420790473@webmaildh2.ad.aruba.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Rating: smtp2.aruba.it 1.6.2 0/1000/N
Cc: draft-ietf-mediactrl-mixer-control-package@tools.ietf.org
Subject: Re: [MEDIACTRL] AD review: draft-ietf-mediactrl-mixer-control package-09
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2010 22:37:27 -0000

Hi Spencer,

about 1) I'm ok with the XCON reference then.

For what concerns 2), I couldn't find any generically
appliable rule for that, except some "MUST NOT change"
related to specific scenarios. In general the text says "If
the MS is not able to process the request and carry out the
mixer operation, the request has failed and the MS MUST
indicate the class of failure using an appropriate 4xx
response code" (this is for mixer, IVR is the same
basically). My guess is that "the request has failed" means
"all or nothing", but it's not 100% clear, so a few words to
clarify this might actually help.

Cheers,
Lorenzo


----- Original Message -----
From: "Spencer Dawkins" <spencer@wonderhamster.org>
To: "Lorenzo Miniero" <lorenzo@meetecho.com>, "Robert
Sparks" <rjsparks@nostrum.com>, <mediactrl@ietf.org>
Cc:
<draft-ietf-mediactrl-mixer-control-package@tools.ietf.org>
Subject: Re: [MEDIACTRL] AD review:
draft-ietf-mediactrl-mixer-control package-09
Date: Fri, 15 Jan 2010 15:01:56 -0600

> Hi, Lorenzo,
> 
> Thanks for the speedy response on a Friday night! A couple
> of comments  below...
> 
> Spencer
> 
> >> Dear Mediactrl,
> >>
> >>
> >> > This draft is essentially ready to go. I have two
> >> > questions/comments  for  the group.
> >>
> >> Robert is really trying to get Framework, IVR and MIXER
> >> into IETF Last Call  for publication, but we need to
> >> answer two questions that he asked. Please  look at
> these >> carefully.
> >>
> >> > 1) As written, the reference to the XCON datamodel
> >> > document needs to  be  normative.
> >> >      (You have to know what's defined there to know
> when >> > a prefix is  required, and
> >> >        realistically, it's a must read to use any of
> the >> > video  layouts  defined there).
> >> >      I'm expecting XCON to pubreq that document
> within a >> > couple of  weeks,  so making
> >> >      the reference normative shouldn't slow down
> >> > publication of this  document.
> >> >      Would anyone object to making that reference
> >> normative?
> >>
> >> I think Robert is correct here. I think the only
> possible >> alternative is to  require all video layouts
> to be >> prefixed with a label, whether it's defined  in
> [XCON] or >> not (that's the dependency that caught
> Robert's eye). Does >> anyone strongly disagree with
> moving the reference? to >> Normative?
> >>
> >> Could the authors move this reference to Normative as
> >> requested and post a  new revision?
> >>
> > [LM] Actually I'm not sure we really need an explicit
> > reference to the data model. Layouts are layouts with or
> > without XCON, and maybe just defining an extendable set
> > of valid layout strings in this document's schema is
> enough.
> 
> If I'm understanding this suggestion, I would have
> concerns about taking  this work on, both from a schedule
> perspective and a working group scope  perspective - if
> you're suggesting that MEDIACTRL produces that definition,
> and I think you are.
> 
> I'd much rather answer Robert's question by a small text
> change, if that's  possible.
> 
> >> > 2) I'm not easily finding where framework (or this
> >> > document) says what  happens
> >> >     when part of a command with multiple components
> >> > fails. For  instance,  in section
> >> >     4.2.2, there's an example of a join command that
> >> > operates two  different volumes.
> >> >     If one of those fails for some reason, does the
> >> > other one fail  with  it? Where is
> >> >     the text that says this is so?
> >>
> >> We really need to make sure we all have the same
> >> understanding here...  Please state yours on this
> mailing >> list! ... but Robert said he would not  gate
> IETF Last >> Call on this question.
> >>
> > [LM] If I recall correctly, both the packages only
> > enforce a request when all its components succeed,
> > otherwise the request is considered as failed and
> > nothing is changed. I remember implementing the
> > prototype this way, so I guess some text was there, but
> > I'm not sure about that. It surely makes sense not to
> allow partial successes, anyway.
> 
> Can you poke around and find where we say this? If we
> can't find text that  says it, we have to write text that
> says it ;-)
> 
> Enjoy your weekend,
> 
> Spencer 
> 

Lorenzo Miniero
http://www.meetecho.com