Re: [Autoconf] issues with draft-baccelli address model
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Autoconf] issues with draft-baccelli address model
Hi,
On Thu, Oct 29, 2009 at 7:25 PM, sratliff <sratliff at cisco.com> wrote:
>
> Absolutely correct. I agree 100%. And this is why I see this whole
> discussion as a tempest in a teapot.
>
> "discourage" != "cannot"
Absolutely! I also think that a large confusion comes from wording: I
assist Charlie and Stan that you _are NOT prohibited_ to continue
using your setting with LLs. Nowhere in the draft this is prohibited.
Nevertheless, I hope that the revised section by Charlie can help to
make that clearer. Are there any other opinions on that revised
section?
Ulrich
>
> No one supporting the Bacelli-Townsley draft has said you can't use
> link-local addresses. I support the Bacelli-Townsley draft, and most of my
> deployments use link-local addresses. My deployments will continue to use
> link-local addresses. But I do see that there are deployments where use of
> link-local addresses is either problematic, or impossible. So I understand
> the draft's language concerning "discouraging" their use.
>
> But the draft DOES NOT say they CANNOT be used. That's one of the reasons I
> support the draft.
>
> Regards,
> Stan
>
>
> On 10/29/09 2:07 PM, "Charles E. Perkins" <charles.perkins at earthlink.net>
> wrote:
>
>>
>> Hello Alex,
>>
>> I don't mind discussing with you. But I really don't
>> like having to point out your false statements so
>> often.
>>
>> Alexandru Petrescu wrote:
>>> Charles E. Perkins a écrit :
>>> [...]
>>>> So far the only hard problem seems to be how to avoid squabbling over
>>>> whether link-locals are needed.
>>>>
>>>> I am not sure why the proponents of necessity are so adept at
>>>> ignoring the solutions that do not need link-locals.
>>>
>>> It's very simple why: I have a prototype which involves protocol
>>> extensions (RA) only on the parts of the System which use exclusively
>>> link-locals addresses. You forbidding link-local addresses equates with
>>> forbidding my protocol extensions on the core of my prototype, makes
>>> all break.
>>
>> I _do not_ forbid link-local addresses. I'm not even one of the
>> document authors, and I didn't create that language.
>>
>> But the document does not forbid link-locals either.
>>
>> So how many times do you persist in making this false
>> statement, and, worse, basing your repeated, iterated,
>> verbose, relentless, and seemingly misguided objections
>> based on the false notion that link-locals are forbidden?
>>
>>>
>>>
>>>> It is not explainable by the existence of solutions that use
>>>> link-locals, because such solutions are universally acknowledged to
>>>> be useful in their realm of applicability.
>>>
>>> Is this formulation ok, or an "only" missing somewhere?
>>
>> ...???...
>>
>>>
>>> If you keep that formulation as is - I agree with it!
>>>
>>>> So why do link-locals insist on "their way come hell or high water"?
>>>
>>> BEcause I don't want my prototype discarded by an illogical sense of
>>> forbidding LLs.
>>
>> And in what universe does that prohibition reside?
>>
>> Regards,
>> Charlie P.
>>
>>
>> _______________________________________________
>> Autoconf mailing list
>> Autoconf at ietf.org
>> https://www.ietf.org/mailman/listinfo/autoconf
>
> _______________________________________________
> Autoconf mailing list
> Autoconf at ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.