Re: Usage of services without IPv6 Support

[Fernando Frediani <[e-mail]>]

On 23/04/2020 12:03, Keith Moore wrote:
> On 4/23/20 10:49 AM, Fernando Frediani wrote:
>
>> Well, in order to show example and stick to values we have to get out 
>> of our comfort zone and not always do everything as we would wish. 
>
> We're supposed to be an engineering group, and engineering is all 
> about pragmatism and compromise.  IMO we should expeditiously 
> gravitate toward tools that best support our work, and that includes a 
> lot of considerations like supporting IPv6 and avoiding vendor 
> lockin.   But we should not let that impede our work. It's a difficult 
> balance to maintain because inertia gets in the way. It's easy to get 
> stuck.
Sure Keith, fully agree.
That's why I asked on my first message "What unique feature does it have 
that it has to be it?". With the other tools that have support will not 
the meeting happen the same and the work get done pretty much with the 
same efficiency? If so then it matches both criteria you just mentioned.
>
> IMO any vendor-provided services that aren't well-defined by open 
> standards or maybe open source code are inherently suspect, because we 
> won't be able to easily modify such tools to suit our changing needs, 
> or migrate to other tools that support our needs better.   Our 
> organization is dedicated to producing and promoting open standards, 
> so anything we use that isn't entirely or at least mostly specified by 
> open standards inherently puts us in a conflicted position and impedes 
> our work sooner or later.   Lack of IPv6 support is only one example 
> of an issue that results from reliance on nonstandard tools.

You said well: not just producing but promoting as well. That's why 
eating our own dog food is something pertinent here, specially when it 
doesn't bring any losses to the work to get done at the end.

Regards
Fernando