August 2008 - NA-Discuss - lists.icann.org

El documento del procedimiento revisado de apoyo a los viajes de la comunidad para el año fiscal 2009
by At-Large Staff Aug. 28, 2008

Aug. 28, 2008

El documento del procedimiento revisado de apoyo a los viajes de la comunidad para el año fiscal 2009 http://www.icann.org/es/topics/travel-support/revised-procedure-11aug08-es.h tm 11 August 2008 1. 0 Antecedentes En varias ocasiones, la comunidad ha solicitado a ICANN que considere el apoyo a los viajes de la comunidad de diversas maneras, y que aporte claridad y transparencia en los procedimientos relacionados con este apoyo. ICANN dispone de un mayor número de recursos que en el pasado y es lógico que en estos momentos se vuelva a considerar el método que emplea ICANN para apoyar los viajes de los integrantes. A medida que madura la institución ICANN, se hace cada vez más importante realizar un análisis correcto del método de apoyo a los viajes y que éste se documente e implemente con transparencia. Muchas personas de la comunidad han solicitado un mayor apoyo para los viajes, aunque evidentemente no todas están de acuerdo. Además de los muchos comentarios anecdóticos que se recibieron de la comunidad, se organizó un foro de debate público durante la reunión de ICANN en Delhi en febrero de 2008. Asimismo, se abrió un foro público entre el 3 de marzo y el 24 de abril de 2008 durante el que se recibieron distintos comentarios. (Para obtener un resumen de estos comentarios, consulte: http://forum.icann.org/lists/travel-support-policy/msg00009.html.) También, el 2 de junio de 2008 se publicó un documento que propone una política específica para viajes. Consulte: http://www.icann.org/topics/travel-support/draft-procedure-22may08.htm . Este documento recibió una importante cantidad de comentarios por escrito, además de otros comentarios que se recibieron durante la reunión de ICANN en París. El resumen de los comentarios del foro se encuentra disponible en: http://forum.icann.org/lists/travel-support-draft/msg00013.html Sobre la base de este amplio debate que comprende dos consultas por escrito y debates públicos, el personal de ICANN propone un procedimiento actualizado para el apoyo a los viajes de la comunidad para las reuniones que ICANN lleva a cabo tres veces al año. (Nota: la palabra ³ procedimiento ² se usa en lugar de ³ política ² para evitar confusiones con el trabajo central de elaboración de políticas de ICANN). Este procedimiento se aplicará a los viajes para asistir a las reuniones de ICANN durante el año fiscal 2009. La eficacia de este procedimiento, incluso la cantidad de financiación o de cobertura de apoyo, procesos, etc., se revisará al final del año fiscal. La revisión se dará a conocer al público, y se considerarán los cambios necesarios para el procedimiento de viajes. 1.1 Propósito del apoyo a los viajes de la comunidad La participación en el modelo multilateral de ICANN implica costos de tiempo, energía, esfuerzo y, a menudo, gastos personales. Es completamente adecuado que los ingresos de ICANN, derivados de las tarifas de los registrantes, compensen una parte de estos costos. Al mismo tiempo, una de las ventajas de ICANN es que enlaza una variedad de intereses bajo el parasol de una comunidad cuya pasión y dedicación no se miden en términos financieros. Durante años, la práctica de ICANN ha sido compensar algunos de los costos de participación. Por ejemplo, la Junta directiva de ICANN y los coordinadores respectivos reciben la compensación de los gastos de viajes relacionados con ICANN. Tanto los miembros del Comité de nominaciones como los del Comité asesor de alcance también han recibido compensación para los gastos de viajes relacionados con las reuniones de ICANN. Evidentemente, existe un punto de equilibro entre propósito y presupuesto que se debe tener en cuenta a la hora de considerar hasta dónde ampliar el método de apoyo a los viajes y según qué principios. Dado que un objetivo principal del modelo multilateral de ICANN es el desarrollo de políticas, parece lógico ampliar el apoyo a los viajes disponibles a las organizaciones de apoyo (SO) que establecen la política de ICANN, ahora que ICANN cuenta con los recursos necesarios para respaldar esta ampliación. En general, el objetivo de financiar el apoyo para viajes debería ser disminuir las barreras para la participación, ampliar el grupo de participantes y adelantar el trabajo de ICANN. Es importante no perder de vista el hecho de que una manera clave de mejorar la participación es seguir mejorando la participación remota y aprovechar al máximo los gastos de viaje; realizando viajes de la manera más económica posible para el beneficio del mayor número de viajantes posible. 1.2 Revisión del apoyo actual a los viajes para las reuniones de ICANN Junta directiva y coordinadores de ICANN : la Junta directiva de ICANN recibe compensación para gastos razonables de viaje y alojamiento con el fin de participar en las reuniones de ICANN. Para los viajes con una duración superior a cinco horas, el viaje del miembro de la Junta directiva se reserva con pasajes en clase Business. Justificación: los miembros de la Junta directiva de ICANN tienen la responsabilidad personal y profesional más importante de la organización ICANN. La intención de este nivel de apoyo es reconocer dicha responsabilidad y proporcionar un mayor nivel de eficacia y comodidad durante sus viajes en nombre de ICANN. ALAC : actualmente, todos los miembros del comité reciben compensación para pasajes en clase Economy y un diario para participar en las principales reuniones de ICANN. Justificación: cuando se estableció la organización de alcance, se determinó la importancia de financiar la participación a través de viajes de todos los miembros del ALAC para respaldar las actividades iniciales. En la reunión de ICANN en París, la Junta directiva adoptó una resolución que afecta a los viajes de la estructura de alcance de dos maneras. En primer lugar, la Junta directiva aprobó una financiación específica para viajes para una sola ocasión, la cumbre de alcance. Esta cumbre se realizará junto con una asamblea de ICANN, y se financiarán los gastos para que un miembro de cada ALS asista a la reunión. En segundo lugar, la Junta directiva reconoció el hito que representa esta cumbre en el proceso de madurez de la organización de alcance, y solicitó que el apoyo futuro para viajes del ALAC coincida con el nivel de apoyo que se brinda al resto de las organizaciones de ICANN (según se documenta en este procedimiento de viajes). Comité de nominaciones : en general, los miembros del Comité de nominaciones no reciben compensación para viajes a las reuniones de ICANN, pero sí se compensan los gastos razonables y los pasajes en clase Economy para todas las reuniones de dicho Comité (el presidente actual, el vicepresidente y el presidente anterior del Comité de nominaciones reciben compensación por la participación en las reuniones de ICANN). Justificación: el trabajo del Comité de nominaciones va más allá del trabajo normal de desarrollo de políticas de ICANN, por lo que los gastos de los participantes se apoyan por completo. Programa de becas : ICANN ha operado durante el último año, aproximadamente, un programa de becas. El objetivo específico de este programa es aumentar la participación de personas y regiones que de otro modo no podrían participar en una reunión de ICANN. Los becarios reciben compensación para pasajes de clase Economy más un diario para participar en las reuniones de ICANN. Justificación : el propósito explícito de este programa es proporcionar apoyo a los viajes con el fin de ampliar la participación. 2.0 Procedimiento propuesto para el apoyo a los viajes de la comunidad El procedimiento propuesto para el apoyo a los viajes de la comunidad incluirá elementos de los procedimientos existentes para la Junta directiva y los coordinadores de ICANN, el ALAC y el Comité de nominaciones (se consideran los cambios esperados en los viajes del ALAC). Además, ampliará el apoyo financiero para incluir las organizaciones de apoyo de ICANN. No ofrece apoyo a los viajes a otras organizaciones de ICANN. Se mencionó en la reunión de ICANN en París y, con posterioridad, el presidente del GAC solicitó formalmente que el GAC reciba apoyo adicional para viajes (después del cierre del ciclo presupuestario para el año fiscal 2009). Para el año fiscal 2009, se espera que el programa de becas considere la posibilidad de dar prioridad a la participación del GAC (mientras se cumplan todos los criterios de becas) y que la solicitud del GAC se vuelva a evaluar durante el siguiente ciclo presupuestario, momento en que se revisará la política de viajes en su totalidad. En resumen, el nuevo procedimiento de viajes de la comunidad propone asignar fondos (según una metodología de cálculo transparente) para que cada organización de apoyo pueda destinarlos para asistir a las reuniones de ICANN. Cada organización de apoyo deberá acordar el proceso apropiado para determinar qué miembros de la unidad constitutiva recibirán dicho beneficio. En todos los casos, las solicitudes de apoyo para viajes se darán a conocer al público, y se espera que cada uno de los miembros que reciba el apoyo, presente un informe público de las actividades básicas y el interés de asistir a la reunión. Se diseñará un modelo de este informe en el programa de becas. El personal trabajará con las organizaciones de apoyo para minimizar la carga administrativa de esta actividad. 2.1 Elementos clave del procedimiento para el apoyo a los viajes de la comunidad Proporcionar apoyo financiero a los viajes a todas las organizaciones que participan en la creación de políticas para su participación en las reuniones de ICANN. (Nota: Como política, la ASO no ha aceptado fondos de apoyo para partidas como viajes. Si bien se lo reconoce, no es probable que se modifique, ya que el principio de equidad exige que la ASO sea tratada de la misma manera que otras organizaciones de apoyo en cuanto al método propuesto de apoyo a los viajes). Reservar un monto fijo para la financiación del apoyo a los viajes para cada organización de apoyo según una metodología de cálculo transparente. Cada organización de apoyo adoptará un proceso de selección y asignación para determinar qué persona de dicha organización tendrá el beneficio de la financiación, en función de cómo se satisfacen mejor las necesidades de elaboración de políticas de la entidad; los fondos sólo se pondrán usar para gastos de pasajes aéreos y otros gastos de traslado de los miembros activos de la organización de apoyo para asistir a las reuniones de ICANN. A continuación, se mencionan algunos ejemplos de lo que podría comprender el proceso de selección y asignación: un comité de viajes de la organización de apoyo con miembros de cada unidad constitutiva (o región geográfica) que sigue un proceso público para seleccionar a los miembros de la organización de apoyo que financia ICANN para asistir a cada una de sus reuniones; también dicha organización podría solicitar al personal de ICANN que lleve a cabo un proceso sobre la base de criterios que esta organización identifique. Para maximizar la participación, los viajes se harán en clase Economy. Sin embargo, el presidente de la SO viajará según la misma política que la de la Junta directiva de ICANN. La financiación del presidente con el mismo nivel que el de la Junta directiva reconoce la responsabilidad de los presidentes (similar a la de la Junta directiva) y es un pequeño incentivo para que acepten estos puestos. Un objetivo clave será hacer que la SO pueda implementar la política de apoyo con facilidad (consulte la sección ³Elementos prácticos ² a continuación). Si bien el cálculo de la financiación para el apoyo a los viajes se basa parcialmente en el tamaño de cada consejo y sus coordinadores, la SO puede decidir brindar apoyo a otros miembros representados en función de lo que sería mejor para el trabajo de elaboración de políticas de cada SO. Por ejemplo, se puede brindar apoyo a los miembros del grupo de trabajo. En todos los casos, los miembros designados por el Comité de nominaciones recibirán apoyo para viajes y en el mismo nivel que lo reciben otros miembros (según se describe en este documento de procedimiento de viajes). Los niveles de apoyo a los viajes para cada SO se determinarán del modo siguiente: ICANN asignará fondos suficientes para que el presidente, los miembros designados por el Comité de nominaciones y la mitad de los asesores restantes puedan recibir apoyo a los viajes (nuevamente, el apoyo a los viajes se podría usar para otras personas que no sean asesores). Se supondrá que el presidente viajará en clase Business. Los demás viajes se harán en clase Economy. Se supondrá que el precio medio de los pasajes en clase Economy será de USD 2 000 y en clase Business de USD 6 000. Se supondrá que el total de diarios promedios será de USD 2 800 por reunión. Se publicarán importes de diarios reales para cada reunión, en función de los estándares internacionales. Para el presupuesto del año fiscal 2009, el importe propuesto para viajes es el siguiente: ( http://www.icann.org/es/topics/travel-support/revised-procedure-11aug08-es.h tm) Cada SO y AC que reciba financiación para viajes deberá crear un proceso para la notificación pública con el fin de proporcionar transparencia y responsabilidad, así como para demostrar eficacia. La eficacia global de este nuevo procedimiento de apoyo a los viajes de la comunidad se revisará al final del año fiscal 2009. Debe tenerse en cuenta que este incremento en el presupuesto de explotación se financiará en gran medida porque el personal de ICANN viajará en clase Economy a las reuniones de ICANN. Elementos prácticos Cada organización de apoyo proporcionará al personal de ICANN una lista de los miembros de la SO que deberán recibir apoyo al menos con 60 días de anterioridad a cada reunión de ICANN. Todos los viajes se reservarán a través de una agencia de viajes aprobada por ICANN, a menos que esto no resulte práctico (determinación conjunta con el personal). Los detalles de las reservas se publicarán en el sitio web de ICANN. El personal de ICANN puede presentar excepciones para el método de viaje en clase Economy, en casos de problemas de salud documentados. ICANN pagará directamente los pasajes aéreos, otorgará una compensación razonable para otros métodos de viaje (p. ej. ferrocarril) y abonará un diario para cubrir todos los demás gastos (comidas, alojamiento, gastos varios, taxis, aparcamiento, etc.). Si ICANN paga directamente el hotel de un miembro, las comidas o el transporte, dichos costos se deducirán del diario. Dado que existen varias preguntas e inquietudes de casos especiales con respecto a los viajes, el personal de ICANN publicará y mantendrá un documento de Preguntas más frecuentes relacionado con el apoyo a los viajes. El objetivo será asegurar una buena comunicación de los detalles del apoyo a los viajes, así como una toma de decisiones justa y coherente en el transcurso del tiempo. Los participantes que acepten la financiación para viajes de ICANN deberán comprender y respetar el procedimiento de viajes y las Preguntas frecuentes relacionadas. -- Regards, Nick Ashton-Hart, Matthias Langenegger, Frederic Teboul ICANN At-Large Staff email: staff(a)atlarge.icann.org

