Резюме

  • Совместная публикационная история Oran движется от исторического описания явных записей внутридоменной маршрутизации к информационному описанию границы экземпляра сервиса anycast и далее к информационной терминологии для состояния пересылки на основе имён.
  • Последовательный вывод остаётся ограниченным, а не героическим: непрерывность легче анализировать, когда идентичность и состояние видны, но ни одна из цитируемых записей не доказывает единоличного изобретения, повсеместного использования, конкретного действующего результата или нынешних полномочий над сетью.

Профиль, написанный через общие технические решения

Публичный технический облик Dave Oran виден без изобретения частных мотивов или превращения работы над стандартами в биографию. Запись начинается здесь сRFC 1142, опубликованного в феврале 1990 года как историческая, устаревшая перепечатка ISO DP 10589. В нём D. Oran указан как редактор записи протокола внутридоменной маршрутизации IS-IS, организованной вокруг иерархии, смежности, согласованности маршрутной информации и обмена конфигурацией. Это наблюдаемые решения о том, как система маршрутизации описывает саму себя. Они не являются доказательством того, что один редактор изобрёл протокол, а перепечатка не является действующим стандартом интернета.

Позже запись смещается от идентичности маршрутов внутри домена к идентичности сервиса, представленного из нескольких мест.RFC 7094, опубликованный в январе 2014 года как информационная запись IAB и написанный в соавторстве с Oran, описывает anycast-адрес сервиса, доступный в нескольких автономных точках. Маршрутизация выбирает экземпляр, однако смена маршрута может направить последующий трафик на другой экземпляр. Если транспортное или промежуточное состояние остаётся локальным для первого экземпляра, доступность адреса сама по себе не сохраняет непрерывность.

Третья запись снова меняет единицу пересылки.RFC 8793, опубликованный в июне 2020 года как информационная терминология исследовательской группы и написанный в соавторстве с Oran, определяет имена и базу информации о пересылке (Forwarding Information Base), таблицу ожидающих интересов (Pending Interest Table) и хранилище контента, используемые при пересылке, ориентированной на информацию. Документ делает обсуждаемыми три различные формы состояния: куда может быть переслано имя, какие запросы остаются неразрешёнными и какой контент хранится локально.

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

Февраль 1990 года: историческая запись о маршрутизации с узким статусом

Первая граница — это статус самого документа.RFC 1142 был опубликован в феврале 1990 года, указывает D. Oran как редактора и является исторической, устаревшей перепечаткой ISO DP 10589. Все четыре части этого описания важны. Дата локализует запись. Редакторская заслуга устанавливает документированную роль Oran. Метки «исторический» и «устаревший» не позволяют представлять его как действующее руководство. Статус перепечатки не позволяет раздувать редакторское участие до единоличного изобретения.

Этот аккуратный статус — не сноска к профилю; это первый пример центральной дисциплины профиля. Запись протокола имеет идентичность, происхождение и область применения так же, как и описываемая ею маршрутная информация. Называть документ просто «стандартом IS-IS» означало бы стереть различия, которые сохраняет принятая запись. Точное описание вместо этого говорит, чем он является: перепечаткой, фиксирующей историческую форму протокола и ныне устаревшей.

В рамках этого узкого статуса запись всё же полезна как доказательство. Она документирует внутридоменную схему маршрутизации, связанную с иерархической маршрутизацией, смежностью, согласованностью маршрутной информации и обменом конфигурацией. Эти механизмы раскрывают условия, от которых зависит расчёт маршрута.Историческая, устаревшая перепечатка RFC 1142 организует эти элементы в явную запись протокола, позволяя аналитику обсуждать, как были представлены идентичность и состояние, не предполагая, что документ управляет нынешней практикой.

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

Иерархия делает домен маршрутизации читаемым

Иерархия — первое содержательное правило идентичности висторической, устаревшей перепечатке RFC 1142. Запись описывает иерархическую внутридоменную маршрутизацию, а не рассматривает весь домен как одну недифференцированную совокупность информации. На уровне, поддерживаемом принятой записью, этот выбор устанавливает отдельные уровни маршрутизации и даёт расчёту маршрута явную структуру, в которой он может работать.

Важность выбора — в читаемости. Решение о маршрутизации нельзя согласованно оценить, если запись не показывает уровень или контекст, к которому относится её информация. Иерархия задаёт границу вокруг интерпретации: информация, записанная для одного уровня, не должна незаметно приобретать значение информации, записанной для другого. Поэтому описание протокола превращает область действия в часть маршрутной записи, а не оставляет её невысказанным предположением.

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

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

Этот ранний выбор также готовит аналитический мост к более поздним работам. Anycast спрашивает, какой экземпляр сервиса стоит за одним адресом после изменения маршрутизации. Пересылка на основе имён спрашивает, какое имя и какая запись о состоянии направляют следующее действие. Иерархия задаёт более раннюю версию того же дисциплинированного вопроса: в каком контексте маршрутизации эта информация имеет смысл? Механизмы различаются, но необходимость удерживать идентичность привязанной к области действия уже видна.

Смежность превращает достижимость в зафиксированное отношение

Историческая, устаревшая перепечатка RFC 1142включает состояние смежности в число явных записей протокола внутридоменной маршрутизации IS-IS. Этот выбор важен, потому что расчёт маршрута не может опираться только на абстрактные пункты назначения. Ему также нужен документированный учёт отношений, через которые интерпретируется маршрутная информация. Принятый материал поддерживает этот ограниченный тезис, не требуя утверждений о более поздних реализациях.

Смежность — это граница между простым именованием и пригодным для использования отношением маршрутизации. Система может иметь идентификаторы окружающих сущностей, но запись о смежности утверждает, что конкретное отношение признано в текущем состоянии протокола. Запись даёт расчёту маршрута нечто явное для консультации. Если отношение меняется, связанное с ним состояние можно отличить от вневременного утверждения, что две сущности всегда связаны.

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

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

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

Январь 2014 года: один адрес сервиса, несколько точек

RFC 7094, опубликованный в январе 2014 года, является информационной записью IAB, написанной в соавторстве с Oran. Его центральное решение об идентичности — то, что один anycast-адрес сервиса может обозначать сервис, доступный в нескольких автономных точках, при этом маршрутизация выбирает экземпляр. Адрес используется как идентичность сервиса, но экземпляр, получающий трафик, выбирается через маршрутизацию.

Такое устройство разделяет два вопроса, которые обычный язык адресов может смешивать. «Доступен ли адрес сервиса?» касается общей идентичности. «Какой экземпляр получает этот трафик?» касается выбора маршрута в конкретный момент. Ответ на первый вопрос не определяет навсегда ответ на второй.Информационная запись IABпоэтому устанавливает операционную границу между адресом, который остаётся неизменным, и экземпляром, который может меняться.

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

По сравнению с исторической записью IS-IS проблема идентичности сместилась вверх. Более ранняя перепечатка описывает, как маршрутная информация, смежность, иерархия и конфигурация остаются согласованными внутри домена. Запись об anycast спрашивает, что происходит, когда согласованная маршрутизация делает именно то, что ей разрешено, — выбирает другую точку, — а обмен верхнего уровня по-прежнему зависит от состояния в первой.

Поэтому anycast занимает центральное место в этом профиле. Он демонстрирует, что корректность маршрутизации и непрерывность сервиса связаны, но не тождественны. Адрес может продолжать вести куда-то корректно, в то время как состояние, необходимое для конкретного обмена, остаётся в другом месте. Соавторство Oran документирует участие в обозначении этой границы, а не единоличное изобретение anycast и не операционные полномочия над anycast-сервисом.

Смена маршрута — граница отказа anycast

RFC 7094, информационная запись IAB, написанная в соавторстве с Oran, определяет смену маршрута как момент, когда расщепление идентичности anycast становится операционно значимым. До смены трафик для общего адреса достигает одного экземпляра. После смены последующий трафик может достичь другого. Архитектура не обязательно потеряла доступность адреса, но непрерывность обмена с сохранением состояния может быть нарушена.

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

Совместным решением было сохранить выбор на основе маршрута среди автономных точек сервиса. Ограничение состояло в том, что транспорт с сохранением состояния предполагает, что необходимое состояние остаётся доступным по мере продолжения обмена. Документированным результатом стало точное предупреждение: смена маршрута может направить последующий трафик на другой экземпляр и нарушить транспорт, если состояние не следует за ним.Информационная запись IABописывает риск; она не утверждает, что каждая смена маршрута вызывает нарушение или что кто-то из упомянутых авторов предотвратил такое нарушение.

