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>