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

Hello, Suresh.

Thank you for your interests and important comments. 
I put my opinions below your comments. 

- Joseph
------- Original Message -------
Sender : Suresh Krishnan<suresh.krishnan@ericsson.com> 
Date   : 2008-06-19 04:45 (GMT+09:00)
Title  : Re: [dhcwg] [FYI] I-D Action : draft-cha-ipv6-ra-mo-00.txt

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.
(Joseph) Thank you for suggestions. However, the issues we are dealing with in this draft are related to implementations conforming to RFC2462. Those implementations will remain unchanged until new standard regarding M & O flags is written. 

* 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?
(Joseph) Thank you for your point. When we revise this draft, we will consider normative languages. And, below is my answer for your questions. 
If the client picks O1, it keeps its operations until all bindings expire (if any) and terminates when it try to send a SOLICIT or INFO_REQUEST. However, if the client picks O2, it release its bindings (if any) and terminates immediately. 

* 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
(Joseph) Good point. This must be a problem we should solve. 

Cheers
Suresh

HYUN WOOK CHA wrote:
> 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------