Skip to main content

Беглый взгляд на техническую «фабрику» корпорации ICANN и новости по CZDS

Во время недавних вопросов и ответов на неделе подготовки к ICANN69 с руководством корпорации ICANN меня спросили, как отдел инженерных и информационных технологий (E&IT) расставляет приоритеты в своей работе в целом и, в частности, как идет работа над Централизованной службой файлов корневой зоны (CZDS). Прежде чем я расскажу о CZDS, я хотел бы объяснить, как E&IT подходит к определению приоритетности проектов.

E&IT выступает в качестве основного «поставщика услуг» для ICANN. Поскольку системы не полностью соответствуют функциональным границам, определенным корпорацией, E&IT – это место, где межфункциональные воздействия становятся легко заметными. Таким образом, команда E&IT использует интеграционный и коллективный процесс для сбора требований к системам и определения приоритетов работы. Дважды в год старших руководителей корпорации ICANN просят оценить текущие и будущие потребности в проектах, связанных с E&IT, соответствующих их подразделениям. Проекты могут быть относительно простыми, например оптимизация инфраструктуры компьютеров, сетей и хранилищ, или более сложными, например заказное создание специализированных программных систем, а также оптимизация инфраструктуры для работы с такой системой. Этот процесс включает в себя сбор отзывов от каждой команды, согласование предложений по проектам с заявленными стратегиями организации, понимание межфункциональных зависимостей и воздействий, рассмотрение отзывов сообщества и определение приоритетности запросов. Это приводит к упорядоченному списку требований E&IT для каждой функции в корпорации ICANN.

Затем эти проектные требования сопоставляются с доступным капиталом (на основе проверенных сообществом и утвержденных Правлением ICANN бюджетов) и возможностями E&IT (на основе производительности внештатных сотрудников E&IT, включая внешние ресурсы). Это основные факторы, используемые для определения того, сколько проектов, зависящих от E&IT, можно выполнять в каждом семестре (январь-июнь и июль-декабрь). Это помогает устанавливать разграничения в упорядоченном списке требований.

Окончательный список проектов E&IT называют «замороженной цепочкой проектов». Каждый семестр «замороженная цепочка проектов» сначала проверяется и утверждается старшими вице-президентами ICANN, а затем генеральным директором ICANN, что приводит к определению набора предполагаемых результатов. Любые изменения, внесенные в план, включая добавления или исключения из проекта, вызовут проверку генеральным директором.

Чтобы помочь внутренней организации и координации «замороженной цепочки проектов», работа E&IT разделена на семь рабочих потоков. Первые шесть относительно не пересекаются, в то время как все рабочие потоки обычно в той или иной форме сходятся в седьмом (усиленная ИТ-инфраструктура). Семь рабочих потоков:

  1. Взаимодействие с сообществом: работа, связанная с поддержкой взаимодействия с сообществом ICANN. Например, системы, поддерживающие программу Fellowship ICANN, структуры сообщества ICANN и программы командировок.
  2. Сотрудничество с сообществом: работа в основном связана с инструментами и веб-сайтами, используемыми корпорацией ICANN, организациями поддержки (SO) и консультативными комитетами (AC). Инициатива по обеспечению информационной транспарентности (ITI) попадает в эту категорию.
  3. Стороны, связанные договорными обязательствами: работа по поддержке транзакционной работы, связанной с регистратурами и регистраторами, включая портал для поставщиков услуг в области доменных имен (NSp).
  4. Технические услуги: работа, связанная с многочисленными системами, которые используются корпорацией ICANN и/или сообществом ICANN для обеспечения выполнения договорных обязательств сторонами по договору. К этой категории относятся такие системы, как мониторинг соглашений об уровне обслуживания (SLAM), доступ к файлу корневой зоны и CZDS.
  5. Услуги Администрации адресного пространства интернета (IANA): работа, связанная с системами, используемыми сообществом и группой IANA для выполнения функций IANA, включая управление корневой зоной.
  6. Услуги персонала: работа, связанная с системами, обслуживающими корпорацию ICANN, включая функции планирования ресурсов предприятия (ERP), такие как HR и финансы, интранет, электронная почта, телефонные системы, Slack для внутренних сообщений и т. д.
  7. Усиленная ИТ-инфраструктура: работа, связанная с системами и услугами, используемыми всеми заинтересованными сторонами, перечисленными выше. Включает такие системы, как Zoom, центры обработки данных, облако, информационную безопасность и корневые серверы под управлением ICANN (IMRS).

Помня об этом процессе определения приоритетов, я хотел бы более подробно остановиться на CZDS, поскольку сообщество продолжает проявлять интерес.

Несколько лет назад CZDS была переработана путем переноса платформы на комбинацию Java для подателей запросов, взаимодействующих с сообществом ICANN, на внешнем интерфейсе, и Salesforce для согласованных сторон, утверждающих запросы, на серверной части (также объединяя эту функциональность в NSp). Эта работа завершена в январе 2019 года. Начало было хорошим, однако есть дополнительные элементы работы, которые необходимо рассмотреть, чтобы CZDS соответствовала рекомендациям, изложенным в документе SAC097 Консультативного комитета по безопасности и стабильности (SSAC) в 2017 году.

Работа E&IT, связанная с CZDS, включает рабочие потоки № 3 (Стороны, связанные договорными обязательствами) и № 4 (Технические услуги). Ниже представлена «замороженная цепочка проектов», связанная с этими рабочими потоками на предстоящий семестр (январь-июнь 2021 года), на основе приоритетов и распределения ресурсов, а также краткие пояснения к проектам.

«Замороженная цепочка проектов» E&IT

Технические услуги

  • Система контроля SLA (SLAM) подвергается серьезному обновлению, чтобы улучшить производительность, безопасность и показатели для регистратур. Система SLAM является основой систем технических услуг ICANN.
    • Проект Registrar Watch обеспечит контроль SLA для регистраторов, что позволит ICANN контролировать услуги, предоставляемые регистраторами в соответствии с Соглашением об аккредитации регистраторов (RAA).
    • Усовершенствования API системы мониторинга ICANN (MoSAPI) затронут мониторинг протокола доступа к регистрационным данным (RDAP), позволяя ICANN предоставлять подробную информацию RDAP сторонам, связанным договорными обязательствами, после включения мониторинга. Это принесет пользу регистратурам за счет включения дополнительных показателей мониторинга SLA.
    • Усовершенствования интерфейса отчетности о регистрации (RRI) позволят отделу соблюдения договорных обязательств ICANN лучше решать проблемы с уведомлениями провайдера услуг временного депонирования данных (DEA), когда они возникают.

Стороны, связанные договорными обязательствами

  • Продолжается работа над порталом для поставщиков услуг в области доменных имен (NSp).
    • Мы восстанавливаем интеграцию с системами технических служб, которые выводят из эксплуатации устаревшую платформу соответствия требованиям (Kayako), сокращают расходы на лицензирование, повышают эффективность отдела соблюдения договорных обязательств и улучшают взаимодействие с пользователями для составителей отчетов о соблюдении требований.
    • Отдел соответствия NSp представит функцию, позволяющую всем подателям сообщений подавать несколько заявлений о соответствии (групповые заявления), и будет учитывать оставшиеся интеграции.
    • В период с июня по июль 2021 года команда надеется начать разработку CZDS v3.0, которая выполнит рекомендацию SSAC по автоматическому продлению утвержденных запросов на файлы зон.

Подводя итог, с 2017 года, когда SAC097 был принят Правлением ICANN, работа, связанная с CZDS, была приоритетной. В CZDS было внесено много изменений, но они не были видны конечным пользователям, поскольку они включали изменения в базовую инфраструктуру, используемую CZDS. Кроме того, консультации с сообществом и внутренние обсуждения в корпорации ICANN привели к повышению приоритета других проектов. Тем не менее, технологические рабочие потоки предстоящего семестра показывают, что работа над CZDS возобновится в середине 2021 года, исходя из текущих приоритетов и ограничений.

Понимая желание сообщества видеть более быстрое выполнение проектов CZDS, команда E&IT рассматривает, как лучше всего увеличить потенциал в рамках ограничений капитала и человеческих ресурсов в краткосрочной перспективе. Ресурсы Java было относительно легко привлечь во временном и долгосрочном плане, но оказалось, что таланты Salesforce для работы, связанной с NSp, значительно сложнее выявить и привлечь.

Я с нетерпением жду возможности предоставить сообществу дальнейшие новости, поскольку мы вступаем в следующий семестр работы. А пока благодарю вас за понимание и терпение.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."