[GTER] Fwd: Balanço do SERPRO sobre ataques

[Cristiano Monteiro]

Olá,

Só pra ficar claro. O que eu falei foi que muitas vezes as operadoras não
exercem  a regulação pelo poder de compra, por não investir em R&D o
suficiente pra avaliar se um determinado protocolo atende ou não uma
demanda.

 Citei um exemplo claro de um protocolo que atende uma demanda e não foi
implementado em todos fabricantes.Mais uma vez quem determina a
implementação de protocolo não é IETF, nem os acadêmicos mas sim o mercado.

Minha crítica não era contra o IETF e não sei porque você tá levando pra
esse lado. Minha crítica construtiva é direcionada ao mercado que deveria
avalair melhor o que os fabricantes devem implementar ou não.

Pessoalmente não gosto da idéia de tercerizar pra  "gente muito mais
entendida das coisas"  a função de definir o que me atende ou não.


Cristiano



Em 1 de julho de 2011 14:52, Humberto Galiza <humbertogaliza at gmail.com>escreveu:

> Oi,
>
> No geral, as RFCs são documentos escritos de modo que foram pensandos a
> resolver problemas que afetam grande parcela dos usuários de tecnologia
> (genericamente falando). Infelizmente não há um mecanismo de impedir que a
> empresa A, cuja tem o funcionário X, sendo que e está escrevendo o draft da
> futura RFC saia na frente dos outros em sua implementação; isto é um caminho
> natural, já que a empresa está investindo grana nesta pesquisa e
> desenvolvimento de tecnologia. Sinceramente não considero isso lobby, mas
> sim pesquisa e desenvolvimento, e é lógico que a empresa vai visar auferir
> lucros com produtos oriundos deste projeto.
> IMHO, lobby é o tráfico de influência realizado sob determinadas
> circustâncias para fazer com que o draft/projeto Y resolva um problema
> localizado qualquer, cujo não afeta parcela significativa dos usuários, a
> fim de obter *apenas* vantagens comerciais.
>
> Um exemplo que acompanho de perto é o do procolo LISP que por sinal quem
> encabeça os esforços de desenvolvimento é um time de engenheiros da Cisco.
> Quem acompanha a lista do LISP percebe que a futura RFC não está seguindo os
> rumos que a Cisco quer, basta perceber a enorme quantidade de críticas que
> ele tem recebido desde as ideias iniciais. Ainda que ele venha a se tornar
> um draft candidato a RFC, ainda irá passar por mais um comitê misto de
> outras áreas do IETF, que irá aprová-lo ou não. Portanto não é um processo
> tão simples como você descreve.
>
> O IETF é um local púbico, portanto você pode escrever draft do que vc
> quiser; se vai passar e virar RFC é outra história. Considero o IETF um
> ambiente plural o suficiente e com gente muito mais entendida das coisas do
> que eu para detectar ocorrência de lobbies nos drafts.
>
>
> Att,
>
>
> Galiza
> Computer B.Sc. (UFBA)
>
>
>
>
> Em 1 de julho de 2011 14:35, Cristiano Monteiro <crmonteir at gmail.com>escreveu:
>
> Oi Galiza,
>>
>> Como você identifica um lobby ? Eu pago um funcionário e ele propõe um
>> protocolo no IETF vc acha sinceramente que este protocolo não tem um
>> interesse comercial ?
>>
>> A crítica é construtiva. Os fabricantes ocupam um lugar que hoje  está
>> vago. Não estou dizendo que os fabricantes não devam propor idéias pra
>> comunidade o que estou dizendo é que as operadoras que são os consumidores
>> de tecnologia deveriam regular através de sua ferramenta mais poderosa, o
>> poder de compra. Além ter  áreas de R&D mais ativas nos orgãos de
>> padronização.
>>
>> Exemplo, se protocolo de fulano é bom porque não pressionar os outros a
>> implementá-lo dentro de um tempo adequado.... É aí que está o pecado.
>>
>> Vamos citar o exemplo do BGP Flowspec. Ele foi proposto por um funcionário
>> da empresa A .Quando o draft foi pra rua  já estava implementado nos
>> roteadores da empresa A. Um outra empresa C não implementou o protocolo pois
>> se implementasse daria uma vantagem a empresa A que era a entrante no
>> mercado  e havia desenvolvido e testado a funcionalidade antes. O que vi
>> muitas operadoras fazerem ? Não vamos pedir o protocolo X porque ele não é
>> uma abordagem multivendor e o maior fabricante fica fora. Logo vira uma das
>> RFC´s fantasmas. Note que muitas vezes as tecnologias que vem do fabricante
>> dominante não enfrentam a mesma dificuldade mas percebe o que acontece ?
>>
>>
>>
>> Cristiano
>> Em 1 de julho de 2011 11:22, Humberto Galiza <humbertogaliza at gmail.com>escreveu:
>>
>> Oi,
>>>
>>> Cristiano:
>>> Quando há detecção de possíveis lobbies acerca de um determinado draft o
>>> pessoal de lá pega pesado com o lobista. Assim, não acredito que o IETF
>>> seja
>>> dominado pelos fabricantes como você afirma. Além disso, tem muita gente
>>> da
>>> academia envolvida na processo de padronização de RFCs.
>>>
>>> Att,
>>>
>>> Galiza
>>> Computer B.Sc. (UFBA)
>>>
>>>
>>>
>>>
>>> Em 1 de julho de 2011 06:59, Cristiano Monteiro <crmonteir at gmail.com
>>> >escreveu:
>>>
>>> > Quem regula o mercado ??? O consumidor. Se as operadoras começam a
>>> exigir
>>> > um
>>> > novo protocolo geralmente os fabricantes escutam. Hoje o IETF é
>>> > praticamente
>>> > dominado pelos fabricantes, o que é complicado, pois quem deveria
>>> dominar o
>>> > IETF e outros órgãos de regulamentação   na minha opinião deveriam ser
>>> os
>>> > consumidores e suas demandas.
>>> >
>>> >
>>> > Cristiano Monteiro
>>> >
>>> > Em 30 de junho de 2011 21:38, Rubens Kuhl <rubensk at gmail.com>
>>> escreveu:
>>> >
>>> > > >> Infelizmente, pelo que me lembro, há "pouco interesse da
>>> comunidade"
>>> > > para
>>> > > >> implementação deste protocolo e (por isso!!!) alguns fabricantes
>>> não
>>> > > >> tem interesse em suportá-lo.
>>> > > >>
>>> > > >
>>> > > > Nisso o NIC.BR poderia ajudar.
>>> > >
>>> > > Esse mercado é global, e a comunidade nesse contexto é a de
>>> operadores
>>> > > do mundo. O escopo disso é IETF, não GTER, por exemplo.
>>> > >
>>> > > E apesar de só ser suportado por um fabricante, esse fabricante é o
>>> > > maior fornecedor de core-routers das operadoras hoje. Se apenas esses
>>> > > roteadores bloqueassem já cortaria muito do poder de fogo de um
>>> > > ataque, talvez já para recair num volume que o próprio cliente
>>> > > conseguisse filtrar o resto.
>>> > >
>>> > >
>>> > > Rubens
>>> > > --
>>> > > gter list    https://eng.registro.br/mailman/listinfo/gter
>>> > >
>>> > --
>>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>>> >
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>