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

From: "Lorenzo Miniero" <[email-masked]>
Date: Fri, 15 Jan 2010 23:37:20 +0100

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Jan 2010 16:48:46 -0600

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" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Lorenzo Miniero" 
<[email-masked]>; "Robert Sparks" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 15, 2010 4:37 PM
Subject: Re: [MEDIACTRL] AD review: draft-ietf-mediactrl-mixer-control 
package-09

---

From: Scott McGlashan <[email-masked]>
Date: Thu, 28 Jan 2010 19:16:34 +0100

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 28 Jan 2010 14:06:45 -0600

Hi, Scott,

Thanks for taking care of this - Robert has just launched the control
framework, the IVR package, and the MIXER package for IETF Last Call.

This is a big step forward (and I look forward to the next big step, when 
the documents are approved for publication as Proposed Standards ;-)

To the group,

Scott has made a one-sentence change in the draft that I agree with (and I
also agree with Robert that we had to say SOMETHING about whether requests
can "partially fail", whether the answer was "yes" or "no"), but I need to
make sure the working group agrees with it. The diff pops out for you at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-mixer-control-package-10.

So, what we have is a statement in one control package, but we do not
require atomicity for control packages in general - right?

For ease of reference in this thread, here's what MIXER-10 says:

   If the
   MS is not able to process the request and carry out the mixer
   operation (in whole or in part), then the request has failed: the MS
   MUST ensure that no part of the requested mixer operaton is carried
   out, and the MS MUST indicate the class of failure using an
   appropriate 4xx response code.

And here's what IVR-07 says, in roughly the same place:

   If the
   MS is not able to process the request and carry out the dialog
   operation, the request has failed and the MS MUST indicate the class
   of failure using an appropriate 4xx response code.

Do we have this right? Please let us know on-list!

Thanks,

Spencer

----- Original Message ----- 
From: "Scott McGlashan" <[email-masked]>
To: "Lorenzo Miniero" <[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; "Robert Sparks"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 28, 2010 12:16 PM
Subject: Re: [MEDIACTRL] AD review: draft-ietf-mediactrl-mixer-control
package-09

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

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Thu, 28 Jan 2010 16:21:58 -0500

That feels right to me.

I can imagine with IVR a prompt & collect routine of some length going
on where there's a problem part way through (MS software or subsystem
hiccup or whatever) and MS can't complete. Can't expect the MS to know
that ahead of time, and it can't undo.

With MIXER, I can't imagine a scenario, practically, where there would
be a problem in the middle of doing something. (Not sure there really is
much of a middle with MIXER operations.)

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Thursday, January 28, 2010 3:07 PM
To: Scott McGlashan; Lorenzo Miniero
Cc: [email-masked];
[email-masked]
Subject: Re: [MEDIACTRL] AD review:
draft-ietf-mediactrl-mixer-controlpackage-09

Hi, Scott,

This is a big step forward (and I look forward to the next big step,
when 
the documents are approved for publication as Proposed Standards ;-)

To the group,

Scott has made a one-sentence change in the draft that I agree with (and
I
also agree with Robert that we had to say SOMETHING about whether
requests
can "partially fail", whether the answer was "yes" or "no"), but I need
to
make sure the working group agrees with it. The diff pops out for you at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-mixer-control-pa
ckage-10.

   If the

   If the

Thanks,

Spencer

----- Original Message ----- 
From: "Scott McGlashan" <[email-masked]>
To: "Lorenzo Miniero" <[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; "Robert Sparks"

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 

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 28 Jan 2010 15:43:16 -0600

Gary,

This is exactly the kind of feedback I'm looking for - I'm not saying 
there's a problem, I'm just saying that we forwarded two specs to Robert 
that deal with partial failures differently, and I want to make sure that we 
did that on purpose!

Do others see it the same way?

Thanks,

Spencer