Процесс регистрации доменов регистраторами

[Фаррух Караматов]

Доброго времени суток!

У меня есть одно предложение по облегчению процесса регистрации доменов регистраторами. Возможно у Вас уже имеются свои начинания или идеи по этому процессу. Ну как говорится идея идее рознь :)

Предлагаю создать вторичную базу данных с идентичными таблицами и полями как и основная база данных для регистраторов и дать прямой доступ к этой базе данных каждому регистратору доменов. Чтобы процесс внесения нового домена регистратором проходил не через ИФ на cctld.uz а напрямую при помощи обращения к БД Узинфокома. Один раз в сутки модерировать ее и синхронизировать ее с основной базой данных. В целях безопасности доступ к БД вы можете ограничить до одного IP для каждого регистратора.

Если сделать предложенную мной идею регистраторам при регистрации не придется копировать данные "copy&paste"ом со своего биллинга в вашу форму регистрации. Это намного сократит время, а также даст возможность автоматизции уведомления владельцев домена о истечении срока действия.

Вам ведь прекрасно известно какое огромное количество полей приходится "copy&paste"ить регистраторам при регистрации каждого домена. Я думаю мою идею поддержат и другие регистраторы и добавят свои идеи по ее реализации.

[el2500]

Самое главное в этой идее, придумать, как реализовать РЕЗЕРВИРОВАНИЕ домена на недельку хотябы

конкретнее туть http://forum.uzinfocom.uz/showthread.php?t=94

[Anatoliy Pelepetz]

Доброго времени суток!

Предлагаю создать вторичную базу данных с идентичными таблицами и полями как и основная база данных для регистраторов и дать прямой доступ к этой базе данных каждому регистратору доменов. Чтобы процесс внесения нового домена регистратором проходил не через ИФ на cctld.uz а напрямую при помощи обращения к БД Узинфокома. Один раз в сутки модерировать ее и синхронизировать ее с основной базой данных. В целях безопасности доступ к БД вы можете ограничить до одного IP для каждого регистратора.

Если сделать предложенную мной идею регистраторам при регистрации не придется копировать данные "copy&paste"ом со своего биллинга в вашу форму регистрации. Это намного сократит время, а также даст возможность автоматизции уведомления владельцев домена о истечении срока действия.


Если я правильно понял, то вы хотите напрямую в таблице БД просто копировать записи, а потом их редактировать.
Эсли это так то реализация вашей идеи технически возможна но она создаст еще больше проьлем для тех кто будет заводить домен, так как добовляя домен нре заполняется одна только таблица. Их заполняется несколько и к томуже с привязками.
Вы думаете что проше проследить все привязки и забить их вручную?
И к томуже сколько человек из тех кто заводят домены смогут грамотно это сделать?, ведь не все же разбираются в БД.
И плюс еще ко всему вы предлагаете выставить структуру БД навсеобщее обозрения.

А во то что, это даст возможность автоматизции уведомления владельцев домена о истечении срока действия, мне вобше не понятно. Что мешает в данный мометн оповещать владельцев доменов?

[Ilya Rubinchik]

Доброго времени суток!

У меня есть одно предложение по облегчению процесса регистрации доменов регистраторами. Возможно у Вас уже имеются свои начинания или идеи по этому процессу. Ну как говорится идея идее рознь :)


Автоматизация нужна, но не в таком же виде...
Надо сделать возможность работы с регистраторским интерфейсом путем загрузки xml (например), или прямым POST запросом с некоей автоматической авторизацией.

[Utkirbek Abdullaev]

Думаю проще будет дать права доступа регистраторам к базам на UzInfoCom с возможностью ввода и редактирования данных по регистрации домена. Базу нужно будет поделить на "ячейки" или же подбазы для каждого регистратора отдельно. Мониторинг будет вестись один для всех подбаз (баз регистраторов).

[Djalolatdin Rakhimov]

Для регистраторов будет создана служба (окно) ввода данных сразу в нашу базу данных. Это упростит работу регистратора по созданию собсвтенного ПО для ведения данных. Лучше мы это сделаем единообразно для всех, чем каждый регистратор будет создавать свою копию и тратить на это время. Мы уже как-то говорили об этом регистраторам, предлагали обсудить требования к данному ПО, но так и не получили откликов, поэтому процесс затормозился, ввиду отсутствия необходимости.

Регистраторы, создайте отделльную ветку для обсуждения требований. Реализуем.

[Фаррух Караматов]

Если я правильно понял, то вы хотите напрямую в таблице БД просто копировать записи, а потом их редактировать.
Эсли это так то реализация вашей идеи технически возможна но она создаст еще больше проьлем для тех кто будет заводить домен, так как добовляя домен нре заполняется одна только таблица. Их заполняется несколько и к томуже с привязками.
Вы думаете что проше проследить все привязки и забить их вручную?
И к томуже сколько человек из тех кто заводят домены смогут грамотно это сделать?, ведь не все же разбираются в БД.

Если Вы предоставите доступ к БД, регистраторы могут для своих сотрудников разработать интерфейс при помощи которого весь этот процесс будет проходить без "ручных" манипуляций в БД.


И плюс еще ко всему вы предлагаете выставить структуру БД навсеобщее обозрения.
Вам не выставлять всю структуру вашей основной БД на всеобщее обозрение. Вы можете создать вторую базу данных с НЕОБХОДИМЫМИ таблицами для регистрации доменов.
К тому же выставлять структуру вашей БД вы будете не на всеобщее обозрение а только представителям регистраторов.

Еще один плюс если Вы предоставите доступ к БД для регистраторов. Регистраторы смогут предоставить доступ своим клиентам Персональный кабинет. В котором клиенты смогут менять данные о НС серверах и т.д.

[Искандар Адылов]

Для регистраторов будет создана служба (окно) ввода данных сразу в нашу базу данных. Это упростит работу регистратора по созданию собсвтенного ПО для ведения данных. Лучше мы это сделаем единообразно для всех, чем каждый регистратор будет создавать свою копию и тратить на это время. Мы уже как-то говорили об этом регистраторам, предлагали обсудить требования к данному ПО, но так и не получили откликов, поэтому процесс затормозился, ввиду отсутствия необходимости.

Регистраторы, создайте отделльную ветку для обсуждения требований. Реализуем.

что Вы имеете в виду под службой? веб-ИФ? или все-таки веб-сервис с использованием xml?

[Djalolatdin Rakhimov]

что Вы имеете в виду под службой? веб-ИФ? или все-таки веб-сервис с использованием xml?

Любые разумные требования со стороны регистраторов. Постараемся сделать удобныими. При необходимости будут реализованы несколько вариантов работы - каждый может выбрать свой.

[Фаррух Караматов]

Для регистраторов будет создана служба (окно) ввода данных сразу в нашу базу данных. Это упростит работу регистратора по созданию собсвтенного ПО для ведения данных.
Такой вариант не принесет существенных результатов в плане повышения производительности и облегчения регистрации доменов регистраторами.

Понимаете для Регистратора, регистрация доменов это услуга, которую они предоставляют клиентам. А для нормального предоставления качественного и оперативного предоставления этих услуг нужна существенная автоматизация процесса регистрации + биллинговая система.

Любые разумные требования со стороны регистраторов. Постараемся сделать удобныими. При необходимости будут реализованы несколько вариантов работы - каждый может выбрать свой.
Поскольку пока других от других регистраторов кроме BCC предложений не было. Можно остановится на двух вариантах:
1) Создание вторичной БД к которой будет предоставлен доступ регистраторам.
2) Предоставление веб сервиса с использованием XML или API к вашей БД.

Оба варианта должны дать следующие возможности регистраторам:
1) Автоматизированная система регистрация доменов
2) Смена адресов НС серверов для уже зарегистрированных доменов
3) Изменение контактных данных владельцев доменов.

[Ibrohim Djuraev]

Оба варианта должны дать следующие возможности регистраторам:
1) Автоматизированная система регистрация доменов
2) Смена адресов НС серверов для уже зарегистрированных доменов
3) Изменение контактных данных владельцев доменов.


мы сейчас говорим о технической стороны, а вот если посмотреть с другой стороны на предмет смены НС серверов и контактных данных, тогда как быть с аккуратностью при смене нс серверов со стороны пользователей, и конечно о достоверности внесенных изменений в контактных данных? Регистратор будет нести полную ответственность?

Я понимаю что регистраторы хочеть сделать максимально удобным и простым процесс регистрации и поддержки доменов своих пользователей, но не надо забывать при этом чтобы параллельно не создавались трудности или допускались ошибки

[Anatoliy Pelepetz]

Поскольку пока других от других регистраторов кроме BCC предложений не было. Можно остановится на двух вариантах:
1) Создание вторичной БД к которой будет предоставлен доступ регистраторам.
2) Предоставление веб сервиса с использованием XML или API к вашей БД.

Оба варианта должны дать следующие возможности регистраторам:
1) Автоматизированная система регистрация доменов
2) Смена адресов НС серверов для уже зарегистрированных доменов
3) Изменение контактных данных владельцев доменов.

Объясните пожалуйсто пнкт "1) Автоматизированная система регистрация доменов".

Может быть лучше все регистраторы просто напишут что их не устраивает в данный момент в системе регистрации доменов, и мы придем к обшему мнения что нужно изменять в системе, а что нет.

[Anatoliy Pelepetz]

Если Вы предоставите доступ к БД, регистраторы могут для своих сотрудников разработать интерфейс при помощи которого весь этот процесс будет проходить без "ручных" манипуляций в БД.


Вы хотите сказать что каждый регистратор готов написать для своих сотрудников свой интерфейс удобный для них, но я сомневаюсь что это кто то будет делать, потов в резулатате отладки интерфейса могут возникнуть ошыбки в БД в результате чего все "шишки", из за неработающего домена УЗ, полетят в нас.
Да и к тому же заставить каждого регистратора писать себе админку это всеравно что, если вы придете в микрософт а вам тама дадут диск с АПИ библиотеками и скажут виндовс самому писать

[Фаррух Караматов]

мы сейчас говорим о технической стороны, а вот если посмотреть с другой стороны на предмет смены НС серверов и контактных данных, тогда как быть с аккуратностью при смене нс серверов со стороны пользователей, и конечно о достоверности внесенных изменений в контактных данных? Регистратор будет нести полную ответственность?
Смена контактной информации нужна для выполнения пунктов 8.1 и 8.3 "ПОЛОЖЕНИЯ О ПОРЯДКЕ АДМИНИСТРИРОВАНИЯ ДОМЕНОВ В ЗОНЕ «UZ»".
в которых сказано:

