-----Original Message-----
From: Owen DeLong [mailto:owen(_at_)delong(_dot_)com]
Sent: Thursday, September 22, 2011 6:32 PM
To: George, Wes
Cc: Jari Arkko; ietf(_at_)ietf(_dot_)org;
draft-weil-shared-transition-space-request(_at_)tools(_dot_)ietf(_dot_)org;
draft-bdgks-arin-shared-transition-space(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt>
(IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as
additional private-scope use cases?
I don't believe so. I believe that conflating these drafts with RFC-1918 would
only serve to further increase the
probability that someone would consider this additional space for the same
purpose. I would not oppose
adding a reference to RFC-1918 that links to these documents as additional
related considerations.
WEG] "adding a reference to RFC1918 that links to..." means updating RFC1918,
which is why I suggested it. It is not necessary to rewrite/replace/obsolete
1918, and I believe that some of the language that you added to bdgks after our
discussion about how these cases are different from 1918 would be fine to help
prevent conflation between the two. It's incumbent upon us to ensure that the
draft is very crisp in defining acceptable and unacceptable uses of the space
and its relationship to existing RFC1918 uses, and I believe that this is quite
doable. Regarding increased risk of off-label use, all we can say is "don't do
this" and "only do this" using the strongest language we feel appropriate. What
implementers ultimately decide to do will be driven by their individual
business and technical needs more than whether or not we choose to update 1918
formally.
There is urgency to make the space available for use, so, the split you
describe does not actually help. The urgency
is to make this space available before providers start having to deploy NAT444
without it, or, at this point, more
accurately, to limit the amount of NAT444 deployed using GUA, Squat Space, or
any of the other alternatives
that these drafts show are a significantly worse alternative vs. this /10
shared transition space.
Pushing draft weil back as you describe would be extremely harmful IMHO.
WEG] this is exactly the type of hand-waving I'm trying to avoid when
discussing whether there's actually this much urgency and what is driving it.
While I've heard good support for this reservation of shared transition space,
and the concern that if we screw around for too long the address space will be
gone, I have not heard anyone saying "I need this within the next few weeks (or
even months) or I'm going to have to do something else." It's been over a year
since this round of discussion started (with
draft-weil-opsawg-provider-address-space-00), and yet no one has unequivocally
said "I'm being materially impacted by your failure to get this done *right
now*." As may be obvious, I work for a broadband residential ISP. This idea of
when/if we have to do CGN is pretty important to us and to my colleagues in the
industry right now, and I'm not hearing event horizons earlier than 12-18
months. If anything, people are starting to look at this and say, "wow, this is
going to suc
k, I wonder how long I can hold it off?" So I simply don't see the necessity
for short-circuiting the process. Even if the timeframe is more like 6 months,
we still have time to do this correctly.
I speak for no one but myself, but if you fall into the category of needing
this address space ASAP, you'd be wise to speak up to lend credence to the
perceived sense of urgency.
Wes George
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf