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