Michael,
  I do not understand why you are insisting on SHOULD? If IETF is not 
against having such MUSTs as in this case, let's have it. How can a 
revolutionary technology such as MIPv6 allow HA reverse tunneling like 
MIPv4 does?
  Another benefit will be to mandate HAO in any new implementations. 
Becasue of all these, I think that we should (or MUST) keep the MUST 
there, what the heck?

Regards,

Michael Thomas wrote:

>[EMAIL PROTECTED] writes:
> > > Given that MIPv6 will interoperate without binding
> > > code in CN's, it looks pretty much like a SHOULD
> > > to me. Indeed, the protocol would not be robust if
> > > it didn't consider the case of a non-conformant CN.
> > 
> > I think we want to ask is, is it the right thing to do?  For 
> > proper protocol functioning, will this lead to the correct
> > behavior.  If we think it is important, the MUST is OK.  The
> > spec does contain a mechanism to support existing implementations
> > of IPv6, which means the protocol designers are doing their
> > jobs.
>
>   I think we're straying into a "good" as in
>   "good for the overall health of the Internet"
>   kind of good, rather than a "good" as in will
>   the protocol operate correctly. For the former,
>   I think you need to have extremely compelling
>   motivation, as well as a lot of evidence that
>   the health of the net will be imperiled if *all*
>   nodes don't implement a particular function, which
>   is what is at issue here.
>
>   Frankly, I don't think that there is any evidence
>   that the net would be substantially harmed if RO
>   wasn't widely implemented and/or enabled. Indeed, 
>   I think  there's good reason to believe that many/most
>   nodes will not enable RO even if their kernel
>   implements it. In some cases, it's likely to be
>   a nice and useful optimization, but I really
>   don't see it as a "if we don't do this the net
>   will fall apart". As such, SHOULD seems like it
>   strikes the right balance.
>
>              Mike
>

-- 
Behcet 



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to