Re: [dhcwg] Interface

Erik Nordmark <Erik.Nordmark@eng.sun.com> Thu, 20 September 2001 17:25 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16688; Thu, 20 Sep 2001 13:25:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04007; Thu, 20 Sep 2001 13:16:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03984 for <dhcwg@optimus.ietf.org>; Thu, 20 Sep 2001 13:16:50 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16359 for <dhcwg@ietf.org>; Thu, 20 Sep 2001 13:16:47 -0400 (EDT)
Received: from bebop.France.Sun.COM ([129.157.179.15]) 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 [129.150.133.11]) 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 <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [dhcwg] Interface
To: Ted Lemon <mellon@nominum.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, "'Guja, ArturX'" <ArturX.Guja@intel.com>, dhcwg@ietf.org
In-Reply-To: "Your message with ID" <200109201541.f8KFfcN02244@grosse.bisbee.fugue.com>
Message-ID: <Roam.SIMC.2.0.6.1001005897.27649.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> 
> > 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.

Ted,

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) ..."

  Erik


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg