Annandale-on-Hudson - Bem, muito obrigado, é um prazer único e uma honra estar aqui. Depois de ouvir esta apresentação me parece que eu tenho que dizer-lhes que eu venho de um lado do mundo que carrega pouco peso – sem apresentação - e de uma tradição de padrões simples elaborados da melhor forma possível, e de experimentação. Este é o 20º aniversário do CGI que é um grupo de governança, um importante grupo de governança - eu comentarei mais sobre isso em um segundo - muito disso vocês já sabem, é claro. Realmente, eu estou aqui representando duas capacidades. Atualmente, como vocês ouviram, eu sou o Presidente da Diretoria da ICANN e todo nosso trabalho gira em torno da governança e estamos totalmente envolvidos nas grandes discussões e na evolução da nossa estrutura de governança. Provavelmente você já tenha ouvido que o governo americano há um ano, ao redor de um ano atrás, anunciou que estava disposto a finalizar o contrato que até então tinha tido com a ICANN no que se refere à função IANA que presta serviços ao mundo inteiro. No entanto, eles queriam ter certeza de que isto pareceria bem para todos e isto deu início a uma das mais intensas discussões e diálogos que eu já vivenciei em toda a minha vida – milhares de páginas, milhares de horas de trabalho humano todas as formas de controvérsias e abertura para todos que desejassem participar. Ainda está um pouco aberto, ainda há um pouco de incerteza sobre como tudo isso vai se desenrolar. O que supostamente seria uma pergunta relativamente simples se, como ICANN estamos preparados e funcionando adequadamente acabou por transformar-se em questionamentos muito, muito fortes e desafiadores sobre a estrutura de governança da ICANN e assim por diante, muitos dos quais tinham muito pouco a ver com a pergunta que de fato havia sido feita, que era: nós somos capazes de fazer a função IANA funcionar? Função esta que vinha funcionando perfeitamente há muito tempo. Portanto, isto é uma das questões que me trouxe aqui e a outra é muito simples. Eu sou um homem velho e me foi solicitado que falasse sobre o princípio (da Internet) e eu falarei um pouco sobre isso e tentarei tornar essa fala um pouco mais divertida do que algumas das discussões sobre a governança. Aqui está, eu falarei um pouco sobre as questões técnicas e um pouco sobre a inter-relação dos padrões – esta foi uma fala muito, muito boa, eu gostei muito. No entanto, sempre estou pensando com meus botões enquanto ouço o que está sendo dito e refletindo sobre as coisas. Um dos fenômenos que se pode observar é que cada empreendimento relacionado à rede tem que possuir um slogan, toda nova companhia tem um slogan, toda organização tem um slogan – o slogan da ICANN é UM MUNDO – UMA INTERNET. Parece-me que eu deveria perguntar qual é o slogan do CGI – eu deveria aprender esse slogan, mas o primeiro slogan que nós criamos no começo da ARPANET foi: REDES REÚNEM PESSOAS, o que era verdade, mesmo para o pequeno microcosmo de pequenos esforços nos quais estávamos envolvidos quando a ARPANET começou no final dos anos 60. Tudo começou com quatro notas ao redor da parte oeste dos Estados Unidos – UCLA onde eu me encontrava, Santa Barbara – Califórnia, a umas 100 milhas ao Norte de onde estávamos na Califórnia, o SRI que estava mais ou menos a 350 milhas ao Norte na Califórnia e a Universidade de Salt Lake City. A primeira coisa que aconteceu quando nós começamos a nos envolver uns com os outros foi que começamos a visitar-nos, o quê de fato acabou por produzir - como era de se esperar- formação de relacionamentos e de algumas amizades que persistiram por muito tempo. Portanto a noção de que a rede reuniria pessoas não se referia somente ao nível profissional, mas também englobava o nível social. Tendo observado este grupo aqui presente, além de outros grupos que também estão refletindo sobre suas próprias histórias, eu preciso dizer que as celebrações também reúnem as pessoas e, portanto nós temos um processo de construção sobre o que já fizemos no sentido de transformar tudo isso em um conjunto de relações muito complexas e muito ricas que foram construídas ao longo de certo período de tempo. E o tema sobre o qual me pediram para falar foi o tema dos primórdios – o que farei – mas eu também gostaria de prestar atenção sobre os primórdios daqui. Voltar vinte anos no tempo nos leva a 1995. Mas a história aqui, assim como a história da Internet, remonta ainda mais além dos marcos usuais do que chamamos “começo”. As coisas não principiam de uma vez só, você sabe, não começam com alguém sentando e dizendo “Isto é uma excelente idéia” e daí esta pessoa escreve um plano completo e antes que se perceba está tudo funcionando perfeitamente. Existe um período de experimentação, existe um período de exploração e de comunicação. Então me contaram, e eu peço desculpas, pois eu não tenho o conhecimento de primeira mão destes fatos, mas o que me contaram é que a história real data pelo menos de 1987 com uma série de reuniões, documentos e discussões, e que, além disso, aconteceram algumas experimentações, o que incluiu a formação de um time vital de pessoas, todos os quais, ou pelo menos a maioria dos quais, estão aqui como meu bom amigo Demi Getschko, Michael Standon, Alexandre Grosjgold, Alberto Gamide e Tadao Takahashi Estão todos aqui? Ah, que pena. Então, de qualquer forma, a questão é que existiu um período entre 1987 e 1995 que representa uma parte muito importante e rica da história daqui, mas que envolveu um número relativamente pequeno de pessoas plantando as sementes do que viria a florescer e, portanto quando chegamos a 1995 já temos informação suficiente, um número suficiente de pessoas já está a par, e já é possível formalizar estas relações e fundar a organização CGI que veio a ser tornar tão importante e tão eficaz - e eu acredito que sua importância deriva diretamente de sua eficiência. Eu mencionei que eu sou parte da ICANN e que nós estamos muito preocupados com a governança da Internet. Uma das fontes de inspiração para todos nós é, de fato, o modelo aqui do Brasil e na verdade nós temos tentado com afinco indicar esse modelo para outras partes do mundo uma vez que realmente acreditamos que este formato funciona muito eficazmente. Deixe-me retornar aos primórdios da rede de trabalho na qual eu estava envolvido. Eu mencionei que a ARPANET iniciou com quatro notas no final dos anos 60. O processo de decisão para construir a ARPANET deu-se ao redor de 1967, mas muito no espírito de manter o meu argumento anterior, sobre o fato de haverem acontecido coisas anteriormente, a ARPANET não começou com um momento único de insight, algo como: “Ah! Nós deveríamos construir uma rede”. Na verdade, algumas tentativas de conectar computadores já haviam ocorrido, muitos anos antes disso e a maior parte destas tentativas era limitada em sua natureza e muitas delas resultaram em fracassos totais, por diversas razões. É relativamente difícil pegar computadores que não tenham sido desenhados para comunicar-se entre si e fazer com que se comuniquem. De uma perspectiva técnica havia pelo menos dois grandes obstáculos: uma é que os computadores durante aquela era ou eram fundamentalmente orientados a lotes ou eram computadores para propósitos únicos e quando se tenta conectar dois computadores a pergunta natural do dia é: Bem, quem estará no comando? E como conseguir com que eles se comuniquem - isto é assumindo que você consiga que se comuniquem. Qual seria a base para o que eles virão a fazer? E o segundo grande problema é que eles - todos os diferentes computadores – foram uniformemente construídos para acreditarem que eles eram o centro de seus próprios universos e não havia interfaces, não havia acesso de hardware que facilitasse a conexão de um computador a outro. Havia interfaces de hardware, é claro, para conectar terminais, impressoras, drives de fita, unidades de disco e assim por diante, mas todos esses casos eram um único computador central conectado a uma série de periféricos que por sua vez eram responssivos. E quando se tenta conectar dois computadores a pergunta é: Quem está no comando? O que significa perguntar como fazer com que um dos computadores se assemelhe a uma instrução para o outro? Então, tendo dito isso eu não me alongarei sobre estes experimentos específicos, mas aconteceu um número considerável de experimentos, alguns dos quais são bem conhecidos. Por acaso, eu fiz parte de um desses experimentos relativamente caro no campus da UCLA que tinha como modesto objetivo conectar os três centros de computadores, sendo que todos estes funcionavam com o mesmo tipo de hardware – e esse experimento falhou devido à grandes diferenças políticas entre as administrações destas três organizações e não por que havia incompatibilidade de hardware. De qualquer forma o escritório de Washington que agora se chama Agência de Projetos de Pesquisa Avançados de Defesa e que antes não tinha o D no nome e, portanto chamava-se somente Agência de Projetos de Pesquisa Avançados, mas mesmo assim é a mesma Agência, possuía em sua estrutura um escritório que focava suas atividades na ciência e pesquisa da computação avançada e estava financiando pesquisas nos tópicos de ponta daquela época, em gráficos e em computadores mais rápidos, além de linguagens de programação interessantes e de sistemas de time-sharing e assim por diante. Todos estes projetos estavam tendo impactos bem importantes e a partir deste escritório eles vinham observando as tentativas fracassadas de conectar redes e eles sabiam perfeitamente bem que de uma forma ou de outra os computadores tinham que ser conectados – que eles tinham que ser conectados por uma variedade de razões diferentes, pudessem trabalhar juntas, talvez a partir de escritórios diferentes, e para aproveitar as diferenças nas arquiteturas de maneira que, por exemplo, pudesse ter uma ampla área de armazenamento de dados em um só lugar e sistemas gráficos muito chiques em outro local. Então, com este pano de fundo as discussões começaram no início de 1967 e frutificaram em 1968, o que acabou por levar à formação do chamado projeto ARPANET, que apresentava algumas características impressionantes – uma era que os computadores que iriam ser conectados não eram do mesmo tipo. Pode parecer que isto tornaria a tarefa ainda mais difícil, mas na verdade acabou por ajudar a separar as questões porque não foi preciso se envolver com o que um fabricante diria sobre como ele, especificamente, queria que seu computador fosse conectado. Eles também disseram muito claramente: “Nós vamos construir essa rede utilizando os centros de pesquisa já existentes”. Essa foi uma decisão muito interessante, pois resultou em alguns resultados sutis, porém muito importantes. Um destes resultados foi o fato que eles já sabiam quem seriam os usuários – eles não tiveram que sair a campo para vender a rede, eles não tiveram que torcer o braço de ninguém – uma vez que, para todos os propósitos práticos, eles eram efetivamente os proprietários de cada um daqueles locais de pesquisa, eles estavam pagando pelo orçamento eles estavam assumindo os custos de tudo. Então quando eles disseram que iriam construir essa rede utilizando locais que já existiam e pelos quais eles mesmos estavam pagando as pessoas que eram responsáveis por estes locais não tiveram muita alternativa a não ser concordar. No entanto as coisas não são assim tão simples. Algumas pessoas ficaram muito entusiasmadas com esta decisão enquanto que outras reagiram negativamente, dizendo, “por que você está me importunando com isso?” “Nós estamos fazendo pesquisas qualificadas, nós não queremos dividir nossos recursos com ninguém” e na verdade esta diferença acabou se manifestando na escolha de expandir a rede da costa oeste a costa leste, uma vez que foi o caso de que muita dessa resistência que eu descrevi se deu no leste enquanto que a maior parte da recepção calorosa veio do Oeste. Tendo crescido na Califórnia eu posso lhes dizer que a Califórnia é um lugar caloroso e amigável e talvez muito do que acabou acontecendo se deveu a isso. De qualquer forma, essa foi uma das decisões. Outro fator sutil sobre tudo isso acabou se revelando em uma das mais atípicas decisões gerenciais que qualquer um de nós jamais verá. Uma quantia significativa de dinheiro havia sido investida e foi gasta de maneira formal, através de contratos organizados, de licitações – todo o mecanismo governamental de licitações – para escolher o contratante que iria projetar o que nós hoje chamamos de roteador e que naqueles tempos nós chamávamos de IMP – Interface Message Processor A companhia Bolt Beranek de Cambridge, Massachusetts ganhou o contrato e eu devo dizer que eles realizaram um trabalho fantástico. Contratos formais também foram assinados com a AT&T, a maior companhia telefônica no que diz respeito ao fornecimento de linhas de longa distância, as linhas arrendadas que conectavam estes computadores uns aos outros. Um ponto chave, é claro - um tipo de ponto chave-duplo- foi que a ideia de comutação de pacotes havia se tornado muito atrativa e sedutora no sentido de que compreendíamos que a comunicação entre computadores seria esporádica e que seria possível conseguir um uso muito mais eficiente das linhas; e na verdade vinculada a esta ideia é que a criação da noção do roteador surgiu - como uma entidade separada dos computadores que estão sendo conectados. Alguém poderia ter imaginado que para estabelecer uma linha do Computador A para o Computador B e do Computador B para o Computador C, e assim por diante, seria necessário sobrecarregá-los com a responsabilidade de passar mensagens através deles em direção a alguma outra coisa, o interessante insight nesse caso foi a remoção desta função dos hosts (computadores anfitriões) e criar roteadores, exatamente o que fazemos hoje em dia. Estas foram as decisões de base que foram tomadas antes da construção da rede. As decisões que não foram tomadas eram relativas à: o que faremos com essa rede, que protocolos nós iríamos construir, quais aplicações iríamos inserir? Houve um pouco de discussão sobre essas questões, mas não houve uma decisão firme, não havia um programa planejado e não havia um cronograma. Não havia nenhuma atribuição quanto a estas questões. Ao invés disto o que aconteceu foi que a parte básica da rede foi instalada, os roteadores e as linhas foram instalados e foi dito aos locais que as recebiam “Descubram o que vocês gostariam de fazer com isso”, uma abordagem muito estranha e dependendo do seu ponto de vista, os resultados poderiam vir a ser ou perigosos ou brilhantes. Agora, o que de fato aconteceu foi que os locais que estavam recebendo estas notas eram, obviamente como eu mencionei anteriormente, grandes centros de pesquisa sendo que cada um deles era dirigido por um Professor Sênior que por sua vez possuía sua própria agenda e carreira para as quais possuía seu orçamento e, portanto estavam todos altamente engajados em produzir seus próprios projetos e fazendo com que seus graduandos fizessem o trabalho. E de repente chega essa mensagem dizendo que este departamento vai receber esta rede e, portanto eles fizeram exatamente o que você esperaria que eles fizessem. Eles disseram: “Humm, esta não é a minha tarefa primordial” e a passavam adiante. Na Universidade quando você passa adiante, passa adiante para os graduandos. Portanto, a tarefa de tentar descobrir o que faríamos com esta rede foi designada aos estudantes de graduação ou aos seus pares em todos estes locais diferentes. E da maneira pela qual as coisas se deram, eu tive o acaso de estar lá na hora certa e no lugar certo – Vint Cerf, um amigo de longa data e um colega de escritório foi um dos outros, John Postel outro dos que também estavam lá. Nós nos reunimos com nossos pares graduandos e membros da equipe das organizações não governamentais e começamos a conversa do zero. Não havia uma agenda sobre a qual falaríamos que tivesse sido previamente organizada, mas nós entendíamos as linhas gerais desta rede – nós sabíamos que haveria linhas de 50.000 bits/segundo e que o processo seria através da comutação de pacotes. Nós não sabíamos muito mais simplesmente por que não havia muito mais a saber. Então nós nos sentamos ao redor de uma mesa em uma sala na Universidade da Califórnia em Santa Barbara e muito rapidamente percebemos que, a grosso modo, tínhamos as mesmas questões na cabeça. Foi como em um coquetel quando você conhece pessoas com quem você se afina e ali mesmo nós tomamos uma das decisões críticas: de que iríamos continuar a nos falar e para tanto visitaríamos os laboratórios uns dos outros. Imediatamente compreendemos a ironia desta decisão uma vez que a rede deveria fazer com que economizássemos dinheiro em viagens e a primeira coisa que decidimos fazer foi começar a viajar pesadamente entre um local e outro. Este fato foi muito educativo para nós e acabou por causar alguns espasmos no orçamento. E ao longo dos meses seguintes, de Agosto de 1968 a Março de 1969, aproximadamente, em uma série de reuniões em cada um destes locais, nós começamos a gravitar em torno das ideias sobre o que faríamos com esta rede e sobre o que poderia ser feito. Algumas das ideias eram... eu as chamo de “as ideias fáceis”. Nós obviamente queríamos mover arquivos de um local ao outro, nós obviamente queríamos poder logar como se você tivesse discado de um lugar ao outro – tem um pouco de água aqui, mas eu acho que eu estou bem, obrigado – mas também nós estávamos profundamente cientes, profundamente cientes de que havia muitas, muitas, muitas outras possibilidades para além destas aplicações fáceis e simples Se nós meramente focássemos em conseguir fazer com que as coisas simples funcionassem, e não fornecêssemos uma base para que coisas além deste mínimo pudessem vir a ser realizadas, estaríamos seriamente perdendo importantes oportunidades. Então nós entendíamos que havia grandes coisas por aí afora assim como também entendíamos que não sabíamos quais eram essas coisas, e esta é uma posição muito estranha e desconfortável. Como eu disse, nós podíamos imaginar algumas dessas coisas, mas sabíamos que não poderíamos imaginar todas essas possibilidades. Portanto nós adotamos uma postura que, no sentido positivo você poderia chamar de humilde. Eu diria que nós estávamos simplesmente apavorados, nós queríamos ser muito cuidadosos e cautelosos então dissemos que iríamos colocar algumas das peças nos lugares nos quais achamos que elas possam vir a ser úteis e vamos fazer questão de deixar espaço para que outros construam outras coisas, e nós não tínhamos nem a certeza de que as partes que estávamos construindo seriam coisas que outros chegariam a usar. Então, se alguém decidisse contornar o que construímos e fazer algo isso também estaria bem. Então eu retornarei a este ponto, pois isso acabou por conduzir ao principio arquitetônico da abertura. Nós também não tínhamos nenhum ego quanto a estarmos a cargo de coisa alguma, nós não achávamos que tínhamos qualquer autoridade formal, nós esperávamos que outras pessoas viessem a participar e de qualquer forma não houve nenhuma estrutura que tenha sido imposta sobre nós, ninguém veio até nós e nos disse para reportar sobre isso ou aqui está o seu cronograma ou esta pessoa é que está no comando - portanto nós nos auto-gerimos durante aqueles vários meses. E então em uma reunião importante em Utah em março de 1969 – e até este momento nós vínhamos interagindo há um pouco menos de meio ano - nós percebemos que nós deveríamos cumprir a nossa obrigação natural e escrever algumas destas ideias. Nós estávamos sentados ao redor de uma mesa, todos nos conhecíamos, e sabíamos quem vinha defendendo uma ideia atrás da outra e assim nós lidamos com essa tarefa – você escreve sobre o quê você vem falando e assim por diante e eu recebi uma dessas tarefas e ao mesmo tempo me voluntariei para fazer a tarefa trivial da relatoria – eu disse: “Eu vou organizar isso para todos nós”. E eu levei essa tarefa a sério e ao longo das próximas semanas eu continuei tentando anotar como a organização destas notas se daria e a cada vez que eu iniciava a tarefa eu gelava, de puro medo. Eu pensava, para tudo que eu consigo pensar em escrever eu também consigo prever uma reação negativa, alguém virá e dirá: “você está assumindo uma autoridade que você não tem. Quem te colocou no comando?” – e uma chicotada. Eu quero dizer: eu estava no início dos meus vinte anos, eu não tinha um PHD ainda, então, você sabe, eu era dispensável na hierarquia tal qual ela estava estabelecia. Mas ao mesmo tempo eu estou obrigado a realizar esta tarefa. Então após diversas tentativas, eu me peguei uma noite, bem tarde, em uma casa onde um grande número de pessoas estava dormindo e eu não queria perturbá-las; então eu estava de pé no banheiro tentando resolver esse problema às 3 da manhã, e eu finalmente disse: OK – estas notas não possuem nenhum tipo de status, elas não possuem nenhum requisito para que sejam completas em si – escreva qualquer coisa que deseje podem ser tão curtas quanto uma sentença e não são nem mesmo publicações uma vez que não queremos ter que passar pelos ciclos de revisão que algumas instituições possuem. E para enfatizar esse ponto eu tive essa pequena ideia peculiar – Eu disse: Vamos chamá-las de “Requests for Comments” (Solicitação para o envio de Comentários), não importa o que elas sejam, mesmo que seja o mais formal e massivo dos documentos nós iríamos, só por uma questão de forma, chamá-lo de Solicitação para o envio de Comentários. O que eu achei que seria quase como uma piada e que em alguns meses nós teríamos a documentação formal e estas coisas murchariam. Isso não aconteceu, ao contrário, o que aconteceu foi que na verdade esse termo se enraizou e acabou por se tornar a forma de comunicação ao redor da comunidade da rede. Naqueles tempos uma vez que ainda não tínhamos a rede; tudo, absolutamente tudo que passava de um para o outro era um documento de “Requests for Comments” (Solicitação para o envio de Comentários) e entre outras coisas nós utilizamos a série de “Requests for Comments” (Solicitação para o envio de Comentários) para escrever a lista de correspondência que iríamos utilizar e a cada momento em que adicionávamos alguém à lista acabávamos por criar mais uma Solicitação para o envio de Comentários e, portanto eu tenho um grande número de “Requests for Comments” (Solicitação para o envio de Comentários) creditada a mim, mas se você for verificar verá que muitas delas não eram nada além de atualizações da lista de correspondência. As “Requests for Comments” (Solicitação para o envio de Comentários) estão ao redor de 6.000 hoje em dia, mas isso não é um número comparável ao que estávamos fazendo naquele tempo, uma vez que, desde que a rede foi construída nós temos o e-mail e nós temos uma classe subordinada de documentos chamada “Internet Drafts”(Rascunhos da Internet), que deveriam ter uma vida curta, de forma que quando chega o momento de escrever um “Requests for Comments” (Solicitação para o envio de Comentários), nos dias de hoje, esses comentários já passaram por uma enorme seqüência de mensagens e de “Internet Drafts” (Rascunhos da Internet) que ditam sobre o processo de consenso e na verdade não é de forma alguma uma Solicitação para o envio de Comentário, o que quer dizer é: “Cala a boca e leia isto”. Ainda é chamado de “Requests for Comments” (Solicitação para o envio de Comentários), já tentamos aniquilar esse esse nome e cada vez que surge essa discussão a coisa toda já está muito enraizada, mas eu estimaria que, e é difícil conseguirmos precisão nessa estimativa - mas eu vou simplesmente chutar um número as 6.000 SCs hoje representam algo na ordem de 600.000, uma expansão de 101 vezes dos tipos de coisa que estávamos fazendo lá atrás e, portanto o número é bastante substancial. As pessoas me perguntam, entre outras coisas, sobre o que nós podíamos imaginar quando estávamos construindo a rede. Eu acredito que nós não tínhamos nenhum problema em imaginar o quão importante a rede seria, não tínhamos nenhum problema em imaginar que os computadores seriam conectados uns aos outros. Eu jamais poderia ter imaginado que as singelas RFCs viveriam para além do ano calendário em que foram inventados. Existem muitas coisas que surgiram deste processo exatamente pela forma com a qual nós o iniciamos. Pela forma com que nos percebíamos quem éramos - - e particularmente quem não éramos - não impusemos nenhuma restrição de qualquer espécie, não impusemos nenhuma restrição de qualquer espécie, sem nenhuma cobrança. Sem nenhuma cobrança. Qualquer pessoa poderia escrever um desses documentos. Qualquer pessoa poderia ter um desses documentos. Quando nós começamos a fazer reuniões os encontros eram totalmente abertos, qualquer pessoa poderia comparecer. Ao longo dos anos este grupo se tornou o que originalmente chamamos de Grupo de Trabalho da Rede e este grupo se metamorfoseou ano após ano e hoje se encontra incorporado na Força Tarefa de Engenharia da Internet e, portanto nós temos um sistema de abertura que tem pelo menos três pilares, um é a abertura de acesso sobre a qual eu já falei, outro é a abertura de participação e aí, voltando ao primeiro ponto que eu estava enfatizando, um princípio arquitetônico de abertura de que estes novos protocolos que são criados são opcionais e são construídos para que qualquer pessoa possa trabalhar sobre seja lá o que for que já exista ou para que esta pessoa possa procurar uma alternativa ao que já exista e, portanto nós temos um processo muito vibrante, muito ativo, que ainda está em andamento nos dias de hoje. Existem mais de 100 Grupos de Trabalho ativos no IETF nos dias de hoje. Alguém poderia perguntar: Mas como pode ser? Os protocolos não estão prontos? Os principais que nós utilizamos todos os dias certamente estão prontos. No entanto existe uma combinação de melhorias a estes protocolos e de criação de novos protocolos e esta situação nos conduz à resultados muito peculiares e inesperados. Nós fizemos o “Packet Switched Voice” (pacote de comutação de voz) logo nas etapas iniciais em Harvard no que se refere à digitalização de voz e tentamos enviá-lo através da ARPANET. Era evidente que nós podíamos realizar esse procedimento, estava claro que a questão econômica seria viável mas ninguém poderia haver previsto que o provedor dominante dos protocolos e sistemas viria de um pequeno país do Norte da Europa, que naquele momento estava atrás da Cortina de Ferro, ninguém poderia prever que iniciaríamos isso na Estônia. Estas coisas eram simplesmente muito difíceis de enxergar. Então, eu acredito que estes três pilares da abertura têm sido extremamente dominantes. Outro elemento que está relacionado à palestra que vocês acabaram de ouvir é a questão da alçada. Os padrões que são criados no IETF não possuem a força da lei, não possuem previsões contratuais em si mesmas. São contribuições técnicas que têm o seu efeito, na verdade têm um grande efeito, pois geralmente elas funcionam, então o processo de reunir as pessoas e arrancar o consenso – e tendo observado o interior desse processo eu sou obrigado a concordar quanto a existência de todas as forças sobre as quais você falou (Liane), elas de fato acontecem, companhias pressionando, além de várias outras coisas. No entanto a ética prevalente e a regra é que todos deveriam estar presentes como indivíduos e que a qualidade técnica é a que deveria ser a regra dominante. Mas outro elemento que existe nesse processo é o pragmatismo, um senso muito enraizado de pragmatismo, consensos duros e códigos em execução e, portanto há muita ênfase em construir coisas, construir coisas rapidamente, experimentá-las e vivenciá-las antes de tomar as decisões de que esta será a especificação final. Então, este processo - que como eu disse não possui a força da lei, não possui a força contratual - tem sido a forma com a qual o IETF vem se desenvolvendo e em contraste com o que já é existente – e eu não estou aqui atirando pedras em ninguém nem tampouco criticando – mas esse processo tem sido, ou pelo menos costumava ser (talvez isso tenha mudado) muito mais rápido,muito mais simples e muito mais eficiente do que outros tipos de processos padrão. E, portanto acabou acontecendo o caso em que o Governo Americano estava adotando o perfil GOSIP para OSI onde você podia ir a escritórios que estavam triturando documentos massivos a partir do USI em máquinas que estavam comunicando-se umas com as outras utilizando o TCP-IP, o que é uma grande ironia que se pudesse, na verdade, comprar produtos que estavam sendo utilizados e que eles não estivessem prestando atenção ao fato de que o TCP-IP estava em uso enquanto eles estavam tentando dizer, bem, nós vamos adotar o OSI e isto irá dominar todo o resto. O jogo já tinha acabado bem antes disso, era somente uma questão de quando. E esta é mais ou menos a história principal. Diversas anedotas úteis surgem de tudo isso, muitos experimentos foram tentados e alguns falharam, sendo que os que falharam são enterrados muito rapidamente e aqueles que são bem sucedidos permanecem. As primeiras versões de correio eletrônico foram construídas sobre o protocolo de transferência de arquivos e posteriormente foi decidido que era necessário ter um protocolo de correio em separado O protocolo de correio que existe hoje - e eu posso dizê-lo a vocês - do ponto de vista técnico, é feio e tende a erros, não é algo do qual nenhum de nós deveria estar orgulhoso, e mesmo assim toda a nossa vida depende deste protocolo e isto tem sido, pelo menos a partir do meu ponto de vista, extremamente educativo. Eu posso lhes dizer que eu sou obrigado a pensar nisso quando estou sentado nas reuniões da governança nas quais as discussões algumas vezes são escandalosamente fora do ponto e algumas vezes as discussões são francamente perversas em sua natureza. Daí eu me recordo que isso não é fundamentalmente diferente dos comprometimentos que nós fizemos na arena técnica. Então eu relaxo e digo, tudo bem, nós vamos conseguir fazer o nosso melhor. Eu não tenho certeza, mas eu suspeito que já utilizei a maior parte do tempo a mim designado então eu vou concluir dizendo que eu sempre aprecio minhas vindas ao Brasil e considero estar aqui tanto um prazer como uma honra. E também quero novamente enfatizar que o que tem sido feito aqui no Brasil é realmente um dos pontos altos tanto em termos de capacidade técnica quanto em governança da Internet, na governança dos processos da Internet daqui. O Brasil tem sido visivelmente um líder, tão visível que, do outro lado do globo, eu posso ver o Brasil auxiliando outros países na elevação do nível e no funcionamento de seus próprios domínios; assim como também posso ver o esforço do Brasil em um tópico no qual venho despendendo muito do meu tempo: a promulgação da extensão de segurança DNS-SAC para o esforço do DNS. Frederico é um exemplo de alguém que certamente foi enviado por Deus no que se refere a ser prestativo, tanto ao redor do mundo quanto na própria região, e, portanto eu tiro o meu chapéu para todos aqui e aí está a razão pela qual eu acredito que o mundo olha para o Brasil e continuará a fazê-lo. Obrigado. Liane, Muito obrigado. Steve, muito obrigado. Steve, você tem um comentário? Sim, mas primeiro vou começar dizendo que na ICAAN não temos controle sobre o conteúdo ou sobre os serviços. Temos muito cuidado com a informação que acumulamos e, portanto o que vou dizer não tem nada a ver com a postura da ICANN, de fato tentamos ficar o mais afastados disso quanto possível. Eu quero falar sobre algumas coisas e quero iniciar com um pequeno incidente engraçado. Meu filho, de quem eu me orgulho muito, é advogado e trabalha para a Electronic Frontier Foundation (EFF), na Califórnia, e ele anda muito preocupado sobre a questão da privacidade. Um dia ele me visitou e notou que no meu Mac o buraco da câmera não estava coberto. Ele imediatamente sacou de seu bolso um pequeno bloco de etiquetas com a marca do EFF e com a minha permissão colocou uma destas etiquetas em cima do buraco da câmera - eu entendo seu ponto de vista, entendo com o que ele se preocupa e eu disse “- Perfeito - tudo bem” e deixei a etiqueta lá por um certo tempo. Algum tempo se passou e eu, ao precisar fazer uma chamada no Skype, afastei a etiqueta do buraco da lente da câmera, e mesmo após a chamada, eu a deixei assim, porque eu tendo a não ser tão preocupado sobre essas coisas quanto meu filho. Um pouco mais de tempo passou e eu fui para uma reunião na DARPA, localizado no Departamento de Defesa dos Estados Unidos e eles não quiseram que eu entrasse com o meu laptop. Eu insisti que precisava do laptop para esta reunião, e disseram que não havia problema - rapidamente apareceu uma pessoa que desligou o meu wi-fi e o Bluetooth, e vendo a etiqueta EFF, e o colocou sobre o buraco de lente da câmera O Departamento de Defesa dos Estados Unidos e e a Electronic Frontier Foundation assim absolutamente alinhados, ambos buscando esse mesmo tipo de segurança, bom... você entende. Eu fiz questão de contar este incidente para meu filho e ele disse “Ah, posso passar essa informação para a minha colega que fez os adesivos?” E eu lhe disse “Pode contar para todo mundo,você sabe, porque está tudo bem”. A privacidade é uma questão complicada. Se eu digo “Olá” para você - Isto é privado para mim ou privado para você, ou é privado para nós dois? E o problema já começa aí; ou você entra no seu restaurante favorito e imediatamente lhe entregam a sua bebida de preferência, porque você é reconhecido e lembrado. Isto é uma violação da sua privacidade ou é simplesmente um serviço? Há um enorme espectro e estamos muito longe de filtrar o que é aceitável daquilo que não só é aceitável como desejável – quem está sendo servido e para quê. Há claramente muito abuso, mas a questão é ainda mais complicada do que isso - dentro de uma determinada cultura, dentro de uma dada sociedade pode-se tentar encontrar o equilíbrio correto, mas se viajarmos ao redor do globo me parece que vamos encontrar diferenças bastante acentuadas. Certamente há países onde, quando alguém envia uma mensagem, o governo diz: “- Esta mensagem nos pertence, nós podemos inspecioná-la” - e não há discussão sobre a questão da privacidade no sentido que estamos discutindo aqui. Então, haverá vários confrontos vários confrontos dentro de cada país e haverá conflitos entre os países antes que consigamos alcançar um acordo geral Eu não acho que vai ser uma situação fácil nem de rápida resolução, e dou as minhas boas vindas – e acredito que todos também devemos saudar – à chegada de uma discussão vigorosa, porém informada, deste assunto, o que inclui criação de Termos de Referência relativamente comuns, de modo que quando você interage com alguém, eles, ao invés de lhe enviar um longo contrato que diz: “- Aqui estão os nossos termos e serviços e aqui está a nossa nova política de privacidade” – Quantos de nós, em algum momento, leremos essas informações ou quantos de nós compararemos linha por linha daquilo que daquilo que está sendo dito em comparação com o próximo cara? Atrevo-me a dizer que que precisamos de alguns padrões, quando me refiro a padrões não me refiro apenas a uma coisa, mas a um conjunto compacto de coisas que meros seres humanos possam entender - a estimativa típica de quanto um ser humano pode deter em sua memória de curto prazo é sete (+/- 2). Seria bem agradável se as declarações sobre privacidade e utilização fossem feitas em um vocabulário amplamente compartilhado entre os usuários de maneira para que todos nós possamos compreender. Esse então é o tipo de não-resposta sobre para onde as coisas estão indo, nenhum de nós gosta de ter a nossa privacidade violada, todos nós gostamos de ser bem servida, a informação que abunda em nossas transações é extremamente valiosa e grandes investimentos são aplicados na mineração de dados para que estes dados possam ser utilizados - algumas destas iniciativas são simplesmente para fins de marketing e outras são mais amplas e muito mais sofisticadas. Então acho que a única coisa que eu posso dizer é que não devemos banalizar a discussão sobre a privacidade é uma discussão extremamente importante, mas que também abrange muito conteúdo. Obrigado Fragmentação da Internet Sim, este é um processo do tipo gangorra, ele vai e volta existe um enorme valor em padrões, em interoperabilidade, em coisas de uso comum assim como existe um enorme valor em especialização, em captura e em dominância por empresas individuais e essas duas coisas competem vigorosamente, repetidas e diversas vezes. Você tem o negócio da telefonia celular com protocolos diferentes, você tem a Internet, com protocolos, por vezes, diferentes, você tem guerra dos “browsers” nos quais as novas funcionalidades - e isso ainda é verdade - novas funcionalidades são adicionadas de maneira que o conjunto só funcione com um determinado navegador e, então, surge a questão se isto vai prevalecer ou se estas coisas serão copiadas por todos os lados. Tivemos muita, muita sorte que os padrões comuns tenham prevalecido e que as tentativas de criar sistemas fechados não tenham caído em solo fértil. Estas tentativas conseguem sucesso por um período de tempo. O termo descritivo para esse tipo de prática é “jardins murados”. Você entra e então se encontra num ambiente controlado por pessoas e por uma determinada companhia e então você age da maneira deles. A vida nesses ambientes é boa se é isso que você quer fazer, mas você terá dificuldades se um dia resolver cair fora dali. Tipicamente os jardins murados colapsaram e, tipicamente, os padrões têm prevalecido, mas o desafio ainda permanece Eu poderia lhes dizer que da minha perspectiva a partir da ICAAN, que no que diz respeito ao sistema de atribuição de nomes, nós nos preocupamos bastante quanto à possível fragmentação e tentamos manter o espaço de nomes unificado e não baixamos a guarda sobre esta questão, pois isso não é uma garantia. Mas eu acredito que esta questão é algo sobre o qual devemos manter a vigilância, e recomendo fortemente a todos nós que detemos o poder de especificar como os sistemas devem ser - tanto como compradores quanto como usuários - que tentemos insistir no máximo de abertura possível. Então, você tocou em um nervo com essa pergunta, pois eu me importo muito com esta questão e eu acho que com a minha resposta vou conduzi-los por algumas veredas que podem surpreendê-los. Antes de eu entrar na parte interessante: quando falamos de segurança estamos realmente falando sobre um monte de coisas diferentes que se encaixam sob o mesmo guarda-chuva. Será que isso significa que meu computador não seja invadido por pessoas de fora? Ou será que significa que o tráfego que está passando através do meu computador para alguns outros lugares não está sendo lido ou alterado? Ou será que significa que o e-mail que eu recebo seja proveniente de fontes autênticas que eu reconheço? Então, isso é apenas o começo de uma lista bastante longa, portanto uma das precauções que devemos tomar quando falamos de segurança é notar que a segurança subdivide-se em um grande número de coisas distintas. E é fácil nos encontrarmos em uma sala cheia de pessoas que estão falando umas sobre as outras, mas não umas com as outras. Existe uma grande quantidade de dinheiro em jogo no que diz respeito à violação de direitos autorais e não é muito difícil que nos encontremos em uma sala cheia de pessoas,algumas dos quais dizem que temos que tirar estes sites do ar devido à questão de segurança, mas o que elas realmente querem dizer é que elas não gostam do fato de que seu material protegido por direitos autorais está sendo vendido ou disponibilizado sem o pagamento adequado de royalties. Um elemento com o qual eu me preocupo um pouco é se a estrutura de base da Internet está operando e funcionando bem ou se ela tem um potencial para para colapsar ou que alguém ou alguma coisa possa vir a interferir com essa estrutura. Há cerca de três, quase quatro anos atrás, cerca de quatro anos atrás, 2011, eu tomei conhecimento de um... (esta é uma história verdadeira e terei que contá-la em detalhes e, então me acompanhe) eu fiquei ciente da existência de um bug, um bug de software que tinha sido descoberto nas então atuais versões do BIND. Agora, BIND é o nome do software que executa a maior parte do DNS no mundo de 80 a 85% dos resolvers e servidores com autoridade, é esta a estimativa . Agora, o bug não estava em todas as versões do BIND e havia uma enorme quantidade de versões do BIND, porque o BIND continuava a ser modificado e alterado, o bug estava somente nas versões mais recentes. Assim o entendimento lógico é que este bug não seria, na verdade, evidente em toda a rede, mas apenas em uma fração pequena; mas ainda assim estava presente nas versões atuais do BIND daquele momento. A natureza deste bug era a seguinte: um pacote único, um pacote enviado para o servidor de DNS ou resolver, na porta 53 padrão, poderia levar o sistema a colapsar. Colapsar significa que o sistema ficaria fora de serviço e não mais forneceria respostas a consultas depois disso, até que o sistema seja reiniciado. Ademais, não existia nenhum mecanismo padrão para reinício. Então, essas são as más notícias, a boa notícia é que, bem, isso não foi um pacote que ocorre naturalmente, ele teria que ser muito especialmente construído e foi encontrado por acidente através de alguns mecanismos de mensuração muito sofisticados o que acabou por nos conduzir a uma investigação sobre como era a estrutura interior daquela referida versão do BIND. Mas, mesmo assim existia a possibilidade de que seria possível alguém se apropriar e construir sobre o que estava no pacote, enviá-lo para um endereço IPv4, porta 53 e se aquela porta estivesse executando essa versão particular do BIND então apagavam-se as luzes, fim de jogo. Isto seria muito desagradável para as pessoas que eram dependentes dessa versão do BIND e do respectivo servidor DNS e ainda muito mais desagradável para as pessoas que estavam gerenciando aquele servidor e fornecendo os serviços. E para as pessoas leigas - eu não sei qual é a mistura da plateia que está aqui - mas para ter certeza de que estamos todos na mesma página, o DNS está no coração de cada uma das transações que acontecem. Todas as vezes que você digita um nome do domínio tal como www.nic.br esta instrução tem de ser traduzida em um endereço IP. A tradução ocorre por uma série de consultas que acontecem em velocidade muito alta o que reduz a instrução a pedaços que então vão a um servidor - no nível raiz caso necessário - para descobrir onde estão as respostas para o nível .br , que então vai para dentro dos servidores, que por sua vez, irão lhe dizer quais são as respostas para o próximo nível .br e assim por diante. E, assim, finalmente, ejetará um endereço IPv4 e estas transações, como eu disse, acontecem muito, muito rapidamente e elas estão inseridas em tudo o que fazemos. Portanto, se o serviço DNS for desativado você está fora do negócio. Agora, como eu disse, um único pacote poderia derrubar um servidor específico, mas imagine o que aconteceria se alguém dissesse: “- Bem, que tal tentarmos isso para todos os endereços IPv4, os quatro bilhões de endereços IPv4?” – naturalmente, nem todos estão executando o DNS mas é possível fazer um um levantamento de fundo e descobrir quais deles estão rodando com DNS - e você identificará um número de alguns milhões, talvez. Então, como um experimento mental, você pode imaginar o que aconteceria se eu enviasse esse pacote em particular, este pacote matador, para cada um desses poucos milhões de endereços, quanto trabalho isso me custaria? Não muito trabalho, alguns segundos, poucos minutos, que seja. E, então, todos estes endereços morreriam. Agora você não tem um dia ruim para as pessoas que gerenciam esse servidor específico, você não tem um dia ruim para as pessoas que o estão usando, você tem um dia ruim e ponto final. Milhões de pessoas forçadamente deslocadas da Internet. Internet fora de serviço no mundo inteiro, “- Senhores e Senhores, interrompemos a programação para um comunicado importante” bem não se usa mais essa expressão - mas esta seria a notícia nos telejornais. Audiência no Congresso agendada para segunda-feira de manhã: : “Então, Dr. Crocker, o senhor é o Presidente do Conselho de ICANN, como você deixou isso acontecer? Você não é o responsável pela segurança para a Internet?” Não, bem, OK, então apenas pela segurança do sistema de domínio. Aqui diz em seu... Como você deixou isso acontecer? O que quer dizer com você não estar no comando do software? Quem está no comando do software?” Más notícias, este não é um cenário que você deseje contemplar – é claro que não aconteceu, mas realmente o cenário passou por minha mente. A próxima coisa que passou pela minha mente foi – bem, vamos supor que algo de ruim realmente tivesse acontecido. A primeira pergunta que me fariam seria: A quem você alertou? E com a força deste pensamento eu tomei uma atitude: eu realmente peguei o telefone e liguei para algumas pessoas no governo dos EUA e, uma vez que este bug tinha sido descoberto no Reino Unido, fiz em paralelo uma chamada coordenada com o oficial correspondente no governo do Reino Unido apenas para alertá-los que esse bug havia sido encontrao e que existia essa possibilidade extrema de que isso pudesse acontecer e, logo em seguida, todos os fatores de mitigação habituais entraram em ação – patches foram enviados, as pessoas que operavam servidores importantes foram notificados, etc. etc. Para entendermos o nível deste alerta, as pessoas que eu chamei foram Howard Schmidt, que era o oficial de segurança cibernética para a Casa Branca e Larry Strickling secretário adjunto de Comércio Exterior, agências do exterior O momento era inoportuno, era o dia 4 de Julho que é Dia de Independência, um feriado nos Estados Unidos. Por sorte eu os alcancei por telefone celular e e tivemos conversas muito curtas, mas positivas, e, como eu disse, nada de ruim aconteceu. Quase todos os envolvidos nessas discussões e nesse incidente tratam essa questão como o tipo de coisa que acontece a toda hora e argumentam que nós temos os nossos processos alocados para notificações e que nós temos os nossos processos designados para enviar patches rapidamente e dizem: nós retornaremos a este código e tentaremos fazer com que isso não aconteça novamente. Eu participei de tudo isso, mas eu tenho uma percepção diferente. O meu histórico técnico, além do meu trabalho com a rede, vem já de muito tempo. Nas minhas entranhas eu sou um matemático e um programador. E eu cresci com matemática, eu programei muito quando era jovem e fiz meu trabalho de pesquisa sobre a correção formal de softwares. Eu me afastei disso muito tempo atrás, mas esse incidente me fez pensar. Por que diabos acontece que esse software com esse tipo de bug sai a campo? Por que chega a deixar a escrivaninha do programador? Não é uma questão de nos lançarmos à tarefa de descobrir se houve ou não houve desleixo no trabalho, se houve ou não houve disciplina ou processo; nós sabemos que humanos estão envolvidos na criação deste software e nós não vamos fazer enormes mudanças na qualidade do que os humanos fazem. Nós vamos sim fazer enormes mudanças na qualidade do que computadores fazem, nós temos a Lei de Moore trabalhando em nosso benefício nos dando um fator de 10 a cada 5 anos a favor do computador; se você tenta mensurar qual é a melhoria na performance dos humanos você terá um fator de, você sabe, .0000ao longo de 100 anos, e as alavancagens não vão valer a pena; mas a questão que se passou pela minha cabeça foi: Por que a tecnologia para criar softwares não tem progredido ao longo de 40 anos no sentido de erradicar bugs simples? Existem muitas e muitas questões sutis, existem muitos termos profundos, existe a não-decidabilidade e assim por diante, mas para a classe dos bugs que nos infernizam, a vasta maioria das brechas que conduzem a estas brechas de seguranças, que conduzem a problemas como dia zero ou coisas semelhantes – e estes problemas geram uma enorme indústria de patches e coisas reativas, firewalls, verificadores de vírus e daí para frente - Por que nós estamos investindo dinheiro nisso e não estamos fazendo progressos no sentido de apanharmos essas coisas como parte do processo de pensamento antes mesmo que estes softwares saiam das escrivaninhas dos programadores? Então, na verdade, esta é a pergunta na qual eu tenho começado a colocar muita energia em tentar responder. Existe muito progresso na tecnologia no que tange a comprovação dos termos - além de outras coisas relacionadas – mas ainda não conseguimos e ainda não chegamos ao ponto em que tenhamos conseguido fazer uma diferença de primeira grandeza na maneira com queos softwares são produzidos - mas nós podemos fazê-lo, eu acho que nós podemos fazê-lo. Então, provavelmente este não é o tipo de de resposta que você estava esperando, existem muitas outras coisas sobre as quais podemos falar, mas eu acredito que se nós deslocássemos a nossa atenção no que se refere ao que demandamos, nós estaríamos em uma situação melhor. Uma pequena questão sobre isso: FORMAT é um hardware em processadores; é surpreendente, mas é verdade, que nós tenhamos cometido erros na aritmética dos computadores desde o começo. Existe literatura que você pode ler sobre esses erros na maneira pela qual diferentes computadores foram construídos. E isso não incomodou muito as pessoas, foi considerado algo menor, algo marginal, até que um dia a Intel tinha um processador que apresentava um bug muito pequeno em sua aritmética e o mundo enlouqueceu. Como é possível que haja um erro na aritmética nas máquinas que dizem: esta máquina contém Intel (Intel Inside)? E a primeira coisa que a Intel disse foi, bem, não é um problema muito grande, não importa tanto assim, mas se isso é realmente importante para você nós iremos lhe dar um novo processador que concerta esse problema. Não foi considerado o suficiente. A Intel gastou dois bilhões de dólares para substituir aqueles processadores e nós sabemos que a Intel é uma empresa muito respeitável, eles dedicam muito trabalho em fazer as coisas corretamente, isto não aconteceu porque eles foram descuidados ou porque não prestaram atenção. Eu conheço alguma coisa sobre a tecnologia que eles usam no processo de design, no processo de testagem e assim por diante - o que aconteceu não aconteceu por falta de tentativa de acertar. Ultimamente eles alocam ainda mais dinheiro e eles têm processos ainda melhores e eu tenho certeza de que esse tipo de coisa não acontecerá novamente, mas o mundo passou por essa mudança de foco e disse: “Como pode ser que isso tenha acontecido?”. É simplesmente inaceitável que tenhamos esse tipo de coisa. Imaginemos que cheguemos a um ponto em que - só imaginemos - alguém descubra um bug em um sistema operacional e a reação fosse: “O quê? Um bug no sistema operacional? Como pode ser?” Algo deu terrivelmente errado. Nós ainda não chegamos a este ponto, mas eu posso imaginar que venhamos a chegar. Então, você está me perguntando sobre o meu trabalho na UCLA e nós fomos colegas lá atrás, muito lá atrás, naquele belo ambiente da UCLA eu devo dizer. Então, as pessoas cometem muitos erros quando são jovens, e as pessoas cometem ainda mais erros mais adiante do caminho. Eu choquei cada um dos meus filhos, separadamente – e eles me percebem como uma pessoa altamente bem sucedida uma vez que estão todos presentemente lutando através de seus diversos estágios de desenvolvimento profissional – quando lhes digo que se eu fosse escrever a minha autobiografia eu a intitularia “Operação de Salvamento”. Foi realmente um erro atrás do outro. Quando eu me envolvi com o projeto ARPANET na UCLA eu tive que me concentrar na minha pesquisa sobre técnicas formais de comprovação e pelo fato de eu ter tido uma quantidade significativa de experiência com sistemas operacionais e e sistemas de software, pelo fato destas serem coisas que me pareciam ser úteis e principalmente pelo fato de eu ser indisciplinado e me distrair facilmente eu me deixei envolver como esse projeto ARPANET e no design de protocolos, assim como nas organizações dos processos sociais - organizar as pessoas ao redor destes processos. Agora, o meu orientador da tese, Jerry Estrin, que era uma pessoa fantástica, muito caloroso, uma pessoa que nutria muito as outras pessoas, ele corretamente diagnosticou que caso ele tentasse me dizer aquilo que eu deveria ter sabido, que o que eu deveria ter feito era pegar o trabalho que eu havia feito no ARPANET e escrever esse trabalho como uma tese de PHD. Se eu tivesse feito isso eu teria terminado o meu trabalho de graduação mais mais rapidamente e isso teria sido útil para o mundo e teria sido a coisa organizada e disciplinada a fazer. Mas ele não fez isso, pois ele sabia muito bem que eu não estava escutando, e que eu não teria trabalhado e teria simplesmente ficado, você sabe, chateado com ele. Então o que eu acabei fazendo foi trabalhar na ARPANET e eu fiz uma digressão ainda maior e fui trabalhar na agência que buscava financiamentos para a ARPA mesmo,por alguns anos. Daí eu insisti em retornar e estabelecer os métodos formais de comprovação que eu queria realizar. Eu desenvolvi uma técnica de comprovação que verifica a linguagem de código da máquina, com o objetivo de observar o código em um nível muito baixo e e muito precisamente modelar exatamente o que o código iria fazer e daí ser capaz de comprovar as propriedades daquele código. Eu terminei esse trabalho e continuei por alguns anos a conseguir financiamentos e a realizar algumas pesquisas sobre isso, mas o financiamento para esta área acabou sendo cada vez mais difícil naqueles tempos e ao longo do tempo eu acabei voltando a gravitar cada vez mais e mais de volta em direção da rede. Havia uma interseção entre a comprovação formal em si e o trabalho de segurança e, portanto havia algo como um par de passos entre essas duas situações. O pedaço do código; bem, e então para fazer esse tipo de trabalho o que se faz é o seguinte: se estabelece um sistema formal de raciocínio e daí é preciso desenvolver um sistema de comprovação que seja automatizado para que seja possível lidar com estas comprovações a partir daí se pode colher um exemplo e é possível então percorrer todas as partes tentando fazer a mesma coisa. E eu peguei um exemplo muito, muito minúsculo, que eu pensava ser somente um ponto de partida e que acabou sendo tudo que eu poderia fazer. Eu peguei uma seqüência curta de oito instruções que na verdade estava no IMP, simplesmente o pedaço menor possível de código e tudo que aquele código fazia - para aqueles de vocês que são tecnicamente treinados nestas questões - era alocar um buffer para fora da lista livre de buffers para um pacote entrando. Então, eram somente oito instruções que pegavam uma lista de links e desassociava um pacote e o fechava, e assim por diante. O conjunto de instruções daquela máquina era muito rudimentar, era uma máquina pequena e as instruções mais complicadas e poderosas naquela máquina eram uma troca de memória com o acumulador, simplesmente trocava dois lugares, um na memória e outro no CPU. Outro tipo de instrução daquela máquina era adicionar um à memória e pular para zero, o que é tipicamente utilizado para o controle de loop, mas havia esta ocorrência desta instrução que estava enterrada naquelas oito instruções e que não era destinada ao controle de loop, o propósito dessa instrução era contar quantas vezes aquele código havia sido inserido: era para propósitos de mensuração, simplesmente para contar a freqüência através da qual aquele pacote estava sendo alocado. Eu olhei para este código e eu pensei: “Como eu posso provar que este código vai funcionar todas às vezes, sob quaisquer condições?” e eu olhei para essa instrução de contagem e pensei: “O que aconteceria se chegássemos ao ponto em que o contador alcance marcas tão altas que venha a girar e zerar?” Ele irá pular a próxima instrução que é uma das duas instruções de troca neste código, o que é absolutamente central para a integridade deste lista de links? Isto não vai funcionar e ainda assim, agora eu tenho um problema, este código já vinha trabalhando no sistema por cinco anos e eu fiz os cálculos por alto sobre com que freqüência este bug provavelmente apareceria e me pareceu que ele surgiria uma ou duas vezes por dia, em cada IMP, ao redor de toda a rede. E eu disse: “Não, isso não pode estar certo”, pois um bug desta magnitude certamente já teria sido descoberto a essas alturas. Isto me levou algum tempo e eu tive que acabar pedindo ajuda para descobrir por que isto não era um bug E a resposta acabou sendo que havia outro pedaço de código que funcionava no plano de fundo que tomava uma amostragem, mandava essa amostra para o centro de mensuração e daí zerava novamente de forma a evitar que o contador transbordasse e agora o meu problema de tentar demonstrar se o código estava correto não era mais uma simples questão de demonstrar o que cada instrução estava fazendo, mas eu também tinha que demonstrar que aquele código que estava trabalhando no plano de fundo iria funcionar com a freqüência necessária e não iria ficar faminto por ciclos. Agora eu tenho que saber as velocidades da máquina, eu preciso saber com que velocidade estes pacotes estão entrando e eu preciso saber o tamanho destas linhas e talvez ainda seja necessário saber se estão funcionando em relógios de cinqüenta ou sessenta ciclos - dependendo em que parte do mundo estão situados - de forma a demonstrar que aquele código de fundo chegará lá a tempo. E agora a complexidade de comprovar até mesmo esse minúsculo fragmento de código é simplesmente ultrajante. Eu posso te dizer isso agora, uma vez que eles não podem tirar isso de mim, eu simplesmente disse: eu assumo que não irá sobrepor e eu continuei com a comprovação e assim por diante. Mas existe uma dose de complexidade em tentar fazer esse tipo de coisa, é difícil, e ainda por cima existe o inter-play. Eu não sei se era esse tipo de coisa que você estava tentando arrancar de mim, Ivan, ou se eu perdi o ponto completamente Não, não, está bem. Steve, muito obrigado..
Tecnico de seguranca do trabalho manaus ranking cursos de medicina no brasil Acre diabetes tipo 2 pancreas. São Paulo digi curso teste de velocidade Revisão, gerenciamento de projetos gratuito online Dissertação, curse of chucky die morderpuppe kehrt zuruck Outros tipos, unesc sc cursos Redação. Revisao kawasaki z300 os melhores cursos de ingles sp tecnico de seguranca do trabalho manaus Itu trabalhar no exercito como tecnico de enfermagem. Curso de gps em brasilia Outros tipos Santa Catarina art 513 cpc apelacao, aluguel de chacara para festa em franca sp.
Paulista:
Adam Terry, Kings: Adirondack Community College. Uberaba: Dominican College; 2013.
Audrey Lawson, Warren. Rio Grande: General Theological Seminary; 2016.
Carmen Bentley, Enright Road zip 10004. Rio Grande: Culinary Institute of America; 2009.