8.1 Администратор обязан в 10-дневный срок сообщить Регистратору в случае изменения сведений, в ранее поданной им заявке на регистрацию (на продление срока действия регистрации), а также в случае изменении информации о доменном имени, содержащейся в базе сервиса `whois'.
и
8.3 После получения от Администратора сообщения об изменении сведений и проверки этих сведений Регистратор обязан внести соответствующие изменения в Реестр, в базу сервиса `whois' и при необходимости переоформить договор с Администратором.

А насчет смены НСок. Регистратор это все равно делает по запросу администратора домена. Если это будет делать непосредственно сам администратор домена, регистратор не будет промежуточным звеном в этом процессе.

К тому же вот выдержка из того же положения:

16.1 Администратор домена, за которым регистрируется домен второго уровня, должен иметь необходимый уровень квалификации и должен успешно осуществлять эксплуатацию DNS–серверов зарегистрированного за ним домена в соответствии с установленными техническими требованиями.

Объясните пожалуйсто пнкт "1) Автоматизированная система регистрация доменов".

Для начала можно автоматизировать следующее(Из положения параграф 14.2 (http://cctld.uz/info/padmin/)):

создание домена;
обновление любых данных по каждому зарегистрированному им домену;
удаление домена из базы, сохраняя информацию о нем для Администратора домена «UZ»;
специальные действия – сохранить, удалить, реактивировать домены – по согласованию с Администратором домена «UZ»;

[Фаррух Караматов]

Вы хотите сказать что каждый регистратор готов написать для своих сотрудников свой интерфейс удобный для них, но я сомневаюсь что это кто то будет делать
Уважаемый можете не сомневаться в том что это будет сделано регистраторами. У китайцев есть пословица: Без ветра не колышется трава Я не просто так поднял этот вопрос на этом форуме.


потов в резулатате отладки интерфейса могут возникнуть ошыбки в БД в результате чего все "шишки", из за неработающего домена УЗ, полетят в нас.
Поэтому для предотвращения подобных инцидентов я вам и предложил создать вторичную базу данных. Даже ее можно на время отладки не синхронизировать с основной БД. Ну это уже сугубо технические и рабочие вопросы.


Да и к тому же заставить каждого регистратора писать себе админку это всеравно что, если вы придете в микрософт а вам тама дадут диск с АПИ библиотеками и скажут виндовс самому писать
Я ведь не говорю о том что надо кого-то заставлять писать интерфейс. На сайте cctld.uz вы сами можете увидеть рост интереса к домену .uz и тенденции его развития. каждый регистратор все равно рано или поздно придет к этому. Первое время у кого нет желания писать интерфейс могут регистрировать домены по старой схеме путем Copy&Paste кучи полей.
Предоставление API это довольно распространенный метод решения различных задач. Например для владельцев сайтов и продвинутых пользователей такие сервисы как: Google Maps, Livejournal, flickr, yahoo, amazon s3 предоставляют API для облегчения и расширения предоставляемых ими сервисов.

[Anton Kovalyov]

Вы хотите сказать что каждый регистратор готов написать для своих сотрудников свой интерфейс удобный для них, но я сомневаюсь что это кто то будет делать, потов в резулатате отладки интерфейса могут возникнуть ошыбки в БД в результате чего все "шишки", из за неработающего домена УЗ, полетят в нас.

А что, кроме лени, мешает вам автоматически (ну или вручную, если делать нечего) проверять данные перед внесением в конечную базу? Если они введены некорректно — не добавляйте. Ну а ответственность за неточность контактной информации всегда (даже сейчас) лежит на регистраторах. Или вы думаете, что с вашей текущей формой отправки нельзя зарегистрировать домен на несуществующего человека? Вы проверяете каждый паспорт?

Вас никто не просит предоставить доступ к непосредственной базе данных потому что это глупо. Вас просят сделать промежуточный программный слой, который позволит регистраторам автоматизировать процесс регистрации и обновления доменов.

Во всём мире это сделано. Я могу сам поменять свою контактную информацию на всех своих доменах в зонах .com, .net, .org, но не .uz. Потому что в .uz надо сначала написать заявку регистратору, который напишет заявку вам, а потом все состарятся и умрут.

Да и к тому же заставить каждого регистратора писать себе админку это всеравно что, если вы придете в микрософт а вам тама дадут диск с АПИ библиотеками и скажут виндовс самому писать

Чушь, даже отвечать не хочется. Windows — это продукт для конечных пользователей, а вас просят сделать API для регистраторов, которые сами сделают конечные продукты для своих клиентов и встроят в свои биллинги и персональные кабинеты.

Для каждого регистратора создайте отдельный ключ по которому и можно следить кто, кого и когда внес. Вообще, посмотрите на тот же самый Google API.

Кому из иностранных знакомых расскажешь, что у нас регистраторы работают с данными о доменах по методу copy&paste и (!) специалисты Самого Главного Регистратора всея Узнета считают, что это супер правильно и хорошо — засмеют, не иначе.

[Ilya Rubinchik]

Для регистраторов будет создана служба (окно) ввода данных сразу в нашу базу данных. Это упростит работу регистратора по созданию собсвтенного ПО для ведения данных. Лучше мы это сделаем единообразно для всех, чем каждый регистратор будет создавать свою копию и тратить на это время. Мы уже как-то говорили об этом регистраторам, предлагали обсудить требования к данному ПО, но так и не получили откликов, поэтому процесс затормозился, ввиду отсутствия необходимости.

Регистраторы, создайте отделльную ветку для обсуждения требований. Реализуем.
Отсутствия необходимости??? Извините, мы вас просили очень много раз, даже была достигнута предварительная договоренность о безвозмездной помощи с нашей стороны по реализации автоматического интерфейса!

[Ilya Rubinchik]

мы сейчас говорим о технической стороны, а вот если посмотреть с другой стороны на предмет смены НС серверов и контактных данных, тогда как быть с аккуратностью при смене нс серверов со стороны пользователей, и конечно о достоверности внесенных изменений в контактных данных? Регистратор будет нести полную ответственность?

Я понимаю что регистраторы хочеть сделать максимально удобным и простым процесс регистрации и поддержки доменов своих пользователей, но не надо забывать при этом чтобы параллельно не создавались трудности или допускались ошибки
Ответственность полностью возложится на внесшего изменения. То есть это уже дело регистратора создавать ли общедоступный для клиентов ифейс или чтобы данные изменяли только сотрудники регистратора.
Кроме того, регистратор может в своем внутреннем ифейсе для пользователей организовать минимальную "защиту от дурака".

[Ilya Rubinchik]

Вы хотите сказать что каждый регистратор готов написать для своих сотрудников свой интерфейс удобный для них, но я сомневаюсь что это кто то будет делать, потов в резулатате отладки интерфейса могут возникнуть ошыбки в БД в результате чего все "шишки", из за неработающего домена УЗ, полетят в нас.
Да и к тому же заставить каждого регистратора писать себе админку это всеравно что, если вы придете в микрософт а вам тама дадут диск с АПИ библиотеками и скажут виндовс самому писать
Вы немного подменяете понятия. Не "заставить каждого администратора писать свою админку", а дать ему такую возможность. Кроме того, проверка загруженных со стороны регистратора данных на целостность это ваша ответственность, на то вы и администратор зоны. Это можно делать даже прямо "на лету" и возвращать код ошибки(-ок), чтобы регистратор сразу мог данные подкорректировать.

Сейчас у нас на сайте reg.bcc.uz можно отправить заявку на резервирование. Но что толку от этого, если заявка не будет обработана пока в понедельник утром девочка не придет на работу не включит компьютер и не повставляет в вашу гигантскую форму (по 120-му разу) все наши контактные данные?

[Djalolatdin Rakhimov]

А что, кроме лени, мешает вам ...

предупреждение о нетактичности! Свобода слова не значит безответственность и анархия.

[Djalolatdin Rakhimov]

...Вообще, посмотрите на тот же самый Google API...

Интересная аналогия напрашивается. Сравниваете cctld.uz с google.com, а себя с Биллом Гейтсом? Не забывайте, что аналогии - очень тонкая вещь.

[Djalolatdin Rakhimov]

Отсутствия необходимости??? Извините, мы вас просили очень много раз, даже была достигнута предварительная договоренность о безвозмездной помощи с нашей стороны по реализации автоматического интерфейса!

Похоже, настрой достаточно агрессивной с Вашей стороны. Мы ведь пообещали реализовать, хотя и не обязаны (!). Но при таком отношении решение может быть пересмотрено.

[Djalolatdin Rakhimov]

Вы немного подменяете понятия. Не "заставить каждого администратора писать свою админку", а дать ему такую возможность. Кроме того, проверка загруженных со стороны регистратора данных на целостность это ваша ответственность, на то вы и администратор зоны. Это можно делать даже прямо "на лету" и возвращать код ошибки(-ок), чтобы регистратор сразу мог данные подкорректировать.

Сейчас у нас на сайте reg.bcc.uz можно отправить заявку на резервирование. Но что толку от этого, если заявка не будет обработана пока в понедельник утром девочка не придет на работу не включит компьютер и не повставляет в вашу гигантскую форму (по 120-му разу) все наши контактные данные?

Уважаемый Ilya Rubinchik, если Ваш тон в форуме не будет сменем на допустимый, то мы вынуждены будем направить официльное уведомление Вашему руководству о некорректности поведения с просьбой о замене лица, представляющего интересы регистратора в данном форуме.

[Искандар Адылов]

Интересная аналогия напрашивается. Сравниваете cctld.uz с google.com, а себя с Биллом Гейтсом? Не забывайте, что аналогии - очень тонкая вещь.

значит ли это, что API не будет? Можно ли рассчитывать на то, что форум не превратится в разборку?

[Utkirbek Abdullaev]

Сейчас у нас на сайте reg.bcc.uz можно отправить заявку на резервирование. Но что толку от этого, если заявка не будет обработана пока в понедельник утром девочка не придет на работу не включит компьютер и не повставляет в вашу гигантскую форму (по 120-му разу) все наши контактные данные?

Можно же было эту мысль выразить без насмешек и намёков - девочка придёт на работу в понедельник и гигантские формы - наша общая проблема - узнетовская - и должны мы её решать вместе - цивильно!
Для этого мы и собрались здесь!

Уважаемый Ilya Rubinchik, если Ваш тон в форуме не будет сменем на допустимый, то мы вынуждены будем направить официльное уведомление Вашему руководству о некорректности поведения с просьбой о замене лица, представляющего интересы регистратора в данном форуме.

Да... получилось жёстко - но нежелательно так делать! Этот форум приобретает всё большую популярность не из-за того, что объявлен конкурс, а по причине того, что директор центра, его заместители и специалисты общаются на форуме не как должностные лица центра, а как специалисты.

Думаю инцидент исчерпан.

[Anton Kovalyov]

Ну, в общем, всё ясно. Никто ничего делать не будет. До свидания, до новых встреч.

[Djalolatdin Rakhimov]

значит ли это, что Api не будет? Можно ли рассчитывать на то, что форум не превратится в разборку?

В наших планах - сделать его в том или ином виде. Нормальный разбор различных ситуаций приветствуется при соблюдении уважения сторон друг к другу.

[Djalolatdin Rakhimov]

Этот форум приобретает ... популярность не из-за того, что объявлен конкурс, а по причине того, что директор центра, его заместители и специалисты общаются на форуме не как должностные лица центра, а как специалисты.

Не совсем точно. Форум официальный, то есть, кроме компетентного обсуждения вопросов, мы РЕАЛЬНО разбираем их у себя в Центре. Все равно, что Вы пришлете сообщение на официальном бланке по нашему адресу или по факсу. Не обратили внимание, что даже есть ветка "Приемная". Теперь нет необходимости даже приходить к нам в офис (это не говорит о том, что мы не рады видеть гостей, даже напротив), чтобы получить ответы от самого рук-ва Центра. В то же время все рук-ли центра читают все сообщения в форуме, отвечают на них согласно своей компетенции и полномочий.

Мы хотим показать, как можно работать с общественностью, пользователями, клиентами и т.д. в онлайне, что дает свои плюсы сторонам.

Естественно, форум модерируется, чтобы он не превратился в "помойку", выполнял свои функции.

А призы объявленные - считайте - новогодние подарки.

[Ibrohim Djuraev]

А что, кроме лени, мешает вам автоматически (ну или вручную, если делать нечего) проверять данные перед внесением в конечную базу? Если они введены некорректно — не добавляйте. Ну а ответственность за неточность контактной информации всегда (даже сейчас) лежит на регистраторах. Или вы думаете, что с вашей текущей формой отправки нельзя зарегистрировать домен на несуществующего человека? Вы проверяете каждый паспорт?


интересно рассуждаете, то говорите что нам проверять, правильно ли внесли регистраторы данные или же регистраторы несут ответственность за неточность введенной информации, определитесь. Если текущая форма не нравится (хотя все его заполняют и при заключении договоров никто из регистраторов не отрицал о данной форме) не заполняйте, довертесь своему регистратору пусть он Вам заполняет. Так как за достоверность отвечает конечный пользователь, даже не регистратор, тут тоже обратите внимание, ведь заявку подает клиент а не сам регистратор вносит информацию

Во всём мире это сделано. Я могу сам поменять свою контактную информацию на всех своих доменах в зонах .com, .net, .org, но не .uz. Потому что в .uz надо сначала написать заявку регистратору, который напишет заявку вам, а потом все состарятся и умрут.

Если у вас проблем нету по смене информации на доменных именах в зонах .com, .net, .org и.т.д. (кстати эти домены относятся к доменам категории gTLD) то в регистрации и внесении изменении информации в доменных зонах ccTLD есть свои правила. Кстати, советую Вам ознакомится с правилами регистрации gTLD и ccTLD, как видите они отличаются по категории :)

[Anton Kovalyov]

интересно рассуждаете, то говорите что нам проверять, правильно ли внесли регистраторы данные или же регистраторы несут ответственность за неточность введенной информации, определитесь.

Нет, такое я не могу пропустить. Вам надо чисто технически проверять («sadjaskd» в номере телефона), а регистраторам уже по паспорту и всё такое.

[Фаррух Караматов]

Спасибо за ответы на вопросы, в данной теме оставлено 29 сообщений. Пока не вижу ответа. Давайте я Вам задам вопрос в форме закрытого вопроса (http://www.glossary.ru/cgi-bin/gl_find.cgi?ph=%E7%E0%EA%F0%FB%F2%FB%E9+%E2%EE%EF% F0%EE%F1#51401559):

Будет ли поднятый мной вопрос реализован:
Да или Нет.

UPD:
Если ответ ДА.

Вот два варианта которые я предлагаю внедрить:
1) Создание вторичной БД к которой будет предоставлен доступ регистраторам.
2) Предоставление веб сервиса с использованием XML или API к вашей БД.

Еще один закрытый вопрос:
Какой из вариантов вы будете реализовывать:
1 или 2.

[Ibrohim Djuraev]

Нет, такое я не могу пропустить. Вам надо чисто технически проверять («sadjaskd» в номере телефона), а регистраторам уже по паспорту и всё такое.

нам незачем проверять (даже технически), так как данные вводятся самими заявителями, сами заявители должны потдверждать регистратору о достоверности введенных данных.

5.4 Заявитель обязан сообщить в заявке полную и достоверную информацию. Наличие недостоверной информации в заявке является основанием для отказа в регистрации. Регистратор вправе при проверке заявки запросить у Заявителя подтверждение достоверности представленных сведений.

Если вы работаете со своими клиентами, то Вы тоже хотите чтобы они все там точно указали, а не приводили "левые" данные

[Фаррух Караматов]

Уважаемые мне ждать ответа на поставленный мной вопрос?

[Марат Фаттахов]

доступ к базе давать нельзя - полюбому, да и не получится разделять права доступа к разным записям одной таблицы. Думаю никто не будет рад, если его домен спокойно таким макаром перехватят.

нужен именно API, т.е. какой либо программный интерфейс, чтобы софт регистраторов мог работать с ccTLD в автоматическом режиме, но только с тем доступом, что имеется в данный момент и с этим же функционалом.