1 0

The Internet's Biggest Security Hole Revealed
by Jeffrey A. Williams Aug. 27, 2008

Aug. 27, 2008

All, As if some of us for years didn't already know... Again this was discussed on several occasions in the old DNSO and some of us felt and likely still feel that the severity of this long known security hole was downplayed or ignored by ICANN and at that time, especially the IANA. Here we are nearly 10 years later, and still ICANN hasn't yet even recognize this security hole as a significant safety and stability issue. One has to wonder why... See: At DEFCON, Tony Kapela and Alex Pilosov demonstrated a http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html drastic weakness in the Internet's infrastructure that had long been rumored, but wasn't believed practical. They showed how to hijack BGP (the border gateway protocol) in order to eavesdrop on Net traffic in a way that wouldn't be simple to detect. Quoting: "'It's at least as big an issue as the DNS issue, if not bigger,' said Peiter 'Mudge' Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. 'I went around screaming my head about this about ten or twelve years ago... We described this to intelligence agencies and to the National Security Council, in detail.' The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network." Here's the PDF of https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-piloso… Kapela and Pilosov's presentation. Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0

Restoring the Safety Net
by Danny Younger Aug. 27, 2008

Aug. 27, 2008

For discussion in advance of the NARALO Monthly Meeting -- a proposal to the ALAC: Six years ago the ICANN Board resolved [02.83] to revise agreements with the unsponsored TLD registry operators so as to implement the Redemption Grace Period. The RGP is a time frame in which domain names that expire go into a period of stasis after their deletion so that inadvertent expirations can be corrected; the names are disabled during this stasis period so that the registrant's attention is better drawn to the situation. The Redemption Grace Period was widely heralded as an invaluable protective service with ICANN Director Abril i Abril noting for the record that "that the goal of the Redemption Grace Period is not purely technical or to preserve registrars' businesses, but is centered on preserving the legitimate interests of the registrants by installing a safety net." Unlike other ICANN initiatives, the RGP Safety Net was not established by way of the ICANN Consensus Policy process. The ICANN Staff sentiment at the time was that "Resolving all of the perceived issues surrounding domain-name deletions would likely require lengthy policy-development processes that meet the strict requirements for development of "Consensus Policies" set out in ICANN's various agreements with registrars and registry operators. The Redemption Grace Period proposal, on the other hand, allows a way promptly to solve a specific, pressing problem with the cooperation of the affected registry operators." Six years later, we have ample reason to believe that this error in judgment, the failure to invoke the Consensus Policy process, has led to a serious degradation in the degree of protection currently afforded to the registrant community. Framed as a "registry offering", it has been at the sole discretion of the registrar whether to offer or not to offer the Redemption Grace Period service -- and many do not. We have noted that some that offer the service will still deny the registrant the protections of the RGP in the event that they receive an aftermarket back-order for the expiring domain. What was once widely viewed as an ICANN consumer protection triumph is today little more than a degraded product offering engendering a morass of consumer confusion and aggravation, the situation having been exacerbated by the collusion of aftermarket profiteers and registrars to the point that (as indicated by Rob Hall at the Lisbon Tutorial on Changes in the Expiry Process) domains of value no longer enter the ICANN RGP. >From the very beginning, it was the sentiment of many in ICANN's GNSO community that a consensus policy approach was the best way way forward. The Business Constituency's Marilyn Cade, for one, noted that "consensus policy for RGP seems fully appropriate". We in the NARALO share this point of view and ask the ALAC, in accordance with the ICANN bylaws, to raise the issue for RGP consensus policy development by action of the Committee to commence the Policy Development Process, and transmission of that request to the GNSO Council. We further ask that upon requesting the formulation of a Staff Issues Report, that Staff be directed to supply the following within such report: a. a listing of all registrars noting whether they offer or do not offer the RGP service; b. a listing, by registrar, of prices currently charged for the RGP service; c. a listing noting which registries offer or do not offer the RGP; d. an assessment of the impact of aftermarket domain name practices on the RGP e. per the Expired Domain Name Deletion Policy 3.7.5.6 "If Registrar operates a website for domain registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee charged for the recovery of a domain name during the Redemption Grace Period", a listing of all such "statement" URLs of each registrar that offer the RGP; f. the status of the Bucharest recommendation of the Technical Steering Group that "ICANN's President should re-convene this (or a similar) Technical Steering Group to review the implementation of the Redemption Grace Period, to suggest possible improvements to the Redemption Grace Period, and to develop a specification for Stage 2 of the implementation of the Redemption Grace Period, which will enable registrants to choose the “restoring” registrar." g. an assessment as to whether it is now possible to engage in renegotiation of the charges for each restore command -- first set at $85 by ICANN and thereafter at $40, but with development costs long since amortized by the respective registries. We in the North American user community see great value in a universal safety net and in the enhanced registrar competition that will allow RGP prices to fall as consumers choose between the services offered by competing "restoring" registrars. A consensus policy directive should ultimately ensure that all gTLD domain name consumers have the blanket protection that they deserve. We ask the ALAC to set us upon a path that will bring this vision to fruition.

