Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01

["Ali C. Begen" <[e-mail]>]

Hi John,

On Wed, Apr 5, 2017 at 8:47 PM, John Fletcher <[e-mail]>
wrote:

> Here are some comments:
>
>
>
> A revised version of the VC-2 specification SMPTE ST 2042-1 has reached
> Draft Publication status and is likely to be published in the next 2 or 3
> months.  Given that section 4.3 of the memo discusses items that are
> changed in the new version of VC-2, I suggest that the memo is updated to
> reflect the new version.  I am not sure of the timescale for progression to
> RFC but I would suggest delaying this if necessary until the SMPTE document
> is published.
>

Depending on the external parties always creates concerns and also some
issues. So, if the final spec due date is that close, I think we better
wait for it and then finish the RTP work. Does anybody object to this?


>  In section 4.1, the description of the Timestamp field says it
> “corresponds to the sampling instant of the coded picture”.  This will not
> be the case if source of the RTP stream is replayed video.  It also may not
> be the case if the input to the RTP encoder is slightly delayed with
> respect to image capture (highly likely) and/or the interface does not
> provide the capture time.  I suggest re-wording this section.
>

How the RTP timestamps is used, it is a bit different story. I see that
Thomas replied to this as well. The payload drafts are flexible in terms of
how they can use the timestamps. So, if there is any requirement from the
SMPTE folks on this, we should use that one in this draft. Is there?


>  Also in section 4.1, description of Timestamp, I suggest adding: “If the
> required timestamp does not correspond to an integer value of the clock,
> e.g. when the frame or field rate is 60000/1001, the value SHALL be
> truncated to the next lowest integer.”
>
>
>
> Section 5, Congestion control, says it SHALL be in accordance with RFC3550
> but all that RFC3550 says is that congestion control SHOULD be defined in
> each RTP profile.  The section also makes reference to an Internet Draft
> and I believe this is not allowed.  Congestion control is not really a
> matter for Payload Format Specifications and I suggest this section is
> deleted.
>

See https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-14#section-7.3

Essentially this section has to exist, what goes in there depends on the
payload format and how it is used (or how it should not be used).

-acbegen


>
> In section 6.1 under “security considerations”, I suggest changing the
> text to “Please see section 8 of this memo".
>
>
>
> In Normative References, RFC3551 is listed but it is not a normative
> reference, it is only referred to as an example.
>
>
>
> In Normative References, as noted earlier, reference to
> I-D.ietf-avtcore-rtp-circuit-breakers is inappropriate and will not be
> needed if the Congestion Control section is removed.
>
>
>
>
>
> Regards,
>
> John Fletcher
>
>
>
> *From:* payload [mailto:[e-mail]] *On Behalf Of *Ali C.
> Begen
> *Sent:* 04 April 2017 15:40
> *To:* [e-mail]
> *Subject:* Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01
>
>
>
> Any other comments on this draft? So far, we heard from Jean-Marie and
> Victor supporting the draft. If you have any comments, please send them by
> next Wed (April 12th).
>
>
>
> @Thomas
>
>
>
> I believe you volunteered to review this draft? Could you submit it by
> next week?
>
>
>
> Thanks.
>
> -acbegen (co-chair)
>
>
>
> On Fri, Feb 24, 2017 at 9:02 AM, Ali C. Begen <[e-mail]>
> wrote:
>
> WG,
>
>
>
> We are starting WGLC for the following draft. Please review the draft and
> send your comments to the list by March 13th. If you read the draft but you
> have no comments, say so as well.
>
>
>
> It is a short document, so should be a quick review.
>
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-vc2hq/
>
>
>
> -acbegen
>
>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>