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

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 15 Sep 2015 11:59:11 -0700

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."
      
-- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random
values?

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Sep 2015 22:56:00 +0200

Quick comment:

> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/

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

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.

> use of max-fs and max-fr should appear somewhere other than the media

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Tue, 22 Sep 2015 12:30:12 -0400

Hi everyone,

There were some outstanding editorial changes that were suggested prior to
the last WG meeting that are addressed by this draft.  Mostly the term
"rate" has been replace by "bitrate", "bit-rate" or "bit rate" as
appropriate.  This is most relevant to SDP's conveyance of the speech
coder's operating rate (its bit rate).

Please let me know if other changes or clarifications would be helpful.  As
per the discussion at the last WG, we would like the chairs to ask for
permission to adopt as a WG draft and advance toward an RFC.

Thank you.

Victor Demjanenko
David Satterlee

BTW, there is a draft-demjanenko-payload-melp-00.txt which is intentionally
allowed to expire.  There was a mismatch in names (melp vs melpe) which
caused this inconsistency.  No information is lost by the expiring draft.
draft-demjanenko-payload-melpe-04.txt is our latest and most complete
document.