RE: [dhcwg] Interface

["Bernie Volz (EUD)" <[e-mail]>]

Perhaps I'm confused, but don't we have an issue that we should attempt to resolve when a client has multiple interfaces to the same link?

A client may not know this.

I believe IAs should be client specific, not interface specific. But, that still doesn't solve the problem because hows does the server know that there are two interfaces on that client? (Instead of treating all IAs to belong to the first interface.) This could lead to significant problems if we allow a server to tell a client all of the IAs for that client on that link (in an Advertise, for example).

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:[e-mail]]
Sent: Thursday, September 20, 2001 1:12 PM
To: Ted Lemon
Cc: Erik Nordmark; Bernie Volz (EUD); 'Guja, ArturX'; [e-mail]
Subject: Re: [dhcwg] Interface 


> 
> > But that's beside the point - which is to not overconstrain the spec 
> > with MUSTs that aren't quite true.
> 
> The point is to come up with a working, implementable protocol
> definition, that does not only work if you happen to be running
> 802.3ad in a certain obscure implementation.

Ted,

the tone of your statement reads like an attack on a particular unnamed 
implementation.  I certainly did not describe an existing implementation -
in fact I have no idea whether there exists an IEEE 802.3ad that does what
I described. (And the whole mention about implementation was in response to
a question whether there was an automatic way for hosts to determine that
multiple interfaces are connected to the same link.) Sigh :-(

What I did point out is that the IPv6 architecture allows multiple interfaces
connected to the same link. That is the real issue.

> Most implementors will not run into the corner case you've just
> described, but those same implementors have a pretty good chance of
> producing a non-interoperable client implementation if that MUST isn't
> there.  In the corner case you've described, unless I am very much
> mistaken, the MUST will _not_ cause a problem.  So the MUST should
> stay.

I don't think MUSTs are intended to prescribe rules for a subset of
the implementations - their original use was to describe (often subtle)
things that implementors had overlooked in the past that caused rather bad
things to the network (such a broadcast storms).
Today MUSTs are used to make firm statements for behavior
that applies to all implementations.

So you seem to be describing a case where a SHOULD applies. RFC 2119:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Alternatively text along the lines of this makes sense
	"... MUST (unless where the client has multiple interfaces connected to
	the same link [SCOPING-ARCH] in which case the ... MUST be for one
	of the interfaces connected to the same link) ..."

  Erik