Пятьдесят лет RFC

Аннотация

Этот RFC отмечает пятидесятую годовщину серии RFC. Он включает в себя как ретроспективный материал от лиц, вовлеченных в ключевые моменты перегиба, так и обзор текущего положения дел. Он заканчивается мыслями о возможностях на следующие пятьдесят лет для Серии. Этот документ обновляет перспективы, предлагаемые в RFC 2555 и 5540.

Оригинальное название документа

Читать оригинальную версию документа на английском языке draft-iab-fiftyyears-00

Официальный документ RFC 8700 PDF

1. Введение
2. Ключевые моменты в истории RFC
3. Перспективы
3.1. Происхождение RFC — Стивен Д. Крокер
3.2. Команда управления и редактирования RFC – Винт Церф
3.3. Формализация модели редактора RFC — Лесли Дейгл
3.4. Продолжение или создание потока — Невил Браунли
3.5. Взгляд изнутри редактора RFC — Сэнди Гиноза
4. Следующие пятьдесят лет RFC
4.1. Сохранение
4.2. Эволюция формата RFC
4.3. Структура потока
5. Вывод
6. Благодарности
7. Информационные ссылки
Приложение А. Авторы
Адрес автора

1. Введение (начало RFC)

Серия RFC началась в апреле 1969 года с публикации «Программного обеспечения хоста» Стива Крокера. Первые RFC были, по сути, запросами комментариев по идеям и предложениям; цель состояла в том, чтобы начать разговоры, а не создать архивную запись стандарта или лучшей практики. Эта цель со временем менялась по мере развития формальности процесса публикации и роста сообщества, потребляющего материал. На сегодняшний день опубликовано более 8500 RFC, включая информацию о передовой практике, экспериментальные протоколы, информационные материалы и, конечно же, стандарты Интернета. Материал принимается для публикации через IETF, IAB, IRTF и поток независимых представлений, каждый из которых содержит четкие процедуры представления проектов и, возможно, одобрения для публикации в качестве RFC. В конечном счете, целью серии RFC является предоставление канонического источника для материала, публикуемого редактором RFC, и поддержка сохранения этого материала на постоянной основе.

Редактор RFC как роль появился через несколько лет после публикации первого RFC. Фактическая дата, когда термин использовался впервые, неизвестна, но она была формализована [RFC0902] в июле 1984 г; Джон Постел, первый редактор RFC, определил роль своими действиями, а затем определил начальные процессы, связанные с публикацией RFC. Не вызывает сомнений то, что редактор RFC отвечает за то, чтобы качество публикации опубликованных RFC было высоким, а архивная информация о том, что было опубликовано, сохраняется.

Изменения приходят в серию, хотя и медленно. Во-первых, мы увидели, как метод распространения изменился с почтовой почты на FTP и электронную почту. Оттуда мы увидели усиленное руководство для авторов о том, как написать RFC. Коллектив редакции перешел из одного человека, Джона Постеля, в команду из пяти-семи человек. Фактическая работа по редактированию и публикации отделена от сервиса для регистрации кодовых точек протокола. Вся структура редактора RFC была рассмотрена [RFC4844], уточнена [RFC5620] и уточнена снова [RFC6635]. И в последние несколько лет мы начали процесс изменения формата самих документов RFC.

Это эволюция, и серия будет продолжать адаптироваться для удовлетворения потребностей и ожиданий сообщества авторов, операторов, историков и пользователей серии RFC. Эти изменения всегда будут сбалансированы с основной миссией Серии: поддерживать надежную, стабильную архивную запись технических спецификаций, протоколов и другой информации, относящейся к сообществам ARPANET и интернет-сетей.

В истории RFC есть нечто большее, чем можно описать в этом документе. Читатели, заинтересованные в более ранних перспективах, могут найти следующие RFC, представляющие особый интерес, которые сосредоточены на огромном вкладе Джона Постела, царя сокетных номеров [RFC0433] и первого редактора RFC:

[RFC2441] «Работая с Джоном, Tribute доставлен в UCLA»
[RFC2555] «30 лет RFC»
[RFC5540] «40 лет RFC»

В этом документе история серии рассматривается глазами нескольких людей, которые участвовали в формировании серии. Повествования такого характера предлагают ограниченный взгляд на события; почти наверняка есть и другие точки зрения, воспоминания и взгляды на события, которые одинаково действительны и отражают другую историю. Таким образом, хотя эти ретроспективы чрезвычайно ценны и дают представление о событиях дня, они являются лишь одним объективом в истории серии RFC.

Стив Крокер, автор RFC 1, предлагает свои мысли о том, как и почему началась серия. Лесли Дейгл, оказавшая большое влияние на разработку модели редактора RFC, поделилась своими соображениями о переходе редактора RFC на более строгую контрактную функцию. Невил Браунли, независимый редактор материалов с 2010 по февраль 2018 года, делится своим мнением о разъяснении IS и его перехода от Боба Брэйдена. Как нынешний редактор серии RFC, я расскажу о последних изменениях в формализации цифрового сохранения серии, процессе модернизации формата с учетом необходимости стабильности и своих соображениях о следующих пятидесяти годах RFC.

Этот документ обновляет перспективы, предлагаемые в RFC 2555 и 5540.

2. Ключевые моменты в истории RFC

Маркер | Дата | Событие |

Таблица 1: Ключевые моменты в истории RFC

3. Перспективы

3.1. Происхождение RFC — Стивен Д. Крокер

[Это пересмотр материала, включенного в [RFC1000] август 1987 года, более тридцати лет назад.]

Интернет-сообщество теперь включает в себя миллионы узлов и миллиарды пользователей. Своим началом он обязан ARPANET, который когда-то был лишь блеском в глазах Дж. К. Р. Ликлидера, Боба Тейлора и Ларри Робертса из ARPA. Хотя большая часть разработки шла в соответствии с планом, первоначальная разработка протоколов и создание RFC были в значительной степени случайными.

Закупка ARPANET была начата летом 1968 года — вспомните Вьетнам, детей цветов и т. д.? На разных сайтах ARPA проводились предварительные эксперименты по объединению компьютерных систем, но это была первая версия, в которой исследовалась коммутация пакетов как основная часть коммуникационной стратегии. («ARPA» не стал «DARPA» до 1972 года. Он ненадолго перешел обратно на ARPA в 1993 году, а затем снова на DARPA.) В правительственном запросе предложений (RFQ) были названы четыре устройства с коммутацией пакетов, называемые процессорами интерфейсных сообщений. («IMP»), который будет доставлен в четыре пункта в западной части США: Калифорнийский университет в Лос-Анджелесе (UCLA); SRI International в Менло-Парке, Калифорния; Калифорнийский университет в Санта-Барбаре; Университет Юты в Солт-Лейк-Сити. На этих сайтах, соответственно, работали системы Sigma 7 Scientific Data Systems (SDS), SDS 940, IBM 360/75 и DEC PDP-10. Эти машины не только имели разные операционные системы, но даже детали, такие как наборы символов и размеры байтов, различались, и другие сайты будут иметь дополнительные вариации.

Основное внимание было уделено основному движению данных. Точное использование ARPANET не было прописано заранее, поэтому от исследовательского сообщества требуется определенная инициатива. Чтобы стимулировать этот процесс, в августе 1968 года была созвана встреча с представителями отобранных объектов под председательством Элмера Шапиро из SRI. Основываясь на записях Шапиро от этой встречи, присутствовали Дейв Хоппер и Джефф Рулифсон из SRI, Глен Каллер и Гордон Бак из Санта-Барбары, Р. Стивенсон, К. Стивен Карр и В. Боам из Юты, Винт Серф и я из Калифорнийского университета, и несколько других с потенциальных будущих сайтов.

Эта первая встреча была плодотворной. У нас было много вопросов. Каким образом IMP и «хосты» (я думаю, это был первый раз, когда я столкнулся с этим термином) будут связаны? Что хозяева скажут друг другу? Какие приложения будут поддерживаться? Единственными конкретными ответами были удаленный вход в систему в качестве замены для коммутируемого доступа, телефонный интерактивный доступ к терминалу и передача файлов, но мы знали, что видение должно быть шире. Мы обнаружили, что представляем всевозможные возможности — интерактивную графику, взаимодействующие процессы, автоматический запрос к базе данных, электронную почту — но никто не знал, с чего начать. Мы не были уверены, было ли действительно место, чтобы серьезно задуматься над этими проблемами; наверняка кто-то из старших и ответственных, вероятно, с Востока, будет рядом, чтобы донести слово. Но мы пришли к одному выводу: мы должны встретиться снова. В течение следующих нескольких месяцев мы встречались на каждом из наших сайтов, создавая тем самым прецедент для регулярных личных встреч. Мы также сразу почувствовали иронию. Предполагалось, что эта новая сеть позволит работать вместе на расстоянии, и первое, что мы сделали, — это запланировали значительное количество поездок.

В течение следующих нескольких месяцев встретился небольшой, довольно последовательный набор аспирантов и сотрудников из первых четырех мест. Мы использовали термин Сетевая рабочая группа (NWG — Network Working Group), чтобы обозначить себя. Это был тот же термин, который использовал Элмер Шапиро, когда он созвал нашу первую встречу, хотя до этого момента он использовался для обозначения главных следователей и персонала ARPA — пожилых людей, которые планировали сеть. Наша группа была младшей и не отделялась от предыдущей группы, за исключением, конечно, того, что каждый из нас работал на одного из главных следователей.

Первые несколько встреч были довольно незначительными, в первую очередь потому, что мы не были уверены, насколько узкими или обширными должны быть наши цели. У нас не было официального устава или руководства, и, по крайней мере для меня, оставалось неясным, появится ли кто-то или какая-то группа с официальными полномочиями и ответственностью, чтобы взять на себя решение проблем, с которыми мы сталкиваемся. Без четкого определения того, как будет выглядеть интерфейс host-IMP, или даже без точного определения функций, которые обеспечит IMP, мы сосредоточились на более широких идеях. Мы предусмотрели возможность применения протоколов, специфичных для приложений, с кодом, загружаемым на сайты пользователей, и мы взялись за разработку языка для поддержки этого. Первая версия была известна как DEL (Decode-Encode Language) для «языка декодирования и кодирования», а более поздняя версия называлась NIL (Network Interchange Language) для «языка сетевого обмена».

В конце 1968 года Болт Беранек и Ньюман (BBN) в Кембридже, Массачусетс, выиграли контракт на IMP и начали работу в январе 1969 года. Некоторые из нас вылетели в Бостон в середине февраля, чтобы встретиться с командой BBN. В число участников BBN, возглавляемых Фрэнком Хартом, входили Боб Кан, Северо Орнштейн, Бен Баркер, Уилл Кроутер, Берни Козелл и Дейв Уолден. Они были организованы, профессиональны и целенаправленны. Их первоочередная задача заключалась в том, как выполнить график контрактов на поставку первого IMP в UCLA в начале сентября и как быстро и надежно передавать биты. Детали интерфейса host-IMP еще не были точными; спецификация появилась несколько месяцев спустя, как отчет BBN 1822. В частности, BBN не взял на себя процесс разработки нашего протокола и не появился какой-либо другой источник полномочий. Таким образом, мы упорно продолжали обсуждать и разработки протоколов.

Через месяц наш маленький NWG встретился в штате Юта. Когда встреча подошла к концу, нам стало ясно, что мы должны начать записывать наши дискуссии. Мы накопили несколько заметок о дизайне DEL и других вопросах, и мы решили объединить их в набор заметок. Мы назначили работу по письму каждому из нас, и я взял на себя дополнительную задачу организации заметок. Хотя я и инициировал RFC, моя роль была намного меньше, чем редактора. Каждый RFC был пронумерован по порядку. Единственное правило, которое я наложил, было то, что примечание должно было быть завершено до того, как я назначил номер, потому что я хотел минимизировать количество дырок в последовательности.

Я пару раз пытался написать заметку о том, как эти записи будут организованы, но я был полон трепета. Будут ли эти записи выглядеть так, как будто мы утверждаем, что у нас их не было? Будем ли мы непреднамеренно обижать кого бы то ни было официальные разработчики протоколов? Наконец, не в силах уснуть, я написал несколько скромных слов. Основные основные правила заключались в том, что каждый мог сказать что-либо, и что ничего не было официальным. И чтобы подчеркнуть это, я воспользовался предложением Билла Дювалля и пометил примечания «Запрос комментариев». Я никогда не думал, что эти заметки в конечном итоге будут распространяться через ту самую среду, которую мы обсуждали в этих заметках. Разговор о ученике чародея!

