Subject: RE: whether we need the M flag ??

From: "Soliman Hesham" <[email-masked]>
Date: Tue, 27 Apr 2004 05:44:46 -0400

> > => So based on 1) and 2) I suggest that people who want to continue
 > > this discussion, despite the chairs' recommendation should 
 > limit the 
 > > discussion to the M flag. If there are implementations that support
 > > the O flag then removing it should be out of the question.
 > 
 > Fair enough, in that this is the chair's recommendation.
 > 
 > But please note that these implementations assume what is not
 > described in RFC2462; they assume the protocol corresponding to the O
 > flag is stateless DHCPv6 (RFC3736).  So, *if* we need to remove the M
 > flag due to the lack of implementation process-wise but we can keep
 > the M flag because of these implementations, the description in
 > rfc2462bis regarding the O flag should be consistent with the
 > assumption, as a logical consequence.  We should probably clarify in
 > rfc2462bis that the protocol for the O flag is RFC3736, and nothing
 > else.  (For that matter, I'm happy with it.)

=> I'm happy with that too. Associating the O flag with stateless DHCP
is ok because that's all we have today. If later other options come up then
the RA can be extended further. But we don't need to worry about this now
for 2461/2 bis.

 >   We do not have an implementation on some part of RFC2462.  Can we
 >   still recycle rfc2462bis as DS (process-wise), keeping that part,
 >   despite the lack of implementation?
 > 
 > If the answer is yes, we can concentrate on technical aspects of the
 > discussion for both the M and O flags.
 > 
 > If the answer is no, we need to somehow deprecate/remove the M flag,
 > and then concentrate on issues about the O flag (as you suggested
 > above).
 > 
 > I simply do not understand the answer to the general question, and I
 > think it's too early to suggest something at the moment, assuming the
 > answer is "no".  (I'm not intending to say this as a deal for
 > "killing" the O flag as well.  Rather, I'm saying this because we can
 > even keep both flags if the answer is "yes".)
 > 
 > Again, I'd really like to hear the answer to the general question
 > from someone familiar with the process.  Thanks,

=> I guess that's outside my job description ;) this is something for the 
chairs/ADs. I saw one email from the chairs on this. 

Hesham

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

========================================================
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: "Soliman Hesham" <[email-masked]>
Date: Tue, 27 Apr 2004 21:22:47 -0400

I thought that statement referred to one implementation
only, which is confirmed by Jinmei's response to my email

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]
 > Sent: Tuesday, April 27, 2004 12:14 PM
 > To: Soliman Hesham
 > Cc: IETF IPv6 Mailing List
 > Subject: Re: whether we need the M flag ??
 > 
 > 
 > 
 > On Apr 27, 2004, at 1:50 AM, Soliman Hesham wrote:
 > 
 > >
 > >> The facts are:
 > >>
 > >>   1. there is code that sets the M&O bits. (router 
 > implementations)
 > >>   2. there are at least two implementations that read and
 > >> act on the O
 > >>      bit.  These two implementations both invoke 
 > stateless DHCPv6 as
 > >>      the action.
 > >
 > I disagree. There are only 2 known implementations of the O flag,
 > and the author of one of them publicly said he was willing
 > to deprecate it. He said:
 > "Regarding KAME's implementation, at least the implementor 
 > (myself) is
 > okay to deprecate the flags.  Also, it's just an experimental
 > implementation to identify issues, so this feature (invoking an
 > RFC3736 client) is disabled by default in the implementation and is
 > not officially released in the BSD community.  In fact, I'm 
 > tempted to
 > deprecate the flags based on my experiments with the implementation,
 > identifying the issues described above."
 > 
 > So I do not believe that the argument that say they are existing 
 > implementations
 > of 'O' thus we cannot deprecate it is very strong
 > 
 > 	- Alain.
 > 
 >