Subject: WG action - 1 week to discuss [LL7] Add warnings to applicability statement

From: Erik Guttman <[email-masked]>
Date: Sat, 8 Feb 2003 17:40:45 +0100 (CET)

Please see http://www.spybeam.org/ll10.html

This does not seem to be particularly controversial.  A consensus call
on discussion will occur 15 Feb 2003.

Erik, as you were the one who raised the comment in the IESG last call
of draft-ietf-zeroconf-ipv4-linklocal-07.txt, could you please confirm
that the wording of this issue is appropriate?

Thanks,

Erik

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 16:58:40 +0700

Date:        Sat, 8 Feb 2003 17:40:45 +0100 (CET)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <Pine.SOL.3.96.1030208173655.27529D-100000@field>

  | This does not seem to be particularly controversial.  A consensus call
  | on discussion will occur 15 Feb 2003.

Just one point...

The proposed solution to this issue was to point out that the text
already says (in section 1.4)

	Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
	manually

It might be worth adding text making it clear that this means that
people shouldn't go and (attempt to) assign 169.254.3.17 to some host.
On the other hand, it does not mean that people should not be able
to explicitly (manually) configure a node to run the LL assignment
algorithm and have a LL address assigned.

I think to fix this, it would be sufficient to have the note included
above changed to read

	Note that specific addresses in the 169.254/16 ...

(or s/specific/particular/ or something).

A aide issue might be to explicitly assign one (or both) of the
currently unused fragments of address space (169.254.0/24 and 169.254.255/24)
for manual assignment, so should someone turn up to an ad-hoc network,
where LL addresses (and only LL addresses) are in use, they can actually
configure themselves one on a system which is too old to implement LL
addresses.   I know that they could just as easily manually configure
10.1.2.3 and that should work along with appropriate other configuration,
but that's harder to explain to people how to do, and why it will work.
(Future nodes, that know about LL addressing, should be able to handle the
"appropriate extra configuration" automatically, even if the node has no
LL address, but old "legacy" systems aren't going to do that).

How they figure out which address to configure from a range set aside for
this purpose would be beyond the scope of this document - but that's not
a problem, for people with legacy systems connecting to an ad-hoc net with
no address assignment management have to handle that, one way or another,
already.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 09 Feb 2003 12:51:05 +0200

> 	Note that addresses in the 169.254/16 prefix SHOULD NOT be configured

Incidentally I think the text in 1.4:

"Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
manually or by a DHCP server."

Should be clarified to:

"Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
manually, by a DHCP server, or by any mechanism other than the one
described in this document."

The plugs a perceived loop hole regarding address configuration methods
other than v4LL, DHCP, or manual configuration.

Can we do this as part of LL7 or should I file another issue?

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Sun, 9 Feb 2003 14:19:48 +0100 (CET)

<text omitted> 
> Can we do this as part of LL7 or should I file another issue?

This is part of the discussion of LL7.  As long as we are all pulling on
the same rope, we'll hone the text, agree, Accept and close the issue.  

If we have contention, we have five possible avenues - in descending
order of preference. 

 1.  There is a clear technical answer.  Dissenters are dismissed.

 2.  There is no clear technical answer.  One group overwhelms the
     other.  We go with rough consensus.  This is for yes/no questions.

     NOTE:  We try to deal with each issue as a yes/no issue first since
     it is much easier to understand this and conclude discussion.

 3.  The dissenter posts a competing issue.  We choose the group with
     overwhelming support.  This is for multiple choice questions.

 4.  We have a split we cannot overcome and even make a rough 
     consenus call.  Can we drop the goal, accomodate or compromise?

 5.  We have a split, with no rough consensus possible.  We fail.
     Throw up our hands and let a thousand mutant flowers blossom.

Comments?

Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Feb 2003 09:57:37 +0100 (CET)

> that the wording of this issue is appropriate?

I'm confused whether the suggestion is to be applied to section 1.2
or section 7 since the web page seems to say both.
The information needs to be up front in the document and not hidden in the
back.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 11:59:19 -0500

> The plugs a perceived loop hole regarding address configuration
> methods other than v4LL, DHCP, or manual configuration.

You want to clearly distinguish between requirements on protocol
implementations and expectations of users or network operators. And
SHOULD NOT has a specific meaning that is intended to specify
implementation requirements.  Thus it's fine to say

  Addresses in the range 169.254/16 are reserved for use as link-local
  addresses that are allocated and configured according to this
  specification or subsequent revisions.  Under normal conditions, users
  should not assign manually configure interfaces with such addresses,
  nor should DHCP servers be configured to return such addresses.

But you should not use the SHOULD NOT language unless you want to impose
constraints on protocol implementations, e.g.

- DHCP servers SHOULD NOT accept a configuration directing them to
  assign such addresses to hosts, or

- Hosts SHOULD NOT accept manual configuration of interfaces using
  addresses in this range

...neither of which I would find desirable.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 20:53:38 +0200

>   nor should DHCP servers be configured to return such addresses.

It would be good to make clear that this concerns *all* manual
configuration of LL addresses:

Addresses in the range 169.254/16 are reserved for use as link-local
addresses that are allocated and configured according to this
specification or subsequent revisions.  Under normal conditions, users
should not manually configure interfaces with such addresses, nor should
DHCP servers or any other address allocation mechanisms be configured to
return such addresses.

> constraints on protocol implementations, e.g.

Good point.

	MikaL