Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-05.txt

[Colin Perkins <csp at csperkins.org>]

On Thursday 06 May 2004 00:44, Stephan Wenger wrote:
> Hi Colin, AVTers,
>
> first I want to thank Colin and Philippe for their careful review of the
> I-D.  A new version of the draft is in its final stages of preparation
> and will be made available shortly.  This new draft reflects Philippe's
> comment (by restructuring section 8.4 and several other places in the
> draft to avoid too much redundancy) and most comments of Colin as well.
>
> Let me come back to a few items of Colin's list of which we don't know
> what
>
> to do with:
> >  - In Section 5.7.2, is it correct that the DOND field is unsigned?
>
> I believe this is correct.  We can set the DONB (Decoding Order Number
> Base) to make it possible that only positive values are necessary, and
> this definition makes the wrap-around language easier.  Is there a need
> to spell this out explicitely?

No. I was just checking that the text was correct.

> >  - It may be appropriate to move Section 7 to be an appendix?
>
> We think it may be better to leave this where it is, because this
> section explains concepts that are helpful to understand some of the
> following MIME parameter definitions.  Also, many older RTP payload
> specs have the packetization and de-packetization sections next to each
> other -- it seems natural to me.

Okay.

> >- In the encoding considerations for the MIME type, may wish to note
> > that file formats are defined elsewhere?
>
> The problem here is that all file formats are still in their
> specification phase -- we can't reference them (yet).  And what good
> would a simple "elsewhere" do?

Questions about the lack of a file format have been raised during IESG 
review of other RTP payload formats. Noting that the formats are being 
defined elsewhere will avoid the question later. 

> >  - Is there any need to discuss use with RTSP in Section 8.2.2 or
> > 8.2.3?
>
> I believe that in RTSP a simple, declarative process is used.  This sems
> to be well enough defined, and I'm not aware of any special
> considerations needed for RTSP.  Colin, did you have anything in
> particular in mind?

Only that RTSP isn't mentioned in the draft: a simple "for example, RTSP," 
in the appropriate section will cover it.

> >  - The draft needs to discuss congestion control, either within
> > Security Considerations, or as a separate section.
>
> I don't see any issues of congestion control beyond those of RFC3550,
> maybe with the exception of what is written in section 7.3 (it is
> possible to discard certain NALUs in translators, mixers, and receivers
> under certain conditions, and that could be used for congestion control
> in scenarios where mixers and translators are in use).  Hence we suggest
> to add a sentence in the security section that people need to observe
> RFC3550 congestion control, and can possibly make the network's life
> easier by implementing 7.3.  Is there a need to say anything beyond
> that?

No, but that needs to be said (actually, reference RFC 3550 "and any 
applicable RTP profile, e.g. RFC 3551").

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt