IETF Logo Mail Archive

Re: [Gen-art] [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

Robert Sparks <rjsparks@nostrum.com> Mon, 06 May 2013 16:09 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2CC21F8FF5; Mon, 6 May 2013 09:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NceC5ZgUTWW0; Mon, 6 May 2013 09:09:46 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D402121F8F12; Mon, 6 May 2013 09:09:45 -0700 (PDT)
Received: from unnumerable.local (mobile-166-147-079-070.mycingular.net [166.147.79.70]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r46G9fvr027267 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 6 May 2013 11:09:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <5187D5C8.5000902@nostrum.com>
Date: Mon, 06 May 2013 11:09:44 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <517AA051.8080506@nostrum.com> <94C682931C08B048B7A8645303FDC9F36ECC240570@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECC240570@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: multipart/alternative; boundary="------------010407040103010500050401"
Received-SPF: pass (shaman.nostrum.com: 166.147.79.70 is authenticated by a trusted mechanism)
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dhc-triggered-reconfigure@tools.ietf.org" <draft-ietf-dhc-triggered-reconfigure@tools.ietf.org>
Subject: Re: [Gen-art] [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2013 16:09:47 -0000

Looks good to me. Thanks!
RjS

On 5/6/13 3:02 AM, mohamed.boucadair@orange.com wrote:
>
> Dear Robert,
>
> I updated the document to cover the comments you raised. You can check 
> the diff available at: 
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06
>
> Cheers,
>
> Med
>
> *De :*dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] *De la 
> part de* Robert Sparks
> *Envoyé :* vendredi 26 avril 2013 17:42
> *À :* dhcwg@ietf.org; ietf@ietf.org; General Area Review Team; 
> draft-ietf-dhc-triggered-reconfigure@tools.ietf.org
> *Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-dhc-triggered-reconfigure-05
> Reviewer:  Robert Sparks
> Review Date: April 26, 2013
> IETF LC End Date: May 6, 2013
> IESG Telechat date: May 16, 2013
>
> Summary: This draft is on the right track but has open issues, 
> described in
>       the review.
>
> Major issues:
>
> Overall, this document is solid, but I think there is a bug in section 
> 6.3.
> I could be wrong, but If I'm right, this paragraph:
>
> When retransmission is required, the relay may decide to correct the 
> content of RECONFIGURE-REQUEST message it issues (e.g., update the 
> Client Identifier list).  This decision is local to the relay (e.g., 
> it may be based on observed events such as one or more clients were 
> reconfigured on their own).
>
>
> introduces a race-condition that could lead to an erroneous state. If 
> a relay's first message included client A, then the retransmission 
> included clients A and B, but that retransmission crosses with a 
> success RECONFIGURE-REPLY to the request that only included client A, 
> the relay will think it succeeded in asking A and B to be reconfigured.
>
> Minor issues:
>
> This sentence:
>
> Furthermore, means to recover state in failure events must be 
> supported, but are not discussed in this document.
>
> places a requirement on a relay (even though it's not using a 2119 
> MUST). Is there some other document that defines this requirement that 
> you can reference? If not, the requirement should be discussed in this 
> document. Alternatively, you could change the sentence to talk about 
> the consequences of not having a proprietary means for recovering state.
>
> Nits/editorial comments:
>

v2.23.0 | Report a Bug | By Email