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

["Spencer Dawkins" <[e-mail]>]

Hi, Lorenzo,

Robert has changed this draft to "revised ID needed" in the ID Tracker, so 
we need to post a revised draft that addresses these changes so that we can 
move forward. I'd like to make that happen quickly.

For the XCON reference - I haven't heard anyone expressing concerns about 
moving the XCON reference to the Normative References section, so let's make 
this change.

For the question about atomicity - should this be something that we say for 
all packages? Or do people think that some control packages would be atomic, 
while other control packages would not?

Thanks,

Spencer

----- Original Message ----- 
From: "Lorenzo Miniero" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>; "Lorenzo Miniero" 
<[e-mail]>; "Robert Sparks" <[e-mail]>; 
<[e-mail]>
Cc: <[e-mail]>
Sent: Friday, January 15, 2010 4:37 PM
Subject: Re: [MEDIACTRL] AD review: draft-ietf-mediactrl-mixer-control 
package-09


> 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