Re: [dhcwg] Interface

Ralph Droms <rdroms@cisco.com> Thu, 11 October 2001 02:03 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 WAA25591; Wed, 10 Oct 2001 22:03:06 -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 WAA10333; Wed, 10 Oct 2001 22:02:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10314 for <dhcwg@optimus.ietf.org>; Wed, 10 Oct 2001 22:02:34 -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 WAA25588 for <dhcwg@ietf.org>; Wed, 10 Oct 2001 22:02:31 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-17.cisco.com [10.82.224.17]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA09784; Wed, 10 Oct 2001 22:02:02 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010220208.00ba5458@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 22:03:24 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Interface
Cc: dhcwg@ietf.org
In-Reply-To: <4.3.2.7.2.20011010173146.00bb4d80@funnel.cisco.com>
References: <Roam.SIMC.2.0.6.1001060816.11273.nordmark@bebop.france> <"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

I made changes in the -20d rev of the DHCPv6 spec based on my 
interpretation of Erik Nordmark's text.  If that interpretation turns out 
to be wrong, I'll fix it...

- Ralph


At 05:36 PM 10/10/2001 -0400, Ralph Droms wrote:
>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 mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg