Subject: WG ACTION: 2 weeks to discuss [LL69] Move constants to beginning of doc

From: Erik Guttman <[email-masked]>
Date: Wed, 5 May 2004 01:24:53 +0200

Please post discussion of this issue to the mailing list over the 
next two weeks
ending May 18, 2004.  In order to accept this issued, we will need a strong WG
consensus given that this is very late in the process.

Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of
current issues and their status.

[LL69]

Description of Issue:		Move constants to beginning of doc
Submitter Name:                 Stuart Cheshire
Submitter Email Address:        [email-masked]
Date first submitted:           04 May 04
Reference:
Comment Type ['t'ech|'e'dit]:	e
Prio ['S' Must|1 should|2 may]:	1
Section:			9
Rationale/Explanation:
Lengthy Description:

[Stuart]

>9.  Constants
>
>    The following timing constants are used in this protocol.
>
>    PROBE_MIN              1 second
>    PROBE_MAX              2 seconds
>    PROBE_N                2
>    NUM_PROBES             3
>    MAX_COLLISIONS        10
>    RATE_LIMIT_INTERVAL   60 seconds

Can we list this *before* they are used in the text?

Abstractions are great for experts, but not for people learning. Think
about children. They learn specific examples first, and then from a
collection of specific examples generalize to abstractions. Beginning
with the abstract is not the way to inform the reader.

[Erik]

Listing constants early in the RFC is not common practice.  Constants
are not abstractions.

[Stuart]

Using a symbolic identifier in place of a concrete value is not
abstraction?

Since when?

>abB7stracB7tion B B   B PB B B Pronunciation KeyB B (b-strkshn, b-)
>ignoring or hiding details

>  1. Generalisation; ignoring or hiding details to capture some
>  kind of commonality between different instances. Examples are
>  abstract data types (the representation details are hidden),
>  abstract syntax (the details of the concrete syntax are
>  ignored), abstract interpretation (details are ignored to
>  analyse specific properties).
>
>  2. <programming> Parameterisation, making something a function
>  of something else. Examples are lambda abstractions (making
>  a term into a function of some variable), higher-order
>  functions (parameters are functions), bracket abstraction
>  (making a term into a function of a variable).

Requested Change:

Move Section 9 to the beginning of the document, say to terminology.

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 May 2004 07:54:49 +0700

Date:        Wed, 5 May 2004 01:24:53 +0200
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <a05200f06bcbdce5fe223@[80.139.178.51]>

  | Abstractions are great for experts, but not for people learning.

RFCs are for implementors, not for people learning.   Implementors, if
not necessarily experts, should at least be competent.  If someone wants
to publish a book "IPv4 link local addresses for morons" (or whatever)
then they can do it in a way which manes it easy for beginners to
learn the protocol.   The RFC doesn't need to do that.

Reject this (and other similar) change requests (there was at least
one more that was just like this one).

kre

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 May 2004 12:34:19 -0000

I do not support the proposed change. The current usage and placement of constants is fine.

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 May 2004 08:56:33 -0500

> Can we list this *before* they are used in the text?

I support this. Regardless of how other RFCs do this, it is far more
sensible to define constants and other RFC specific terms prior to their
use. Again, this is not catering to the lowest common denominator, but
rather giving the people who will use this RFC more clarity in the terms
used by the RFC.

john 

-- 
"I think love is a snowmobile racing across the arctic tundra which suddenly
flips, pinning you underneath.  At night, the ice-weasels come...."

Matt Groening

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 May 2004 09:10:48 -0500

> Using a symbolic identifier in place of a concrete value is not

I support this. It's far better practice to define terms prior to use.

john

-- 
"Keecking butt fahr gudness"
Baldur's Gate