Re: [dhcwg] Interface

Erik Nordmark <> Thu, 20 September 2001 17:25 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA16688; Thu, 20 Sep 2001 13:25:07 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id NAA04007; Thu, 20 Sep 2001 13:16:52 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id NAA03984 for <>; Thu, 20 Sep 2001 13:16:50 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM []) by (8.9.1a/8.9.1a) with ESMTP id NAA16359 for <>; Thu, 20 Sep 2001 13:16:47 -0400 (EDT)
Received: from bebop.France.Sun.COM ([]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26335; Thu, 20 Sep 2001 10:16:02 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM []) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8KHFsg09599; Thu, 20 Sep 2001 19:15:55 +0200 (MET DST)
Date: Thu, 20 Sep 2001 19:11:37 +0200 (CEST)
From: Erik Nordmark <>
Reply-To: Erik Nordmark <>
Subject: Re: [dhcwg] Interface
To: Ted Lemon <>
Cc: Erik Nordmark <>, "Bernie Volz (EUD)" <>, "'Guja, ArturX'" <>,
In-Reply-To: "Your message with ID" <>
Message-ID: <Roam.SIMC.>
MIME-Version: 1.0
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

> > But that's beside the point - which is to not overconstrain the spec 
> > with MUSTs that aren't quite true.
> The point is to come up with a working, implementable protocol
> definition, that does not only work if you happen to be running
> 802.3ad in a certain obscure implementation.


the tone of your statement reads like an attack on a particular unnamed 
implementation.  I certainly did not describe an existing implementation -
in fact I have no idea whether there exists an IEEE 802.3ad that does what
I described. (And the whole mention about implementation was in response to
a question whether there was an automatic way for hosts to determine that
multiple interfaces are connected to the same link.) Sigh :-(

What I did point out is that the IPv6 architecture allows multiple interfaces
connected to the same link. That is the real issue.

> Most implementors will not run into the corner case you've just
> described, but those same implementors have a pretty good chance of
> producing a non-interoperable client implementation if that MUST isn't
> there.  In the corner case you've described, unless I am very much
> mistaken, the MUST will _not_ cause a problem.  So the MUST should
> stay.

I don't think MUSTs are intended to prescribe rules for a subset of
the implementations - their original use was to describe (often subtle)
things that implementors had overlooked in the past that caused rather bad
things to the network (such a broadcast storms).
Today MUSTs are used to make firm statements for behavior
that applies to all implementations.

So you seem to be describing a case where a SHOULD applies. RFC 2119:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Alternatively text along the lines of this makes sense
	"... MUST (unless where the client has multiple interfaces connected to
	the same link [SCOPING-ARCH] in which case the ... MUST be for one
	of the interfaces connected to the same link) ..."


dhcwg mailing list