dburk

все выключить - нет разницы между одним отключением и другим

Финансисты(в первую очередь CFO), CEO, RIPE NCC stuff при участии Казначея (Treasurer) и - как правило - советуюясь с Chairman - исходя из бюджета - до General Meeting-a обсуждается совместно с Board-ом на заседании Правления http://www.ripe.net/info/ncc/board/minutes/fifty-eight.html и выносится на General Meeting -который или принимает или нет http://www.ripe.net/membership/gm/gm-octob...scheme-2008.pdf http://www.ripe.net/membership/gm/gm-octob...07/minutes.html ссылки иллюстрируют конкретный случай. Кроме ежегодного финплана и бюджета постоянно ведется долгосрочный 3-летний. Ежемесячно члены правления получают сводки о текущем состоянии дел. Я несколько удивлен - в документах весь процесс отражен

про IAA- DoC - это ко мне а остальное - в основе определяется вами же! Это класс - игнорировать списки расслки - почти как спам - а затем удивляться

Executive Board Meeting #67 will take place on 11 March 2009 at 13:00 at the RIPE NCC offices in Amsterdam. Lunch is served prior to the meeting at 12:00. А чего этот протокол не выложили? Что-то в NCC вообще всё очень лениво происходит... Выложат - это - правда - не ко мне - но там ничего интересного - у меня впечатление - что ты предыдущий не прочитал - там есть что спросить - по крайней мере меня

Что имеем? На странице последнее заседание - 28 октября. Ну как-то не растет EB в моих глазах как RIPE NCC member-а. поправили http://ripe.net/info/ncc/board/minutes/sixty-six.html Да - но при низкой активности возрастает вариант флэш-моба

Не совсем понимаю вопрос, что сказать-то? Как участвовать - в общем все равно - но чем официальнее, тем лучше. Т.е. лучше как как RIPE NCC, но главное - чтоб было интересно провайдерам-участникам, это главный критерий. Как RIPE NCC - в начале надо выиграть выборы :-) А доверенностей для голосования мало... Так что до 6 мая...

Наши попытки выйти на КРОС с каким-либо из подобных докладов понимания не нашли, увы. Вообще, предполагалось участие Буркова и Нетассиста с докладами, как в прошлый раз, - поэтому "резалось" все по аналогичной тематике. Для баланса. Сейчас смотрю - и похоже, что Нетассист не приедет, а человек вместо Буркова доклад еще не заявил (хотя еще "не вечер"). В общем, можно вопрос пересмотреть. ты мне скажи просто вовремя - и объясни - как мне как частному лицу или как RIPE NCC участвовать - иначе - кажется - больше проблем и возни - если надо, конечно

