IETF Logo Mail Archive

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

Robert Sparks <rjsparks@nostrum.com> Fri, 26 April 2013 15:42 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 3560B21F9A16; Fri, 26 Apr 2013 08:42:11 -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 zmrnO4NroEmx; Fri, 26 Apr 2013 08:42:10 -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 70EF521F9A0C; Fri, 26 Apr 2013 08:42:10 -0700 (PDT)
Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3QFg80u049436 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 26 Apr 2013 10:42:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <517AA051.8080506@nostrum.com>
Date: Fri, 26 Apr 2013 10:42:09 -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: dhcwg@ietf.org, ietf@ietf.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-dhc-triggered-reconfigure@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------050301090000090703000601"
Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Subject: [Gen-art] 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: Fri, 26 Apr 2013 15:42:11 -0000

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

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