-----Original Message----- From: Benson Schliesser [mailto:bschlies@xxxxxxxxx] Sent: Friday, September 23, 2011 1:21 AM To: Jari Arkko Cc: draft-bdgks-arin-shared-transition-space@xxxxxxxxxxxxxx; ietf@xxxxxxxx; draft-weil-shared-transition-space-request@xxxxxxxxxxxxxx; George, Wes Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC Given constraints on existing IPv4 inventory (i.e. we're running out of the stuff), our desire has been to have draft-weil proceed without delay. <snip> However, I would like to make sure we don't lose sight of the need for some urgency with draft-weil. WEG] I won't repeat my comments to Owen here, but I will note that if the concern is about the availability of the address space, my suggestion would allow us to ensure it's available without any artificial (?) sense of urgency over getting the documents to a form that we're happy with. >> 1) Does IETF recommend the practice of inferring address scope in IPv4 based >> on address/bit value (the actual numbers), and then using this to trigger >> different behavior based on that inferred scope? > > We could probably have varying opinions on this, but I think the reality is > that software *does* depend on specific bit values, for better or worse. I > propose we spend our effort elsewhere, we can't change the situation. So what would this translate to, in terms of updates to draft-weil and/or draft-bdgks? I think it's safe to say that address-inferred scope will break in a number of circumstances - basically, every time an address+scope pairing is not what the implementation expects. And this concern exists for any new reservation that we make for scope purposes. As you pointed out, draft-bdgks makes note that either GUA or the Shared Transition Space (STS) will have a similar effect on existing implementations when deployed behind a NAT. The only way to avoid these impacts is to use RFC1918 space, because it's already well-known, which frequently is not an option (for reasons described in draft-bdgks). WEG] my thought is that it's useful to say exactly that - this exists, so if you're going to do it to avoid breakage, know that there's now additional space to be aware of, especially if we go the route of updating RFC1918. I do appreciate the clarification of the difference between deriving address scope based on bit value for defined-scope values vs. assuming that everything not included in that defined-scope of private space could be unique and global, but I'm not sure that particular distinction is important in the context of these drafts. Similarly, the idea that squatting on other GUA space has a similar problem is mostly interesting as a justification for doing STS instead of squatting, and so that idea is probably minimally important in the grand scheme of things. >> 2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as >> additional private-scope use cases? > > My personal concern was with making the impacts clear, but I think other > people in the IESG have commented on the updates aspect. I personally think it > would be useful if draft-weil updated RFC 1918, because then when someone > looks up RFC 1918 from the web site they would see the Updates: header and go > read the new RFC as well. We should be somewhat careful with this. I respect Wes' comments around updating existing documents etc. But we would need to update RFC1918 in a way that reflects the difference in scopes. The STS may have similar semantics as RFC1918 space, in that it's non-routable on the Internet etc. But it is not meant to be used in the same scope. While it would be appropriate (when possible) to use RFC1918 space inside a CGN, it would not be appropriate to use STS in many of the same places RFC1918 space is used. WEG] Agree, the wording and the distinction between the use cases are important, but I believe it is possible to articulate it properly. I think that crispness and clarity is required anyway, in order to clearly explain why these use cases are not simply solved by use of existing RFC1918 space. BDGKS is getting there, so let's refine that to address both your concern and mine. 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf