Re: [dhcwg] Interface

[Ralph Droms <[e-mail]>]

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
>>[e-mail]
>>http://www1.ietf.org/mailman/listinfo/dhcwg
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>http://www1.ietf.org/mailman/listinfo/dhcwg


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