Re: [payload] Alissa Cooper's No Objection on draft-ietf-payload-vp8-17: (with COMMENT)

Quick comment:

Den 15. sep. 2015 20:59, skrev Alissa Cooper:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-payload-vp8-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -- 4.2: Little confused as to why the I and L behavior is specified
> twice, e.g.:
> 
> "I: PictureID present.  When set to one, the PictureID MUST be present
>       after the extension bit field and specified as below.  Otherwise,
>       PictureID MUST NOT be present."
> 
> and
> 
> "The PictureID extension:  If the I bit is set to one, the PictureID
>       extension field MUST be present, and MUST NOT be present
>       otherwise."

This was done to make each description complete; it doesn't really make
a substantial difference.

>       
> -- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random
> values?

At one point we wondered if this was a security issue; after consulting
with the people who did the implementation, we concluded that it was
not, but existing code does it this way, and there was no reason to make
the existing deployed base non-conformant.

> -- 6.1: Seconding Pete's old comment that the normative requirements on
> use of max-fs and max-fr should appear somewhere other than the media
> type definition.

I'll just have to respectfully disagree with Pete here; these parameters
were added for use in SDP offer/answer negotiation, they have no
references outside the media type definition, and are only useful within
the context of media configuration, which is only done by using the
media type definition.

I do not see any reason to define these parameters or the requirements
on them outside the media type definition.

(The relationship between RTP payload types and SDP is an interesting
one. These are two completely separate layers of protocol, and in my
opinion the dividing line should be strengthened, not weakened. But this
is an issue that has repercussions far outside the specialized field of
RTP payload definitions, so I would prefer not to go further into that
here.)

Hope this helps!

> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
> 