5 6

Re: [NA-Discuss] [At-Large] Re-engineering the Internet
by Jeffrey A. Williams Aug. 26, 2008

Aug. 26, 2008

Oliver and all, Anytime as a good time to bridge any gap, in this case it's late, even very late and the ALAC has not lead the charge nor does it have, or at least has not yet demonstrated that it has the expertise and widom/judgment to make reasonable, fact based decisions, especially of a technical sort. But glad to read you adding your voice, even if you are a bit mislead or under a bit of a misunderstanding, vis a vi the ALAC. Olivier MJ Crepin-Leblond wrote: > Patrick Vande Walle said: > > > This is where I think ICANN could and should be more active in fostering > > and sponsoring new research aimed at designing a new Internet, targeting > > the general public good, with no short term economic considerations. > > Granted, I do not expect ICANN to do the work of the IETF. However, I > > think > > it is not necessarily a good thing to let the engineers be in charge of > > everything, from the general vision to specifications and implementation. > > There needs to be a top level vision, a master plan of what we want the > > Internet to be in 10 years time. > > Can I also add my voice of support to this point of view? Having attended > ICANN Paris & IETF Dublin, I have realised how little cooperation there is > between those two constituencies. Worse, there is much distrust from either > side, often brought forth by individual feuds as well as misunderstanding of > issues (and of each other). > > IMHO it is time to bridge the gap, especially since challenges that lie > ahead of us are somehow far greater than anything we've had to tackle so far > and many of those challenges incorporate a mixed technical/political side to > them. I'm thinking DNS stability in the face of lots more gTLDs as well as > increased brute force hacking capability, IPv4 to IPv6 transition, Network > Neutrality, etc. > > I don't need to list them all here: the ALAC is well informed. > > O. > -- > Olivier MJ Crepin-Leblond, Ph.D. > E-mail:<ocl(a)gih.com> | http://www.gih.com/ocl.html > > _______________________________________________ > At-Large mailing list > At-Large(a)atlarge-lists.icann.org > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > At-Large Official Site: http://atlarge.icann.org Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0

