> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[email protected]]
> Sent: Monday, June 10, 2013 6:06 PM
> To: Romascanu, Dan (Dan)
> Cc: [email protected]; General Area Review Team; Roni Even
> ([email protected]); [email protected]
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>
>
>
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]
> Sent: maandag 10 juni 2013 16:57
> To: Brandenburg, R. (Ray) van
> Cc: [email protected]; General Area Review Team; Roni Even
> ([email protected]); [email protected]
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>
>
>
>
>
> > -----Original Message-----
> > From: Brandenburg, R. (Ray) van [mailto:[email protected]]
> > Sent: Monday, June 10, 2013 5:52 PM
> > To: Romascanu, Dan (Dan)
> > Cc: [email protected]; General Area Review Team; Roni Even
> > ([email protected]); [email protected]
> > 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:[email protected]]
> > Sent: maandag 10 juni 2013 16:35
> > To: Brandenburg, R. (Ray) van
> > Cc: [email protected]; General Area Review Team; Roni Even
> > ([email protected]); [email protected]
> > 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:[email protected]]
> > > Sent: Monday, June 10, 2013 5:27 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: [email protected]; General Area Review Team; Roni Even
> > > ([email protected]); [email protected]
> > > 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?
Dan
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
