On 02/10/2012 20:44, Noel Chiappa wrote:
> > From: Doug Barton <dougb@xxxxxxxxxxxxx>
>
> > You snipped the bit of the my post that you're responding to where I
> > specifically disallowed this as a reasonable argument.
>
> What an easy way to win a debate: 'I hereby disallow the following
> counter-arguments {A, B, C}, and since you have no other
> counter-arguments, I win.'
>
> Just because you don't think much of it, doesn't mean the rest of us have
> to agree with you on that.
I understand that. Do you understand that I understand what you're
saying, and I don't agree with you?
>
> > The new block's purpose is to make collisions impossible.
>
> Ah, no.
>
> If you were to say 'to make collisions very unlikely if it is used in the
> way it is specified', then I could agree with that.
Ok, let's go with that. We already have a way to make collisions "very
unlikely," don't use either of 192.168.[01]. Fortunately this method
doesn't require allocation of a new block.
So now what we're talking about is how much we're willing to pay to make
the collisions how much more unlikely?
> But to take a
> straw-man absolutist position like "impossible", and then knock it down
> with great pomp:
>
> > It cannot fulfill that purpose.
I was using shorthand (or argumentum ad absurdum if you prefer) to point
out that given the fact that this new block can't fix the whole problem,
and also given the fact that there are already solutions available that
fix most of the problem for free, allocating the new block is a bad idea.
> > it's a very irresponsible way for an SDO to conduct themselves.
>
> What, to say 'if you use this in a way that we specifically direct it not
> be used, any problems are your fault'?
Again, you snipped the bit where I answered this. Go back and re-read my
previous post if you're confused.
> > And that's assuming that this action doesn't have a cost, whereas
> > the truth is that it has several, both direct and indirect.
>
> And that would be...? How exactly does simply allocating a chunk of
> address space - something the Internet engineering community does every
> day - for a specific purpose "have a cost ... both direct and indirect"?
Again, I'm really trying not to dive back into the "should we" question,
but just as an example, there are 4,096 /22s in a /10. That's 4k new
SMBs that cannot get IPv4 space if this block is allocated.
If you want more, go look at the archives.
> If you're actually thinking of 'deploying CGNAT' in the text above, this
> discussion is not about that. That's going to happen no matter what the
> IETF says/does.
Yep, I get that.
> (Just like all those other NAT boxes the IETF huffed and
> puffed until it turned blue in the face about.)
FWIW I always said that the IETF sticking its collective fingers in its
ears and singing "la la la la la" instead of acknowledging the reality
of NAT and trying to figure out how to do it right was a big mistake.
> This is only about allocating a chunk of address space.
I wish that were true. :)
Doug
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf