Re: [dhcwg] Interface
Ralph Droms <rdroms@cisco.com> Wed, 10 October 2001 21:39 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 RAA21756; Wed, 10 Oct 2001 17:39:11 -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 RAA02313; Wed, 10 Oct 2001 17:38:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02288 for <dhcwg@optimus.ietf.org>; Wed, 10 Oct 2001 17:38:03 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21730 for <dhcwg@ietf.org>; Wed, 10 Oct 2001 17:38:01 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-182.cisco.com [10.82.224.182]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA22386 for <dhcwg@ietf.org>; Wed, 10 Oct 2001 17:37:33 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010173146.00bb4d80@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 17:36:46 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Interface
In-Reply-To: <Roam.SIMC.2.0.6.1001060816.11273.nordmark@bebop.france>
References: <"Your message with ID" <200109210524.f8L5Ovt00458@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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
Erik - I was about to make a change to the DHCPv6 spec based on this thread, when I realized I don't understand what the proposed text means. You wrote: 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. Do you mean: The client MUST send the message on an interface that will cause the message to be delivered to the agent through the link to which the interface the client is trying to obtain configuration information for is attached. The client SHOULD send the message through the interface for which the client is trying to obtain configuration information. The client MAY send the message through another interface if the client has multiple interfaces on the same link. - Ralph At 10:26 AM 9/21/2001 +0200, Erik Nordmark wrote: > > > > 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Interface Guja, ArturX
- RE: [dhcwg] Interface Bernie Volz (EUD)
- RE: [dhcwg] Interface Erik Nordmark
- RE: [dhcwg] Interface Bernie Volz (EUD)
- Re: [dhcwg] Interface Ted Lemon
- Re: [dhcwg] Interface Erik Nordmark
- Re: [dhcwg] Interface Ted Lemon
- Re: [dhcwg] Interface Erik Nordmark
- RE: [dhcwg] Interface Bernie Volz (EUD)
- Re: [dhcwg] Interface Ted Lemon
- RE: [dhcwg] Interface Erik Nordmark
- Re: [dhcwg] Interface Erik Nordmark
- Re: [dhcwg] Interface Ted Lemon
- [dhcwg] Incorporation of WG last call comments in… Bernard Aboba
- Re: [dhcwg] Incorporation of WG last call comment… Thomas Narten
- Re: [dhcwg] Incorporation of WG last call comment… Bernard Aboba
- Re: [dhcwg] Incorporation of WG last call comment… Ralph Droms
- Re: [dhcwg] Incorporation of WG last call comment… Thomas Narten
- Re: [dhcwg] Incorporation of WG last call comment… Bernard Aboba
- Re: [dhcwg] Incorporation of WG last call comment… Ralph Droms
- Re: [dhcwg] Interface Ralph Droms
- Re: [dhcwg] Interface Ralph Droms
- Re: [dhcwg] Interface Erik Nordmark
- Re: [dhcwg] Interface Ted Lemon
- Re: [dhcwg] Interface Ralph Droms