Subject: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable

From: Erik Guttman <[email-masked]>
Date: Wed, 5 May 2004 01:23:25 +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.

[ll68]

Description of Issue:		Stress constants are not user configurable
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]:	s
Section:			all
Rationale/Explanation:
Lengthy Description:

[Stuart]

Also, we need to stress that these are MUST NOT be user-configurable
options, or the users will just decide they can set them to zero to "make
it go faster".

[Erik]

No user configurable options are mentioned in the text.  I do not
understand what you mean by 'set them to zero.'  What settings are you
referring to?

[Stuart]

When you use symbolic identifiers in place of concrete values it implies
abstraction (Generalisation; ignoring or hiding details to capture some
kind of commonality between different instances), which implies therefore
that there are different instances with different values for those
abstracted identifiers.

If the intention is that different instances will have different values
for these symbolic identifiers, then the draft should say so.

If the intention is that different instances will have NOT different
values for these symbolic identifiers, then the draft should say so.

I'm just asking for clarification.

[Erik]

The reasons we are using constants are
     * The WG called for it, primarily
     * There has been an interest in specifying new sets of
       constants 'in the future' for specific link layers which
       might call for different timing
     * Use of constants instead of values in the text is considered
       absolutely necessary by many technical reviewers, for clarity
       and style consistent with other IETF published technical
       documentation.
     * Use of a constant term assures the assignment of the term will
       be in one authoritative place.  This improves the overall
       consistency of the document and improves ease of reference.
       In this respect technical writing parallels acceptable program
       coding practice.

Requested Change:

TEXT NEEDED

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 May 2004 08:05:02 +0700

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

  | [Stuart]
  | 
  | Also, we need to stress that these are MUST NOT be user-configurable
  | options, or the users will just decide they can set them to zero to "make
  | it go faster".

This is just plain silly.   Nothing suggests that anything is user
configurable.   That said, if the users demand to be able to configure
any of these numbers, the implementations will make them configurable,
whatever the text says.

No change is needed here.

kre

---

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

I do not support the proposed change.

I am quite happy with the current text. The use of protocol constants in the way we have done is commonplace and this is a protocol specification, not a guide for dummies.

Philip

---

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

On 5/7/04 7:32 AM, "Philip Nye" <[email-masked]> wrote:

> I am quite happy with the current text. The use of protocol constants in the
> way we have done is commonplace and this is a protocol specification, not a
> guide for dummies.

Would it not then behoove us to eliminate ambiguity wherever possible? Ego
about "this is not a guide for dummies" set aside, ambiguity about standards
has cause problems before. For an example, see "The Great Microsoft Kerberos
Scandal."

Clarity is always preferable to ambiguity.

john

--------------------------------------------------------
      Misquotation of unattributed, trite
        metaphysical saying goes here.

  Stupid ascii               Unnecessary notice of
graphic goes here.        responsibility goes here.
---------------------------------------------------------