On 9/22/11 4:59 PM, "Jari Arkko" <jari.arkko@xxxxxxxxx> wrote: >> It's unclear from your statement if you're proposing adding the above to this >> draft or to a subsequent draft. > > Sorry. I think this should be a part of draft-weil. I think we'll end up > making further work in this space (e.g., if some RFC needs an update then the > actual update should probably be in another document) but I would like to see > the high level impacts documented here. 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. We hoped to leverage draft-bdgks for more detailed analysis. To some extent, the idea was to have a fast-track/slow-track approach to the conversation. I appreciate that progressing draft-weil in absence of substantial analysis may be undesirable, especially if there are concerns such as the ones you raised. However, I would like to make sure we don't lose sight of the need for some urgency with draft-weil. >> 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). >> 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. >> Assuming that it is in fact necessary to get the allocation completed >> rapidly, I'd rather see us split the logistics of making that happen from the >> process required to produce consensus documents. >> ... > > Interesting thoughts. We discussed some of that in the IESG as well. For what > it is worth, what I am asking should not be a long piece of text or require a > huge amount of analysis. Basically, it should state that the effects are > <here> and that these undesirable <implications> may be seen, and that <this > type of IETF specifications> need revision. Making those actual revisions > should be done in separate documents. This is good guidance for moving forward quickly with draft-weil. It's good to have the approach outlined by Wes as a backup option, but I agree that it amounts to effectively the same as allowing draft-weil to progress as-is. As for research into the alternatives, some of that was discussed in draft-bdgks. If you have specific thoughts on how to improve upon that analysis, I'd appreciate hearing them. Cheers, -Benson _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf