Subject: [dhcwg] [FYI] I-D Action : draft-cha-ipv6-ra-mo-00.txt

From: HYUN WOOK CHA <[email-masked]>
Date: Mon, 09 Jun 2008 08:09:05 +0000 (GMT)

Dear 6man and dhc folks,

Bernie Volz and I published an internet draft to clarify handling of M & O flags of IPv6 RA.
In this draft, we address operational problems regarding handling of M & O flags of RA in existing documents as below.
i) There is no method to revoke the operation of a DHCPv6 client invoked by IPv6 RA flags.  
ii) Per-interface state variables regarding availability of the DHCPv6 service cannot be maintained consistently in case that inconsistent M & O flags are contained in RAs sent by different routers.  
To solve these problems, this document describes a handling scheme of M & O flags in RA messages. which consists of an algorithm for the management of per-interface state variables and options regarding how these variables can be utilized to revoke DHCPv6 clients.

Please refer to the following URL.
http://www.ietf.org/internet-drafts/draft-cha-ipv6-ra-mo-00.txt

We welcome any comments.

Thank you in advance.

Joseph HyunWook Cha

Software Engineer 
Network System Division 
SAMSUNG Electronics, Inc.

  If you do not stand firm in your faith, 
  you will not stand at all.  - Isaiah 7:9
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Jun 2008 15:45:13 -0400

Hi Joseph,
   I went through this draft. It is easy to read and understand. I do 
have a couple of comments though

* The references to 2462 in the draft are not very productive. The text 
relating to these flags was removed in RFC4862 precisely because there 
was no consensus on how to interpret these flags. Is is possible to put 
this in perspective of RFC4862 instead and NOT use the ManagedFlag and 
OtherConfigFlag. A better option is to define new flags in the document.

* Another thing that concerns me about this document is the lack of 
normative language (RFC2119 keywords). Without this I am not sure how 
this will improve the current conditions. e.g. In section 5, can a 
client can choose to implement either 01 or 02? How will an external 
observer know what the client has chosen. If the client picks 01, how 
can an admin know what decision it is going to make regarding the DHCP 
client when a M=1 to M=0 transition happens?

* I personally believe that we cannot make progress on this topic until 
we nail down the meaning of the M and O flag themselves. Something along 
the lines of draft-ietf-ipv6-ra-mo-flags-01.txt

Cheers
Suresh