RE: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

["George, Wes" <[e-mail]>]

-----Original Message-----
From: Owen DeLong [mailto:[e-mail]]
Sent: Thursday, September 22, 2011 6:32 PM
To: George, Wes
Cc: Jari Arkko; [e-mail]; [e-mail]; [e-mail]
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 suck, 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.