Subject: Re: Re: [dhcwg] Fwd: Questions about RA flags (M, O) processing

From: 차현욱 <[email-masked]>
Date: Wed, 10 Oct 2007 04:18:47 +0000 (GMT)

Dear, Alex and all.

Alex, Thank you for your reply.

As long as I understand for linux kernel (2.6.20), conditions for the stateless autoconfiguration (rfc4862) are as follows.
For the kernel configurations, forwarding=0(Host only), accept_ra=1, accept_ra_pinfo=1, autoconf=1.   
Then, only if A flag in the prefix info option is set to 1, the stateless autoconfiguration is performed irrespective of the M flag.
An open source implementation by IBM I checked dhcpv6 daemon gets flag values recorded in "struct inet6_dev" kernel variable during initial stage to be controlled in which mode the client daemon starts by previous received RA flags.

IMO, if DHCPv6 client is designed to be controlled by RA flags, the issues for different RA flags from different routers should be considered and addressed. 
I wonder this WG think this is important issue to tackle in the wg scope or not. If not, which WG will be addressed? IPv6 MAN?

At this stage, I hope I may have lucky chances to get valuable informations from DHCPv6 authors and implementors.
Any comments welcomed!!!

Thank you all.
  
Joseph HyunWook Cha

The truth will set you free !!!

Software Engineer 
Development Part 1. I/Infra  
Network System Division 
Tel 031-279-3804  Mobile 010-3024-3804

------- Original Message -------
Sender : Alexandru Petrescu<[email-masked]> 
Date   : 2007-10-09 21:45
Title  : Re: [dhcwg] Fwd: Questions about RA flags (M, O) processing

차현욱 wrote:
> Dear, all.
> 
> For the previous questions, I checked the behavior of a Windows Vista
>  DHCPv6 client. Maybe many folks already know this, but I want to 
> share the results and get helpful ideas and advices from the DHC WG.
> 
> If the dhcpv6 client received a RA message with M flag set to 1 at 
> first, it begined to solicit by SOLICIT messages. Then, immediately 
> after it received following RA message with M flag set to 0, it 
> released leases addresses by RELEASE messages. If the dhcpv6 client 
> received a RA message with M flag set to 0 and O flag set to 1 at 
> first, it started as the stateless mode by INFO-REQUEST messages. 
> Then, when it received following RA message with M flag set to 0 and 
> O flag set to 0, it removed all other config informations including 
> DNS server addresses. When the client received multiple RA messages 
> with flags set to different combinations from different Routers or 
> different links in one router, it performed infinitely iterative 
> operations between stateful (SOLICIT-REQUEST) and stateless 
> (INFO_REQUEST).

GReat to know thanks.

For information, linux recent kernels seem to ignore the M==1 flag in RA
and do auto-configure addresses statelessly, without invoking DHCPv6
transactions.  Which is not very good, it should do DHCPv6 SOLICIT, IMHO.

> I did not find any RFCs and drafts addressing these issues. Is there 
> anybody who knows helpful informations and experiences of 
> implementations which tackled these?

Err... rfc4862 (recently upgrading rfc2462 says):
> o  Removed the text regarding the M and O flags, considering the 
> maturity of implementations and operational experiences. ManagedFlag
> and OtherConfigFlag were removed accordingly.  (Note that this change
> does not mean the use of these flags is deprecated.)

Reading this text one would think that M flag is no longer used in RA.
Then reading rfc4861 (recently obsoletes rfc2461) one sees:
> M              1-bit "Managed address configuration" flag.  When set,
> it indicates that addresses are available via Dynamic Host
> Configuration Protocol [DHCPv6].

So, yes, I think rfcs and their implementations should be updated
accordingly.

Alex

> 
> Many thanks,
> 
> Joseph Cha
> 
> ------- Original Message ------- Sender : 차현욱 
> <[email-masked]>  E4(선임)/선임/개발1그룹(I/Infra)/삼성전자 Date   : 
> 2007-10-04 17:07 Title  : Questions about RA flags (M, O) processing
> 
> 
> Dear, all.
> 
> I have questions about RA flags (M, O) processing. From the TAHI 
> conformance spec document, I know that if the client already has an 
> active binding, changes of M flag (1->0->1) does not affect behavior 
> of the client. Also, as long as stateless dhcp client initiated does 
> not receive Reply message, changes of O flag (1->0) does not affect 
> behavior of the client. If so, I want to know cases where changes of 
> flags affect behavior of a client after it was triggered(or enabled) 
> in the manner of stateful or stateless mode. Please give me detailed 
> scenarios and explanations. Thank you in advance.
> 
> Regards,
> 
> Joseph HyunWook Cha
> 
> The truth will set you free !!!
> 
> Software Engineer Development Part 1. I/Infra Network System Division
>  Tel 031-279-3804  Mobile 010-3024-3804
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/dhcwg

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2007 01:13:42 -0400

An unmodified Linux system will not run DHCPv6 regardless of the  
state of the M and O bits because, as far as I know, Linux is not  
distributed with a DHCPv6 client.

It's interesting to know that the IBM DHCPv6 client checks the  
received RA flags; how does it get the values of those flags out of  
the kernel?

There was a long discussion about the M and O bits before the  
publication of RFCs 4861 and 4862, with the result that the semantics  
of the M and O flags were left undefined in RFC 4862.  It seems the  
Vista DHCPv6 now uses a different interpretation of the M and O flags  
than was defined in RFC 2462.

In general, there is an assumption that all routers on a link are in  
the same administrative domain, and that different configuration  
information from those routers is a configuration error.

- Ralph

On Oct 10, 2007, at Oct 10, 2007,12:18 AM, 차현욱 wrote:

> As long as I understand for linux kernel (2.6.20), conditions for  
> the stateless autoconfiguration (rfc4862) are as follows.
> For the kernel configurations, forwarding=0(Host only),  
> accept_ra=1, accept_ra_pinfo=1, autoconf=1.
> Then, only if A flag in the prefix info option is set to 1, the  
> stateless autoconfiguration is performed irrespective of the M flag.
> An open source implementation by IBM I checked dhcpv6 daemon gets  
> flag values recorded in "struct inet6_dev" kernel variable during  
> initial stage to be controlled in which mode the client daemon  
> starts by previous received RA flags.
>
> IMO, if DHCPv6 client is designed to be controlled by RA flags, the  
> issues for different RA flags from different routers should be  
> considered and addressed.
> I wonder this WG think this is important issue to tackle in the wg  
> scope or not. If not, which WG will be addressed? IPv6 MAN?
>
> At this stage, I hope I may have lucky chances to get valuable  
> informations from DHCPv6 authors and implementors.
> Any comments welcomed!!!
>
> Thank you all.
>
> Joseph HyunWook Cha
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 12:15:55 +0200

차현욱 wrote:
> As long as I understand for linux kernel (2.6.20), conditions for the
>  stateless autoconfiguration (rfc4862) are as follows. For the kernel
>  configurations, forwarding=0(Host only), accept_ra=1, 
> accept_ra_pinfo=1, autoconf=1. Then, only if A flag in the prefix 
> info option is set to 1, the stateless autoconfiguration is performed
>  irrespective of the M flag.

Thanks, do you mean that if I put A==0 and M==1 in radvd.conf, then the
kernel will _not_  autoconfigure an address based on the prefix in RA?

It's strange one has to tweak the A bit in order for the address to be
obtained from DHCPv6 (not stateless autoconf), because one would like
the prefix to be valid on the interface, add a routing entry for it -
or, if A==0 then the entire prefix is ignored I believe.

I have to check anyways.

> initial stage to be controlled in which mode the client daemon starts
> by previous received RA flags.

Thanks, this is thus the 5th DHCPv6 client available for test:

-windows vista
-IBM DHCPv6 http://sourceforge.net/projects/dhcpv6
-Dibbler
-WIDE DHCPv6
-ISC DHCPv6 isc.org

Alex

> considered and addressed. I wonder this WG think this is important 
> issue to tackle in the wg scope or not. If not, which WG will be 
> addressed? IPv6 MAN?
> 
> informations from DHCPv6 authors and implementors. Any comments 
> welcomed!!!
> 
> Thank you all.
> 
> Joseph HyunWook Cha
> 
> ------- Original Message ------- Sender : Alexandru 
> Petrescu<[email-masked]> Date   : 2007-10-09 21:45 
>> For the previous questions, I checked the behavior of a Windows 
>> Vista DHCPv6 client. Maybe many folks already know this, but I want
>>  to share the results and get helpful ideas and advices from the
>> DHC WG.
>> 
>> Then, when it received following RA message with M flag set to 0
>> and O flag set to 0, it removed all other config informations
>> including DNS server addresses. When the client received multiple
>> RA messages with flags set to different combinations from different
>> Routers or different links in one router, it performed infinitely
>> iterative operations between stateful (SOLICIT-REQUEST) and
>> stateless (INFO_REQUEST).
> 
> GReat to know thanks.
> 
> For information, linux recent kernels seem to ignore the M==1 flag in
>  RA and do auto-configure addresses statelessly, without invoking 
> DHCPv6 transactions.  Which is not very good, it should do DHCPv6 
> SOLICIT, IMHO.
> 
>> I did not find any RFCs and drafts addressing these issues. Is 
>> there anybody who knows helpful informations and experiences of 
>> maturity of implementations and operational experiences. 
>> ManagedFlag and OtherConfigFlag were removed accordingly.  (Note 
>> that this change does not mean the use of these flags is 
>> deprecated.)
> 
> Reading this text one would think that M flag is no longer used in 
> RA. Then reading rfc4861 (recently obsoletes rfc2461) one sees:
>> M              1-bit "Managed address configuration" flag.  When 
>> set, it indicates that addresses are available via Dynamic Host 
>>  active binding, changes of M flag (1->0->1) does not affect 
>> behavior of the client. Also, as long as stateless dhcp client 
>> initiated does not receive Reply message, changes of O flag (1->0) 
>> does not affect behavior of the client. If so, I want to know cases
>>  where changes of flags affect behavior of a client after it was 
>> triggered(or enabled) in the manner of stateful or stateless mode. 
>> Please give me detailed scenarios and explanations. Thank you in 
>> advance.
>> 
>> Regards,
>> 
>> Joseph HyunWook Cha
>> 
>> Software Engineer Development Part 1. I/Infra Network System 
>> Division Tel 031-279-3804  Mobile 010-3024-3804
>> 
>> 
>> 
>  This email has been scanned by the MessageLabs Email Security 
> System. For more information please visit 
> http://www.messagelabs.com/email

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2007 07:36:28 -0400

As I read RFC 4862, use of stateless autoconfiguration and DHCPv6 are  
controlled independently, respectively, by the A bit in the PIO and  
the M/O bits in the RA header.  The state of the A bits in any PIOs  
in an RA should not affect the use of DHCPv6, and the state of the M/ 
O bits in the RA header should not affect the use of stateless  
autoconfiguration.  I understand "A==0 and M==1 in radvd.conf" to  
cause a host to run DHCPv6, add the prefix to its Prefix List but not  
perform stateless autoconfiguratino on that prefix.

If the A bit in a PIO is not TRUE, my understanding is that the  
prefix is added to the host Prefix List, but the host does   not  
perform stateless autoconfiguration on that prefix.

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 14:36:39 +0200

Ralph Droms wrote:
> controlled independently, respectively, by the A bit in the PIO and the 
> M/O bits in the RA header.  The state of the A bits in any PIOs in an RA 
> should not affect the use of DHCPv6, and the state of the M/O bits in 
> the RA header should not affect the use of stateless autoconfiguration.  
> I understand "A==0 and M==1 in radvd.conf" to cause a host to run 
> DHCPv6, add the prefix to its Prefix List but not perform stateless 
> autoconfiguratino on that prefix.

I agree with this intended behaviour.

> If the A bit in a PIO is not TRUE, my understanding is that the prefix 
> is added to the host Prefix List, but the host does   not perform 
> stateless autoconfiguration on that prefix.

But rfc4862 says if A==0 then ignore the PIO; rfc4862:
> 5.5.3.  Router Advertisement Processing
> 
>    For each Prefix-Information option in the Router Advertisement:
> 
>     a)  If the Autonomous flag is not set, silently ignore the Prefix
>       Information option.

I didn't go further than that.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 14:43:41 +0200

Ralph Droms wrote:
> An unmodified Linux system will not run DHCPv6 regardless of the state 
> of the M and O bits because, as far as I know, Linux is not distributed 
> with a DHCPv6 client.

Right.  I meant ISC DHCPv6 installed manually over it.

> It's interesting to know that the IBM DHCPv6 client checks the received 
> RA flags; how does it get the values of those flags out of the kernel?
> 
> publication of RFCs 4861 and 4862, with the result that the semantics of 
> the M and O flags were left undefined in RFC 4862.

In my humble oppinion this is an unfortunate result.  Satisfying all 
oppinions and their contraries with a common text risks headaches to the 
implementer.

How can the semantics of M and O flags be left undefined when the 
implementations do it?

Alex

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 10 Oct 2007 09:52:17 -0400

> of the M and O flags were left undefined in RFC 4862.

The effect of leaving them undefined is that every implementation comes
up with 
a different interpretation and network operators never know what to
expect when
they configure the bits in the RA.  Furthermore, they can probably
anticipate
complete chaos in their network as every host does things a little
differently.
I thought that lack of interoperability and unexpected behaviors was
exactly 
the type of thing the IETF was founded in order to help avoid.

- Wes

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 8:44 AM
To: Ralph Droms (rdroms)
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Fwd: Questions about RA flags (M, O) processing

> of the M and O bits because, as far as I know, Linux is not 

the kernel?
> of the M and O flags were left undefined in RFC 4862.

Alex

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 11 Oct 2007 10:27:30 +0900

At Wed, 10 Oct 2007 14:36:39 +0200,
> I didn't go further than that.

RFC4862 only covers address configuration.  The "Prefix List" Ralph
mentioned is a list of on-link prefixes in the link, which is itself
irrelevant to address configuration.  That's why RFC4862 is silent
about that.  See RFC4861 for the prefix configuration.

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Oct 2007 12:20:14 -0400

Following up, "Considerations on M and O Flags of IPv6 Router  
Advertisement", draft-ietf-ipv6-ra-mo-flags-01.txt http:// 
tools.ietf.org/html/draft-ietf-ipv6-ra-mo-flags-01, was intended (if  
I remember correctly) to address the behavior of a host in response  
to the state of the M/O flags.  This I-D has expired.

- Ralph

On Oct 10, 2007, at Oct 10, 2007,1:13 AM, Ralph Droms wrote:

> [...]
> publication of RFCs 4861 and 4862, with the result that the  
> semantics of the M and O flags were left undefined in RFC 4862.  It  
> seems the Vista DHCPv6 now uses a different interpretation of the M  
> and O flags than was defined in RFC 2462.
>
> [...]
>
> - Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Oct 2007 12:22:57 -0400

In the interest of giving credit where credit is due, Bernie Volz  
reminded me of this draft and it's applicability to this discussion...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Oct 2007 14:33:03 -0400

Bob Hinden reminded me that text about the M and O flags is now in  
section 4.2 of RFC 4861:

       M              1-bit "Managed address configuration" flag.  When
                      set, it indicates that addresses are available via
                      Dynamic Host Configuration Protocol [DHCPv6].

                      If the M flag is set, the O flag is redundant and
                      can be ignored because DHCPv6 will return all
                      available configuration information.

       O              1-bit "Other configuration" flag.  When set, it
                      indicates that other configuration information is
                      available via DHCPv6.  Examples of such  
information
                      are DNS-related information or information on  
other
                      servers within the network.

Hosts are free to use the information transmitted in the M and O  
flags to control the host's use of DHCPv6.

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Oct 2007 11:44:26 +0200

Ralph Droms wrote:
> If the M flag is set, the O flag is redundant and can be ignored
> because DHCPv6 will return all available configuration information.
> 
> indicates that other configuration information is available via
> DHCPv6.  Examples of such information are DNS-related information or
> information on other servers within the network.
> 

Right, that text sounds relevant.  But its expression can have strange
side-effects, because it does not say that when M==1 the host MUST NOT
do stateful autoconf - it should say so.

Otherwise, imagine myself as a network deployer trying to accomodate all
types of hosts: windows, linux, symbian and others.  If I want to make
sure they consistently auto-configure an address then I must set M==0,
ie don't use DHCP.

BEcause, if I set M==1, a windows host will use DHCP whereas a linux
host will use stateless autoconf (M==1 means DHCP is available and hosts
are free to choose).  Which I don't really want.  BEcause I want to
manage the prefixes/addresses with a single manner: either centrally on
a DHCP server, xor with a SNMP or ssh client remotely configuring the
Access Routers.  But not both, it's too much work.

That's why I find the side effect of that host freedom not particularly
helpful.  But I also realize freedom in implementation is very valuable
and sometimes a must (I'm not a particular fan of MUST NOT statements);
maybe later deployments will give more hints to this aspect.

Alex

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Oct 2007 07:35:17 -0400

My understanding is that the M/O flags in an RA and the A flga in a  
PIO have somewhat different meanings: the M/O flags are advisory,  
announcing the availability of DHCP but not requiring its use, while  
the A bit is mandatory, so if the A flag is not TRUE, the host will  
not run stateless autoconf.  I belive a Linux host will obey the A  
flga in a PIO even if it does not have a DHCP client.

So, there are still potential problems - setting the M flag to TRUE  
does not guarantee that all hosts on the link will se DHCP - but  
setting any A flags FALSE will prevent any use of stateless autoconf.

Also, note that stateless autoconf and the use of DHCP are not  
mutually exclusive.

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Oct 2007 16:09:39 +0200

> flga in a PIO even if it does not have a DHCP client.

I agree completely, after checking precisely that in practice.  A linux
kernel 2622 will not auto-configure an address on an interface if the A
flag of RA is 0.  And it will add a 'connected' route in its routing
table with the prefix from the PIO in the received RA.  Which is very good.

Except that rfc4862 says if A==0 then ignore the PIO.  If an
implementation were to ignore the PIO then there would not be connected
route added.  Jinmei said that rfc4861 is a better reading for this A
flag, but I still believe rfc4862 shouldn't say "If A is not set then
ignore the PIO"; it should say "If A==0 then don't auto-configure an
address, but do configure a connected route for the prefix in that PIO".

Or maybe Jinmei sees this A==0=>ignorePIO as a means to push for DHCPv6
to deliver the prefix.  I don't know.

> setting any A flags FALSE will prevent any use of stateless autoconf.
I agree.

On this aspect, while implementing some related stuff people are tempted
to use a super flag, or policy, that automatically sets the A and M
flags in a router's config file.  For example, the config file says
"USE_DHCP=TRUE" then M==1 and A==0, otherwise "USE_DHCP=FALSE" then M==0
and A==1; from these flags then re-configure the radvd's config file,
and others.  This is along the lines of the draft ideas you/Bernie have
mentioned earlier.  I support advancement of that draft, because I've
encountered the same type of problem and inherently thought of same
solution, without knowing that draft existed.

> Also, note that stateless autoconf and the use of DHCP are not

On a side note, I would like to be able to completely manage an access
network with only SLAAC (stateless autoconfig) or only with DHCP. For
DHCPv6, it would be needed to optionally send Prefix of an address
assigned to the mobile (the other discussion), and the default router
address.

The switcher discriminator between the two modes should be in RA, a
single enforced flag, like M but enforced.

Alex

>>> Bob Hinden reminded me that text about the M and O flags is now
>>> in section 4.2 of RFC 4861: M              1-bit "Managed address
>>> configuration" flag.  When set, it indicates that addresses are
>>> available via Dynamic Host Configuration Protocol [DHCPv6]. If
>>> the M flag is set, the O flag is redundant and can be ignored 
>>> because DHCPv6 will return all available configuration
>>> information. O              1-bit "Other configuration" flag.
>>> When set, it indicates that other configuration information is
>>> available via DHCPv6.  Examples of such information are
>>> DNS-related information or information on other servers within
>>> the network. Hosts are free to use the information transmitted in
>>> the M and O flags to control the host's use of DHCPv6.
>> 
>> Right, that text sounds relevant.  But its expression can have
>> strange side-effects, because it does not say that when M==1 the
>> host MUST NOT do stateful autoconf - it should say so.
>> 
>> Otherwise, imagine myself as a network deployer trying to
>> accomodate all types of hosts: windows, linux, symbian and others.
>> If I want to make sure they consistently auto-configure an address
>> then I must set M==0, ie don't use DHCP.
>> 
>> BEcause, if I set M==1, a windows host will use DHCP whereas a
>> linux host will use stateless autoconf (M==1 means DHCP is
>> available and hosts are free to choose).  Which I don't really
>> want.  BEcause I want to manage the prefixes/addresses with a
>> single manner: either centrally on a DHCP server, xor with a SNMP
>> or ssh client remotely configuring the Access Routers.  But not
>> both, it's too much work.
>> 
>> That's why I find the side effect of that host freedom not
>> particularly helpful.  But I also realize freedom in implementation
>> is very valuable and sometimes a must (I'm not a particular fan of
>> MUST NOT statements); maybe later deployments will give more hints
>> to this aspect.
>> 
>> Alex
>> 
>>> - Ralph
>> 
>>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Oct 2007 11:06:11 -0400

I think RFC 4862 would be clearer by replacing "If A is not set then  
ignore the PIO" with "If A is not set, then don't perform stateless  
autoconfiguration with this prefix".

The consensus that lead to the text in RFC 486[12], if I remember  
correctly, was that DHCP is not a required part of the IPv6 protocol  
suite, and is not widely deployed, so making the M flag a "MUST do  
DHCP" was not a reasonable requirement.  If you *want* to manage your  
network using all stateless all autoconfig or all DHCP, you can  
indicate that desire in the RA flags.  However, those hosts that  
don't have a DHCP client won't be able to respond to the M flag setting.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 15 Oct 2007 11:41:14 +0900

At Fri, 12 Oct 2007 16:09:39 +0200,
Alexandru Petrescu <[email-masked]> wrote:

> ignore the PIO";

While RFC4862 is already pretty clear about the limited usage of the A
flag, I wouldn't oppose to making the text super clearer (when someday
the spec advances to full standard).  But

> it should say "If A==0 then don't auto-configure an

this is not correct because the A flag is irrelevant to on-linkness
(the L flag matters) and the usages of A and L flags are orthogonal.
If we want to make it super clearer, it should be "If A==0 then don't
do stateless auto-configuration using the prefix (period)".

> to deliver the prefix.  I don't know.

No, I didn't mean that.  The A flag has nothing to do with whether to
run DHCPv6.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 15 Oct 2007 11:48:26 +0900

At Thu, 11 Oct 2007 12:20:14 -0400,

> to the state of the M/O flags.  This I-D has expired.

More precisely, the draft was dead (and I'm partly responsible for the
death).  We tried to clarify the usage of the M/O flags but the
opinions so varied that we failed to make a clear consensus.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 15 Oct 2007 11:54:30 +0900

At Mon, 15 Oct 2007 11:41:14 +0900,

> While RFC4862 is already pretty clear about the limited usage of the A

I meant "While *I think* RFC4862 is already pretty clear"...

					JINMEI, Tatuya