Эта граница также дисциплинирует язык лидерства. Было бы легко превратить запись в утверждение, что anycast «обеспечивает устойчивость». Принятые доказательства поддерживают лишь более условный вывод. Несколько точек могут улучшить достижимость, а смена маршрута создаёт проблему непрерывности состояния, которую необходимо сделать явной. Преимущества и ограничения должны находиться в одном предложении, потому что механизм создаёт и то и другое.

Контролируемый тезис профиля сильнее всего на этом переходе. В исторической записи IS-IS явное состояние маршрутизации поддерживает расчёт. В anycast корректная смена маршрута может обнажить несоответствие между общей идентичностью и локальным состоянием. Позже терминология ICN сделает явными несколько состояний пересылки вокруг имени. Эта последовательность — не победный нарратив; это постепенно более подробная карта того, где идентичность перестаёт быть достаточной сама по себе.

Транспорт с сохранением состояния показывает разницу между достижимостью и непрерывностью

Информационное обсуждение IAB вRFC 7094различает достижимость и непрерывность через транспорт с сохранением состояния. Anycast-адрес может оставаться доступным из нескольких автономных точек. Однако продолжающийся транспортный обмен может зависеть от состояния, хранящегося на экземпляре, который маршрутизация выбрала первым. Если последующий трафик достигает другого экземпляра, общий адрес остаётся осмысленным, а локальная история обмена — не обязательно.

Это различие — правило идентичности. Идентичность сервиса отвечает, какой распределённый сервис обозначает адрес. Идентичность экземпляра отвечает, какая точка в данный момент получает трафик. Транспортное состояние отвечает, что эта точка знает о продолжающемся обмене. Это связанные, но не взаимозаменяемые записи. Сведение их к одному адресу устраняет информацию, необходимую для объяснения, почему доступность и непрерывность могут расходиться.

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

Это также ясный пример того, как текущее состояние важнее лозунга. «Адрес доступен» — утверждение об одном слое записи. Оно не может определить, существует ли на вновь выбранном экземпляре состояние, необходимое для непрерывности. Фактический операционный отчёт должен смотреть на переход состояния, а не делать вывод об успехе только из доступности адреса.

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

Июнь 2020 года: имена становятся идентичностью пересылки

RFC 8793, опубликованный в июне 2020 года, является информационной терминологией исследовательской группы, написанной в соавторстве с Oran. Он определяет язык информационно-центричных сетей, включая имена и базу информации о пересылке (Forwarding Information Base), таблицу ожидающих интересов (Pending Interest Table) и хранилище контента. В отличие от общего адреса сервиса в записи об anycast, идентичностью пересылки здесь является имя, используемое в системе, состояние которой разделено между отдельными записями.

Терминологический документ не доказывает развёртывание и не предписывает одну универсальную архитектуру. Его ценность — в определениях. Называя записи по отдельности, он позволяет анализировать три операционных вопроса, не смешивая их: куда может быть переслано имя, какие запросы остаются неразрешёнными и какой контент доступен локально.Информационная терминология исследовательской группыподдерживает эти определения и не содержит измеренных результатов.

Совместным решением было описать информационно-центричную пересылку через имена и явное состояние FIB, PIT и хранилища контента. Ограничения включали поиск по префиксу, состояние ожидающих запросов, кэширование и решения стратегии пересылки. Документированным результатом стал словарь, основанный на наблюдаемых записях имён и состояний, а не на допущении об идентичности только по местоположению. Этот результат концептуальный и документальный; он не является доказательством того, что какая-либо конкретная система достигла лучшей производительности или непрерывности.

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

Соавторство Oran снова относится к совместной работе. Запись подтверждает участие в уточнении словаря. Она не устанавливает единоличного изобретения ICN, исключительной ответственности за определённые термины или полномочий над реализацией. Профиль остаётся о решениях, видимых в публичных документах, а не о мотивах, выведенных из них.

FIB фиксирует, куда может быть переслано имя

База информации о пересылке (Forwarding Information Base) — одна из явных записей состояния, определённых вRFC 8793, информационной терминологии исследовательской группы. В доступной здесь ограниченной поддержке FIB участвует в поиске по префиксу и решениях о пересылке для имён. Она фиксирует информацию, с которой стратегия пересылки может консультироваться при решении, куда может проследовать именованный запрос.

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

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

По сравнению с исторической записью IS-IS FIB сохраняет знакомый принцип при другой идентичности пересылки. Расчёт маршрута зависел от иерархии, смежности и согласованной маршрутной информации. Пересылка на основе имён зависит от записи, связанной с именем, и от стратегии, которая её интерпретирует. В обоих случаях решение должно быть прослеживаемо до явного состояния без смешения описания состояния с наблюдаемым результатом.

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