После того, как BBN распространил спецификацию интерфейса аппаратного и программного обеспечения для IMP на начальные сайты ARPANET, наше внимание переключилось на вопросы низкого уровня. Амбициозные идеи по автоматической загрузке кода испарились. Прошло несколько лет, прежде чем появились такие идеи, как мобильный код, удаленные вызовы процедур, интерфейсы ActiveX, JAVA и RESTful.

В течение весны и лета того же года мы столкнулись с детальными проблемами разработки протоколов. Хотя у нас было видение огромного потенциала для межкомпьютерной связи, разработка пригодных для использования протоколов была другим вопросом. Мы знали, что для всего, что мы спроектировали, потребовался пользовательский интерфейс аппаратного обеспечения и добавление программного обеспечения в операционной системе, и мы предполагали, что это создаст определенные трудности на каждом из сайтов. Мы искали существующие абстракции для использования. Было бы удобно, если бы мы могли сделать сеть просто похожей на обычное устройство, например ленточный накопитель, но мы знали, что это не будет делать. Суть этой сети заключалась в одноранговом взаимодействии между машинами и процессами внутри них, а не в центральной машине, управляющей зависимыми устройствами. Мы остановились на уровне виртуального потока битов в качестве основного строительного блока для протоколов, но даже тогда мы знали, что некоторым приложениям, таким как голосовая связь, может потребоваться избежать этого уровня программного обеспечения. (Почему виртуальный битовый поток вместо виртуального байтового потока? Потому что у каждого компьютера было свое представление о том, сколько битов было в байте. Восемь битовых байтов стали стандартными лишь несколько лет спустя.)

В течение следующих двух лет мы разрабатывали, обменивались и реализовывали идеи. Я взял отпуск из Калифорнийского университета в июне 1971 года, чтобы провести время, работая в ARPA. Джон Постел взял на себя заботу и питание RFC, развивая этот процесс и добавляя коллаборационистов в течение следующих двадцати семи лет.

Быстрый рост сети и рабочей группы также привел к большой куче RFC. Когда появился 100-й RFC, Пегги Карп из MITRE взяла на себя задачу их индексации. Тогда это казалось большой задачей, и мы вряд ли могли ожидать увидеть более 1000 RFC несколькими годами позже, а эволюцию к Интернет-шашкам — еще позже.

Когда мы впервые начали работать над протоколами, сеть не существовала. За исключением наших личных встреч, RFC были нашим единственным средством общения. В [RFC0003] я установил планку как можно ниже:

Содержимое заметки NWG может представлять собой любую мысль, предложение и т. Д., Относящиеся к программному обеспечению HOST или другому аспекту сети. Примечания рекомендуется делать своевременными, а не полированными. Философские позиции без примеров или других специфических особенностей, конкретные предложения или методы реализации без вводного или фонового объяснения, а также явные вопросы без каких-либо попыток ответить на них являются приемлемыми. Минимальная длина ноты NWG составляет одно предложение.

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

Делать RFC неформальными было не только способом поощрения участия; это также важно для обеспечения эффективности коммуникации. Один из ранних участников сказал, что у него были проблемы с написанием и отправкой RFC, потому что его организация хотела подвергнуть их рассмотрению публикации. Это не «публикации», заявил я, и проблема ушла. Другой небольшой деталью, инстинктивно и без споров, была модель распределения. Каждое учреждение должно было направить копию непосредственно каждой другой группе участвующих учреждений. Каждое учреждение занималось внутренними копиями и распространением самостоятельно. Представление в центральный пункт для перераспределения не требовалось, чтобы минимизировать задержки. Сетевой информационный центр SRI, однако, сохранил центральное хранилище всего и обеспечил бесценный отчет.

Мы не собирались бросать вызов существующим организациям по стандартизации, но наш естественный режим работы дал некоторые поразительные результаты. RFC открыты в двух важных аспектах: любой может написать один бесплатно, а любой получить их бесплатно. В то время правительство финансировало практически всех в сообществе ARPANET, поэтому конкуренция была незначительной, и не нужно было использовать документы для сбора средств. Конечно, как только у нас была электронная почта, работающая над ARPANET, мы распространяли RFC в электронном виде. Когда ARPANET стала лишь частью Интернета, этот процесс распространения стал всемирным. Эффект этой открытости часто упускается из виду. Студенты и молодые специалисты по всему миру смогли загрузить RFC, узнать о многих технологиях, а затем создать самое удивительное программное обеспечение. И они все еще есть. [Они также являются фантастическим ресурсом для историков.]

Где это закончится? ARPANET родила Интернет, и основная технология перешла от первоначального протокола хост-хост к TCP / IP, но надстройка протокольных уровней, разработка протоколов сообщества и RFC продолжались. Благодаря многочисленным изменениям в технологии физического уровня — аналоговых медных, цифровых, оптоволоконных и беспроводных — в результате скорость увеличивается от тысяч до миллиардов бит в секунду, и аналогичное увеличение от тысяч до миллиардов пользователей, эта надстройка, включая RFC продолжал служить сообществу. Все компьютеры изменились, как и все линии передачи. Но RFC идут. Может быть, я напишу несколько слов для RFC 10000.

Совершенно очевидно, что обстоятельства изменились. Электронная почта и другие средства массовой информации чаще всего используются для немедленного обмена зарождающимися мыслями. Интернет-шашки — это средство обмена существенным, хотя иногда и спекулятивным контентом. А RFC зарезервированы для полностью отшлифованных, проверенных, отредактированных и утвержденных спецификаций. Комментарии к RFC не запрашиваются, хотя обсуждения, связанные с использованием и другие комментарии в списках рассылки, часто, тем не менее, имеют место. Вместо того, чтобы оплакивать изменения, я принимаю это как замечательный пример адаптации. RFC продолжают служить сообществу разработчиков протоколов. Действительно, они являются основой очень динамичного и продуктивного процесса, который подпитывает и направляет интернет-революцию.

3.2. Команда управления и редактирования RFC – Винт Церф

