Re: [Casm] New Version Notification for draft-xie-ps-centralized-address-management-02.txt

MarcoH - lists <> Wed, 22 March 2017 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8123127071 for <>; Wed, 22 Mar 2017 00:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I2sUSqywOIz0 for <>; Wed, 22 Mar 2017 00:58:52 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C027131459 for <>; Wed, 22 Mar 2017 00:58:48 -0700 (PDT)
Received: from [] ([]) by with ESMTP id yvyg1u007391jte01vyl02; Wed, 22 Mar 2017 08:58:46 +0100
From: MarcoH - lists <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 22 Mar 2017 11:58:43 +0400
References: <> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Subject: Re: [Casm] New Version Notification for draft-xie-ps-centralized-address-management-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Centralized Address Space Management <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Mar 2017 07:58:55 -0000

> Hi,
> This draft makes a strong case for coordinated address management.
> In my opinion, it makes no case at all for *centralized* address
> management. But apart from that one word to change, I think it's
> very good.
> Regards
>   Brian Carpenter

Tend to agree here, while I can see how the word “centralised” came in, we might be better off if this project would use the term “coordinated” address management where possible.

Further in response to the draft, Section 5 “requirements” in the second 2nd bullet reads:

"A fast return of unused resources for reassignment is of high value.”

While I can see this as a value for scarce resources such as IPv4 addresses or IP port ranges, I am not sure if this is a beneficial property for IPv6, where networks should be able to afford themselves the luxury of providing hosts with a stable address (prefix) when they require it.

For now I can probably live with the terminology used, but would like to see some clarification on how this requirement will be further expanded and refined to allow for more stable or predictable IPv6 prefixes, without the need to go full static (which would remove a lot of the benefits in efficiency).