Кто придумает протокол?.. Как это совместить со всеми регистраторами?.. Нужно ведь утвердить стандарт этого API, вести версии и т.п.

зы. проголосовал "за", но надо обсудить, как это будет выглядеть в конечном счёте

[Ibrohim Djuraev]

Спасибо за ответы на вопросы, в данной теме оставлено 29 сообщений. Пока не вижу ответа. Давайте я Вам задам вопрос в форме закрытого вопроса (http://www.glossary.ru/cgi-bin/gl_find.cgi?ph=%E7%E0%EA%F0%FB%F2%FB%E9+%E2%EE%EF% F0%EE%F1#51401559):

Будет ли поднятый мной вопрос реализован:
Да или Нет.

UPD:
Если ответ ДА.

Вот два варианта которые я предлагаю внедрить:
1) Создание вторичной БД к которой будет предоставлен доступ регистраторам.
2) Предоставление веб сервиса с использованием XML или API к вашей БД.

Еще один закрытый вопрос:
Какой из вариантов вы будете реализовывать:
1 или 2.

могу ответить ДА, вариант 2 (но ТОЛЬКО надо его обсудить)
поэтому предлагаю, также приглашаю всех представителей регистраторов 16 декабря в 11 часов в Центр UZINFOCOM (http://www.uzinfocom.uz/about/contacts/location/), для обсуждения данного вопроса и прийти к единому решению. Прошу чтобы участвовали ответственные лица от регистраторов, которые непосредственно занимаются вопросами регистрации доменов.

Уважаемые мне ждать ответа на поставленный мной вопрос?

Уважаемый у нас здесь не совещание же, отвечаем по мере возможности, без обид:)

