Subject: [Gen-art] Gen-ART LC review of draft-ietf-mmusic-decoding-dependency-05.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Feb 2009 11:42:38 +1300

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 04 Feb 2009 10:24:51 +0100

Dear Brian, all,

Brian, thanks a lot for carrying out the review!

Here are our replies:

1. We do not think that it is required for the offerer to find out, why 
the offer has been rejected. At least we do not know any context where 
the reason for rejecting an offer is indicated.

2. "Aforementioned" can be removed in RFC editor processing (AUTH48), or 
IESG note.

3. DDP and RDMA in the RFC4296 sense are about as far away technically 
than it gets from SDP signaling.  Confusion is, in our opinion, 
unlikely.  Can we ask the MMUSIC chairs and Cullen for guidance here?

Best regards,
Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at

GSM mobile WORLD CONGRESS / Barcelona, Spain / 16-19 February 2009 / Hall 1 Booth 1G49
http://www.mobileworldcongress.com

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Feb 2009 09:37:31 +1300

Hi Thomas,

> the reason for rejecting an offer is indicated.

Maybe I should be more precise about my question. You say that when the
sender receives:

>> (2) with a refusal to the request (e.g., 488
>>    Not acceptable here or 606 Not acceptable in SIP).

then

>>   In the
>>   second case, if the sender of the offer still wishes to establish the
>>   session, it SHOULD re-try the request with an offer including only a
>>   single media stream.

I don't understand  how the sender decides that it is in this case
rather than any other reason for receiving a Not acceptable reponse.
Is it supposed to *guess* that the reason is the use of DDP? I don't
know what IF statement I would need, if I was writing code for the sender.
The problem would not arise if there was a specific "DDP Not acceptable"
response.

> 2. "Aforementioned" can be removed in RFC editor processing (AUTH48), or

Thanks
> unlikely.  Can we ask the MMUSIC chairs and Cullen for guidance here?

Sure. I have no strong feeling about this.

Regards
    Brian

---

From: Thomas Schierl <[email-masked]>
Date: Thu, 05 Feb 2009 14:14:58 +0100

Hi Brian,

> The problem would not arise if there was a specific "DDP Not acceptable"
Ok, I got it now. What would be an appropriate way forward here? 
Removing the part "In the second case ..."? Or refining the language, 
saying something like: if the sender has identified, that only "DDP" can 
be the problem, then ...

Thanks,
Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Feb 2009 08:20:57 +1300

Thomas,

> saying something like: if the sender has identified, that only "DDP" can

Something like that. If I was implementing this, I guess I would end up
with some logic like this:

IF response=="Not acceptable" AND DDP_sent==TRUE
   THEN try again without DDP
   ELSE report failure

My concern is that a junior programmer reading your document
might not reach the correct solution without some extra words.

    Brian

---

From: Thomas Schierl <[email-masked]>
Date: Thu, 12 Feb 2009 15:37:39 +0100

Hi Brian,

we think that such a modification in section 6.1 makes sense:

Please find a possible modification of the text below:

original text:

In the first case, if the original sender of the offer still wishes

to establish communications, it SHOULD generate a new offer with a

single media stream that represents an Operation Point.  Note: in

most cases, this will be the base layer of a layered Media Bitstream,

equally possible are Operation Points containing a set of enhancement

layers as long as all are part of a single media stream.  In the

single media stream.

new text:

In the case (1), if the original sender of the offer still
wishes

to establish communications, it SHOULD generate a new offer with a

single media stream that represents an Operation Point.  Note: in

most cases, this will be the base layer of a layered Media Bitstream,

equally possible are Operation Points containing a set of enhancement

layers as long as all are part of a single media stream.

In case (2), if the sender of the original offer has identified that
the refusal to the request

is caused by the use of DDP grouping, and

if the sender still wishes to establish the

single media stream.

Best regards,

Thomas

Brian E Carpenter wrote:

Thomas,

Hi Brian,

Brian E Carpenter wrote:

Hi Thomas,

Dear Brian, all,

Here are our replies:

then

In the

know what IF statement I would need, if I was writing code for the
sender.

Brian

Thanks,
Thomas

Thanks

Regards
Brian

Best regards,
Thomas

--
Thomas Schierl
--------------
Fraunhofer HHI

----

Visit us at

http://www.mobileworldcongress.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Feb 2009 15:38:41 +1300

Thomas,

That looks good to me. Thanks!

   Brian

On 2009-02-13 03:37, Thomas Schierl wrote:
>    In the *case (1)*, if the original sender of the offer still wishes
>    layers as long as all are part of a single media stream.  *
> In case (2), if the sender of the original offer has identified that the refusal 
> to the request
>   is caused by the use of DDP grouping, and*

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Feb 2009 16:24:21 -0800

On Feb 4, 2009, at 1:24 , Thomas Schierl wrote:

> 3. DDP and RDMA in the RFC4296 sense are about as far away  
> technically than it gets from SDP signaling.  Confusion is, in our  
> opinion, unlikely.  Can we ask the MMUSIC chairs and Cullen for  
> guidance here?

I'm pretty ambivalent on this. If we changed DDP to something like  
DDPG for "decoding dependency group" would that introduce confusion to  
the MMUSIC world? If moving away from DDP is going to cause confusing  
to MMUSIC implementors, I'd probably rather not do it. If we can  
easily switch to something that does not conflict, well less acronym  
conflict is better but these are pretty far apart.

Authors and Chairs, is there something obvious to change DDP to and  
can we make that change without causing confusion? if not, I'e like to  
leave as is.

Thanks, Cullen

---

From: Thomas Schierl <[email-masked]>
Date: Mon, 23 Feb 2009 12:08:15 +0100

Hi Cullen,

We, the authors, also decided to stay with DDP, since this name is there 
for quite a long time and people may have already implemented it. 
Furthermore, there may be not relation between decoding dependency 
grouping and direct data placement, so that we do not see any problems 
of collision in signaling.

Best regards,
Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at

CeBIT 2009 / March 3-8 / Hannover, Germany / Hall 9, Booth B36 and A30
http://www.cebit.de

embedded world 2009 / March 3-5 / Nuremberg, Germany / Hall 11, Booth 11-101
http://www.embedded-world.de