Есть разные точки зрения - в том числе и ее отсутствие - и есть неизбежная реальность - какой она будет в деталях - никто и нигде не скажет - есть разные варианты Кстати - DNSSEC не единственная напасть... Если это интересно (вся совокупность - а не какой-то кусок)- я могу на КРОСе на эту тему сделать презентацию/круглый стол - но не хочу навязываться - если не надо Сам по себе стандарт DNSSEC весьма универсален - вот только как его использовать - куча вопросов Не хочу повторяться про прошлый год - про опрос NTIA я здесь же на форуме писал - кто читает dns-wg тоже помнит полемику. Все обсуждения публичные - кто этим интересуется, либо знает - либо легко найдет Для ленивых - для простоты - ссылки на блоги для начала рекомендую внимательно прочитать первые две ссылки http://blog.internetgovernance.org/blog/_a.../2/4141451.html http://blog.internetgovernance.org/blog/_a.../3/4142495.html затем можно и это :-) http://blog.internetgovernance.org/blog/_a.../6/4142793.html Про альтернативный же русский - это не мы можем сделать - это нас с той стороны речки могут обрезать - поставить в определенное ... Я себя к маньякам не отношу и думал, что и среди коллег их нет - но после некоторых текстов из предложенного Cybersecurity Act 2009 (sorry - если повторяю) мне как-то некомфортно: http://commerce.senate.gov/public/index.cf...4&Year=2009 http://cdt.org/security/CYBERSEC4.pdf SEC. 8. REVIEW OF NTIA DOMAIN NAME CONTRACTS. (a) INGENERAL.—*No action by the Assistant Sec- retary of Commerce for Communications and Information after the date of enactment of this Act with respect to the renewal or modification of a contract related to the operation of the Internet Assigned Numbers Authority, shall be final until the Advisory Panel—* (1) has reviewed the action; (2) considered the commercial and national se- curity implications of the action; and (3) approved the action. (b) APPROVALPROCEDURE.—If the Advisory Panel does not approve such an action, it shall immediately no- tify the Assistant Secretary in writing of the disapproval and the reasons therefor. The Advisory Panel may provide recommendations to the Assistant Secretary in the notice for any modifications the it deems necessary to secure ap- proval of the action. SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. (a) INGENERAL.—Within 3 years after the date of enactment of this Act, the Assistant Secretary of Com- merce for Communications and Information shall develop *a strategy to implement a secure domain name addressing system. *The Assistant Secretary shall publish notice of the system requirements in the Federal Register together with an implementation schedule for Federal agencies and in- formation systems or networks designated by the Presi- dent, or the President’s designee, as critical infrastructure information systems or networks. (b) COMPLIANCE REQUIRED.—The President shall ensure that each Federal agency and each such system or network implements the secure domain name address- ing system in accordance with the schedule published by the Assistant Secretary. .... SEC. 18. CYBERSECURITY RESPONSIBILITIES AND AUTHORITY. The President— within 1 year after the date of enactment of this Act, shall develop and implement a com- prehensive national cybersecurity strategy, which shall include— ... (B) a plan that encompasses all aspects of national security, including the participation of the private sector, including critical infrastruc- ture operators and managers; ... * (2) may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal government or United States critical infrastructure information system or network; * ... *(6) may order the disconnection of any Federal government or United States critical infrastructure information systems or networks in the interest of national security; * ...

Это обсуждается в рамках dns-wg - но в отношении NCC - это не основное Не надо забывать - что в первую очередь это предмет интереса и деятельности ccTLDs/gTLDs registries - ICANN - IETF - ISOC и правительства США Для NCC - это вторично - это касается того - что под arpa - а это ISOC или IANA ответственность - формально там есть неясности А путаница в восприятии - от использования слов NIC в европейских названиях - вообще-то у нас в России это КЦ Что имеем? На странице последнее заседание - 28 октября. Ну как-то не растет EB в моих глазах как RIPE NCC member-а. Я тоже не понял - почему не опубликован декабрьский - мы его давно выдали - выясню

0. С критикой заголовка согласен - в прошлый раз за меня голосовало немало коллег из других стран - и мои моральные обязательства перед ними ничуть не ниже -иначе быть не может. 1.Ну - это зря ты - Фахада не слышал что-ли? Со мной косноязычным сравнивать... 2. Про DNSSEC А почему не почитать, что происходит - более того сегодня P.Koch предложил провести панель на эту тему на ближайшем RIPE митинге Читать можно везде в разное время - это все публично. Ситуация непростая - многие сгоряча на меня наедут - может Но вариантов пока нет - тот, что ведем - придуман согласованно с Крокером и многими другими А насчет собственного DNS - тебе хочется подписать совместно с NTIA - легко предложить - только как летать DNS будет? Вот и ответ. Это не единственная проблема - sidr c certificates веселее - и это неисчерпывающий список проблем. Кто еще не знает мой email (Белов в свое время прорекламировал Бутенко :-) - я не смог отказаться) dburk at burkov dot aha dot ru - все всегда welcome Дима Забыл уточнить - DNSSEC activity не имеет отношения к RIPE - это наша с вами проблема Так как никто не участвует в деятельности IETF и других

0. С критикой заголовка согласен - в прошлый раз за меня голосовало немало коллег из других стран - и мои моральные обязательства перед ними ничуть не ниже -иначе быть не может. 1.Ну - это зря ты - Фахада не слышал что-ли? Со мной косноязычным сравнивать... 2. Про DNSSEC А почему не почитать, что происходит - более того сегодня P.Koch предложил провести панель на эту тему на ближайшем RIPE митинге Читать можно везде в разное время - это все публично. Ситуация непростая - многие сгоряча на меня наедут - может Но вариантов пока нет - тот, что ведем - придуман согласованно с Крокером и многими другими А насчет собственного DNS - тебе хочется подписать совместно с NTIA - легко предложить - только как летать DNS будет? Вот и ответ. Это не единственная проблема - sidr c certificates веселее - и это неисчерпывающий список проблем. Кто еще не знает мой email (Белов в свое время прорекламировал Бутенко :-) - я не смог отказаться) dburk at burkov dot aha dot ru - все всегда welcome Дима