[Vitaliy Fioktistov]

могу ответить ДА, вариант 2 (но ТОЛЬКО надо его обсудить)
поэтому предлагаю, также приглашаю всех представителей регистраторов 16 декабря в 11 часов в Центр UZINFOCOM (http://www.uzinfocom.uz/about/contacts/location/), для обсуждения данного вопроса и прийти к единому решению. Прошу чтобы участвовали ответственные лица от регистраторов, которые непосредственно занимаются вопросами регистрации доменов.

Только регистраторов? Мы бы тоже хотели поприсутствовать.

[Ibrohim Djuraev]

Только регистраторов? Мы бы тоже хотели поприсутствовать.

Немного подкорректировал ответ с учетом предложения (http://forum.uzinfocom.uz/showpost.php?p=1057&postcount=38), приходите

[Utkirbek Abdullaev]

могу ответить ДА, вариант 2 (но ТОЛЬКО надо его обсудить)
поэтому предлагаю, также приглашаю всех представителей регистраторов 16 декабря в 11 часов в Центр UZINFOCOM (http://www.uzinfocom.uz/about/contacts/location/), для обсуждения данного вопроса и прийти к единому решению. Прошу чтобы участвовали ответственные лица от регистраторов, которые непосредственно занимаются вопросами регистрации доменов.


Хотелось бы получить детальную информацию по результатам обсуждения 16 числа. Если не затруднит, в виде отдельной статьи на сайте. Ждём.

[Evgeniy Sklyarevskiy]

Только регистраторов? Мы бы тоже хотели поприсутствовать.

+1,5 :-)

все регистраторы будут?

[Ibrohim Djuraev]

где будет проходить данное совещание ? у Вас в кабинете или где ?

Вы приходите в центр, место для обсуждение найдется, комнат достаточно для собрания. Самое главное чтобы все пришли

[Djalolatdin Rakhimov]

Вы приходите в центр, место для обсуждение найдется, комнат достаточно для собрания. Самое главное чтобы все пришли

Хочу поправить: чтобы результат был, а не просто демогогия, как порой на форумах.

[Vitaliy Fioktistov]

Учитывая результаты опроса, вижу, что всем это хочется, но подозреваю, что каждому по-своему, в своем понимании, как надо :cool:

[Evgeniy Sklyarevskiy]

не совсем внятно звучит наименование опроса "Есть ли нужда в реализации этой идеи?" Какой этой? Наверное надо написать "Есть ли нужда в реализации предложения Фарруха Караматова". Те кто давно читают ветку форума - в курсе, а новый человек запутается.

[Anatoliy Pelepetz]

Все регистраторы оповещены по телефону по поводу собрания.
Обещали все прити!

[Ibrohim Djuraev]

+1,5 :-)

все регистраторы будут?

позвонили всем, предупредили, сказали что все придут, так что ждем.
повестку дня сегодня поставим на форуме

[Anatoliy Pelepetz]

1. Рассмотрение вопроса по созданию софта для регистраторов по автоматизации процесса регистрации доменов
В частности на рассмотрение будут выдвинуты следующие вопросы:
а) Создание вторичной БД к которой будет предоставлен доступ регистраторам.
б) Предоставление веб сервиса с использованием Xml или Api к БД доменов.