Как упоминает Стив Крокер в Разделе 3.1, Джон Постел взял на себя роль менеджера RFC в 1971 году, когда Стив покинул UCLA для ARPA. Джон взял на себя эту роль в дополнение к своим последующим обязанностям «Царя чисел». Первоначально он сосредоточился в основном на присвоении номеров RFC начинающим авторам, но со временем, и поскольку стандартизация ARPANET и интернет-протоколов продолжала быстро развиваться, он начал выполнять редакционные функции. Кроме того, будучи опытным инженером-программистом, у него были мнения о техническом содержании в дополнение к стилю написания, и он не стеснялся проявлять редакционную осмотрительность, так как будущие опубликованные авторы представляли свои предложения для его изучения. По мере увеличения нагрузки он набирал дополнительные «волонтерские» таланты, прежде всего Джойс К. Рейнольдс, научный сотрудник USC / ISI. В последующие годы он также пригласил Роберта (Боба) Брэйдена в команду, и когда Джон неожиданно скончался в октябре 1998 года (см. [RFC2468]), Джойс и Боб взяли на себя обязательство продолжать работу над RFC, добавив Сэнди Джинозу. в команду. В период, когда Джон и Джойс работали в тесном контакте, Джойс бросила мне вызов, чтобы рассказать, какие изменения были внесены Джоном, а какие — ею. Я нашел это невозможным, настолько выровненным они были в их редакционных чувствах. К сожалению, три из этих неутомимых Internauts ушли в прошлое, и у нас есть только продукт их совместной работы и корпоративной памяти Сэнди Гинозы и других, благодаря которой можно вспомнить историю.

3.3. Формализация модели редактора RFC — Лесли Дейгл

Я был председателем Совета по архитектуре Интернета, совета, ответственного за общий надзор за серией RFC, на определенном переломном этапе в развитии всех институтов интернет-технологий. Чтобы понять, что мы сделали и почему мы должны были, позвольте мне сначала нарисовать более широкую картину дуги этих учреждений.

Как и многие другие, кто занимал руководящие должности в середине XIX века, я не присутствовал при рождении Интернета. До меня дошли знания, что из группы талантливых исследователей, которые разработали основные спецификации и определили направление Интернета, разные люди стали играть роли, необходимые для организации и развития процесса разработки спецификаций. По мере того как работа над спецификацией расширялась, этих людей, как правило, поддерживали организации, действовавшие в том же духе. В основном это был Джон Постел, который управлял распределением и присвоением имен и номеров, а также работал редактором RFC, но были также отдельные лица и учреждения, поддерживающие функцию секретариата IETF. К концу 20-го века, даже эта модель изнашивалась — функции поддержки росли, и у организаций не было возможности пожертвовать еще больше ресурсов для их работы. В некоторых случаях (IANA) существовала значительная отраслевая и международная зависимость от функции и ее нейтральности.

IETF тоже выросла в размерах, росте и коммерческой зависимости. Эта система институциональных элементов, «летающих в формировании», не обеспечивала договорную регулярность или комплексное развитие, в которых нуждалась IETF. Люди, которых там не было, когда институты развивались, в том числе лица, принимающие решения IETF, не понимали, почему все «должно быть так, как было», и были разочарованы, когда пытались обновить отдельные системы для новых требований, и лучше интегрированы во все сферы деятельности.

Интернет-инжиниринг расширился до такой степени, что его поддерживали слабо связанные группы людей, которые были там с самого начала и хорошо знали друг друга. Потребовались новые формы управления, а также рационализированное финансирование. Функция IANA была поглощена специально созданной международной некоммерческой организацией. IETF активизировала свою собственную организационную судьбу, создав деятельность по административной поддержке IETF (IASA), и Секретариат стал одной из ее контрактных функций.

Это оставило функцию редактора RFC независимой инициативой, поддерживаемой интернет-обществом.

Этот независимый характер был необходим для исторической роли серии RFC при рассмотрении всех технических вкладов. Но в тот переломный момент в истории серии потребовалась новая модель управления и финансирования, как и другие организации, поддерживающие технические спецификации Интернета. Кроме того, у руководства IETF были некоторые опасения, которые, по его мнению, необходимо было рассмотреть в своем собственном техническом потоке публикаций. Несмотря на то, что серия RFC была создана до появления IETF, и исторически в ней по-прежнему содержались документы, не относящиеся к IETF, IETF была ее крупнейшим и наиболее организованным участником. Не было никакой конкретной организации независимых участников. Точно так же финансирование Редактора RFC на тот момент осуществлялось Обществом Интернета под предлогом «поддержки IETF». Для людей, которые с самого начала не были связаны с учреждением, было довольно легко воспринимать серию RFC однозначно как серию публикаций IETF. Таким образом, задача состояла в том, чтобы выявить и решить проблемы IETF, наряду с управлением и финансированием, не жертвуя фундаментальным характером серии RFC как серии публикаций, выходящих за рамки IETF.

Чтобы дать представление о видах напряженности, которые были преобладающими, позвольте мне поделиться с вами тем, что единственная фраза, которая мне запомнилась из этих дискуссий: «толчок к публикации». В руководстве IETF были те, кто считал, что это значительно сократит расходы и улучшит своевременность, если RFC можно будет опубликовать, буквально нажав кнопку на веб-интерфейсе в тот момент, когда он будет утвержден IESG. Они также утверждали, что это устранит проблемы со спецификациями, возникающие у редакторов-копировщиков, которые были наняты как временные работники, чтобы помочь улучшить показатели публикации, но которые не всегда были в курсе технических требований технических условий. (Было несколько довольно вопиющих примеров, когда авторы копий вносили изменения, которые значительно изменили технический смысл текста, на который я не могу здесь ссылаться; давайте просто скажем, что не было просто проблемы с тем, чтобы интернет-инженеры были обеспокоены перемещением их сыра). Хотя «толчок к публикации» решил бы эти проблемы, он не решил бы проблему потери ясности из-за многих значительных улучшений текста, которые были успешно внесены редакторами копий, или того факта, что IESG одобрили не все RFC.

Институционально было ясно, что цель состояла в том, чтобы обеспечить управление функциями редактора RFC в пределах досягаемости технического сообщества Интернета (в отличие от какой-либо конкретной частной организации), без привязки его конкретно к IETF. Это было разумно достижимо путем обеспечения того, чтобы результирующие части были созданы под надзором IAB (который сам по себе независим от IETF, даже если он поддерживается организацией IASA).

IETF работал над документом с изложением функциональных требований для публикации своей технической спецификации. Это могло бы быть полезно для создания своей собственной серии, но оно также помогло установить осведомленность о трудностях в публикации документов (это всегда выглядит легко, когда вы не думали об этом), а также заложить основу для диалога с Редактор RFC. Документ с требованиями был опубликован как [RFC4714], как информационный RFC, который сегодня служит руководством для процессов редактирования публикаций IETF.

Однако все еще сохранялась определенная неясность в отношении ответственности за принятие решений и изменений в самой серии RFC. С этой целью я и IAB работали с различными заинтересованными сторонами над созданием [RFC4844]. В этом документе отражена миссия Серии RFC (для целей, превышающих публикацию технических спецификаций IETF), а также роли и обязанности участвующих сторон. Редактор RFC несет ответственность за обеспечение выполнения миссии. IAB продолжает нести обязанности по надзору, в том числе надзору за политикой, в отношении которого он может действовать, меняя человека (организацию) в роли редактора RFC. В то же время оперативный надзор был перенесен в функцию поддержки IASA IETF (и IAB).
Обсуждения и, как следствие, публикация RFC 4844, позволили лучше понять и посвятить себя серии RFC, как общей публикации в Интернете. Это также означало, что по мере развития требований могут быть внесены последующие корректировки — ответственные стороны четко определены.

3.4. Продолжение или создание потока — Невил Браунли

Возможно, начиная с 2006 года с [RFC4714], IAB и сообщество IETF потратили некоторое время на разработку структуры серии RFC в середине 2000-х годов. Эта работа включала в себя определение того, как те группы, которые опубликовали в серии RFC (первоначально включая IETF, IAB [RFC4845] и поток независимых представлений [RFC4846], а затем расширяющийся, чтобы включить IRTF [RFC5743]), будут обрабатывать утвержденные документы для быть опубликованы как RFC. В 2009 году IAB опубликовал «Редактор RFC (версия 1)» [RFC5620]. В этой модели была создана новая роль в редакторе RFC, редакторе серии RFC (RSE), который будет контролировать публикацию и разработку RFC, оставляя процесс утверждения документов для публикации вне его или ее мандата. Хотя, возможно, эту роль долго исполняли такие люди, как Джон Постел, Боб Брэйден и Джойс Рейнольдс, в RFC 5620 роль редактора серии RFC была определена таким образом, чтобы четко отделить ее от роли редактора независимых представлений (ISE). ,

До 2009 года редактор RFC мог принимать «независимые» представления от отдельных лиц и — если он считал их значительными — публиковать их как RFC; Независимый поток был создан для продолжения этой функции. С февраля 2010 года по февраль 2018 года я был Независимым редактором потока (ISE) и начал с чтения [RFC4846], затем продолжил разработку Независимого потока (IS).

Сначала я провел несколько дней в производственном центре RFC в ISI в Марина-дель-Рей с редактором RFC (Боб Брэйден) и Сэнди Джинозой и Алисой Хагенс, чтобы узнать, как на самом деле редактировались и публиковались RFC. Все RFC достигают производственного центра в виде интернет-шашек; они редактируются до тех пор, пока отредактированная версия не может быть одобрена их авторами (AUTH48). На любом этапе авторы могут проверить статус своего проекта в базе данных редактора RFC.

Для независимых представлений Боб вел журнал (простой файл ASCII) своих взаимодействий с авторами для каждого черновика, проиндексированный по имени черновика. Боб также внес независимые черновики в базу данных редактора RFC, чтобы авторы могли отслеживать статус их черновиков. После нескольких дней, проведенных с его командой в ISI, он передал мне этот журнал (охватывающий около 30 проектов) и сказал: «Теперь это вам!»

Я начал с того, что пошел по стопам Боба, вел журнал и отслеживал состояние каждого черновика в базе данных редактора RFC. Мое первое соображение состояло в том, что каждый представленный серьезный интернет-проект нуждается в тщательном рассмотрении. Если ISE знает подходящих рецензентов, он может просто спросить их. В противном случае, если проект относится к рабочей группе IETF или IRTF, он может попросить председателя рабочей группы или региональных директоров предложить рецензентов. Кроме того, у ISE есть Независимая редакционная коллегия заявок (Ed Board), которую он может попросить рецензентов. По моему опыту работы с рецензентами большинство из тех, к кому я обратился, были рады помочь.

Большинство черновиков были простыми, но некоторые требовали дополнительного внимания. Часто проект запрашивает кодовые пункты IANA, и для этого IANA всегда быстро предлагала помощь и поддержку. Кодовые пункты в некоторых реестрах IANA требуют экспертизы — иногда взаимодействие с экспертами-экспертами занимало довольно много времени! Опять же, иногда черновик, казалось, лучше вписывался в поток IETF; для них я бы предложил, чтобы авторы проекта попытались найти регионального директора, который бы спонсировал их работу, как в Индивидуальной подаче в поток IETF.

После первых нескольких лет работы в ISE команда IETF Tools разработала средство отслеживания данных, чтобы оно могло отображать состояние черновика и выполнять все «служебные» задачи для всех потоков. На этом этапе я переключился на использование Data Tracker, а не базы данных RFC Editor.

Как только проект был рассмотрен, и авторы пересмотрели его в диалоге со своими рецензентами, ISE должен представить этот проект в IESG для их «Обзора конфликта» [RFC5742]. В целом, каждый проект IS получил пользу от обсуждений (которые обычно были простыми) с моим Ed Board и IESG. (Очень) несколько проектов были несколько спорными — для тех, кому я смог работать с IESG, чтобы согласовать подходящее «Заявление IESG» и / или «Заявление ISE», чтобы прояснить, почему ISE опубликовал проект.

Одна довольно особенная часть «Независимого потока» — проекты Первого апреля. Это юмористические RFC, которые никогда официально не публикуются в качестве черновиков и не имеют официального процесса проверки. Авторы должны отправить их непосредственно в ISE или в редактор RFC. Только несколько из них могут быть опубликованы каждый год; они рассмотрены ISE и RSE; Критерии Боба Брэйдена для проектов Первого апреля были:

Они должны относиться к Интернету (как и все черновики)

Их читатели должны дойти до конца второй страницы, прежде чем поймут, что это первый апрельский RFC.

На самом деле они должны быть смешными!

Первое апреля RFC имеют большое количество поклонников, и отзывы от интернет-сообщества 1 апреля каждого года были восторженными и быстрыми!

За восемь лет своей работы в ISE я опубликовал 159 RFC независимых потоков. В течение этих восьми лет я работал и часто встречался на собраниях IETF с большинством их авторов. Для меня это был очень полезный опыт, поэтому я благодарю всех этих участников. Кроме того, я работал с большинством членов IESG в течение этих восьми лет, что также дало мне много полезного общения. Наконец, мне всегда нравилось работать с редактором RFC и всеми сотрудниками производственного центра RFC. IETF (в целом) очень повезло иметь такую эффективную команду талантливых специалистов.

3.5. Взгляд изнутри редактора RFC — Сэнди Гиноза

Когда я присоединился к ISI, вскоре после того, как скончался Джон Постел, редактора RFC, как мы его знаем сегодня (как определено в RFC 5620 и устарело в RFC 6548 и 6635), не существовало. Редактор RFC функционировал как одно целое; не было RSE, производственного центра, издателя или независимого редактора представлений. Все эти роли выполнял редактор RFC, в состав которого входили четыре человека: Боб Брэйден, Джойс Рейнольдс, программист, работающий неполный рабочий день, и я.

Боб обеспечил руководство высокого уровня и рассмотрел Независимые Представления. В то время как Боб был исследователем в «Div 7» (Networking) в ISI, якобы, процент времени, который он имел для редактора RFC, составлял 10%, но он потратил гораздо больше времени, чтобы сериал продолжался. Он разбил там, где мог, особенно когда время обработки увеличивалось; в какой-то момент он даже отменил пару будущих RFC. Джойс работала на полную ставку, но, продолжая следить за тем, чтобы RFC публиковались и служили в качестве директора зоны обслуживания пользователей и основного докладчика об Интернете, она также была временно отдана в аренду IANA на 50% своего времени, пока IANA получала устанавливается после отделения от ISI. Студент-программист выполнял задачи программирования по запросу и в то время отвечал за разбор MIB. Я был штатным сотрудником и должен был быстро освоить веревки, чтобы RFC продолжали публиковаться.

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

Рабочая нагрузка значительно возросла в течение следующих нескольких лет. Когда рабочая нагрузка увеличилась, редактор RFC отреагировал и постепенно увеличивал штат сотрудников. Чтобы понять рост команды, давайте сначала взглянем на показатели публикаций за всю историю. В таблице ниже приведены среднегодовые показатели публикации за 5-летние периоды.

Таблица 2 - Ежегодные темпы публикации — Таблица 2 — Ежегодные темпы публикации

В 90-е годы и в последующие годы наблюдался значительный скачок в количестве публикаций, причем число публикаций почти удвоилось в период с 1993 по 2007 год. Годовой объем заявок впервые превысил отметку 300 в 2004 году и достиг рекордного максимума в 385 в 2011. Уровень представления не опускался ниже 300 до 2016 года (284).

По мере роста количества заявок редактор RFC испытывал все больший рост. Время обработки стало увеличиваться, поскольку существующий персонал не мог успевать за расширяющимся размером очереди. В попытке уменьшить учебный барьер и избежать постоянного найма персонала в случае, если посылка была случайной, ISI привлек временных редакторов копирования — таким образом, персонал может быть легко изменен по мере необходимости. Однако, как заметил Лесли, это не очень хорошо сработало. Результаты эксперимента будут продолжительными, поскольку это привело к той форме процесса, которую мы имеем сейчас, когда редактор RFC задает больше вопросов во время AUTH / AUTH48, а технические изменения требуют одобрения соответствующих региональных директоров или менеджеров потоков, в зависимости от поток документов. Эти изменения добавили к рабочей нагрузке и продлили время публикации; многие часто в шутку называют AUTH48 авторами «48 дней», «48 недель» и т. д.

Поскольку рабочая нагрузка продолжала увеличиваться (во многих отношениях, а не только за подачу документов; тестирование инструментов, изменения в редакторских процессах и т. Д.) И уроки, извлеченные с помощью редакторов временных копий, наша команда постоянно росла. Несмотря на то, что между нами были другие редакторы, два дополнения представляют особый интерес, поскольку они испытали большую часть растущих трудностей редактора RFC, помогли вывести нас из состояния с ошибками, сформировали функцию редактора RFC и до сих пор работают в команде: Алиса Руссо присоединился к команде в 2005 году, а Меган Фергюсон присоединилась к нам в 2007 году.

С пониманием того, что рекордное количество представлений не было аномалией, мы внесли значительные улучшения в инфраструктуру функции редактора RFC, чтобы упростить отслеживание документов и создание отчетов. Например, знаменитый «черный переплет» — фактический переплет из трех колец, используемый для отслеживания назначения номеров, HTML-файл, отредактированный вручную для страницы очереди, и набор текстовых файлов и сценариев Рубе-Голдберга, которые создавали статистику очереди. в итоге заменили; была предложена и внедрена система опечаток; и XML стал вновь принятым исходным файлом.

В 2009 году был опубликован RFC 5620, представляющий начальную версию модели редактора RFC, которую мы имеем сейчас. Хотя он был опубликован в 2009 году, он не вступил в силу до 2010 года, когда проект Редактора RFC, как я знал, был расформирован и разделен на четыре части: Редактор серии RFC (RSE), Независимый редактор представлений (ISE), Производство RFC Центр (RPC) и Издатель. Кроме того, была создана Консультативная группа серии RFC (RSAG) для «предоставления экспертного, информированного руководства (главным образом, RSE) по вопросам, влияющим на эксплуатацию и развитие серии RFC».

В 2010 году контракты RPC и издателя были присуждены Системам управления ассоциациями (AMS); мы начали с трех существующих членов команды (Алиса Руссо, Меган Фергюсон и я), и мы были рады, что к нам присоединилась Линн Варфоломей, новый коллега, который закрепил нас в офисе AMS, а позже и Ребекка ВанРинен вскоре после этого.

Я с осторожностью относился к этой модели и особенно беспокоился о дыре, которую может создать отъезд Боба Брэйдена. К счастью для нас, Боб Брэйден предоставил мудрый совет и понимание во время перехода (и далее). Он дал персоналу, переходящему на AMS, особенно полезные напутствия — «продолжайте работу с RFC» — и это то, что мы сделали.

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

Наше внимание при переходе было сосредоточено на том, чтобы: 1) поддерживать движение поездов; то есть мы хотели начать работать с минимальным временем простоя и 2) работать с Переходной RSE, Независимым редактором представлений (Невилом Браунли), RSAG и IAD, чтобы лучше понять и реализовать недавно определенную модель редактора RFC.

