[apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
Ted Hardie <ted.ietf@gmail.com> Thu, 11 April 2013 22:51 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8E121F8935 for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level:
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 56sN2Y5W1a0w for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:51:03 -0700 (PDT)
Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9616521F8842 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
Received: by mail-ia0-f171.google.com with SMTP id f27so7280iae.16 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hKMTqw/3cppzHKdB2bmIh+atzRgdotcqUbVm1SLzCdI=; b=IhV/3cQTPs9/dn+1iSEEZf9EoLQlPZxguhuSZKiIXF5FDGweUPaY99IQ8j9yo4oXGl hPTWQV72BZYkNdeW7ICl8ezKd6gL8Vr63m++6SCv/mnF2cAkWBipgDhihfy04UMxCvfl vymLN8nrPJc6r9Rdk+0YYiPGaK8PtKRyApVlelU9IGEooc54+4Y7Z2Wx7UoN/2xAYMpy wWVXkfCbN98frneFCLQlwu/iVHzmEO829rO8Agy9ocVT6ovlaMhUZQZ6WdKgcH6GRRXH qWfQc6NNNrm01aPCUyNdr3qzZVn0L94Vp4y8P2tMnxotbsqarNhqiigIhs9WMMFg+xyK iZ2Q==
MIME-Version: 1.0
X-Received: by 10.50.27.10 with SMTP id p10mr114067igg.20.1365720661111; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Thu, 11 Apr 2013 15:51:00 -0700 (PDT)
Date: Thu, 11 Apr 2013 15:51:00 -0700
Message-ID: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-6renum-gap-analysis.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="047d7b10cd29de865504da1d9ec2"
Subject: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 22:51:05 -0000
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document:draft-ietf-6renum-gap-analysis-05 Title: IPv6 Site Renumbering Gap Analysis Reviewer: Ted Hardie Review Date: April 11, 2013 Summary: This document is basically ready to be published as an Informational draft. There are minor issues which the authors may wish to address before final publication. Minor Issues: The document currently motivates its work with the following statement: If IPv6 site renumbering continues to be considered difficult, network managers will turn to Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. A citation for this would be useful. It might also be worth it to highlight other potential risks--for example, the widespread deployment of ULAs, which do not admit of aggregation, or the deployment of address translation technologies which make referral more difficult. I note that RFC 5887 included some of these issues. If the intent is to reference those from RFC 5887, I note that the document currently says that it "starts from existing work in [RFC5887], [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references to these documents are informative. If the document is meant to be an extension, rather than a replacement, such that these documents must be read to get the full picture, than a normative reference may be better. For the session survivability section, a reference to RFC 6724 may be useful, so that those adding new global addresses understand how the application API to determine which address is used with interact with the addition of new addresses (if there is a specific draft or other treatment of that topic, that would be even better, but I am not personally aware of one). In section 6, the document currently says: When nodes in a site have been renumbered, then all the entries in the site which contain the nodes' addresses must be updated. The entries mainly include DNS records and filters in various entities such as ACLs in firewalls/gateways. This appears to imply that these updates must take place after the renumbering event, but this is variable. ACLs and filters may well be updated in advance; DNS may be updated concurrently or post facto. A rewording to highlight that this is variable by record type may be useful. Section 9.2, in the bullet entitled "DNS data structure optimization" The discusses a DNS feature proposed but declared historic. I don't think it identifies the related renumbering gap in a way that is useful for a naive reader. If it cannot be reworded to focus on the gap, I suggest it be removed. In section 9.4, the document says: For application layer, as [RFC5887] said, in general, we can assert that any implementation is at risk from renumbering if it does not check that an address is valid each time it opens a new communications session. This might be reworded to include or focus on session resumption, rather than new communications sessions. From an applications perspective, the laptop "sleep" function seems to be one of the bigger risks of this. Nit: For me personally, section 6.1 seemed needlessly pessimistic.
- [apps-discuss] Review of draft-ietf-6renum-gap-an… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Liubing (Leo)
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Brian E Carpenter
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Barry Leiba
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Brian E Carpenter
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Liubing (Leo)
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Brian E Carpenter
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… Barry Leiba
- Re: [apps-discuss] Review of draft-ietf-6renum-ga… S Moonesamy