Re: [NA-Discuss] [At-Large] Re-engineering the Internet
by Jeffrey A. Williams Aug. 26, 2008

Aug. 26, 2008

Patrick and all, Largely I agree with your sentiments below. But try to remember ICANN doesn't lead in any real sense, especially not in a technology sense. Nor should it at this time due to it's poor performing leadership. We have called time and time again for ICANN and the IETF to get away form the hiarcial DNS we know oh to well today and move towards a relational DNS. Those calls fell, and still fall on deaf hears. Private industry will either lead this migration our of advantage or necessity, and maybe even both. The IETF's and the IANA strong if not stubborn support of IPv6 a largely failed or failing protocol due to security and privacy considerations as well as application migration reasons, was doomed nearly from it's earliest beginnings nearly 10 years ago. But forward thinking business and technical folks that know this than, were shouted or "Hummed" down, and so we have the promotion of IPv6 such as it is and has been. Yet still failing to be very attractive even on the eve of the running out of IPv4 address space. But yet others are quietly moving forward with IPv8, and perhaps IPv9 and Dynamic DNS. Yet as you rightly indicate the "Cash Cow" of the legacy Internet becoming more and more a "Scam Cow" remains preferred. Yet I amongst others, remain undaunted and reticent that the Legacy Internet we use today is wilting on the vine as more and more governments are becoming more and more involved and willing to impose regulation that seeks to make the Legacy Internet "Safe", yet also further hampers it's appeal. Small wonder really given Phishing, Spam, and other forms of miscreant behavior becoming nearly insermountable as ICANN dragged it's feet for years to address these problems for too long in favor of "Cultural" issues. -----Original Message----- >From: Patrick Vande Walle <patrick(a)vande-walle.eu> >Sent: Aug 27, 2008 12:27 AM >To: At-Large Worldwide <at-large(a)atlarge-lists.icann.org> >Subject: Re: [At-Large] Re-engineering the Internet > > >Khaled, > >This is indeed an interesting debate to have. As we know, most of the >technology we use today was developed 25 years ago. Since then, there has >been no change to the fundamentals, but rather patches designed from the >start with backward compatibility. > >I think most people will agree that the DNS is broken beyond repair. The >changes we have seen over the years were all enhancements to the previous >standards. DNSSEC and IDNs come to mind. Both were designed to prevent >incompatibilities with older software. Punycode is ugly. We would need an >8-bit clean naming system. DNSSEC keys make zone files unreadable by a >normal human being. > >Note also that, over the last 15 years, most of the new developments in >Internet standards were developed by the industry, and not by government >funded academic research. The goal of the industry is make profits. Hence, >technical choices are mostly short or medium term and tend to perpetuate >existing economic models. >The DNS hierarchical model has been generating an interesting cash flow for >the registries and registrars (and ICANN, BTW). See for example the fact >that domain names have largely prevented Verisign from going bankrupt. >(http://www.domainpulse.com/2008/08/08/verisign-reports-68-million-loss-873-… >) > >The net result is that there is no real work done to change the fundamental >design to address new concerns. IDN ugliness and security are issues, but >so is the "one TLD, one registry" model, which prevents real competition in >the TLD space. More distributed models for naming systems, like CoDoNS >(http://www.cs.cornell.edu/people/egs/beehive/codons.php ) remain purely >academic, as there is no willingness from the industry to kill the cash >cow. > >I focused here on the DNS, but similar considerations could apply to other >parts of the Internet infrastructure, like traffic routing. > >This is where I think ICANN could and should be more active in fostering >and sponsoring new research aimed at designing a new Internet, targeting >the general public good, with no short term economic considerations. >Granted, I do not expect ICANN to do the work of the IETF. However, I think >it is not necessarily a good thing to let the engineers be in charge of >everything, from the general vision to specifications and implementation. >There needs to be a top level vision, a master plan of what we want the >Internet to be in 10 years time. From there, we could articulate work >packages and deliverables. > >This discussion is very relevant to the ALAC also. While it is good that >the ALAC provides comments on ICANN processes, it also needs to know where >it wants the Internet to go, especially in the naming and numbering area, >and articulate its positions according to its own vision. > >Patrick Vande Walle > >On Wed, 27 Aug 2008 07:35:52 +0200, Khaled KOUBAA <khaled.koubaa(a)gmail.com> >wrote: >> >> Re-engineering the Internet >> >> Source : http://iftf.org/node/2275 >> >> During a workshop at IFTF this week, I offered a forecast that there >> is at least a 50% probability of a fundamental re-engineering of the >> internet. Here's a bit of detail on this forecast and why I think this >> last week has been a critical turning point. >> >> Domain Name Services, DNS, like most of the Gen One Internet is a >> system built on cooperation. DNS servers have a narrow function to >> accurately translate domain names like ABC.com into numerical IP >> addresses, using an an up to date directory from other -trusted- DNS >> servers. The problem in simple terms is the length of the encryption >> key used by DNS servers to authenticate each other is short enough, >> that using modern high performance CPUs, it's possible to calculate a >> key to enable access to " poison" the DNS database on the server >> server with fraudulent routing information to misdirect any query for >> ABC.com to XXX.com. Dan Kaminsky, a 'white hat' hacker/security >> expert, has been telling Internet engineering leadership about this >> exploit for at least four years, and talking publicly, without revealing >> details, ( I heard him talk about this three years ago.) trying to >> provoke action. Finally, this last month Dan forced the issue by >> releasing the details into the wild along with short term patch using a >> longer encrypted number requiring a lot more computing power to decrypt. >> The Global Internet Engineering Security and Operations communities >> scrambled frantically, and deployed his patch in about three days, >> remaining open, vulnerable until then. Here's a video of the patch being >> deployed over several days:. Red are vulnerable domains, green are >> protected http://www.youtube.com/watch?v=Ff5WBDOwueI >> >> As we know, we are entering an era where super computing power will be >> trivially available on local multi-core processors, and on scalable >> platforms in the cloud. So it is inevitable that the current DNS patch >> will fall to superior decryption computation. So in the meantime limited >> software patches will forestall the inevitable crisis, that will occur >> when the black hat hackers have adequate computing cycles to break the >> encryption. This week most Internet routing experts agreed that we need >> a fundamentally more Secure DNS system that will withstand a massive >> assault. We may need a totally new, more powerful generation of >> software, computers, servers, routers and switches are necessary along >> with new operations regimens, and training and education for IT >> personnel. >> >> _______________________________________________ >> At-Large mailing list >> At-Large(a)atlarge-lists.icann.org >> >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… >> >> At-Large Official Site: http://atlarge.icann.org > > >_______________________________________________ >At-Large mailing list >At-Large(a)atlarge-lists.icann.org >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >At-Large Official Site: http://atlarge.icann.org Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827 Patrick Vande Walle wrote: > Khaled, > > This is indeed an interesting debate to have. As we know, most of the > technology we use today was developed 25 years ago. Since then, there has > been no change to the fundamentals, but rather patches designed from the > start with backward compatibility. > > I think most people will agree that the DNS is broken beyond repair. The > changes we have seen over the years were all enhancements to the previous > standards. DNSSEC and IDNs come to mind. Both were designed to prevent > incompatibilities with older software. Punycode is ugly. We would need an > 8-bit clean naming system. DNSSEC keys make zone files unreadable by a > normal human being. > > Note also that, over the last 15 years, most of the new developments in > Internet standards were developed by the industry, and not by government > funded academic research. The goal of the industry is make profits. Hence, > technical choices are mostly short or medium term and tend to perpetuate > existing economic models. > The DNS hierarchical model has been generating an interesting cash flow for > the registries and registrars (and ICANN, BTW). See for example the fact > that domain names have largely prevented Verisign from going bankrupt. > (http://www.domainpulse.com/2008/08/08/verisign-reports-68-million-loss-873-… > ) > > The net result is that there is no real work done to change the fundamental > design to address new concerns. IDN ugliness and security are issues, but > so is the "one TLD, one registry" model, which prevents real competition in > the TLD space. More distributed models for naming systems, like CoDoNS > (http://www.cs.cornell.edu/people/egs/beehive/codons.php ) remain purely > academic, as there is no willingness from the industry to kill the cash > cow. > > I focused here on the DNS, but similar considerations could apply to other > parts of the Internet infrastructure, like traffic routing. > > This is where I think ICANN could and should be more active in fostering > and sponsoring new research aimed at designing a new Internet, targeting > the general public good, with no short term economic considerations. > Granted, I do not expect ICANN to do the work of the IETF. However, I think > it is not necessarily a good thing to let the engineers be in charge of > everything, from the general vision to specifications and implementation. > There needs to be a top level vision, a master plan of what we want the > Internet to be in 10 years time. From there, we could articulate work > packages and deliverables. > > This discussion is very relevant to the ALAC also. While it is good that > the ALAC provides comments on ICANN processes, it also needs to know where > it wants the Internet to go, especially in the naming and numbering area, > and articulate its positions according to its own vision. > > Patrick Vande Walle > > On Wed, 27 Aug 2008 07:35:52 +0200, Khaled KOUBAA <khaled.koubaa(a)gmail.com> > wrote: > > > > Re-engineering the Internet > > > > Source : http://iftf.org/node/2275 > > > > During a workshop at IFTF this week, I offered a forecast that there > > is at least a 50% probability of a fundamental re-engineering of the > > internet. Here's a bit of detail on this forecast and why I think this > > last week has been a critical turning point. > > > > Domain Name Services, DNS, like most of the Gen One Internet is a > > system built on cooperation. DNS servers have a narrow function to > > accurately translate domain names like ABC.com into numerical IP > > addresses, using an an up to date directory from other -trusted- DNS > > servers. The problem in simple terms is the length of the encryption > > key used by DNS servers to authenticate each other is short enough, > > that using modern high performance CPUs, it's possible to calculate a > > key to enable access to " poison" the DNS database on the server > > server with fraudulent routing information to misdirect any query for > > ABC.com to XXX.com. Dan Kaminsky, a 'white hat' hacker/security > > expert, has been telling Internet engineering leadership about this > > exploit for at least four years, and talking publicly, without revealing > > details, ( I heard him talk about this three years ago.) trying to > > provoke action. Finally, this last month Dan forced the issue by > > releasing the details into the wild along with short term patch using a > > longer encrypted number requiring a lot more computing power to decrypt. > > The Global Internet Engineering Security and Operations communities > > scrambled frantically, and deployed his patch in about three days, > > remaining open, vulnerable until then. Here's a video of the patch being > > deployed over several days:. Red are vulnerable domains, green are > > protected http://www.youtube.com/watch?v=Ff5WBDOwueI > > > > As we know, we are entering an era where super computing power will be > > trivially available on local multi-core processors, and on scalable > > platforms in the cloud. So it is inevitable that the current DNS patch > > will fall to superior decryption computation. So in the meantime limited > > software patches will forestall the inevitable crisis, that will occur > > when the black hat hackers have adequate computing cycles to break the > > encryption. This week most Internet routing experts agreed that we need > > a fundamentally more Secure DNS system that will withstand a massive > > assault. We may need a totally new, more powerful generation of > > software, computers, servers, routers and switches are necessary along > > with new operations regimens, and training and education for IT > > personnel. > > > > _______________________________________________ > > At-Large mailing list > > At-Large(a)atlarge-lists.icann.org > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > > > At-Large Official Site: http://atlarge.icann.org > > _______________________________________________ > At-Large mailing list > At-Large(a)atlarge-lists.icann.org > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > At-Large Official Site: http://atlarge.icann.org

1 0

Re: [NA-Discuss] [WHOIS-WG] FW: Report of the WHOIS Study Hypothesis Group attached
by Jeffrey A. Williams Aug. 26, 2008

Aug. 26, 2008

Nick and all, Thank you for the study. Seems that the paranoia regarding proxy registrations remains strong. Seems also that the study doesn't provide any definitive information to justify such paranoia. Ergo, I can only conclude that this study takes the WHOIS problems very little closer to a viable or fact based resolution. Nick Ashton-Hart wrote: > Dear Working Group Members and At-Large Community Members: > > Attached please find the report of the WHOIS Study Hypothesis Group to > the GNSO Council as requested by the Council in its resolution of 26 > June 2008. > > -- > > Regards, > > Nick Ashton-Hart > Director for At-Large > Internet Corporation for Assigned Names and Numbers (ICANN) > Main Tel: +33 (450) 40 46 88 > USA DD: +1 (310) 578-8637 > Fax: +41 (22) 594-85-44 > Mobile: +41 (79) 595 54-68 > email: nick.ashton-hart(a)icann.org > Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / > Skype: nashtonhart > Online Bio:https://www.linkedin.com/in/ashtonhart > > ---------------------------------------------------------------- > _______________________________________________ > WHOIS-WG mailing list > WHOIS-WG(a)atlarge-lists.icann.org > http://atlarge-lists.icann.org/mailman/listinfo/whois-wg_atlarge-lists.ican… > > WHOIS WG Wiki: https://st.icann.org/gnso-liaison/index.cgi?whois_policy > Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0

Nominating Committee delegate for North America
by Alan Greenberg Aug. 25, 2008

Aug. 25, 2008

A public solicitation to the NA-Discuss list was made asking for nominations for the person to be the NA delegate to the Nominating Committee (which will chose next year's appointees to the Board, GNSO, ccNSO and ALAC). Currently, the NA delegate is Ross Rader, who is eligible to serve one more term. Only one public nomination was received, and that was to reappoint Ross. In parallel with the solicitation, discussions among the NA members of ALAC, and NARALO Chair and Secretariat, resulted in two nominations, specifically Ross and Dharma Dailey. Neither the ALAC members nor RALO representatives could come to consensus, and so both names are being submitted to the ALAC for their vote. Alan Greenberg, on behalf of Beau Brendler and Robert Guerra

1 0

Cybersecurity lacking in Africa, beware!
by Jeffrey A. Williams Aug. 25, 2008

Aug. 25, 2008

All, It seems that many of us were correct in recognizing that the approval of some African ccTLD's, by the ICANN Bod was likely, if not certainly, premature, if not a departure in good judgment. Too late however, the damage is now done. Next thing to do is to determine how ICANN, the responsible party largely, can facilitate providing for African countries so that users around the globe are not unwittingly damaged unnecessarily. Such work would go a long way in reducing Phishing scams, and other security related miscreant behaviors, which seem to be ever increasing out of Africa. See: http://www.networkworld.com/news/2008/082508-cybersecurity-lacking-in-afric… Africa will not realize the benefits of IT without improvements in cybersecurity, the secretary general of the Common Market for Eastern and Southern Africa (COMESA) said today. Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0

Election for NARALO ALAC Representative
by At-Large Staff Aug. 25, 2008

Aug. 25, 2008

Dear all, We recently sent out an email to the global list with a summary of the regional provisions governing the ALAC elections and a proposed timeline for the regional elections . This email is to provide you a detailed overview of the situation in North America and assist you with the organization of the elections. There will be one NARALO ALAC representative up for election this year as Beau Brendler¹s term ends at the close of the Cairo meeting. Please note that Alan Greenberg¹s term also expires at the close of the Cairo meeting. His seat will be filled by a NomCom appointment which will be announced in September. Beau Brendler has been nominated for a second term in an email sent by Robert Guerra on June 7th. Evan Leibovitch then sent an email to the list where he suggested having an election during the NARALO July meeting. According to the summary minutes, there has not yet been an ALAC election. With regards to the election process, the NARALO Operating Principles state that the length of the nomination period shall be 30 days and the start of nomination period shall be on or before 1 July (OP 11). The election date shall be "sufficiently in advance of ICANN's annual meeting" (OP 11). North America is one of the regions that have adopted detailed Rules of Procedure for meetings. Provisions for elections and voting during meetings can be found under: https://st.icann.org/naralo/index.cgi?ralo_organizing_documents <https://st.icann.org/naralo/index.cgi?ralo_organizing_documents It is up to the region to decide if it wishes to treat the election as if it were a meeting. Alternatively, NARALO can decide to adopt the following election process that has been suggested to the regional organizations without specified provisions : * The regional Secretariat will make a call for election no later than seven weeks before the start of the annual ICANN meeting (14 September 2008) * Nominations shall be accepted for two weeks after the Secretariat calls for nominations (until 28 September 2008) * The nominees need to accept their nomination no later than seven days after the nomination period ends (05 October 2008) * The election shall begin no later than one week after the end of the acceptance deadline (12 October 2008) and end not later than two weeks before the start of the annual ICANN meeting. (19 October 2008). In other words, votes would actually be cast between 12 to 19 October 2008. The votes would be cast via an electronic voting system (www.bigpulse.com) To facilitate this election, we ask the NARALO Secretariat to send us a note on the election procedures the region would like to adopt. Regards, Nick Ashton-Hart, Matthias Langenegger, Frederic Teboul ICANN At-Large Staff email: staff(a)atlarge.icann.org

5 12

[Fwd: Beware: Afilias.net and Afilias-nst.org DNS miss configured]
by Jeffrey A. Williams Aug. 25, 2008

Aug. 25, 2008

-------- Original Message -------- Subject: Beware: Afilias.net and Afilias-nst.org DNS miss configured Date: Mon, 25 Aug 2008 01:25:44 -0700 From: "Jeffrey A. Williams" <jwkckid1(a)ix.netcom.com> Organization: IDNS and Spokesman for INEGroup To: abuse(a)afilias.net,ICANN registry comments <registryservice(a)icann.org>,Ga <ga(a)gnso.icann.org>, DHS security alert <soc(a)us-cert.gov> CC: "ICANN Admin supp. Manager Karen Lettner" <karen.lettner(a)icann.org>,icann board <icann-board(a)icann.org>,icann legal <jeffrey(a)icann.org>,ICANN Policy staff <policy-staff(a)icann.org>,GAC Rep <ssene(a)ntia.doc.gov>, DHS Julie Myers <Julie.myers(a)dhs.gov> To whom it may and should concern, It has recently come to my attention that Afilias.net, and afilias-nst.org an ICANN Registry, DNS is grossly miss configured. Such would seem to be in conflict with ICANN's RAA contractual obligations and represents a clear and significant danger to any and all users, including current registrants accordingly. See: http://private.dnsstuff.com/tools/dnsreport.ch?domain=afilias.net&token=061… http://private.dnsstuff.com/tools/dnsreport.ch?domain=afilias-nst.org&token… Please take the appropriate and immediate necessary action accordingly. Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0