Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-08.txt

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 12 Feb 2010 17:28:27 -0500

Thanks again, Tom. All addressed. See below for details. 

BR, YK

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Tuesday, November 10, 2009 10:45 PM
> To: 'Ye-Kui Wang'; Roni Even; Tom kristensen; Randell Jesup
> Cc: [email-masked]
> Subject: Comments on draft-ietf-avt-rtp-rfc3984bis-08.txt
> 
> Please roll these in with whatever IETF Last Call comments 
> you receive. No immediate action is required.
> 
> 1) Nit: typo, fifth line up from section 5.5 heading: MTAP14 -> MTAP24
> 

Done.

> 2) Section 8 final sentence currently reads:
> 
>    "This
>     uncommon characteristic of the "sprop" parameters may not be
>     compatible with some signaling protocol concepts, in 
> which case the
>     use of these parameters SHOULD be avoided."
> 
> It's not clear whether this is general advice against using 
> "sprop" parameters or advice against using them in cases 
> where they are incompatible with the normal signalling protocol usage.
> 

This was from RFC 3984. To avoid confusion, I removed the following
sentences (the one pointed out above and the previous sentence): 

"The media sender selects all "sprop" parameters rather than the receiver.
This uncommon characteristic of the "sprop" parameters may not be compatible
with some signaling protocol concepts, in which case the use of these
parameters SHOULD be avoided."

> 3) This sentence near the beginning of section 8.1 seems to 
> belong in a section on signalling rather than a media type 
> registration:
> 
> "The receiver MUST ignore any unspecified parameter."
> 
> (I also find "unspecified" ambiguous: unspecified in this 
> document or unspecified where?)

Updated to "The receiver MUST ignore any parameter unspecified in this
memo." and moved to the beginning of section 8.2.

> 
> 4) Section 8.1, profile-level-id, second paragraph. I can 
> make sense of this only if I read it as an overly compressed 
> attempt to specify the significance of the parameter for the 
> receiver separately from the sender. I suggest it be deleted, 
> because the necessary concepts are well-presented further down.
> 

This paragarph gives an introduction of what is default sub-profile and what
is default level. Text below describes how these two are indicated by the
value of profile-level-id. Therefore, I think it should be kept. 

> 5) Section 8.1, profile-level-id, paragraph beginning: "If 
> the profile-level-id parameter is used to indicate properties 
> of a NAL unit stream, ...":
> 
> Doesn't the default level indicate the highest rather than 
> lowest level that has to be supported?
> 

No, it indicates the minimum. A decoder with higher capability can also be
used.

> Just above that paragraph: typo: "confirming" -> "conforming".

Done.

> 
> 6) Section 8.1, packetization-mode: there is a normative 
> reference to RFC3894, but this document obsoletes RFC3984. 
> Can this be an internal reference instead?
> Check whether any other such references exist.
> 

Great point. There are serveral other places. Removed or made as internal
references. 

> Tom Taylor