Хотя некоторые этапы перехода были сложными и длились дольше, чем ожидалось, исполняющая обязанности RSE (Олаф Колкман) официально передала бразды правления RSE (Хизер Фланаган) в 2012 году. Ей пришлось вскочить, выучить редактор RFC и культуру IETF, и проработать список проблем, которые остались без внимания.

Две проблемы с ошибками были такими старыми, они были теми, о которых кто-то меня спрашивал на моем первом IETF: когда Редактор RFC разрешит использование символов не-ASCII в RFC, и когда Редактор RFC примет более современный формат публикации.

В то время, хотя мы понимали желание перейти к поддержке более широкого набора символов и получать более современные результаты, мы также регулярно получали электронные письма от отдельных лиц с просьбой отправить им текстовые файлы (вместо того, чтобы указывать их на веб-сайт). ) потому что их доступ в интернет был ограничен. Мы также регулярно получали жалобы от пользователей rfc-editor.org, когда что-то на сайте не работало корректно с их старыми браузерами. Короче говоря, мы не могли продвигаться вперед, не оставляя позади большое количество пользователей.

Однако теперь мы находимся на грани перемен. 2019 год обещает быть БОЛЬШИМ для серии RFC, так как мы ожидаем перехода от публикации простых текстовых файлов только в формате ASCII к публикации нескольких форматов файлов (XML, HTML, PDF / A-3 и TXT), которые допускают как не-ASCII персонажи и SVG арт.

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

4. Следующие пятьдесят лет RFC

Как упомянул Стив Крокер, серия началась с цели коммуникации, а не формальности, открытости, структуры. Поскольку Интернет вырос и стал повсеместным глобальным конструктом, мы по-прежнему стремимся к открытости и общению, но признаем, что для протоколов и другой информации, обеспечивающей взаимодействие, должны быть точки стабильности, из которых можно строить. Маленькие разработчики приложений для многомиллиардных компаний находятся в том же положении. Любой человек должен иметь возможность оглянуться назад и понять, что было сделано и почему.

В то время как неформальность уступила место усиленной структуре, открытость и прочная основа, которую обеспечивает Серия, должны продолжаться. Имея это в виду, что будет дальше на следующие пятьдесят лет RFC?

4.1. Сохранение

Редактор RFC существует для редактирования, публикации и ведения архива документов, опубликованных в серии RFC. Однако правильный цифровой архив — это больше, чем просто сохранение RFC на диск и обеспечение резервного копирования дисков; область цифрового сохранения выросла и превратилась в отрасль сама по себе. «Рекомендации по сохранению цифровых данных для серии RFC» [RFC8153] рассматривает, что означает цифровой архив сегодня, и описывает способы поддержки архива в будущем, а также рекомендует редактору RFC воспользоваться теми организациями, которые специализируются в этой области.

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

4.2. Эволюция формата RFC

Документы RFC были цифровыми документами с самого начала серии. Хотя этот формат не всегда публикуется в US-ASCII, он был каноническим форматом на протяжении десятилетий. Тот факт, что этот формат пережил так много эволюции и изменений, примечателен.

К сожалению, старый формат US-ASCII недостаточно расширяется, чтобы соответствовать ожиданиям и требованиям пользователей сегодня. Вся область представления документов в режиме онлайн, их потребления и хранения в некоторых случаях была изобретена только спустя годы после публикации первого RFC. Хотя можно (и было) утверждать, что эти более новые области и их инструменты не имели возможности выдержать испытание временем, Редактор серии RFC (в консультации с сообществом) начал согласованные усилия в 2012 году, чтобы представить серию RFC в соответствие с новым набором возможностей для сохранения и отображения.

Информация о текущем проекте формата RFC, обоснование и требования к изменениям, происходящим сегодня, можно найти в [RFC7990]. С появлением этих изменений была открыта дверь для рассмотрения дальнейших изменений в будущем по мере развития спецификаций для архивирования цифрового материала и в ожидании прогресса в области веб-разработки.

4.3. Структура потока

В глазах многих, особенно в рамках IETF, серия RFC является синонимом IETF. Хотя сама серия предшествует IETF на восемнадцать лет, со временем IETF стала источником большинства документов, представляемых для публикации в RFC Editor. Политики, разработанные для потоковых проектов IETF, имеют тенденцию применяться ко всем четырем потокам документов, а связанные с публикацией инструменты, как правило, фокусируются на IETF в качестве основной аудитории для их использования. Людям трудно понять, как и даже почему существует различие между Серией и IETF.

Сейчас мы находимся в центре этого вопроса больше, чем когда-либо. Каково будущее серии? Если люди не могут сказать, где заканчивается IETF и начинается серия, следует ли нам считать это искусственным различием и объявлять их одним и тем же объектом?

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

5. Вывод

По мере развития интернета развиваются и ожидания, и возможности. В течение следующих пятидесяти лет Серия продолжит демонстрировать баланс между необходимостью сохранять верность первоначальной миссии публикации и сохранения, а также соответствовать потребностям авторов и потребителей RFC. Напряжение в уравновешивании этих потребностей лежит на редакторе RFC и сообществе, которое должно решить. Мы не избежим проблем.

6. Благодарности

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

Дополнительная благодарность членам Консультативной группы RFC Series и Независимой редакционной коллегии, в частности Скотту Брэднеру, Брайану Карпентеру и Адриану Фаррелу, за их ранние обзоры и вклад в последовательность ключевых моментов в истории Серии.

7. Информационные ссылки

[IAB-19880712] IAB, «IAB Minutes 1988-07-12», July 1988, <https://www.iab.org/documents/minutes/minutes-1988/iabminutes-1988-07-12/>.

[IETF1] «First IETF; January 16-17, 1986; San Diego, California», January 1986, <https://www.ietf.org/old/2009/proceedings/prior29/IETF01.pdf>.

[ISI-to-AMS] The IETF Administrative Support Activity, «RFC Production Center Agreement between Association Management Solutions,
LLC, and the Internet Society», October 2009, <https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-2009.pdf>.

[RFC-ONLINE] RFC Editor, «History of RFC Online Project», February 2010, <http://www.rfc-editor.org/rfc-online-2000.html>.

