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

["Even, Roni" <[e-mail]>]

Hi Magnus,

Thanks, see my response inline

Roni

-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: Wednesday, January 11, 2006 4:24 PM
To: Even, Roni; IETF AVT WG
Subject: Comments on draft-ietf-avt-rfc2032-bis-11

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.

RE: The status of this memo section is added by the xml2rfc schema, but
I think it is right to remove the second paragraph in the abstract
section

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.

...

RE: OK

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.

RE:OK

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?

RE: I got this sentence from Collin but I think that your comment is
more precise, so I will change the updates to obsolete.

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"?

RE: OK

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

RE: OK, Thanks


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.

RE: Is this a dependency for publication - I thought that it is OK to
have such a reference in the informative section.

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.

RE: I do not mind mentioning RFC4288 template but I fail to see the
value. The registration updates the current registered version in
RFC3555.
So is it really required to add 4288

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".

RE: OK

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?

RE: You got the right reason, the receiver can assume that it is most
likely that he will get QCIF. As for the rephrasing I prefer option A
which have the same meaning. Option B implies that a receiver must
support QCIF, this will enable encoder to send QCIF even if it was not
signaled.

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.

RE: OK

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".

RE: OK

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.

RE: I agree that almost any H.261 implementation may support QCIF 30 but
I did not want to make this implicit since it will prevent a receiver
that implement the new optional parameters from stating that he wants to
receive CIF and not QCIF.


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.

RE: I will remove the last paragraph add your suggestion to the start
and clarify that encryption will be done after the encoding " encryption
will be
   performed after"

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.

RE: I see this as an example for a method and not the only method, this
is why it is informative.

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.
RE: I am using XML2RFC, at least I will verify I am using the latest
version 

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