On Aug 1, 2012, at 9:52 AM, Sylvain Vallerot <sylv...@gixe.net> wrote:
> > > On 01/08/2012 08:53, Greg Villain wrote: >> Mince alors… Gueudou et Frouny. >> …gros gros coup de mal du pays tout d'un coup. >> >> Plus sérieusement, j'ai tendance à croire qu'une partie de la faute incombe >> aux RIRs et >> aux équipementiers: > > good point, mais les équipementiers ne parviennent déjà pas à faire des > protocoles > tout à fait compatibles, faudrait en plus qu'ils aient la même interface ? > ciel… >> - on trouve difficilement une info uniforme sur l'ensemble des registriez >> - pour chaque registry on a pas le même accès ni le même output Oui enfin personne ne semble vraiment remettre en question la dictature des équipementiers, j'arrive pas trop a piger pourquoi sans rentrer dans des débats conspirationnistes de comptoir. Y'a un besoin, ça ressemble quand meme a un facteur vachement différenciant (c'est la raison pour laquelle j'aurais tendance a choisir du Juniper si j'etais encore dans le métier…). > ah c'est la beauté de whois : on peut tout servir avec whois. > >> - pour la plupart des équipementiers, c'est la misère d'automatiser de >> telles mises à jour. > > et sans compter que les infos disponibles dans la base du Ripe (je ne parse > que > les réponses de celle-là) ne sont pas conformes à ses propres spécifications > : que > ce soit les contenus des champs (genre import: ou export: pour au-num), ou > même > leur encodage qui est supposé être ASCII. Nan mais on est en 2012… l'ere des startups qui font des milliards en sortant un produit qui repose uniquement sur un mashup d'APIs… Tous les outils sont la pour ca. J'arrive pas a piger cette fascination des ingénieurs réseau pour les technos du passe: rancid, perl, expect, cacti… pour moi ça a un sens d'exiger des outils décents quand on sait que cote système les admins ont eux un niveau d'exigence beaucoup plus haut et pourtant des problèmes similaires a résoudre. Si le but des RIR est de veiller a la "bonne utilisation" des ressources IPs et que cela inclut de fournir les outils pour que personne se tire dans le pied, dans ce cas la c'est un cas évident qu'ils ne font pas bien leur job. RIPE semble avoir compris ça a travers les RIPE labs, mais dans ce cas, pourquoi ils communiquent pas avec les autres RIRs pour leur filer leur solution technique??? https://labs.ripe.net/ripe-database/database-api/api-documentation > > je me demande bien qui renseigne en détail sa politique de routage dans son > objet > AS et je me demande encore plus qui est assez fou pour lire et exploiter ces > informations. Aux US on marche sur la tete: les objets AS et Routes sont deliberement obfusquees en tant qu'infos confidentielles… C'est aberrant. Les RIR devraient s'assurer que c'est le cas. Je veux pas être fasciste, mais il semble trivial que c'est la source de sérieux problèmes (pakistan telekom vs gootube), et que les solutions ont l'air d'être assez évidentes. > >> (d'un coup je suis pris de panique, j'ai pas lu tout le thread… si ça se >> trouve ça a rien a >> voir avec la compote ce que je raconte). > > c'est complémentaire :-) > > bon cela dit moi sur un opé avec un CA de boulangerie j'arrive à générer des > filtres > et même toutes mes configs automatiquement en interrogeant le Whois, donc > j'imagine > pas bien que ce ne soit pas à la portée de tout le monde. Bin je pense que le fond de la question est que ça devrait requérir le moins de dev possible. Plus c'est facile a mettre en oeuvre plus la mise en place est systématique. Je pense que c'est un souci d'état d'esprit qui va avec le métier d'inge réseau - rien de ce que j'ai vu ces 10 dernières années dans ce coeur de métier ne me porte a croire que les inges réseaux cherchent a supprimer des taches de gestion ardues, répétitives et sans valeur ajoutees… (elle est un peu pourrie ma phrase…) > > +1 sur l'idée de l'API > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
