Subject: RE: M=1/O=0 is not valid in full 3315 ?

From: "Bound, Jim" <[email-masked]>
Date: Thu, 19 Aug 2004 08:10:07 -0400

It is relevant completely to users and implementation your wrong.

But all marked cells for all matrice possibilities for m or o should be permitted.

/jim 

> -----Original Message-----
> From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
> Sent: Thursday, August 19, 2004 8:05 AM
> To: Bound, Jim
> Cc: Christian Huitema; S. Daniel Park; 
> [email-masked]; [email-masked]
> Subject: Re: M=1/O=0 is not valid in full 3315 ?
> 
> >>>>> On Thu, 19 Aug 2004 07:54:48 -0400, "Bound, Jim" 
> >>>>> <[email-masked]> said:
> 
> > I did not ever agree to that as a note. If it is set the admin has 
> > said you should use it the admin is in charge not the host.
> 
> Fine, but please note that this particular point is not at 
> all relevant to the main issue of this thread.  Since even 
> the main discussion has fully diverged, please change the 
> subject if you want to continue the discussion on what 
> Christian said to avoid further chaos.
> 
> Thanks...
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
> 
> >> > Besides, as jinmei indicated earlier as editor of 2462bis,
> >> M flag (ON)
> >> > indicated that the host (should) use the stateful protocol
> >> for address
> >> > autoconfiguration. This should mean the M flag (ON) indicates 
> >> > Solicit/Advertise/Request/Reply.
> >> 
> >> I disagree with the "host should use" part of this statement. 
> >> We reached a consensus on this point in previous discussion. 
> >> The consensus is "the
> >> M=1 flag indicates that the host MAY use the stateful protocol for 
> >> address autoconfiguration" -- i.e., that this protocol is 
> available 
> >> should the host decide to use it.
> >> 
> >> -- Christian Huitema
> >> 
> >> 
> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6
> >> 
> --------------------------------------------------------------------
> >> 
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 20 Aug 2004 19:44:47 +0900

>>>>> On Thu, 19 Aug 2004 08:10:07 -0400, 
>>>>> "Bound, Jim" <[email-masked]> said:

> It is relevant completely to users and implementation your wrong.

Just for some clarification since I was perhaps not very clear:

When I said

>> all relevant to the main issue of this thread.

I just meant the relevance to this particular thread.

Of course, what you said in your previous message is completely
relevant to what Christian said, and I respect the discussion per se.
I'd apologize if I sounded not.

I wanted to point out that what Christian said is irrelevant to this
particular thread, and (since your respone is relevant to his message)
your response to Christian is therefore irrelevant to this particular
thread.

Very roughly speaking (to avoid confusion), we were mainly talking
about whether "M=1" means both Solicit/Advertise/Request/Reply and
Information-request/Reply exchanges or just Solicit/.../Reply
exchanges.  Christian then suddenly (perhaps due to incomplete
citation which was unfortunate for all of us) mentioned the "host
should xx" issue, which is orthogonal to which types of exchanges M=1
means.

What I wanted to point out was that we were already fully confused
about the main topic in this thread and the discussion already
diverged (now seems to have converged, though), and what I was afraid
was that continuing the "orthogonal" issue with the same subject might
increase the confusion.  That's why I asked to change the subject.

Again, I respect the "irrelevant" discussion per se, and I didn't
intend to discourage the discussion.

Hope this helps.

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