ietf
[Top] [All Lists]

Re: Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)

2012-05-14 18:09:09

Thank you kindly for the detailed review. More inline ...

On May 14, 2012, at 9:06 AM, Elwyn Davies wrote:

Summary: 
Before offering some views on the document, let me say that this piece
of work seems to be a tour de force on behalf of its developers.  It is
certainly one of the (if not the) most technically complex pieces of
work that has been presented to the IETF,

And I would like to say thank you for the detailed review - having read the 
whole draft several times, I know that ones eyes can start to glaze over on 
what seems like something almost as long as the NFS spec ... so thanks for the 
review. 

I did want to comment on the one major issues 



Major issues: 
Can we accept the code as normative?  If not how do we proceed?

RFC 6569 says that the code needs to be the normative specification so I think 
this issues is pretty much resolved by that RFC. 

As a bit of irrelevant history - this topic was discussed at various stages. If 
was discussed in the chartering process - draft-valin-codec-guidelines referred 
to by the charter said code would be normative. I don't mean by this that the 
charter said the code had to be normative but just that this conversation goes 
back to before the WG was formed. It was later discussed in the WG and resulted 
in WG consensus to having the code as normative. Just as background on a few of 
the reasons that this was decided this way, many people felt that the spec 
would be much longer, and much harder to implement or review if the text was 
normative. Code is a very compact representation of what happens on boundary 
edge conditions and eliminates many types of misinterpretations. I do 
understand normative code introduces other types of issues but it is a fairly 
common practice in specifying codecs to use normative code.

Cullen <Codec Co-Chair>