IETF Logo Mail Archive

Re: [dhcwg] Interface

Ted Lemon <mellon@nominum.com> Thu, 20 September 2001 15:52 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 LAA13934; Thu, 20 Sep 2001 11:52:01 -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 LAA00994; Thu, 20 Sep 2001 11:51:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00969 for <dhcwg@optimus.ietf.org>; Thu, 20 Sep 2001 11:51:06 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13923 for <dhcwg@ietf.org>; Thu, 20 Sep 2001 11:51:02 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8KFMLv12165; Thu, 20 Sep 2001 08:22:21 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f8KFfcN02244; Thu, 20 Sep 2001 08:41:38 -0700 (MST)
Message-Id: <200109201541.f8KFfcN02244@grosse.bisbee.fugue.com>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
cc: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, "'Guja, ArturX'" <ArturX.Guja@intel.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] Interface
In-Reply-To: Message from Erik Nordmark <Erik.Nordmark@eng.sun.com> of "Thu, 20 Sep 2001 10:18:00 +0200." <Roam.SIMC.2.0.6.1000973880.4738.nordmark@bebop.france>
Date: Thu, 20 Sep 2001 08:41:38 -0700
From: Ted Lemon <mellon@nominum.com>
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.

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.

			       _MelloN_

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

v2.30.2 | Report a Bug | By Email | System Status