Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

["Brandenburg, R. (Ray) van" <[e-mail]>]

On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" <[e-mail]> wrote:

> 
> 
> 
> 
>> -----Original Message-----
>> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
>> Sent: Monday, June 10, 2013 6:06 PM
>> To: Romascanu, Dan (Dan)
>> Cc: [e-mail]; General Area Review Team; Roni Even
>> ([e-mail]) [e-mail]
>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>> 
>> 
>> 
>> -----Original Message-----
>> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
>> Sent: maandag 10 juni 2013 16:57
>> To: Brandenburg, R. (Ray) van
>> Cc: [e-mail]; General Area Review Team; Roni Even
>> ([e-mail]) [e-mail]
>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>> 
>> 
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
>>> Sent: Monday, June 10, 2013 5:52 PM
>>> To: Romascanu, Dan (Dan)
>>> Cc: [e-mail]; General Area Review Team; Roni Even
>>> ([e-mail]) [e-mail]
>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>>> 
>>> Hi Dan,
>>> 
>>> See below...
>>> 
>>> Best regards,
>>> 
>>> Ray
>>> 
>>> -----Original Message-----
>>> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
>>> Sent: maandag 10 juni 2013 16:35
>>> To: Brandenburg, R. (Ray) van
>>> Cc: [e-mail]; General Area Review Team; Roni Even
>>> ([e-mail]) [e-mail]
>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>>> 
>>> 
>>> Yes, we seem to get closer and closer, focus on one last issue (and
>>> much agreement deleted)
>>> 
>>> Thanks and Regards,
>>> 
>>> Dan
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
>>>> Sent: Monday, June 10, 2013 5:27 PM
>>>> To: Romascanu, Dan (Dan)
>>>> Cc: [e-mail]; General Area Review Team; Roni Even
>>>> ([e-mail]) [e-mail]
>>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>>>> 
>>>> Hi Dan,
>>>> 
>>>> Please see inline. We seem to be converging:)
>>>> 
>>>> Ray
>>> 
>>>>>> 7. In Section 8:
>>>>>> 
>>>>>>   The timestamp is formatted based on the NTP
>>>>>>   timestamp format as specified in [RFC5905].  If this field is
>>>>> empty,
>>>>>>   then it SHALL be set to 0.  This field MAY be left empty if
>>>>>> none
>>>> or
>>>>>>   only one of the receivers reported on presentation
>> timestamps.
>>>>>> 
>>>>>> Why a MAY here? Especially for the case when none of the
>>>>>> receivers reported, what content can be set there but 0 ?
>>>>>> 
>>>>>> [Ray: I believe it should be up to the implementation to decide
>>>>>> how it wants to handle the case of there being only one receiver
>>>>>> who reported on presentation timestamps].
>>>>>> 
>>>>> [[DR]] OK, so the cases when none of the receivers reported and
>>>>> one receiver only reported should be dealt with differently. This
>>>>> needs to be clarified.
>>>>> 
>>>>> [Ray] What exactly is the problem with the MAY here? IMO it
>>>>> doesn't create any interop issues: whatever is the reason for
>>>>> setting the value to 0, to the client the end result is the same:
>> ignore it.
>>>>> 
>>>> 
>>>> [[DR]] In the case when none of the receivers reported we want to
>>>> avoid leaving some garbage in this field which could be interpreted
>>>> differently - don't we?
>>>> 
>>>> [Ray] I think I see where we disagree. The paragraph says: "If this
>>>> field is empty, then it SHALL be set to 0. This field MAY be left
>>>> empty if none or only one of the receivers reported on presentation
>>>> timestamps". The way I read this is as: In the case the field is
>>>> declared empty (= contains NULL information), it SHALL be set to 0.
>>>> There can be different reasons for declaring the field empty/NULL,
>>>> one of those reasons is if none or only one receiver reported on
>>>> presentation timestamps. To me, the paragraph doesn't say that this
>>>> is the only possible reason, but it does specify very clearly that
>>>> if you decide the field should be empty, you SHALL set it to zero.
>>>> 
>>>> 
>>> 
>>> [[DR]] But then, why do not you take out 'if none or' - because for
>>> the option of 'none' there is no alternative but the 'null'
>>> information, and the MAY does not make sense.
>>> 
>>> [Ray] The fact that no receiver reported on the packet presentation
>>> timestamp does not necessarily mean that the MSAS does not want to
>>> indicate a proposed packet presentation timestamp. The absence of such
>>> reports just means that the proposed playout moment might not be
>>> realistic, or be supported by any receiver.
>>> 
>> 
>> [[DR]] yes, but is the field set to anything but 0 in such cases?
>> 
>> [Ray] If the MSAS decides to leave the field empty, it is set to 0
>> according to the SHALL. If the MSAS decides to include a timestamp
>> anyway, it is set to whatever value the MSAS proposes.
>> 
> 
> [[DR]] So two different implementations may behave differently in similar situations. Is this a problem? 
> 

No, I don't think it is a problem if two different MSAS implementations behave differently in this regard. I see it as server-side configuration. Anyway, even if we would replace the MAY with a SHOULD or remove the sentence all together, there would still be different implementations: for example, let's say we have a sync group of 12 devices, with 7 of them reporting presentation timestamps. What should the MSAS do? Set the field in the IDMS Settings Packet to 0 or not? I feel this decision should be up to the implementation as I don't see an advantage to us specifying either one way or the other. 

Ray



> Dan
> 
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer