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

[Elwyn Davies <[e-mail]>]

On Mon, 2012-05-14 at 17:08 -0600, Cullen Jennings wrote:
> 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. 
> 
Not sure I would say 'it was my pleasure' but it certainly taught me a
thing or two!

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

I don't have a problem with this in principle: however as a reviewer I
get this nagging feeling that on a few days acquaintance, its impossible
to demonstrate that the text accurately, albeit non-normatively
describes the code.  And that makes me feel I have done a half job.
However, I also know that starting from scratch it would take me several
months to get anywhere near an accurate view (I know from considerable
experience with the DTN2 reference implementation and years ago the
source code of yacc - now that ages me!) 

If the wg, doc shepherd and the IESG are happy that the mapping is near
enough, so be it.  And, sorry, I didn't look at RFC 6569 during my
review.. probably shoyuld have done.

Regards,
Elwyn
> 
> 
> 
> 
> 
> 
>