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

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 18 June 2008 19:43 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6088228C1DA; Wed, 18 Jun 2008 12:43:35 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE2F28C1D3; Wed, 18 Jun 2008 12:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.433
X-Spam-Level:
X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFyUiIkLv6Nw; Wed, 18 Jun 2008 12:43:33 -0700 (PDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 07D4E28C1D2; Wed, 18 Jun 2008 12:43:32 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m5IJiJl5017738; Wed, 18 Jun 2008 14:44:20 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 14:44:37 -0500
Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 14:44:36 -0500
Message-ID: <485965C9.2060200@ericsson.com>
Date: Wed, 18 Jun 2008 15:45:13 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: hyunwook.cha@samsung.com
Subject: Re: [dhcwg] [FYI] I-D Action : draft-cha-ipv6-ra-mo-00.txt
References: <30925978.204361212998945070.JavaMail.weblogic@epml08>
In-Reply-To: <30925978.204361212998945070.JavaMail.weblogic@epml08>
X-OriginalArrivalTime: 18 Jun 2008 19:44:37.0012 (UTC) FILETIME=[BD79D540:01C8D17B]
Cc: ??? <pblim@samsung.com>, dhcwg@ietf.org, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

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

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
--------------------------------------------------------------------