Subject: Re: [dhcwg] Interface

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2001 17:36:46 -0400

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
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2001 22:03:24 -0400

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Oct 2001 22:19:47 +0200 (CEST)

> through another interface if the client has multiple interfaces

Yes, that was what I was trying to say.

I think it might make sense to make the last sentence stronger by
saying
 The client MAY send the message
 through another interface attached to the same link if and only if the client
 is certain that the two interfaces are attached to the same link.

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Oct 2001 16:37:18 -0400

>  is certain that the two interfaces are attached to the same link.

I think this is the right way to express it.

				_MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Oct 2001 16:57:16 -0400

Following up on Erik's comments...

So, what I wrote in the -20d rev turns out to be (I did some last minute 
wordsmithing that [may or may not have] improved the readability:

    The Confirm message MUST be transmitted on the link that the
    interface for which configuration information is being obtained
    is attached to.  The client SHOULD send the message through that
    interface.  If the client has multiple interfaces attached to the
    same link, the client MAY choose to send the message through another
    interface attached to that link.

and (for those messages that might be unicast):

    If the client multicasts the Request message, the message MUST be
    transmitted on the link that the interface for which configuration
    information is being obtained is attached to.  The client SHOULD
    send the message through that interface.  If the client has multiple
    interfaces attached to the same link, the client MAY choose to send
    the message through another interface attached to that link.

I will substitute Erik's suggested replacement for the last sentence:

The client MAY send the message through another interface attached
to the same link if and only if the client is certain that the two
interfaces are attached to the same link.

- Ralph