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

From: "Even, Roni" <[email-masked]>
Date: Tue, 17 Jan 2006 11:17:27 +0200

Hi Magnus,

Thanks, see my response inline

Roni

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
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 +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Jan 2006 13:14:12 +0100

Hi Roni,

Please see comments inline.

> have such a reference in the informative section.

Yes, but it should only be used if that dependency will result in a 
blocked publication. As RTCP feedback is in the RFC-editor queue already 
it will be an RFC before this document, thus no issues and you can use 
the future RFC as reference.

> So is it really required to add 4288

This is to indicate for the future which rules and template the 
currently implemented registration uses. This will be beneficial if the 
there are future procedural updates. It also indicates to the Media 
Types review people that we are attempting to follow the indicated set 
of rules.

> support QCIF, this will enable encoder to send QCIF even if it was not

I am fine with A.

> receive CIF and not QCIF.

I don't see how it would prevent one from stating that one desires to 
use another mode. The main thing with always declaring the mode of usage 
is that one can separate the updated from the non updated in the 
negotiation. Which has some advantages.

> and clarify that encryption will be done after the encoding " encryption

In that case I would state it using informative must or shall. 
Encrypting first and encoding then is not really working. Which is 
something the Security Ad has commented on before.

> is why it is informative.

Okay, I don't know if I like this. I would prefer a single method for 
this. If one desires to do this, then use RTCP feedback messages. Or at 
least SHOULD level. With the exception that RTCP feedback does not suite 
the operational environment and another method exist.

Cheers

Magnus Westerlund