Для информации выставляем протокол совещания с регистраторами, у них уже есть протокол, здесь публикуем для ознакомления форумчан.
Повестка дня:
1. Внесение изменений в систему управления доменами, с целью повышения эффективности и доступности работы.
2. Исключение периода бронирования домена.
3. Общие вопросы.
1. Внесение изменений в систему управления доменами
(Выступали: Джураев И.Д., Пелепец А., Гайбуллаев Б., Фаттахов М., Караматов Ф., Хамидов Р., Ржанов А., Каракишьян С., Cкляревский Е., Фиоктистов В., Швабауер П.)
По первому вопросу внесения изменений в систему управления доменами, для облегчения работы с ней, регистраторами было предложено создать вторичную базу данных (БД) системы управления доменами, и сделать прямой доступ регистраторам, сами же регистраторы напишут API, удобный для них.
В результате обсуждения данного метода было выяснено, что сервер-база данных (mysql), который используется на данный момент в системе управления доменами, не поддерживает разграниченного доступа к полям БД, то есть каждый регистратор будет видеть и может корректировать записи другого регистратора.
При этом представляется затруднительным синхронизирование основной БД со вторичной, так как в случае, если два регистратора зарезервируют один и тот же домен, при синхронизации может возникнуть проблема, на кого регистрировать дважды зарезервированный домен.
Данный метод единогласно было решено не использовать по причине сложности и громоздкости программного кода.
Следующим предложением стало создание (написание) протокола для системы управления доменами (по принципу системы EPP).
В данном случае администратор зоны UZ пишет (создает) серверную часть ПО, которая все время задействована на сервере и определяет поведение функциональных блоков в процессе передачи данных. В свою очередь, в это же время регистраторы создают клиентскую часть ПО, которая, используя наборы правил, будет управлять серверной частью ПО, и, тем самым, вносить изменения в систему управления доменами.
Обсудив предложение, собравшиеся согласились, что в данном методе существуют следующие недостатки:
- требуется длительное время для запуска системы, так как сначала администратор составляет набор правил, необходимых для управления сервером, затем согласует их с регистратором, потом пишет (создает) саму серверную часть ПО. Только потом программисты (регистраторам) создают клиентскую часть и начинают ее тестирование.
- не у всех регистраторов в штате есть программисты, которые могут написать данное ПО. Также имеются сложности в поддержке самого протокола, - при внесении изменений в серверную часть приходится вносить изменения и в клиентскую часть софта, таким образом, при каждом внесении изменений в программные части придется тестировать ПО, что может привести к задержкам регистрации доменов или к неработоспособности системы на момент отладки новой версии протокола.
Решено: Внести изменения в личный кабинет регистраторов с целью облегчения «парсинга» со стороны регистраторов. Считать данный способ самым оптимальным на данный момент, регистраторам внести свои предложения по модернизации личного кабинета регистратора для дальнейшего обобщения и выбора оптимального варианта.
2. Исключение льготного периода при бронировании домена до оплаты
(Выступали: Джураев И.Д., Пелепец А., Гайбуллаев Б., Фаттахов М., Караматов Ф., Хамидов Р., Ржанов А., Каракишьян С., Пикуль А., Cкляревский Е., Фиоктистов В., Швабауер П.)
По результатам проведенного мониторинга было выявлено, что некоторые домены неоднократно бронировались, и это не представляло возможности выделения домена для продажи и последующей передачи реальному владельцу (потенциальному покупателю).
Решено: Исключить период бронирования до оплаты, Центру внести изменения в существующие документы. Определить, что домен будет функционировать с начала регистрации ровно 12 месяцев, а в течение 1 месяца после окончания регистрации домен будет находиться в режиме ожидания продления, переделегирования или удаления. В данном режиме домен исключается из списка NS серверов и является неактивным.
3. Общие вопросы
(Выступали Джураев И.Д., Пелепец А., Гайбуллаев Б., Фаттахов М., Караматов Ф., Хамидов Р., Ржанов А., Пикуль А., Cкляревский Е., Фиоктистов В., Швабауер П.)
1. Рассматривалась возможность кредитования регистраторов при нехватке средств на депозите регистратора в Центре UZINFOCOM (возможность отрицательного депозита не допускается в настоящее время) и отключать данную возможность при злоупотреблении со стороны регистратора.
Решено: Рассмотреть вопрос при нехватке средств на депозите регистратора и отключать данную возможность при злоупотреблении со стороны регистратора, только по результатам работы регистраторов, при условии отсутствия нарушений работы в качестве регистратора.
2. О возможности переделегирования домена прозрачным для регистратора, то есть при продлении домена регистратором не отправлять его к администратору на делегирование, а автоматом снимать деньги с счета регистратора и продлевать его без дополнительного рассмотрения у администратора.
Решено: При продлении домена регистратором не отправлять его к администратору на делегирование, а автоматом снимать деньги со счета регистратора и продлевать его.
3. Возможность продления домена в течение всей его “жизни”, а не только в последние месяцы работы домена и разрешить многолетнее использование домена без переделегирования.
Но, как выяснилось, возникают вопросы со стороны бухгалтерии, и, по всей видимости, от этого придется отказаться.
Решено: Не применять, т.к. возникают проблемы при взаиморасчете со стороны бухгалтерии Центра.
4. Внести изменения во whois с целью создания возможности выбора клиентом самостоятельно устанавливать, какие из его личных данных будут доступны публично.
Решено: Внести изменения в whois сервис, т.е. дать возможность клиенту самому выбирать, показывать его личные данные или нет.
5. Завести на форуме закрытую ветку, для обсуждения внутренних вопросов между регистраторами и администрацией зоны.
Решено: Создать данную ветку и, в дальнейшем, обсуждать рабочие (вопросы) моменты в данной ветке.
UZINFOCOM
Линейный вид
