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

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

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