Subject: RE: [rfc2462bis] whether we need the M/O flags

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 15 Apr 2004 08:49:53 -0400

> As I just said in a separate message, one big question had 
 > been raised
 > about rfc2462bis.  It was, in my understanding, 

=> The question you raise affects 2461 and as a consequence it affects 2462.
FWIW, I really think that there is no point in going round and round again
in this discussion when there is no harm done by keeping them. 
Removing them is not backward compatible for 2461 anyway. 
So I recommend we leave them as defined.

Hesham

 > 
 >   whether we need the M/O flags for the "stateful" protocol(s) in the
 >   first place.
 > 
 > (Actually, different people used different representation related to
 > this issue, but, in my understanding, we can simply summarize the
 > essential part of the question as above).
 > 
 > I know this is probably highly controversial, but I tend to agree on
 > removing (or deprecating) these bits.
 > 
 > The main reasons have already been shown in the thread 
 > starting at the
 > following URL:
 > http://www1.ietf.org/mail-archive/working-groups/ipv6/current
/msg02262.html

One additional point is that I'm not sure if we can really recycle
rfc2462bis as a draft standard with keeping these bits.  If we keep
them, we'll probably need to find running implementations regarding
these bits that are interoperable.  (If so) can we really make it
soon?  As far as I know, no host implementation supports the M flag.
Regarding the O flag, I've implemented the host side of the flag,
which invokes a DHCPv6 client upon receiving an RA with the O bit.
But I've never heard of other implementations.

This also means one obvious problem when we remove these bits is
actually a non-issue.  That is, we do not have to worry about the
problem that we may make serious loss of compatibility.

Another possible disadvantage is that we'll lose the ability to
trigger DHCPv6 (or, if you like a general wording, trigger a stateful
protocol).  I admit this can be a problem.  A rough idea to deal with
this is to provide a different, more general way to provide the
ability as a separate document.  For example, a separate ND option
which can trigger a particular protocol (including DHCPv6) for a
particular purpose (e.g., to get "additional" configuration
information) might make sense to implement the idea.  In fact, an
extension to ND to re-invoke a protocol for "other information" has
already been proposed: draft-vijay-ipv6-icmp-refresh-otherconf-00.txt.

I know this is probably too radical to make a concrete proposal at
this stage, but if we can really agree on the basic idea of this path,
I'd probably do the followings in rfc2462:

- remove all references to "stateful" protocols
- deprecate the M and O flags, that is,
   + reserve the fields and clarify that they must not be used
     (this may affect rfc2461bis, too)
   + remove all the usages regarding these flags

Any comments/suggestions/objections are welcome.  Thanks in advance,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 15 Apr 2004 22:26:30 +0900

>>>>> On Thu, 15 Apr 2004 08:49:53 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> => The question you raise affects 2461 and as a consequence it affects 2462.

Yes, I know.  I tried to explain that in my previous message, but I'd
apologize if I was not clear enough.

> So I recommend we leave them as defined.

I see your points, and I actually expected this type of responses.  I
do not necessarily stick to introducing the radical change.  However,
it seems to me that the actual effects on 2461 is minimum.  RFC2461
basically only defines some syntaxes of the M/O bits, and leaves
almost all the details of the semantics to RFC2462.  So, we could even
keep the wording in RFC2461(bis), and only deprecate the usage in
RFC2462.  (Again, I'd like to emphasize that I'm not insisting on
introducing the change.  I'm saying this only when we could ever agree
on the changes from RFC2462's perspective (i.e., the usage side)).

					JINMEI, Tatuya