Subject: Oppose: LL24 Weaken the PRN generated address requirement from MUST to MAY

From: Stuart Cheshire <[email-masked]>
Date: Mon, 3 Mar 2003 22:28:19 -0800

I see no compelling arguments to support LL24.

The term "pseudo-random number generator" is already sufficiently vague 
as to allow implementers significant leeway in what algorithm they choose.

The important point, as explained by others, is that different hosts MUST 
NOT get stuck in lock-step suffering an unending series of conflicts.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 4 Mar 2003 08:27:42 -0800

Stuart, I think you are right in that the definition of PRN is vague
enough
to include any algorithm. A sentence to reflect that in the draft would
be
appropriate, what do you think ?

Subrata

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stuart Cheshire
> Sent: Monday, March 03, 2003 10:28 PM
> To: [email-masked]
> Subject: Oppose: LL24 Weaken the PRN generated address 
> requirement from MUST to MAY
> 
>

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 4 Mar 2003 08:28:27 -0800

The following is a brief description of another algorithm, distributed,
to generate a unique LLv4 address among other things. It makes use of
the broadcast address 169.254.0.255. The algorithm goes as follows.

1. Any LL node, LLn1, that wants an LLv4 address sends out an REQUEST
packet (exact details of this packet is glossed over at this point) on
the link with source/destination address as 0.0.0.0/169.254.0.255.  The
REQUEST packet contains a  request for the receiver to respond with its
LLv4 address.

2. All the nodes with LLv4 address on the link that receives the REQUEST
packet responds with a RESPONSE packet. The RESPONSE packet has
source/destination address as 169.254.x.x/169.254.0.255, where
169.254.x.x is the LLv4 address of the receiving node.

3. The node, LLn1, then picks an LLv4 address that it has not received a
response from.

The algorithm  is skeletal at this point (and also there is the
scalability problem we discussed before in a different context).  

Subrata

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 4 Mar 2003 08:33:39 -0800

Subrata

---

From: Erik Guttman <[email-masked]>
Date: Tue, 04 Mar 2003 18:54:57 +0100

Subrata,

A distributed counter algorithm is a 'good idea' (perhaps), but
what IESG comment does it address?  What burning problem does
it solve?

Remember - this process of issue resolution is not an avenue
to bring new 'good ideas' to the table.  The bar is high.  It
is not enough to show that a new idea may have merit, sort of.
You must show that if we do not accept this as a problem, and
the suggested text as its solution - we will be asking the IESG
to advance a broken protocol specification.  You must get something
like consensus support for the initiative, too.

Erik

------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 17:34:26 +0700

Date:        Tue, 04 Mar 2003 18:54:57 +0100
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | A distributed counter algorithm is a 'good idea' (perhaps), but
  | what IESG comment does it address?  What burning problem does
  | it solve?

Erik, I'd suggest abandoning that approach.   This doc is clearly getting
enough revisions done to it, that it is going to need another WG last call,
and then IETF last call (if it got as far as one of those before).

While it would, I'm sure, be annoying to simply revisit ever decision that
has ever been made, closing off all new suggestions isn't a good thing to
do.

If someone makes a suggestion, and you rule it out of order, as not
being a response to an IESG comment, or not solving something currently
considered to be a burning question, you're simply inviting IETF last
call arguments.   If, at that stage, someone can say "the suggestion X
was not considered by the working group" then the IESG should return the
doc to the WG to have the suggestion considered.

If to that you (the WG) can reply "the suggestion was considered, and
rejected" then all is fine.   But if the answer is "we didn't want to
look at that, it was too late", then the WG will have a problem.  It
is not yet too late for anything at all.

If whatever the issue is isn't considered useful by the WG, then it can
quickly be disposed of, without being ruled out of order.

kre

---

From: Erik Guttman <[email-masked]>
Date: Thu, 6 Mar 2003 09:04:28 +0100 (CET)

Robert,

> quickly be disposed of, without being ruled out of order.

What you say is true enough for the charter we currently have for the
ZEROCONF WG.  I would like to be clear though:  At this time we (WG
chair, IESG) have no intention in broadening the work items or work load
of the ZEROCONF WG.  For this reason, I am vigorously pushing back on
work items which seem peripheral to our central task.  We will
discuss and decide what to do as a WG, as you suggest, within the
bounds of our inelastic scope.

Erik