Re: WG ACTION: 2 weeks to discuss [LL60] Forward reference style

Robert Elz <[email protected]> Sat, 08 May 2004 02:24:15 +0700
Newsgroups gmane.ietf.zeroconf
Message-ID <[email protected]>
    Date:        Thu, 6 May 2004 22:52:08 -0700
    From:        Stuart Cheshire <[email protected]>
    Message-ID:  <[email protected]>

  | What possible reason would we have to NOT make an RFC as clear and 
  | understandable as possible?

None.   And if you had raised some of you points when the doc was
being debated, I'd be agreeing with more of them - even if it had been
done during the last call.   But that isn't what happened.   Now it
just looks like an attempt to delay a doc that you don't really like for
as long as possible in the hopes that it will end up being so late as
to be useless.   Much better to publish what we have now.  If necessary
after experience with it, a clearer doc can be made part of advancing
this from PS to DS (or whatever the standards process migrates into,
assuming that it may eventually alter).

That said, I actually don't agree that putting const definitions at the
front makes the text easier to understand.   For me, it makes it harder.
When I see a bunch of definitions like that, I immediately find myself
jumping to conclusions about how they're going to be used, and inventing
my own imaginary protocol to use the things as I have dreamed them.
That then makes actually understanding what is written harder, as I'm
constantly prejudiced by my earlier imaginings about how the whole thing
is going to work.

So, even if there was some desire to make things better, and some text
was going to be changed, the very most I'd want would be a forward
reference in the introduction - something along the lines of "Symbolic
constants will be used throughout this document, to determine the
values of those constants, refer to section 9".

And then, when I read the doc, initially (not actually doing an
implementation) I avoid looking forward at the values, as 99% of the
time, knowing the actual numbers helps with nothing (short of
implementing it).

But at this stage in the processing of this doc, I don't want even that.

kre