<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Times New Roman, Times, serif">David,<br>
<br>
Thank you for that summary. This has been an interesting
discussion.<br>
<br>
My own reading of the "room" is that people have come to
understand that if you assign a price of 0 to something that has
value without any bounds on acquisition of that resource, someone
somewhere will arbitrage the difference. The way the community
has attempted to prevent that is through restrictions on
"ownership", including a needs assessment and a limitation on
transfers. It would seem prudent to maintain the same sorts of
restrictions for ULA-C that we have for any other IP address as
you wrote, particularly if reverse DNS is offered. At that point,
even more so than you wrote, the difference between PI and ULA-C
is strictly a matter of service provider policy, and nothing more,
with even fewer externalities than that of RFC 1918 addresses .
Indeed under those circumstances, a single service provider could
offer VPN services using ULA-C without MPLS, although let us agree
that the edge configuration might be a bit more "interesting".<br>
<br>
This leads to my own ultimate question: why doesn't Section 6.5.8
cover interior needs sufficiently? And this goes to your point
(4), which I quote:</font><br>
<br>
<blockquote type="cite"><font face="Times New Roman, Times, serif">4.
The availability of ULA-C for internal addressing will likely
make PA addressing facing the Internet more palatable at least
for some classes of enterprise users. This might be implemented
with NAT66, multiple RAs, or any number of possible future
solutions. Like maybe some variation of LISP, or some other GSE
type solutions. But, the details are irrelevant that is an
operational issue not a policy one.
</font></blockquote>
<br>
<font face="Times New Roman, Times, serif">Of the arguments in your
message, it would seem to me that this one, combined with whatever
security argument one would be the ones that should be further
developed. In addition, given that ARIN and the RIRs have
demonstrated reasonable flexibility in terms of making changes to
policies, one could reasonably ask the question as to whether this
proposal is well timed. The introduction of NAT66 into the
discussion is one that would need to be carefully considered, and
LISP and ILNP (GSE's successor) are still nascent technologies.<br>
<br>
Regards,<br>
<br>
Eliot<br>
</font><br>
</body>
</html>