Дима, расшифруй плз для тупого лойера. Все - смотри здесь http://www.icann.org/en/general/agreements.htm JPA - Joint Project Agreement or Memorandum of Understanding (первоначально) - читай все дополнения тоже IANA functions Contract http://www.icann.org/en/general/iana-contract-14aug06.pdf остальное здесь http://www.ntia.doc.gov/ntiahome/domainname/nsi.htm чего не хватает - еще и здесь http://www.icann.org/en/nsi В общем - удовольствие это может доставить только лойеру :-)

Про нас писать заблаговременно - бестолково, никто читать не будет, а прочтет - не поверит или поймет. Я вообще-то про "оруэлловщину"... Кто такие "МЫ"? Законодатели и сильные мира сего? Тогда это точно, "МЫ" - туповаты и бзделоваты в прогрессивном национальном и 1. Иллюзий о величии собственных советских/русских/независимых от всего мира разработок не имею - особенно в области технологий требующих сквозной совместимости (interoperability) 2. LEA/Echelone/DPI/DMCA etc - тоже не наше - но при применении на нашей почве - вызывает весьма нервную реакцию ничего личного...

FYI 1 ICANN скорее сейчас площадка для обсуждения 2 ICANN выполняет свои функции под - JPA - соглашение с US DoC (NTIA) - IANA contract - DNS & IP addresses 3. Формирование и дистрибуция мастер файла корневой зоны исполняется Verisign по контракту на .com с US DoC 4 По всем контрактам DoC выполняет не только супервайзерские функции, но и формально принимает решения По сути - это стандартные госконтракты США на закупку услуг со всеми вытекающими последствиями Примечание За последние полгода NTIA - остановила ICANN с инициативой по DNSSEC - отказалась даже обсуждать завершение упомянутых госконтрактов, что фактически является от заявленной 10 лет назад политической позиции - а на рождество тормознуло основную за последние годы инициативу-проект ICANN по новым gTLDs Все сидят и ждут новых людей Обамы - но ничего хорошего я не вижу - все по сути зависит от доброй воли и текущих коньюктурных политических интересов чиновников одной страны. Фразу типа - мы хорошие ребята, с нами все будет хорошо, а потому поддерживайте нас - я слышал не раз и на разных языках... Не про нас было написано - но все более реально... кстати - особо в высокотехнологичном мире Мы же обычно копируем чужие технологии или просто их применяем - как теперь...

СОРМ?И как в таком случае понимать фразу про "механизмы управления интернетом"? http://forum.nag.ru/forum/index.php?showtopic=46559 Despite its promise, RPKI is controversial because it gives unprecedented operational authority to IANA and the regional Internet registries. For example, RPKI opens up the possibility that the registries could purposefully stop routing traffic to a particular block of IP addresses from a rogue nation such as Iran or North Korea. "If you use RPKI with BGP [security], you're fundamentally changing the Internet infrastructure. You're going from a distributed, autonomously operated routing structure to one with a root and authoritative sources," McPherson says. "We're going to have to accept that trade-off to secure the routing infrastructure.’’ При определенном сценарии развития тоже относится потенциально и к DNSSEC

http://www.networkworld.com/cgi-bin/mailto...p;site=security в принципе это не новость - просто в коротком тексте http://www.cyber.st.dhs.gov/docs/spriRoadmap.pdf надеюсь, что возможные последствия пояснять не надо...

Так сам-то проголосуй

