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

[Scott McGlashan <[e-mail]>]

I've updated the mixer draft with a clarification along the lines Lorenzo suggested. Hopefully it is clearer now - if a operation fails in part, then the MS ensures that no part of the operation is carried out.

thanks

Scott

On 15 Jan 2010, at 23:37, Lorenzo Miniero wrote:

> 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" <[e-mail]>
> To: "Lorenzo Miniero" <[e-mail]>, "Robert
> Sparks" <[e-mail]>, <[e-mail]>
> Cc:
> <[e-mail]>
> 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