2. Рассмотрение вопроса исключения льготного периода

[Djalolatdin Rakhimov]

2. Рассмотрение вопроса исключения льготного периода

либо превращение его в период блокирования домена. Определить сроки блокирования.

[Марат Фаттахов]

ну пусть пишет: "Ожидание делегирования", но в этот момент домен не будет работать и всё

[Фаррух Караматов]

ну пусть пишет: "Ожидание делегирования", но в этот момент домен не будет работать и всё
эту идею я предлагал тут (http://forum.uzinfocom.uz/showpost.php?p=971&postcount=30).

[Ibrohim Djuraev]

немного оффтоп:
обновили статистику по росту доменов, получилось таким образом:

Статистика на текущий момент (дд.мм.гг чч:мм:сс)
Активных доменов на начало текущего года - 2696
Новых доменов за 2006 год - 2017
Удаленных доменов за год - 1206
Всего активных доменов на данный момент - 3507
Прирост количества активных доменов за год - 811
Прирост по отношению к началу года - 30.0%


realtime stat -> http://www.cctld.uz/

[Марат Фаттахов]

Статья о том, как прошла эта встреча: http://ru.infocom.uz/more.php?id=1999_0_1_0_M

[Utkirbek Abdullaev]

Статья о том, как прошла эта встреча: http://ru.infocom.uz/more.php?id=1999_0_1_0_M

Отличная работа!
Я рад, что всё таки нашли решения к некотрым проблемам и пришли к единому мнению.

[Ibrohim Djuraev]

Для информации выставляем протокол совещания с регистраторами, у них уже есть протокол, здесь публикуем для ознакомления форумчан.

Повестка дня:
1. Внесение изменений в систему управления доменами, с целью повышения эффективности и доступности работы.
2. Исключение периода бронирования домена.
3. Общие вопросы.

1. Внесение изменений в систему управления доменами
(Выступали: Джураев И.Д., Пелепец А., Гайбуллаев Б., Фаттахов М., Караматов Ф., Хамидов Р., Ржанов А., Каракишьян С., Cкляревский Е., Фиоктистов В., Швабауер П.)

По первому вопросу внесения изменений в систему управления доменами, для облегчения работы с ней, регистраторами было предложено создать вторичную базу данных (БД) системы управления доменами, и сделать прямой доступ регистраторам, сами же регистраторы напишут API, удобный для них.
В результате обсуждения данного метода было выяснено, что сервер-база данных (mysql), который используется на данный момент в системе управления доменами, не поддерживает разграниченного доступа к полям БД, то есть каждый регистратор будет видеть и может корректировать записи другого регистратора.
При этом представляется затруднительным синхронизирование основной БД со вторичной, так как в случае, если два регистратора зарезервируют один и тот же домен, при синхронизации может возникнуть проблема, на кого регистрировать дважды зарезервированный домен.
Данный метод единогласно было решено не использовать по причине сложности и громоздкости программного кода.
Следующим предложением стало создание (написание) протокола для системы управления доменами (по принципу системы EPP).
В данном случае администратор зоны UZ пишет (создает) серверную часть ПО, которая все время задействована на сервере и определяет поведение функциональных блоков в процессе передачи данных. В свою очередь, в это же время регистраторы создают клиентскую часть ПО, которая, используя наборы правил, будет управлять серверной частью ПО, и, тем самым, вносить изменения в систему управления доменами.
Обсудив предложение, собравшиеся согласились, что в данном методе существуют следующие недостатки:

требуется длительное время для запуска системы, так как сначала администратор составляет набор правил, необходимых для управления сервером, затем согласует их с регистратором, потом пишет (создает) саму серверную часть ПО. Только потом программисты (регистраторам) создают клиентскую часть и начинают ее тестирование.
не у всех регистраторов в штате есть программисты, которые могут написать данное ПО. Также имеются сложности в поддержке самого протокола, - при внесении изменений в серверную часть приходится вносить изменения и в клиентскую часть софта, таким образом, при каждом внесении изменений в программные части придется тестировать ПО, что может привести к задержкам регистрации доменов или к неработоспособности системы на момент отладки новой версии протокола.


Решено: Внести изменения в личный кабинет регистраторов с целью облегчения «парсинга» со стороны регистраторов. Считать данный способ самым оптимальным на данный момент, регистраторам внести свои предложения по модернизации личного кабинета регистратора для дальнейшего обобщения и выбора оптимального варианта.

2. Исключение льготного периода при бронировании домена до оплаты
(Выступали: Джураев И.Д., Пелепец А., Гайбуллаев Б., Фаттахов М., Караматов Ф., Хамидов Р., Ржанов А., Каракишьян С., Пикуль А., Cкляревский Е., Фиоктистов В., Швабауер П.)
По результатам проведенного мониторинга было выявлено, что некоторые домены неоднократно бронировались, и это не представляло возможности выделения домена для продажи и последующей передачи реальному владельцу (потенциальному покупателю).
Решено: Исключить период бронирования до оплаты, Центру внести изменения в существующие документы. Определить, что домен будет функционировать с начала регистрации ровно 12 месяцев, а в течение 1 месяца после окончания регистрации домен будет находиться в режиме ожидания продления, переделегирования или удаления. В данном режиме домен исключается из списка NS серверов и является неактивным.

3. Общие вопросы
(Выступали Джураев И.Д., Пелепец А., Гайбуллаев Б., Фаттахов М., Караматов Ф., Хамидов Р., Ржанов А., Пикуль А., Cкляревский Е., Фиоктистов В., Швабауер П.)
1. Рассматривалась возможность кредитования регистраторов при нехватке средств на депозите регистратора в Центре UZINFOCOM (возможность отрицательного депозита не допускается в настоящее время) и отключать данную возможность при злоупотреблении со стороны регистратора.
Решено: Рассмотреть вопрос при нехватке средств на депозите регистратора и отключать данную возможность при злоупотреблении со стороны регистратора, только по результатам работы регистраторов, при условии отсутствия нарушений работы в качестве регистратора.

2. О возможности переделегирования домена прозрачным для регистратора, то есть при продлении домена регистратором не отправлять его к администратору на делегирование, а автоматом снимать деньги с счета регистратора и продлевать его без дополнительного рассмотрения у администратора.
Решено: При продлении домена регистратором не отправлять его к администратору на делегирование, а автоматом снимать деньги со счета регистратора и продлевать его.

3. Возможность продления домена в течение всей его “жизни”, а не только в последние месяцы работы домена и разрешить многолетнее использование домена без переделегирования.
Но, как выяснилось, возникают вопросы со стороны бухгалтерии, и, по всей видимости, от этого придется отказаться.
Решено: Не применять, т.к. возникают проблемы при взаиморасчете со стороны бухгалтерии Центра.

4. Внести изменения во whois с целью создания возможности выбора клиентом самостоятельно устанавливать, какие из его личных данных будут доступны публично.
Решено: Внести изменения в whois сервис, т.е. дать возможность клиенту самому выбирать, показывать его личные данные или нет.

5. Завести на форуме закрытую ветку, для обсуждения внутренних вопросов между регистраторами и администрацией зоны.
Решено: Создать данную ветку и, в дальнейшем, обсуждать рабочие (вопросы) моменты в данной ветке.

[Ibrohim Djuraev]

Самое простое и почему то не сделано до сих пор

PS в 3-ем пункте меня аж двое :)

насколько помню, некторые регистраторы пожелали работу по почте, так удобнее говорили, закрытую ветку создать нет проблем, и так смотрим активность регистраторов, когда даже на элементарные почтовые сообщения не отвечают, а закрытую ветку будт заходить?

про повтор вашей фамилии уже исправил, но вы там показывали свою активность может из за этого так получилось :)

[Anton Kovalyov]

Прошло почти 4,5 месяца с момента легендарной встречи. Не посвятите ли простых смертных, какой у нас прогресс с первым пунктом?

[Evgeniy Sklyarevskiy]

Еще интересно по именам третьего уровня - будут ли дешевле, кто-то занимается этим? Какие планы? какие успехи? Какие сроки реализации?

согласитесь, для сайта о провайдерах не очень подходит prov.barbaris.uz гораздо кучерявее было бы prov.com.uz или что-то вроде.

[Azamat Shamuzafarov]

я вообще против таких доменов третьего уровня. да ну их в баню. тока мысли путают.

[Evgeniy Sklyarevskiy]

я вообще против таких доменов третьего уровня. да ну их в баню. тока мысли путают.
Что это за мысли если их домены путают?

Для того же сайта о провайдерах - не хочется платить 25 баксов... а за 10 я бы купил 3-го уровня... нет, за 5 лучше :-) или даром - еще лучше.

[Ibrohim Djuraev]

Прошло почти 4,5 месяца с момента легендарной встречи. Не посвятите ли простых смертных, какой у нас прогресс с первым пунктом?
первый пункт давно завершен, об этом мы писали на форуме. Поищите в ветках ссTLD

Еще интересно по именам третьего уровня - будут ли дешевле, кто-то занимается этим? Какие планы? какие успехи? Какие сроки реализации?

согласитесь, для сайта о провайдерах не очень подходит prov.barbaris.uz гораздо кучерявее было бы prov.com.uz или что-то вроде.

по данному пункту уже были и обсуждения на форуме, мы со своей стороны готовы, но вопрос стоит на счет регистраторов, как будем реализовать вопросы поднятия whois сервиса для субдоменов? кстати об этом тоже писали. На счет оплаты они будут дешевле, у нас уже готовы типовые правила по регистрации доменов в субдоменах. срок реализации пока сказать не могу. так как есть непосредственные вопросы к самими регистраторам в плане регистрации субдоменов. это уже оффлайновая встреча