Кратко

  • RFC 1302 выделил четыре функции NIC: информационные ресурсы, прямую помощь, сведения для направлений и поддержку общей инфраструктуры NIC.
  • Ответственность до разрешения не делала ответ, направление и координацию с NOC взаимозаменяемыми результатами.
  • Дата, номер редакции и создавший документ NIC позволяли проверять происхождение, но сами не доказывали точность и решение проблемы.

Следующий адрес был маршрутом, а не результатом

RFC рекомендовал единый вид адреса NIC@domain. Пользователю не требовалось заранее понимать устройство организаций. Письмо должно было вызвать человеческий ответ либо актуальный автоматический ответ, который распределял вопросы по категориям.

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

NIC должен был действовать по принципу best effort и отвечать за запрос до его разрешения некоторым способом. Документ назвал три способа: ответить, направить к подходящему источнику или координировать с NOC устранение проблемы связи. Это разные окончания обязанности сопровождения. Отправленное направление не равно принятой передаче, а координация не равна восстановлению.

У справки и эксплуатации были разные функции

NIC предоставлял информационную, административную и процедурную поддержку. NOC наблюдал за повседневной эксплуатацией сети и поддерживал её. Одна организация могла совмещать роли, и они должны были тесно работать, но граница сохранялась.

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

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

Полная карта была невозможна

RFC прямо говорил, что один NIC не способен хранить полные и свежие сведения обо всех службах и ресурсах Интернета. Центры должны были знать друг друга и области компетенции. Общая база nic-profiles превращала это знание в доступный маршрут.

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

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

Место выдачи не всегда было источником

NIC мог скопировать материал с другого сайта, указать удалённый источник или создать собственный документ. Только для собственного материала RFC возлагал на создающий NIC исключительную ответственность за содержание и точность.

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

RFC 1290 отделял указатель от конечной информации. RFC 1309 показывал единый каталог над распределёнными держателями, копиями и направлениями. Особая тема RFC 1302 — организационная нить, удерживающая вопрос пользователя при переходе между такими поверхностями.

Годовой запрос обновления не останавливал изменения

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

NIC следовало активно запрашивать обновления не реже раза в год и публиковать дату последнего изменения. Это процедура обслуживания, не постоянная гарантия истины. Дата делает период неопределённости видимым.

RFC 1261 уже показал различие во время передачи NIC от SRI к GSI. Знакомые пользовательские пути старались сохранить, но главная база WHOIS и все регистрационные действия пять дней не менялись. Доступность справочной службы не доказывала доступность авторитетной записи.

Источники

RFC 1302 описывает модель 1992 года и не доказывает современный NIC, реальное дело, принятую передачу, ремонт, точность базы, реакцию на инцидент или результат пользователя.