Skip to main content

RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs
RFC 7310

Discuss


Yes

(Richard Barnes)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
(Stewart Bryant)

Note: This ballot was opened for revision 04 and is now closed.

Sean Turner Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2013-12-18 for -04)
I hate to be that guy but I gotta ask .... 

Normally when we're defining a company specific thing we put the name of that company in the title to make it clear it's their "thing".  Here the authors don't work for that company - how's this supposed to work?  And, shouldn't this be in the vnd space?
Richard Barnes Former IESG member
Yes
Yes (for -04)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -04)

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-12-19 for -04)
I share my colleagues' uncertainty with some of what's in this document.  It disturbs me to see text such as this in a Standards Track document (from the first paragraph of Section 3):

   Standard apt-X and Enhanced apt-X are proprietary audio coding
   algorithms, which can be licensed from CSR plc. and are widely 
   deployed in a variety of audio processing equipment.  
   For commercial reasons, the detailed internal operations of these 
   algorithms are not described in standards or reference documents.

And at the end of Section 3, the address to whom we can write, presumably to buy software that does apt-X....

That said, the rest of the document does appear to provide a technical specification that the working group wants to publish.  I'm going to let my colleagues' DISCUSS positions cover things, and ballot No Objection.
Benoît Claise Former IESG member
No Objection
No Objection (for -04)

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -04)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-12-18 for -04)
I take it on the basis that there is no IPR disclosure that there is no IPR contained in section 3.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04)

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04)

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04)

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2014-05-09)
I had a discuss that said:

"I don't understand how section 3 does not have
an accompanying IPR declaration. Nor do I get
how this helps interoperability if the codec
details themselves are not openly specified.
And the section ends with an advertisement.
Did the WG discuss those issues?"

The WG had discussed it so I'm clearing, 
but it'd be better if in future the IPR stuff
was made more clear IMO so I hope the 
WG consider that if/when they process 
other similar codecs. I just mean getting an
IPR declaration so the IETF LC has more
clarity on what's going on, and note that I
am not saying that this is required by our
process, (I'm not sure) but it'd still be overall 
better.
Stewart Bryant Former IESG member
No Objection
No Objection (for -04)