[AVT] Comments on draft-ietf-avt-rfc2032-bis-11

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the draft and have some nits. Yes we are mostly talking 
nits but fixing them will make publication process go smoother.

1. Front page:Paragraph starting with: This specification is a product 
of ...
Please move that to the status of this memo section. I don't think the 
idnits tool complains about this.

2. The abstract. It is to short. A single sentence abstract is not 
acceptable and will be commented on. So please expand it a bit. Please 
remember

 From the online ID checklist: http://www.ietf.org/ID-Checklist.html#anchor6

# Abstract

     A
         Should be meaningful to someone not versed in the technology; 
most abbreviations must be expanded on first use
     B
         no citations
     C
         See [I-D.rfc-editor-rfc2223bis] (Reynolds, J. and R. Braden, 
“Instructions to Request for Comments (RFC) Authors,” July 2004.) 
section 4.5.


from draft-rfc-editor-rfc2223bis-08:
    4.5  Abstract


       Every RFC must have an Abstract section following the Copyright
       notice.  An Abstract will typically be 5-10 lines.  An Abstract of
       more than 20 lines is generally not acceptable.


       The Abstract section should provide a concise and comprehensive
       overview of the purpose and contents of the entire document, to
       give a technically knowledgeable reader a general overview of the
       function of the document.  In addition to its function in the RFC
       itself, the Abstract section text will appear in publication
       announcements and in the online index of RFCs.

...

3. A general editorial thing is that the citations in this document are 
always directly following a word. Please insert a space before the [ref] 
bracket.

4. Section 1. Last paragraph:
"  This document updates RFC 2032 and the "video/h261" media type that
    was registered in RFC 3555."

Is that really the intention of the document. I thought it was to 
obsolete RFC 2032 and update the "video/h261" media type in RFC 3555?

5. Section 3.2, second paragraph:
"Similarly, we will not attempt to multiplex audio and
    video signals in the same packets, as UDP and RTP provide a much more
    efficient way to achieve multiplexing."

Wouldn't it be better to replace the word "efficient" with "suitable"?

6. Section 4.1, high order bit number scale is out of alignment on both 
figures on page 8.

7. Section 5, last paragraph:
"The first method is by using the
    Extended RTP Profile for RTCP-based Feedback and sending RTCP generic
    control packets as described in



Even                      Expires July 8, 2006                 [Page 11]

Internet-Draft          H.261 RTP payload format            January 2006


    draft-ietf-avt-rtcp-feedback[rtcp-feedback]."

I think you should replace "draft-ietf-avt-rtcp-feedback" with "RFCXXXX" 
and an RFC editor note asking them to replace XXXX with the RFC number 
draft-ietf-avt-rtcp-feedback receives.

8. Section 6.1: I think this section should indicate that registration 
has been done using RFC 4288 template and the rules in RFC 3555.

9. Section 6.1.1: D parameter:
       D: specifies support for still image graphics according to H.261
       annex D.  If supported SHALL have the value "1".  If not supported
       SHOULD NOT be listed or SHALL have the value "0".

I think the later two sentences could benefit from being written as real 
sentences. I would propose:

       D: specifies support for still image graphics according to H.261
       annex D.  If supported the parameter value SHALL be "1".  If not 
supported the parameter SHOULD NOT be used or SHALL have the value "0".

10. Section 6.2.1:
"If the receiver does not specify the picture size /MPI optional
    parameter then it SHOULD be ready to receive QCIF resolution with
    MPI=1."

I think using SHOULD here is a bit problematic. If this is not enforced, 
then what can you expect when a client answers without any parameters. 
And this is an issue of handling non updated terminals also. As I see 
there are a few alternatives that provide better solutions:

A. Require all updated implementations to always indicate their receiver 
capabilities. Even if it is QCIF with MPI = 1. Then state that any 
counter part that not supported the updated spec will thus be detectable 
and it is recommended to use QCIF with MPI = 1 because it will most 
likely work.

B. Require that anyone follows this specification SHALL support QCIF and 
MPI=1 if it doesn't include any parameter indicating otherwise. Then 
include a statement about backwards compatibility that it is likely that 
this work but not guaranteed.

Or where there any other reason why there is a SHOULD in that sentence?

11. Section 7.1:
This new RFC suggest generic methods to address the
    same requirement.
I think you should change "new RFC" to "memo" to more clearly indicate 
that it is this document that you refer to. "memo" seem to be a favorite 
word of the RFC editor.

12. Section 7.1:
Since these are
    optional features new implementations SHALL ignores them and they
    SHALL not be used by new implementations.

Two things: "ignores" shouldn't this be "ignore"?
And "not" after SHALL needs to be "NOT".

13. Section 7.2, connect with my comments in issue 10. I think one can 
clear explain that we expect that any H261 implementation will support 
QCIF and 30 Hz. And that is what will happen when new peers connect to 
old ones, assuming that they ignore the parameters they do not 
understand. This is something I would not like to put all my money on.

14. Section 8.

I think the security section needs a bit of rewrite. The first part of 
paragraph 1 is fine. However the second one is not okay. We have 
received AD comments on the formulation about encryption and order. I 
would suggest that you change the paragraph to:

    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [RFC3550], and any appropriate RTP profile (for example
    [RFC3551]).  This implies that confidentiality of the media streams
    is achieved by encryption.  SRTP [RFC3711] may be used to provide
    both encryption and integrity protection of RTP flows.

Then the second sentence is fine with the exception that is lacking an 
authorative statement if that is the case or not for the H261 codec. So 
please clarify if H261 exhibits any such behavior or not.

I would remove the complete last paragraph. It statement is very generic 
  however I don't think it present either a fair statement of the issue 
or provide any sufficient recommendations. Also this a generic problem 
that  is not particular to RTP nor specifically to this payload format.

15. Section 11.2: The reference to rtcp-feedback. Is this not a 
normative reference? You recommend that one uses this format for NACK 
and loss indication. Also the version of that draft has been updated, it 
is now 11.

16. Super minor nit: Your draft includes the RFC editors standard 
acknowledgment about funding. However that has now changed due to new 
administrative structure of the IETF. For your information it now reads:
    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).

However I do assume that it is put there by XML2RFC. In that case ignore 
this comment.

Cheers

Magnus







-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt