Re: [dhcwg] Interface

Erik Nordmark <Erik.Nordmark@eng.sun.com> Fri, 21 September 2001 08:33 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 EAA17630; Fri, 21 Sep 2001 04:33:25 -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 EAA07069; Fri, 21 Sep 2001 04:31:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07000 for <dhcwg@optimus.ietf.org>; Fri, 21 Sep 2001 04:31:18 -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 EAA17624 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 04:31:56 -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 BAA24459; Fri, 21 Sep 2001 01:31:16 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8L8VEg28095; Fri, 21 Sep 2001 10:31:14 +0200 (MET DST)
Date: Fri, 21 Sep 2001 10:26:56 +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" <200109210524.f8L5Ovt00458@grosse.bisbee.fugue.com>
Message-ID: <Roam.SIMC.2.0.6.1001060816.11273.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

> 
> I don't know what to say, Erik.   It feels to me like you are trying
> to open the protocol to breakage in order to be pedantic.   What
> matters to me is not the precise wording of RFC2119, but rather
> whether or not the protocol specification we arrive at will result in
> interoperable implementations.
> 
> If we turn this particular MUST into a SHOULD, I promise you that
> there will be interoperability problems.  I speak on the basis of a
> wealth of personal experience with DHCP client implementations.

OK - I sense the equivalent of grade inflation here caused by presumed clueless
implementors. Need to update RFC 2119 with the "REALLY MUST" and "REALLY MUST
NOT" to deal with this :-) :-)

> I argued with you about the particulars because you gave IEEE802.3ad
> as an example of why we need to change this MUST into a SHOULD, and it
> was not a valid example.   So I would really appreciate it if we could
> keep this as a MUST.

No, I did NOT! Please re-read the email thread.
The reason for changing it (or clarifying the constraint) was
draft-ietf-ipngwg-scoping-arch-02.txt.

But I haven't read what the actual text says so this might all be a red
herring. I responded to an email which had an explanation which essentially
said (with significant ad-libbing)
	MUST send on that interface since otherwise the agent will be
	confused.
This statement is incorrect.
But if the statement is instead
	MUST send on that interface to ensure that the packet is guaranteed
	to appear on the correct link (*). If the message appears on the wrong
	link the agent will be confused.
	*) This ensures that the packet arrives on the correct link even
	in the case when a node has multiple interfaces on the same link
	but has incorrect information about which interfaces connect to
	which links.
I think the footnote can be omitted - but it might help future readers to
understand the background.

  Erik


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