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