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

[Cullen Jennings <[e-mail]>]

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>