О документе
Network Working Group G. Scott, редактор
Request for Comments: 2360 Defense Information Systems Agency
BCP: 22 June 1998
Категория: Лучшая современная практика
Руководство для авторов интернет-стандартов
1 Введение
Этот документ представляет собой руководство для авторов интернет-
стандартов. Он предлагает руководящие указания по написанию документа
категории standards track с ясностью, точностью и полнотой. Эти
руководящие указания основаны как на прежнем успешном, так и на
неуспешном опыте IETF по подготовке спецификаций. Эти руководящие
указания следует использовать вместе с RFC 2223, "Instructions to RFC
Authors", либо его обновлением. Следует отметить, что некоторые
руководящие указания могут не применяться в определённых ситуациях.
Цель состоит в повышении вероятности взаимодействия нескольких
реализаций протокола. Написание спецификаций в соответствии с этими
руководящими указаниями не гарантирует совместимости. Однако признанным
препятствием для создания совместимых реализаций протокола являются
неясные спецификации.
Хорошо написанные спецификации протоколов принесут пользу многим.
У разработчиков реализаций будет больше возможностей соответствовать
спецификации протокола. Тестировщики протокола смогут использовать
спецификацию для вывода однозначных утверждений, поддающихся проверке.
Покупатели и пользователи протокола будут лучше понимать его
возможности.
Для получения дополнительной информации о процессе стандартизации
протоколов и процедур обратитесь к BCP 9/RFC 2026, "The Internet
Standards Process -- Revision 3". Кроме того, некоторые соображения по
проектированию протоколов приведены в RFC 1958, "Architectural
Principles of the Internet".
2 Общие руководящие указания
Важно, чтобы несколько читателей и разработчиков реализаций стандарта
одинаково понимали документ. Для этого информация должна быть упорядоченной
и подробной. Ниже приведены общие руководящие указания, предназначенные
для помощи в подготовке такого документа. IESG может потребовать, чтобы
все или некоторые из следующих разделов присутствовали в документе
категории standards track.
2.1 Обсуждение безопасности
Чтобы Интернет мог полностью реализовать свой потенциал в коммерческих,
государственных и личных делах, он должен обеспечивать пользователям
уверенность в том, что передача их информации защищена от
несанкционированного изменения или компрометации. Хорошо написанные
разделы безопасности в документах категории standards track могут помочь
сформировать требуемый уровень уверенности. Прежде всего, новые протоколы
и практики НЕ ДОЛЖНЫ (MUST NOT) ухудшать общую безопасность Интернета.
Значительная угроза для Интернета исходит от лиц, которые мотивированы и
способны использовать обстоятельства, события или уязвимости системы для
причинения вреда. Кроме того, преднамеренное или непреднамеренное
поведение пользователя может сделать систему уязвимой для атаки или
эксплуатации. Вред может варьироваться от нарушения или отказа в
предоставлении сетевой службы до повреждения пользовательских систем.
Помимо этого, раскрытие информации может предоставить средства для атаки
другой системы либо раскрыть модели поведения, которые могут быть
использованы для причинения вреда отдельному лицу, организации или сети.
Это вызывает особую озабоченность в стандартах, определяющих часть базы
управляющей информации (MIB).
Авторы стандартов должны принять, что указанный ими протокол будет
подвергаться атакам. Они несут ответственность за определение возможных
атак и за подробное описание характера атак в документе. В противном
случае они должны убедительно доказать, что атака нереалистична в
конкретной среде, и ограничить использование протокола этой средой.
После того как в документе исчерпывающе определены риски безопасности,
которым подвержен протокол, авторы должны сформулировать и подробно
описать защиту от этих атак. Они должны обсудить применяемые меры
противодействия либо риск, который пользователь принимает, используя
протокол. Меры противодействия могут предоставляться механизмом протокола
или основываться на внешних механизмах. Авторам следует знать о
существующих механизмах безопасности и повторно использовать их, если это
практически осуществимо. Когда используется криптографический алгоритм,
протокол СЛЕДУЕТ (SHOULD) писать так, чтобы в будущем допускалась его
замена другим алгоритмом. Наконец, авторам следует обсудить подсказки или
руководящие указания по реализации, например способы работы с
недостоверными данными или одноранговыми системами.
Меры безопасности будут влиять на среду, в которой они используются.
Возможно, пользователи теперь будут ограничены в том, что они могут делать
в Интернете, либо столкнутся со снижением скорости обслуживания. Следует
обсудить влияние мер безопасности на использование и производительность
протокола.
Обсуждение безопасности может быть сосредоточено в разделе документа
«Соображения безопасности» либо распределено по всему документу там, где
оно относится к отдельным частям спецификации. Преимущество второго
подхода состоит в том, что он обеспечивает включение безопасности как
неотъемлемой части разработки протокола, а не как последующей или
второстепенной работы. Если безопасность обсуждается по всему документу,
раздел «Соображения безопасности» ДОЛЖЕН (MUST) содержать сводное изложение
и ссылки на соответствующие разделы спецификации. Это обеспечит, что меры
безопасности протокола будут акцентированы как для разработчика
реализации, так и для пользователя.
В разделе «Соображения безопасности» может быть уместно обсудить
невыбранный путь. По различным причинам могут существовать несколько
механизмов безопасности, которые не были выбраны: из-за стоимости или
сложности реализации либо неэффективности для данной сетевой среды.
Перечисляя неиспользованные механизмы и причины этого, редакторы могут
продемонстрировать, что рабочая группа (WG) протокола уделила безопасности
необходимое внимание. Кроме того, это предоставляет пользователям
протокола информацию, необходимую им для рассмотрения того, подходит ли
один из невыбранных механизмов лучше для их конкретных требований.
Документ, предоставляющий дальнейшие рекомендации по темам безопасности,
находится в разработке. Авторам следует получить экземпляр завершённого
RFC, чтобы он помог им подготовить часть стандарта, посвящённую
безопасности.
Наконец, больше не приемлемо, чтобы разделы «Соображения безопасности»
состояли исключительно из утверждений о том, что безопасность не была
рассмотрена при подготовке стандарта.
Некоторые примеры разделов «Соображения безопасности» приведены в STD
33/RFC 1350, STD 51/RFC 1662 и STD 53/RFC 1939. RFC 2316, "Report of the
IAB Security Architecture Workshop", предоставляет дополнительную
информацию по этой теме.
2.2 Описание протокола
Документы категории standards track должны включать описание протокола.
Это описание должно охватывать назначение протокола, предполагаемые
функции, предоставляемые им службы, а также сферу, обстоятельства или
любые особые соображения использования протокола.
Авторы спецификации протокола будут располагать большим объёмом знаний о
причинах существования протокола. Однако читатель с большей вероятностью
будет обладать общими знаниями и опытом в области сетей, а не экспертными
знаниями о конкретном протоколе. Объяснение его назначения и использования
даст читателю точку отсчёта для
понимания протокола и того, какое место он занимает в Интернете. STD
54/RFC 2328 был рекомендован рабочей группе STDGUIDE как хороший пример
этого в его разделе "Protocol Overview".
Общее описание протокола также должно предоставлять информацию о
взаимоотношениях между различными сторонами протокола. Это можно сделать,
показав типичные последовательности пакетов.
Это также относится к алгоритмам, используемым протоколом. Необходимо
подробное описание алгоритмов или ссылка на доступные источники, в которых
приведено такое описание.
2.3 Целевая аудитория
RFC создавались для множества различных целей — от технических до
административных. В документах, написанных как стандарты, следует ясно
указывать предполагаемую аудиторию, например проектировщиков,
разработчиков реализаций, тестировщиков, персонал службы поддержки,
преподавателей, конечных пользователей или иных лиц. Если документ
адресован нескольким аудиториям, необходимо определить раздел для каждой
аудитории. Цель состоит в том, чтобы помочь читателю обнаружить и
сосредоточиться на том, ради чего он обратился к документу, и избежать
того, что он может счесть запутывающим, отвлекающим или излишним.
2.4 Уровень детализации
Автору следует рассмотреть, какой уровень описательной детализации лучше
всего передаёт замысел протокола. У краткого текста есть несколько
преимуществ. Он облегчает чтение документа. Такой текст уменьшает
вероятность противоречий между разными частями спецификации. Читатель
может без труда определить требуемые механизмы протокола в стандарте.
Кроме того, он облегчает выявление требований к реализации протокола.
Недостаток кратких описаний состоит в том, что читатель может не до конца
понять обоснование протокола и поэтому сделать предположения, которые
приведут к ошибкам реализации.
Более длинные описания могут потребоваться для объяснения назначения,
фона, обоснования, опыта реализации либо для предоставления учебной
информации. Это помогает читателю понять протокол. Однако развёрнутый
текст таит несколько опасностей. В таком тексте сложно или запутанно
находить требования протокола. Один и тот же механизм может иметь
несколько описаний, что ведёт к неверному толкованию или противоречию.
Наконец, его сложнее понять; это важно, поскольку английский не является
родным языком для многих читателей стандартов IETF по всему миру.
Один из подходов состоит в разделении стандарта на разделы: один кратко
описывает протокол, тогда как другой раздел содержит пояснительный текст.
STD 3/RFC 1122/RFC 1123 и STD 54/RFC 2328 предоставляют примеры этого
метода.
2.5 Журналы изменений
По мере продвижения документа по пути стандартизации — от Proposed к Draft, от Draft к Full либо при циклическом изменении уровня — в него будут вноситься изменения вследствие лучшего понимания протокола или опыта реализации. Чтобы помочь разработчикам реализаций отслеживать вносимые изменения, требуется журнал, показывающий, что изменилось по сравнению с предыдущей версией спецификации (см. Appendix).
2.6 Версии протокола
Часто стандарт задаёт новую версию существующего протокола. В таком случае авторам следует подробно описать различия между предыдущей и новой версиями. Это должно включать обоснование изменений, например опыт реализации, изменения технологии, реакцию на пользовательский спрос и т. д.
2.7 История принятия решений
При разработке стандартов достижение консенсуса требует принятия трудных решений. Эти решения принимаются в ходе обсуждений рабочей группы или на основе опыта реализации. Включив основания для спорного решения, автор может предотвратить повторное возвращение к этим разногласиям в будущем, когда первоначальные участники уже перейдут к другим делам. Кроме того, знание «почему» столь же полезно разработчику реализации, как и описание «как». Например, невыбранная альтернатива могла быть проще в реализации, поэтому включение причин, стоящих за выбором, может удержать будущих разработчиков реализаций от нестандартных упрощений.
2.8 Реакция на поведение вне спецификации
Полезно подробное описание действий, предпринимаемых в случае поведения, отклоняющегося от спецификации или выходящего за её пределы. Это область, в которой разработчики реализаций часто расходятся во мнениях о надлежащей реакции. Задав общую реакцию, автор стандарта может снизить риск возникновения конфликтов между различными реализациями.
Стандарту следует описывать реакции на явно запрещённое поведение или поведение вне границ, определённых спецификацией. Возможны два подхода к таким случаям: отбрасывание либо вызов механизмов обработки ошибок. Если выбрано отбрасывание, может потребоваться подробно описать дальнейшую судьбу отброшенного объекта.
Например, считать отброшенные кадры никогда не полученными либо сбросить состояние существующего соединения или смежности.
Спецификация должна описывать действия, предпринимаемые при исчерпании критически важного ресурса или превышении предела масштабирования производительности. Это необходимо для случаев, когда существует риск ухудшения состояния сети или эксплуатационного отказа. В таких случаях необходимо согласованное поведение реализаций.
2.9 Правило либеральности/консервативности
Правило, впервые сформулированное в STD 5/RFC 791 и признанное полезным для устойчивости реализации и совместимости:
«Будь либерален в том, что принимаешь,
и консервативен в том, что отправляешь».
Или устанавливайте ограничения на то, что передаёт протокол, но будьте способны обработать любую мыслимую полученную ошибку. При применении этого подхода в протоколах пути стандартизации настоятельно рекомендуется осторожность. В прошлом он приводил к конфликтам между поставщиками при сбоях совместимости. Отправитель обвиняет получателя в недостаточной либеральности, а получатель обвиняет отправителя в недостаточной консервативности. Поэтому автор обязан предоставить подробное описание поведения при отправке и приёме.
Чтобы избежать путаницы между этими двумя аспектами, рекомендуется, чтобы авторы стандартов отдельно задавали поведение при отправке и приёме. Описание приёма потребует наибольшей детализации. Ожидается, что реализации продолжат работу независимо от полученной ошибки. Поэтому действия, предпринимаемые для достижения этого результата, необходимо изложить в спецификации протокола. Авторам стандартов следует заботиться о достижении такого уровня взаимодействия, который ограничивает нарушение работы сети, а не только о том, как выжить в сети. Появление неопределённой информации или условий не должно вызывать отказ сети или хоста. Для этого требуется специфицировать, как пытаться принять большую часть пакетов. Доступны два подхода: использовать как можно больше содержимого пакета либо вызывать процедуры обработки ошибок. Автору следует указать границу, определяющую, когда применять каждый из подходов.
Следует рассмотреть случай протокола маршрутизации, в котором принятие ошибочной информации может вызвать отказ сети. Для таких протоколов спецификации следует идентифицировать пакеты, которые могут иметь различные интерпретации, и предписывать их полное отклонение либо характер попытки извлечь из них некоторую информацию. Например, обновления маршрутизации, содержащие больше данных, чем показывает число кортежей.
Авторам протокола следует рассмотреть, можно ли принять некоторые завершающие данные как дополнительные маршруты либо отклонить весь пакет как подозрительный, поскольку он не соответствует требованиям.
2.10 Обработка опций протокола
Спецификации с множеством необязательных возможностей повышают сложность реализации и вероятность появления несовместимых реализаций. Опасность состоит в том, что различные реализации могут задавать сочетания опций, не способные взаимодействовать друг с другом.
По мере продвижения документа по пути стандартизации опыт реализации должен определять необходимость каждой опции. Реализация должна показать, следует ли сделать опцию обязательной частью протокола или оставить её опцией. Если опция не реализована по мере продвижения документа, её необходимо удалить из протокола до того, как он достигнет статуса draft standard.
Поэтому опции должны присутствовать в протоколе только для удовлетворения реального требования. Например, опции могут поддерживать будущую расширяемость протокола, определённый рынок, например финансовую отрасль, или конкретную сетевую среду, например сеть, ограниченную малой пропускной способностью. Их не должны включать как средство «откупиться» от мнения меньшинства. Отсутствие необязательного элемента не должно иметь последствий для совместимости реализации, в которой он отсутствует.
Один из возможных подходов — документировать опции протокола в отдельной спецификации. Это сохраняет основную спецификацию протокола чистой и ясно показывает, что опции не требуются для реализации протокола. Независимо от того, представлены ли они в спецификации или в отдельном документе, текст должен обсуждать полные последствия как использования опции, так и отказа от неё, а также основания для выбора любого из этих вариантов. В рамках этого автору необходимо рассмотреть и описать, как опции используются вместе с другими протоколами. Текст также должен задавать условия по умолчанию для всех опций. Для опций проверки безопасности условием по умолчанию является включённое состояние.
Иногда в протоколе присутствуют взаимоисключающие опции. То есть реализация одной необязательной возможности исключает реализацию другой необязательной возможности. Для ясности автору необходимо указать, когда реализовывать одну или другую, каков эффект выбора одной вместо другой и с какими проблемами может столкнуться разработчик реализации или пользователь.
Выбор одной или другой опции не должен иметь последствий для совместимости между несколькими реализациями.
2.11 Обозначение уровней требований
BCP 14/RFC 2119, «Key words for use in RFCs to Indicate Requirement Level», определяет несколько слов, необходимых для написания документа пути стандартизации. Редакторы документов пути стандартизации не должны отклоняться от приведённых в нём определений, поскольку они предназначены для указания требований совместимости или ограничения потенциально вредного поведения. Написание этих слов прописными буквами является принятой нормой и может помочь выявить непреднамеренное или необоснованное требование. Эти слова использовались в нескольких RFC; первыми примерами были STD 3/RFC 1122/RFC 1123.
2.12 Соглашения о нотации
Нотации формального синтаксиса могут использоваться для определения сложных понятий протокола или типов данных, а также для задания значений этих типов данных. Это позволяет записать протокол, не заботясь о том, как построена реализация или как тип данных представлен при передаче. Спецификация упрощается, поскольку её можно представить в виде «аксиом», которые будут доказаны реализацией.
На формальную спецификацию используемого синтаксиса следует ссылаться в тексте стандарта. Любые расширения, подмножества, изменения или исключения из этого формального синтаксиса следует определять в самом стандарте.
STD 11/RFC 822 даёт пример этого. В RFC 822 (раздел 2 и Appendix D) метаязык Backus-Naur Form (BNF) был расширен, чтобы сделать его представление компактнее и проще для понимания. Другой пример — STD 16/RFC 1155 (раздел 3.2), в котором определено подмножество Abstract Syntax Notation One (ASN.1).
Автору протокола пути стандартизации необходимо рассмотреть несколько вопросов, прежде чем использовать нотацию формального синтаксиса. Может ли существующая машина разобрать используемый язык формальной спецификации? Если синтаксического анализатора не существует, достаточно ли информации предоставлено в спецификации для создания такого анализатора? Если нет, то, вероятно, читателю не хватит информации, чтобы решить, что означает эта нотация. Кроме того, автору следует помнить, что синтаксис, разбираемый машиной, часто нечитаем для людей и может чрезмерно увеличить объём спецификации. Поэтому синтаксические нотации не могут заменить ясно написанное описание протокола.
2.13 Соображения IANA
Широкое использование сообществом Интернета протоколов пути стандартизации требует назначения уникальных значений полям параметров. Рабочая группа IETF не имеет полномочий назначать эти значения для разработанного ею протокола. Internet Assigned Numbers Authority (IANA) является центральным органом, назначающим уникальные значения параметров для интернет-протоколов. Авторам разрабатываемого протокола необходимо согласовать с IANA правила и процедуры управления пространством номеров. Эта координация должна быть завершена до подачи Internet Draft на путь стандартизации.
Готовится документ, обсуждающий вопросы, связанные с политикой назначения идентификаторов, и рекомендации по конкретному тексту для поручения IANA его администрирования. Авторам стандартов следует получить его копию, когда он будет окончательно оформлен как RFC.
Для дополнительной информации о назначении параметров и текущих назначениях авторы могут ссылаться на STD 2, RFC 1700, «Assigned Numbers» (http://www.iana.org).
2.14 Соображения управления сетью
Когда это уместно, каждому стандарту необходимо обсуждать, как управлять специфицируемым протоколом. Этому процессу управления следует быть совместимым с текущим стандартным протоколом управления IETF. Кроме того, MIB должна быть определена в стандарте или сопроводительном документе. MIB должна быть совместима с текущей Structure of Management Information (SMI) и разбираться с помощью такого инструмента, как SMICng. Там, где управление или MIB не требуется, этому разделу стандарта следует объяснять, почему это не относится к протоколу.
2.15 Соображения масштабируемости
Стандарту следует установить ограничения масштаба использования, например десятки миллионов сеансов, гигабиты в секунду и т. д., а также ограничения используемых ресурсов, например времени кругового прохождения, вычислительных ресурсов и т. д. Это важно, поскольку устанавливает способность сети обслуживать число пользователей и сложность их взаимоотношений. STD 53/RFC 1939 содержит пример такого раздела. Если это неприменимо к протоколу, следует включить объяснение причин.
2.16 Стабильность сети
Стандарту следует обсуждать взаимосвязь между топологией сети и поведением сходимости. В рамках этого следует идентифицировать любую топологию, которая могла бы быть проблемной для протокола. Кроме того, спецификации следует рассмотреть любые возможные дестабилизирующие события и средства, с помощью которых протокол противостоит им или восстанавливается после них. Цель состоит в обеспечении того, чтобы сеть своевременно стабилизировалась после изменения и чтобы сочетание ошибок или событий не ввергло сеть в хаос. В качестве примера STD 34/RFC 1058 содержит разделы, в которых рассматривается, как этот протокол обрабатывает последствия изменения топологии.
Очевидный случай, к которому это применимо, — протокол маршрутизации. Однако динамическое поведение, влияющее на сеть, может быть и у прикладного протокола. Например, протокол обмена сообщениями может внезапно выгрузить в сеть большое число сообщений. Поэтому редакторам прикладного протокола потребуется рассмотреть возможные воздействия на стабильность сети и поведение сходимости.
2.17 Интернационализация
Когда-то Интернет имел географические границы и был только англоязычным. Сейчас Интернет распространяется на международном уровне. Поэтому данные обмениваются на различных языках и в различных наборах символов. Чтобы соответствовать требованиям международного Интернета, стандарт ДОЛЖЕН (MUST) соответствовать политикам, изложенным в BCP 18/RFC 2277, "IETF Policy on Character Sets and Languages".
2.18 Глоссарий
Каждый RFC на пути стандартизации следует снабжать глоссарием, поскольку слова могут иметь много значений. Определяя любые вводимые новые слова, автор может избежать путаницы или введения в заблуждение реализаторов. Определение следует приводить при первом появлении слова в тексте спецификации протокола, а также в отдельном разделе глоссария.
Вероятно, определение протокола будет опираться на множество слов, часто используемых в документах IETF. Все авторы ДОЛЖНЫ (MUST) знать общепринятые определения этих часто употребляемых слов. FYI 18/RFC 1983, "Internet Users' Glossary", содержит определения, относящиеся к Интернету. Авторам настоятельно не рекомендуется отклоняться от этих определений. Если обстоятельства требуют отклонения, автору следует указать, что он изменяет общепринятое определение, и обосновать необходимость этого. Изменённое определение ДОЛЖНО (MUST) быть включено в раздел «Глоссарий».
Если автор использует слово в его общепринятом значении, ей не требуется включать определение в глоссарий. Как минимум FYI 18/RFC 1983 следует указывать как источник.
3 Специальные рекомендации
Ниже приведены рекомендации по представлению конкретной технической информации в стандартах.
3.1 Диаграммы пакетов
Большинство протоколов канального, сетевого и транспортного уровней содержат описания пакетов. Диаграммы пакетов, включённые в стандарт, весьма полезны читателю. Предпочтительная форма диаграмм пакетов — последовательность длинных слов в сетевом порядке байтов, где каждое слово располагается на странице горизонтально, а нумерация битов приведена сверху:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В случаях, когда пакет в значительной степени выровнен по байтам, а не по словам (например, при использовании полей переменной длины с границами по байтам), отображайте диаграммы пакетов в формате шириной в байт. Автор может использовать блоки разной высоты для коротких и длинных слов, а также разорванные блоки для полей переменной длины:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
3.2 Сводные таблицы
Спецификации некоторых протоколов особенно объёмны и иногда занимают сто или более страниц. В таких случаях включение сводной таблицы может уменьшить риск несоответствия реализации из-за недосмотра. Сводная таблица перечисляет, какие характеристики протокола являются обязательными, необязательными или запрещёнными. Сводные таблицы не гарантируют соответствия, но помогают реализатору проверить, что он учёл все характеристики протокола.
Сводная таблица будет состоять как минимум из четырёх (4) столбцов: характеристика протокола, ссылка на раздел, статус и ссылки/сноски. Автор может добавить столбцы, если они дополнительно объясняют или уточняют протокол.
В столбце «Характеристика протокола» перечислите характеристики протокола, например командное слово. Мы рекомендуем группировать серии связанных транзакций под описательными заголовками, например RECEPTION.
Ссылка на раздел направляет реализатора к разделу, абзацу или странице, где характеристика протокола подробно описана.
Статус указывает, является ли характеристика обязательной, необязательной или запрещённой. Автор может использовать либо отдельный столбец для каждого варианта, либо один столбец с соответствующими кодами. Чтобы избежать путаницы, эти коды необходимо определить в начале сводной таблицы. Возможные коды статуса:
M - must or mandatory
MN - must not
O - optional
S - should
SN - should not
X - prohibited
В столбце «Ссылки/сноски» авторы могут указывать другие RFC, которые необходимо учитывать при реализации данной характеристики протокола, или любые сноски, необходимые для дальнейшего пояснения реализации.
STD 3/RFC 1122/RFC 1123 содержит примеры сводных таблиц.
3.3 Описания конечных автоматов
Удобный способ представления поведения протокола — модель конечного автомата. То есть протокол может быть описан последовательностью состояний, возникающих вследствие команды, операции или транзакции. Модели конечных автоматов определяют переменные и константы, устанавливающие состояние, события, вызывающие переходы состояний, и действия, являющиеся результатом этих переходов. Благодаря этим моделям возможно понимание динамической работы протокола как последовательности переходов состояний, происходящих для любого заданного события. Переходы состояний можно детализировать диаграммами, таблицами или временными шкалами.
Обратите внимание, что модели конечных автоматов никогда не должны заменять подробное текстовое описание спецификации. Они дополняют текст. В случае конфликта спецификация протокола должна всегда иметь преимущественную силу.
При использовании диаграммы переходов состояний показывайте каждое возможное состояние протокола в виде блока, соединённого дугами переходов состояний. Автору следует помечать каждую дугу событием, вызывающим переход, и в скобках — любыми действиями, выполняемыми при переходе. STD 5/RFC 1112 содержит пример такой диаграммы. Поскольку ASCII-текст является предпочтительным форматом хранения RFC, возможны только простые диаграммы. Таблицы могут обобщать более сложные или более обширные переходы состояний.
В таблице переходов состояний разные события перечисляются вертикально, а разные состояния — горизонтально. Форма «действие/новое состояние» представляет переходы состояний и действия. Запятые разделяют несколько действий, а последующие строки используются по мере необходимости. Если это существенно, авторам следует представлять несколько действий в порядке, в котором они должны быть выполнены. Буквы после состояния обозначают поясняющую сноску. Дефис ('-') обозначает недопустимый переход. STD 51/RFC 1661 содержит пример такой таблицы переходов состояний. Начальные столбцы и строки этой таблицы приведены ниже в качестве примера:
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
STD 18/RFC 904 также представляет переходы состояний в табличном формате. Однако он перечисляет переходы в форме n/a, где n — следующее состояние, а a представляет действие. Предпочтителен метод из RFC 1661, поскольку новое состояние логически следует за действием. Кроме того, Appendix C RFC 904 моделирует переходы как декартово произведение двух конечных автоматов. Это более сложное представление, которое может быть трудно понять читателям, не знакомым с таким форматом. Мы рекомендуем авторам представлять таблицы так, как определено в предыдущем абзаце.
Последний способ представления изменений состояний — временная шкала. Две стороны временной шкалы представляют машины, участвующие в обмене. Автор перечисляет состояния, в которые входят машины по мере продвижения времени (вниз), с внешней стороны временной шкалы. Внутри временной шкалы показывайте действия, вызывающие переходы состояний. Пример:
client server
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
4 Контрольный список документа
Ниже приведён контрольный список, основанный на приведённых выше рекомендациях, который можно применить к документу:
o Идентифицирует ли он риски безопасности? Предусмотрены ли меры противодействия для каждой потенциальной атаки? Детально ли описано влияние мер безопасности на эксплуатационную среду?
o Объясняет ли он назначение протокола или процедуры? Рассмотрены ли предполагаемые функции и услуги? Описано ли, как он соотносится с существующими протоколами?
o Учитывает ли он вопросы масштабирования и стабильности?
o Были ли процедуры назначения номеров скоординированы с IANA?
o Рассматривает ли он управление определяемым протоколом? Определена ли MIB?
o Определена ли целевая аудитория?
o Ссылается ли он на алгоритмы, используемые в протоколе, или объясняет их?
o Приводит ли он диаграммы пакетов в рекомендуемой форме, если это применимо?
o Имеется ли журнал изменений?
o Описывает ли он отличия от предыдущих версий, если это применимо?
o Отделяет ли он пояснительные части документа от требований?
o Приводит ли он примеры работы протокола?
o Указывает ли он поведение при некорректной работе других реализаций?
o Разграничивает ли он, какие пакеты следует принимать для обработки, а какие следует игнорировать?
o Если приведено несколько описаний требования, определяет ли он одно из них как обязательное?
o Сколько необязательных возможностей он определяет? Разделяет ли он их на классы вариантов?
o Были ли все комбинации вариантов или классов вариантов проверены на несовместимость?
o Объясняет ли он обоснование и применение вариантов?
o Были ли все обязательные и необязательные требования идентифицированы и задокументированы принятыми ключевыми словами, определяющими уровни требований Интернета?
o Соответствует ли он действующим политикам IETF по интернационализации?
o Используются ли рекомендуемые значения распространённых терминов Интернета?
o Если нет, приведены ли новые или изменённые определения терминов в глоссарии?
5 Соображения безопасности
Этот документ не определяет протокол или процедуру, которые могли бы быть подвержены атаке. Он устанавливает рекомендации относительно информации, которую следует включать в RFC, представляемые на путь стандартизации. В области безопасности авторы стандартов IETF призваны чётко определять угрозы, с которыми сталкивается протокол, и то, предоставляет или не предоставляет протокол пользователю гарантии безопасности.
6 Ссылки
[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791
September 1981.
[RFC 904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1984.
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, June 1988.
[RFC 1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R., "Requirements for Internet hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. (http://www.iana.org)
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
August 1996.
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Language", RFC 2277, January 1998.
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
7 Благодарности
Peter Desnoyers и Art Mellor начали работу над этим документом.
Другие участники, внесшие вклад:
Bernard Aboba
Harald T. Alvestrand
Fred Baker
Scott Bradner
Brian Carpenter
Robert Elz
Dirk Fieldhouse
Dale Francisco
Gary Malkin
Neal McBurnett
Thomas Narten
Craig Partridge
Vern Paxson
Mike O'Dell
Henning Schulzrinne
Kurt Starsinic
James Watt
8 Адрес редактора
Gregor D. Scott
Director, Defense Information Systems Agency
ATTN: JIEO-JEBBC
Ft. Monmouth, NJ 07703-5613
USA
Phone: (732) 427-6856
Fax: (732) 532-0853
EMail: scottg@ftm.disa.mil
10 Полное заявление об авторском праве
Copyright (C) The Internet Society (1998). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему, иным
образом объясняющие его или содействующие его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться полностью
или частично без каких-либо ограничений, при условии, что приведённое выше
уведомление об авторском праве и этот абзац включаются во все такие копии
и производные работы. Однако сам этот документ не может быть изменён
каким-либо образом, например путём удаления уведомления об авторском праве
или ссылок на The Internet Society либо другие организации Интернета, кроме
случаев, когда это необходимо для разработки стандартов Интернета, при
которой должны соблюдаться процедуры в отношении авторских прав, определённые
процессом Internet Standards, или когда это требуется для его перевода на
языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут
отозваны The Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ» («AS IS»), И THE INTERNET SOCIETY И THE INTERNET ENGINEERING
TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ
ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.