PIT даёт ожидающим запросам собственную границу состояния

Таблица ожидающих интересов (Pending Interest Table) отдельно определена вRFC 8793, информационной терминологии исследовательской группы, написанной в соавторстве с Oran. Её включение означает, что направление пересылки и состояние неразрешённых запросов не рассматриваются как одно целое. FIB касается того, куда может быть переслано имя; PIT фиксирует состояние ожидающих запросов. Это разделение — точная операционная граница.

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

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

Связь с anycast аналитическая, а не утверждение об эквивалентности механизмов.Информационная запись IAB RFC 7094показывает, как продолжающийся обмен с состоянием становится уязвимым, когда маршрутизация выбирает другой экземпляр сервиса. Терминология PIT показывает другой способ, которым система пересылки держит историю запросов отдельно от общего идентификатора. В обоих случаях непрерывность зависит от большего, чем продолжающееся существование адреса или имени.

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

Хранилище контента отделяет доступность от направления пересылки

Хранилище контента — третий явный компонент состояния, поддерживаемыйRFC 8793, информационной терминологией исследовательской группы. Оно представляет локально хранимый контент, отличный от информации о пересылке в FIB и состояния ожидающих запросов в PIT. Терминология, таким образом, не позволяет утверждению «система знает имя» становиться двусмысленным утверждением о трёх разных условиях.

Имя может иметь информацию о пересылке без соответствующего локально хранимого контента. Состояние ожидания может существовать, когда искомый контент отсутствует в локальном хранилище. Хранимый контент может быть доступен независимо от нового выбора пересылки. Эти утверждения — аналитические разделения, выведенные из отдельных записей; они не утверждают конкретную последовательность реализации.Информационная терминологияподдерживает три категории и их роли, а не измеренное поведение.

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

Граница хранилища контента завершает прогрессию от маршрутизации по местоположению к состоянию данных на основе имён. В исторической перепечатке IS-IS записи маршрутов описывают, как рассчитывается достижимость внутри иерархии. В описании anycast один адрес может вести к разным точкам, а непрерывность зависит от локального состояния экземпляра. В терминологии ICN имя окружено отдельными записями пересылки, ожидающих запросов и хранимого контента. Каждый этап раскрывает ещё одну причину не отождествлять идентификатор со всем операционным состоянием.

Роль Oran остаётся коллективной и документальной. RFC 8793 указывает его как соавтора. Он не говорит, что он единолично разработал хранилище контента, не показывает всеобщее использование и не сообщает о результатах. Ограниченный профиль сильнее, потому что рассматривает общий словарь как доказательство технического участия и останавливается на этом.

Хронология меняет единицу идентичности

Три записи протоколов образуют датированную прогрессию в том, что должна идентифицировать система пересылки.Февральский RFC 1142 1990 года — это историческая, устаревшая перепечатка под редакцией D. Oran; он организует внутридоменную маршрутизацию вокруг иерархии, смежности, маршрутной информации и обмена конфигурацией.Январский RFC 7094 2014 года — информационная запись IAB, написанная в соавторстве с Oran; он отделяет один адрес сервиса от экземпляра, выбранного маршрутизацией, и локального состояния, необходимого для непрерывности.Июньский RFC 8793 2020 года — информационная терминология исследовательской группы, написанная в соавторстве с Oran; он определяет имена вместе с состоянием FIB, PIT и хранилища контента.

Изменение — не простая замена одного протокола другим. Записи решают разные задачи и имеют разные статусы. Полезный синтез в том, что каждая задаёт границу вокруг идентичности. Маршрут принадлежит иерархическому внутридоменному контексту. Anycast-адрес обозначает сервис, доступный в нескольких автономных точках, но не определяет навсегда один экземпляр. Система данных на основе имён использует имя, сохраняя отдельные состояния пересылки, ожидающих запросов и хранимого контента.

Цепочки «решение — ограничение — результат» становятся всё более явными в отношении переходов состояния. В исторической записи о маршрутизации решение — поддерживать проверяемые уровни, смежности, маршрутную информацию и конфигурацию; ограничение — корректная интерпретация; результат — вычисляемая маршрутная запись. В anycast решение — выбор на основе маршрута за одним адресом; ограничение — локальное состояние экземпляра при смене маршрута; результат — улучшенная достижимость с границей непрерывности.

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

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