On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote:
> 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.
But, what we've been told by operators in the discussion about this draft is that "very unlikely" is not "sufficiently unlikely", and that no /10 within the set of RFC 1918 addresses makes the probability of a collision sufficiently unlikely. You may disagree with that claim, but I think we have to respect it.
> So now what we're talking about is how much we're willing to pay to make
> the collisions how much more unlikely?
I would certainly feel more comfortable with better data, but it seems highly unlikely that we can generate it.
- Ralph
>
>> 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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf