RE: WG ACTION: 2 weeks to discuss [LL53] Forward references requested

I have no objection to the suggestion to move
the parameters definition to the front of the
document.

Even if it is left in section 9, I think Stuart
has done a fine job with his proposed text.  It
addresses all of my original concerns about
parameterization and probing intervals.

One minor exception, I think the sentence that
begins, "An important part of creating interoperable
products..." is a bit preachy.

					-Alex

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Stuart Cheshire
> Sent: Friday, May 07, 2004 12:39 AM
> To: [email protected]
> Subject: Re: WG ACTION: 2 weeks to discuss [LL53] Forward references
> requested
> 
> 
> >     Personally I slightly prefer A.  If you have an alternative
> >     proposal, please send text.
> 
> What I suggest is:
> 
> 1. List the constants, with a brief explanation, and give the 
> value. The 
> brief explanation doesn't have to duplicate the full 
> explanation which 
> appears later -- just enough to demystify an otherwise opaque name.
> 
> 2. State the technologies that may use other values.
> 
> e.g.
> 
> Section 1.3 "Constants"
> 
>    The following constants are defined here and referenced later in
>    this document.
> 
>    START_WAIT           1 second   (initial random delay)
>    PROBE_NUM            3          (number of probe packets)
>    PROBE_INTERVAL       1 second   (time between probe packets)
>    ANNOUNCE_NUM         2          (number of announcement packets)
>    ANNOUNCE_INTERVAL    2 seconds  (time between announcement packets)
>    RATE_LIMIT_NUM      10          (max collisions before 
> rate limiting)
>    RATE_LIMIT_INTERVAL 60 seconds  (delay between successive attempts)
>    DEFEND_INTERVAL     10 seconds  (minimum time between 
> defensive ARPs)
> 
>    These values are fixed for all implementations conforming to this
>    standard. They MUST NOT be end-user configurable options, 
> nor should
>    the listing of the values here be taken to imply that each
>    implementer is free to substitute other values instead, 
> based on what
>    they think will suit each device best. An important part 
> of creating
>    interoperable products is being able to depend on predictable
>    behaviour from the other products you're interoperating with, and
>    having arbitrary variation between different implementations would
>    significantly undermine that ability.
> 
>    Future standards documents, extending IPv4 Link-Local Addressing to
>    media types other than those covered in this document, may specify
>    different values for these constants.
> 
> Section 1.4 "Applicability"
> 
>    ...
> 
>    Link-layer technologies that support ARP but operate at 
> rates below 1
>    Mbps or latencies above one second may need to specify different
>    values for the constants listed in Section 1.3.
> 
> [delete the a/b/c/d list]
> 
> Stuart Cheshire <[email protected]>
>  * Wizard Without Portfolio, Apple Computer, Inc.
>  * www.stuartcheshire.org
> 
>