[RFC0001] Crocker, S., «Host Software», RFC 1, DOI 10.17487/RFC0001, April 1969, <https://www.rfc-editor.org/info/rfc1>.

[RFC0003] Crocker, S.D., «Documentation conventions», RFC 3, DOI 10.17487/RFC0003, April 1969, <https://www.rfc-editor.org/info/rfc3>.

[RFC0114] Bhushan, A.K., «File Transfer Protocol», RFC 114, DOI 10.17487/RFC0114, April 1971, <https://www.rfc-editor.org/info/rfc114>.

[RFC0433] Postel, J., «Socket number list», RFC 433, DOI 10.17487/RFC0433, December 1972, <https://www.rfc-editor.org/info/rfc433>.

[RFC0690] Postel, J., «Comments on the proposed Host/IMP Protocol changes», RFC 690, DOI 10.17487/RFC0690, June 1975, <https://www.rfc-editor.org/info/rfc690>.

[RFC0748] Crispin, M.R., «Telnet randomly-lose option», RFC 748, DOI 10.17487/RFC0748, April 1978, <https://www.rfc-editor.org/info/rfc748>.

[RFC0902] Reynolds, J.K. and J. Postel, «ARPA Internet Protocol policy», RFC 902, DOI 10.17487/RFC0902, July 1984, <https://www.rfc-editor.org/info/rfc902>.

[RFC1000] Reynolds, J.K. and J. Postel, «Request For Comments reference guide», RFC 1000, DOI 10.17487/RFC1000, August 1987, <https://www.rfc-editor.org/info/rfc1000>.

[RFC1083] Defense Advanced Research Projects Agency and Internet Activities Board, «IAB official protocol standards», RFC 1083, DOI 10.17487/RFC1083, December 1988, <https://www.rfc-editor.org/info/rfc1083>.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1150] Malkin, G.S. and J.K. Reynolds, «FYI on FYI: Introduction to the FYI Notes», RFC 1150, DOI 10.17487/RFC1150, March 1990, <https://www.rfc-editor.org/info/rfc1150>.

[RFC1311] Postel, J., «Introduction to the STD Notes», RFC 1311, DOI 10.17487/RFC1311, March 1992, <https://www.rfc-editor.org/info/rfc1311>.

[RFC1818] Postel, J., Li, T., and Y. Rekhter, «Best Current Practices», RFC 1818, DOI 10.17487/RFC1818, August 1995, <https://www.rfc-editor.org/info/rfc1818>.

[RFC2441] Cohen, D., «Working with Jon, Tribute delivered at UCLA, October 30, 1998», RFC 2441, DOI 10.17487/RFC2441, November 1998, <https://www.rfc-editor.org/info/rfc2441>.

[RFC2468] Cerf, V., «I REMEMBER IANA», RFC 2468, DOI 10.17487/RFC2468, October 1998, <https://www.rfc-editor.org/info/rfc2468>.

[RFC2555] Editor, RFC. and et. al., «30 Years of RFCs», RFC 2555, DOI 10.17487/RFC2555, April 1999, <https://www.rfc-editor.org/info/rfc2555>.

[RFC4714] Mankin, A. and S. Hayes, «Requirements for IETF Technical Publication Service», RFC 4714, DOI 10.17487/RFC4714, October 2006, <https://www.rfc-editor.org/info/rfc4714>.

[RFC4844] Daigle, L., Ed. and Internet Architecture Board, «The RFC Series and RFC Editor», RFC 4844, DOI 10.17487/RFC4844, July 2007, <https://www.rfc-editor.org/info/rfc4844>.

[RFC4845] Daigle, L., Ed. and Internet Architecture Board, «Process for Publication of IAB RFCs», RFC 4845, DOI 10.17487/RFC4845, July 2007, <https://www.rfc-editor.org/info/rfc4845>.

[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., «Independent Submissions to the RFC Editor», RFC 4846, DOI 10.17487/RFC4846, July 2007, <https://www.rfc-editor.org/info/rfc4846>.

[RFC5540] Editor, RFC., «40 Years of RFCs», RFC 5540, DOI 10.17487/RFC5540, April 2009, <https://www.rfc-editor.org/info/rfc5540>.

[RFC5620] Kolkman, O., Ed. and IAB, «RFC Editor Model (Version 1)», RFC 5620, DOI 10.17487/RFC5620, August 2009, <https://www.rfc-editor.org/info/rfc5620>.

[RFC5742] Alvestrand, H. and R. Housley, «IESG Procedures for Handling of Independent and IRTF Stream Submissions», BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <https://www.rfc-editor.org/info/rfc5742>.

[RFC5743] Falk, A., «Definition of an Internet Research Task Force (IRTF) Document Stream», RFC 5743, DOI 10.17487/RFC5743, December 2009, <https://www.rfc-editor.org/info/rfc5743>.

[RFC6360] Housley, R., «Conclusion of FYI RFC Sub-Series», RFC 6360, DOI 10.17487/RFC6360, August 2011, <https://www.rfc-editor.org/info/rfc6360>.

[RFC6410] Housley, R., Crocker, D., and E. Burger, «Reducing the Standards Track to Two Maturity Levels», BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, <https://www.rfc-editor.org/info/rfc6410>.

[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, «RFC Editor Model (Version 2)», RFC 6635, DOI 10.17487/RFC6635, June 2012, <https://www.rfc-editor.org/info/rfc6635>.

[RFC6949] Flanagan, H. and N. Brownlee, «RFC Series Format Requirements and Future Development», RFC 6949, DOI 10.17487/RFC6949, May 2013, <https://www.rfc-editor.org/info/rfc6949>.

[RFC7990] Flanagan, H., «RFC Format Framework», RFC 7990, DOI 10.17487/RFC7990, December 2016, <https://www.rfc-editor.org/info/rfc7990>.

[RFC8153] Flanagan, H., «Digital Preservation Considerations for the RFC Series», RFC 8153, DOI 10.17487/RFC8153, April 2017, <https://www.rfc-editor.org/info/rfc8153>.

Приложение А. Авторы

Большое спасибо Стиву Крокеру, Винту Серфу, Лесли Дейглу, Невилу Браунли и Сэнди Джинозе за их взгляды на сериал и их постоянную поддержку.

Адрес автора

Heather Flanagan (editor)
RFC Editor
Email: rse@rfc-editor.org
URI: https://orcid.org/0000-0002-2647-2220
Flanagan