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

["Romascanu, Dan (Dan)" <[e-mail]>]

> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> Sent: Monday, June 10, 2013 7:19 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
> 
> 
> 
> 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
> 

[[DR]] The open issue is not about this case but about the case when no receiver reported. You say one MSAS implementation may treat this as null information setting the field to 0 (which would seem to me like the obvious thing to do), but other MSAS implementation may include a timestamp anyway (which one?). My question 'Is this a problem' was about this case? 

Dan