Коллеги - я решил написать сюда по двум причинам 1. Большинство здесь LIR-ы 2. Большинство российских LIR-ов (contact persons) от многих списков ripe отписалось или сливает их в /dev/null Поэтому перепечатываю письмо из списка рассылки 9 октября USG DoC NTIA объявила о консультациях по внедрению DNSSEC. http://www.ntia.doc.gov/DNS/DNSSEC.html (рекомендую прочитать и комментарии) Все это может иметь последствия для нас. ( В этом посте вдаваться не буду - можно отдельно обсудить.) За последние недели это широко обсуждалось в RIPE коммьюнити - как в DNS WG, так и на последнем RIPE митинге. В результате был подготовлен следующий комментарий-заявление в адрес NTIA. На мой взгляд он получился сбалансированным и отражает и наши интересы и потенциальные болячки. Сейчас заканчивается финальное обсуждение-принятие этого заявления в ripe-list@ripe.net Предлагаю вам высказать в этот список (ripe-list) вашу точку зрения - поддерживаете или нет. Дмитрий Бурков PS1: хотелось бы знать, кто разбирается в dnssec - пока у меня представление, что катастрофически мало людей, разбирающихся в теме PS2: Это текст с переводом - в конце просто оригинал письма: The RIPE community thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. This view is supported by the letter from the RIPE community to ICANN as an outcome of discussions at the May 2007 RIPE meeting in Tallinn: http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community about the principles that should form the basis of the introduction of a signed DNS root. Сообщество RIPE благодарит NTIA за организацию консультаций по вопросу подписания корневой зоны и с радостью предлагает свой ответ. Мы призываем принять решение о скорейшем подписании корневой зоны. Наше сообщество считает, что подписание корневой зоны – это необходимый и своевременный шаг на пути к масштабному вводу DNSSEC как средства защиты DNS. Эта точка зрения поддержана письмом от участников сообщества RIPE в адрес ICANN как резальтат дискуссии на встрече RIPE в Таллине, май 2007: http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf. Ожидается, что сообщество, не менее разнообразное чем RIPE, не может иметь единой точки зрения в ответах на вопросы, предложенные в вопроснике NTIA. Ведь все члены RIPE будут отвечать на эти вопросы по отдельности. Мы предлагаем следующие положения, как собирательное мнение сообщества (рабочей группы DNS) по поводу основных принципов, которые должны лечь в основу внедрения подписания корневой зоны. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 1. DNSSEC предназначен для обеспечения целостности данных и защиты подлинности в DNS, а не для контроля. 2. The introduction of DNSSEC to the root zone must be made in such a way that it is accepted as a global initiative. 2. Внедрение DNSSEC в корневой зоне должно быть сделано так, чтобы оно было принято как глобальная инициатива. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 3. Внедрение DNSSEC в корневой зоне должно быть произведено таким образом, чтобы это не привело к нарушению стабильности и безопасности системы доменных имен (DNS). 4. When balancing the various concerns about signing the root zone, the approach must provide an appropriate level of trust and confidence by offering an optimally secure solution. 4. Сопоставляя различные варианты подписания корневой зоны необходимо учитывать, что выбранный путь должен быть максимально безопасным с технической точки зрения. 5. Deployment of a signed root should be done in a timely but not hasty manner. 5. Подписание корневой зоны должно быть сделано без излишней торопливости. 6. Updates from TLD operators relating to DNSSEC should be aligned with the operational mechanisms for co-ordinating changes to the root zone. 6. Для проведения своевременного обслуживания любые изменения, связанные с DNSSEC, должны быть проведены в соответствии с текущими процессами, ведущимися по координированию корневой зоны. Однако эти изменения должны обеспечивать достаточную гибкость процессов в целях их возможного изменения . 7. If any procedural changes are introduced by the deployment of DNSSEC they should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 7. Если в следствии внедрения DNSSEC будут изменены процедуры, эти изменения должны обеспечить достаточную гибкость, чтобы после соответствующих консультаций провести изменения не только в ролях и процессах, но и в субъектах, за которыми эти роли закреплены. 8. Policies and processes for signing the root zone must be transparent and trustworthy, making it straightforward for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. 8. Политики и процессы подписания корневой зоны должны быть прозрачными и вызывающими доверие, стимулируя домены верхнего уровня предоставить ключи и полномочия , для того чтобы делегирования для доменов верхнего уровня могли бы принести пользу от наличия общей точки доверия DNSSEC , подписанной корневой зоной. 9. There is no technical justification to create a new organisation to oversee the process of signing of the root. 9. Не существует никаких технических обоснований для создания новой организации по контролю подписания корневой зоны. 10. No data should be moved between organisations without appropriate authenticity and integrity checking, particularly the flow of keying material between a TLD operator and the entity that signs the root. 10. Данные не должны передаваться между организациями без соответствующей проверки на подлинность и целостность. 11. The public part of the key signing key must be distributed as widely as possible. 11. Публичная часть ключа должна быть распространена настолько широко, насколько это возможно. 12. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 12. Организация, которая генерирует файл корневой зоны, должна подписывать файл и хранить закрытую часть ключа (закрытый ключ) подписи зоны. 13. Changes to the entities and roles in the signing process must not necessarily require a change of keys. 13. Смена организаций и изменения ролей процесса подписания не обязательно должны требовать смены ключей. Оригинал Subject: Call for Support: RIPE response to the US NTIA's NoI From: Peter Koch <pk@DENIC.DE> Date: Fri, 14 Nov 2008 23:59:09 +0100 To: ripe-list@ripe.net Dear RIPE Community, as mentioned in my email sent on Monday, the DNS working group has come up with a response to the US NTIA's Notice of Inquiry (NoI) regarding the introduction of DNSSEC for the DNS root zone (for details see <http://www.ntia.doc.gov/DNS/DNSSEC.html>). The text below reflects the consensus of the DNS working group. As a follow up to our earlier efforts (see below), the DNS WG suggests that the response to the NTIA come from the broader RIPE community. So, this is the DNS WG's request for your support and endorsement of the proposal. Please read the text and voice your support or opposition. As mentioned earlier, we will have to meet an external deadline. Therefore, we are not looking for editorial suggestions. Regrettably, it is impractical to further refine or reword the text, since that would require more editing cycles and new consensus calls, which time won't permit. The WG chairs' collective and the RIPE Chair have agreed that it needs a binary decision on the proposal as presented here. It is possible that the text doesn't represent the optimum for everyone. Still, please consider whether you can support it as a community statement. In any case, the NoI is open for anybody, so you might want to send your individual response and/or contribute to other group efforts, as well. Clarifying questions are welcome, probably best asked on the DNS WG mailing list or to the DNS WG co-chairs <http://www.ripe.net/ripe/wg/dns/index.html>. Given the 24 Nov deadline and to allow some time for the evalutaion of the list traffic, you are kindly asked to send your explicit statements to this list no later than Friday, 21 Nov 2008 12:00 UTC. Thanks in advance for your consideration! -Peter Koch [DNS WG co-chair] ----------------------------------------------------------------------------- # # $Id: ntia-draft,v 1.9 2008/11/13 20:20:41 jim Exp $ # The RIPE community thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. This view is supported by the letter from the RIPE community to ICANN as an outcome of discussions at the May 2007 RIPE meeting in Tallinn: http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be made in such a way that it is accepted as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 4. When balancing the various concerns about signing the root zone, the approach must provide an appropriate level of trust and confidence by offering an optimally secure solution. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. Updates from TLD operators relating to DNSSEC should be aligned with the operational mechanisms for co-ordinating changes to the root zone. 7. If any procedural changes are introduced by the deployment of DNSSEC they should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 8. Policies and processes for signing the root zone must be transparent and trustworthy, making it straightforward for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. 9. There is no technical justification to create a new organisation to oversee the process of signing of the root. 10. No data should be moved between organisations without appropriate authenticity and integrity checking, particularly the flow of keying material between a TLD operator and the entity that signs the root. 11. The public part of the key signing key must be distributed as widely as possible. 12. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 13. Changes to the entities and roles in the signing process must not necessarily require a change of keys. -----------------------------------------

Ага! Точно также как в МРК. Нужно кабель кинуть, а в подразделении МРК ни одного монтера не осталось, всех сократили, одни начальники остались. Ну, говорят, позвоним в соседнюю область, может у них кто остался... Не путайте РТ с МРК

Неправда ваша - 6000-7000, если останется - то выживет - и выживет далее при любых условиях Не кадры нужны - а сокращение кадров...

Не совсем так - тогда была другая мысль - сквозной a-la "франчайзинг" в СИ и весь СИ под один ТМ (trademark) - единые услугиОстановили - это правда Текущий - имеет предтечу в другом старом предложении - в урезаном виде В принципе - и то и другое - довольно банально... Но всегда работают тупые вещи - вопрос - какой вариант сегодня более актуален...

В WinXP dns требует IPv4 - так что работать будет только с двумя стеками В общем - без ipv4 XP... покупайте Vist-у :-) если надо чистый ipv6

Я лечу из Шереметьева на полчаса позже.Могу составить компанию по прилете.