Рабочая группа по сетям F. Kastenholz
Запрос комментариев: 1915 FTP Software, Inc.
BCP: 3 Февраль 1996
Категория: Лучшая современная практика
Отступление для
Протокола управления соединением PPP
и
Протокола управления шифрованием PPP
Статус данного документа
Этот документ определяет лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этой записки не ограничено.
1. Отступление
1.1. Проблема
1.1.1. История
Рабочая группа PPP разработала два протокола: один для управления
сжатием на линиях PPP — Compression Control Protocol (CCP),
документированный в draft-ietf-pppext-compression-04.txt. Второй —
Encryption Control Protocol (ECP), используемый для управления
шифрованием на последовательных линиях, документированный в
draft-ietf-pppext-encryption-03.txt. В ходе разработки этих
протоколов корпорация Motorola сообщила IETF, что они могут нарушать
некоторые патенты, принадлежащие Motorola, а именно патенты США
5,245,614 и 5,130,993.
После завершения разработки протоколов они были представлены IESG
для стандартизации. На этом этапе их продвижение было остановлено
вследствие неурегулированных патентных претензий. В соответствии с
процедурами RFC 1602 Секретариат IESG попытался получить лицензии,
требуемые RFC 1602. В частности, в соответствии с разделом 5.6 RFC
1602 была предпринята попытка получить форму лицензии и сделать её
публично доступной через Интернет.
Motorola предпочла бы предоставить общее заявление, указывающее,
что лицензии будут предоставляться «любой стороне на разумных
условиях, которые доказуемо свободны от несправедливой
дискриминации».
1.1.2. Другие предпринятые решения
Была предпринята попытка поручить рабочей группе PPP разработать
пересмотренные версии CCP и ECP, которые не нарушали бы патенты.
Хотя это технически возможно, некоторые члены рабочей группы считают
предложенные технические изменения значительно менее желательными с
технической точки зрения, чем исходные CCP и ECP; более того, эти
члены ясно заявили, что будут реализовывать исходный CCP независимо
от протокола, стандартизированного рабочей группой или принятого
IESG. Следует отметить, что, хотя другие члены рабочей группы приняли
предложенные изменения, они сделали это скорее потому, что считали
их единственной жизнеспособной альтернативой, а не в силу технических
достоинств альтернативы. Короче говоря, технические изменения не
достигли традиционного для IETF критерия Rough Consensus.
1.2. Отступление от процедур RFC 1602
Отступление от процедур RFC 1602 заключается в следующем.
Раздел 5.6 RFC 1602 (релевантные части включены в Приложение B)
требует, чтобы для использования проприетарной технологии в Internet
Standard держатель технологии: 1) согласился предоставить ISOC
бесплатную лицензию на использование технологии и предоставить
другим лицензию на использование технологии на справедливых и
недискриминационных условиях; 2) сделал форму этой лицензии доступной
в электронной форме в Интернете; и 3) позволил любому лицу заключить
эту лицензию путём загрузки копии формы, выполнения её требований и
отправки подписанного экземпляра лицензиару по почте. Документам
стандартного направления не разрешается продвигаться до выполнения
этих условий.
Предлагаемое в этом запросе отступление позволило бы CCP и ECP
продвинуться в стандартное направление без выполнения указанных выше
условий. Всё, что получило бы сообщество, — заверение держателя
лицензии в том, что он будет предоставлять лицензии.
1.3. Решение
В рамках Variance Procedure (опубликованной как RFC 1871) IESG от
имени рабочей группы PPP предоставляет отступление от процедур RFC
1602, чтобы позволить IESG принять CCP и ECP в первоначально
разработанном виде. IESG принимает заявление G. David Forney из
Motorola, датированное 5 июня 1995 года (приложено как Приложение A),
о том, что Motorola будет предоставлять лицензии на использование
технологии, охватываемой патентами США 5,245,614 и 5,130,993.
1.4. Предполагаемые преимущества
Польза для сообщества от принятия этой процедуры состоит в том, что
IESG затем сможет стандартизировать CCP и ECP, а сообщество получит
стандартизированный способ управления сжатием и шифрованием данных
на линиях PPP. То, что этот протокол разрабатывался значительно
более года, показывает, что предоставляемые протоколом возможности
нужны сообществу.
1.5. Предполагаемые риски
Это отступление создаст возможность того, что лицензии не будут
предоставляться справедливым и недискриминационным образом. Держатель
лицензии, если бы он был к этому склонен, мог бы по-разному
рассматривать каждый запрос, продвигая одни, задерживая другие и так
далее. Это противоречило бы давней, достойной и успешной традиции
IETF открытости и равного доступа к технологиям.
Соображения безопасности
В этой записке вопросы безопасности не рассматриваются.
Адрес автора
Frank Kastenholz
FTP Software, Inc
2 High Street
North Andover, Mass 01845-2620 USA
EMail: kasten@ftp.com
2. Приложение A -- Последнее сообщение от Motorola
Ниже приведено сообщение электронной почты, полученное Steve Coya,
исполнительным директором IETF, в котором представлены положения и
условия Motorola.
From: Dave_Forney-LUSE27@email.mot.com
Date: 5 Jun 95 12:08:46 -0600
To: scoya@CNRI.Reston.VA.US
Cc: John_Fisher-AJF003@email.mot.com, Dj_Stockley-ADS002@email.mot.com,
Ray_Wood-ARW004@email.mot.com
Subject: RE: License agreement for CCP and ECP
Message-Id: <"Macintosh */PRMD=MOT/ADMD=MOT/C=US/"@MHS>
Уважаемый г-н Coya!
Благодарю за Ваше сообщение электронной почты от 1 июня.
Motorola уже некоторое время имеет доступное лицензионное соглашение
для этих патентов и уже предоставила его нескольким запросившим его
компаниям. Однако было бы крайне необычно приложить такое соглашение к
стандарту. Предоставления контактной информации должно быть достаточно.
Можно было бы сказать примерно следующее:
***
Motorola, Inc. сообщила IETF, что она владеет двумя патентами, которые,
по её мнению, являются существенными для стандартов CCP и ECP, — U.S.
5,245,614 и U.S. 5,130,993 — и заявила о своей готовности предоставлять
лицензии на эти патенты любой стороне на разумных условиях, которые
доказуемо свободны от несправедливой дискриминации. Стороны,
заинтересованные в получении такой лицензии, могут обратиться по адресу:
Mr. John A. Fisher
Vice President and Intellectual Property Licensing Counsel
Motorola, Inc.
1303 E. Algonquin Road
Schaumburg, Ill. 60196
***
Я полагаю, что это заявление будет удовлетворительным.
Искренне Ваш,
G. David Forney, Jr.
Vice President
3. ПРИЛОЖЕНИЕ B -- Релевантный раздел RFC 1602
5.6. Заверения
Соглашение о заверениях, изложенное ниже, обычно заключается между
владельцем прав и ISOC в момент, когда документ стандартного направления,
в отношении которого заявлены проприетарные права, достигает стадии
зрелости «Proposed Standard»:
Это соглашение заключается между ______________(далее
именуемым «Правообладатель (Rights Holder)») и Internet Society от своего имени и
от имени своих попечителей (trustees), должностных лиц, работников,
подрядчиков и агентов, Internet Architecture Board, Internet
Engineering Steering Group, Internet Engineering Task Force и
других целевых групп, комитетов и групп, координируемых Internet
Society (далее именуемых «ISOC»), а также в интересах всех
пользователей Интернета и пользователей любых других сетей,
которые реализуют и используют Internet Standards (далее вместе
с ISOC именуемых «интернет-сообщество (Internet community)»). Это соглашение вступает
в силу при его подписании от имени Правообладателя и Internet
Society.
Правообладатель заявляет, что он имеет или будет иметь права
на патентные заявки, патенты, авторские права, коммерческие
тайны и другие проприетарные права в различных странах (далее
именуемые «Права (Rights)»), которые могут блокировать или препятствовать
способности интернет-сообщества реализовывать стандарты, изложенные
в документе стандартов ISOC ____,____ и ____, и работать в
соответствии с ними (перечисленные стандарты и любые подобные или
связанные стандарты, существующие сейчас либо разработанные
позднее, далее вместе именуются «Стандарты (Standards)»). Права в их текущем
виде перечислены в прилагаемом Перечне A (Schedule A). Правообладатель далее
соглашается время от времени пересматривать Права, перечисленные
в Перечне A (Schedule A), и, в частности, непосредственно перед повышением
Стандартов до уровня зрелости Internet Standard в соответствии с
Internet Standards Process, а также незамедлительно информировать
исполнительного директора Секретариата Internet Engineering Task
Force, когда ему станет известно о любых новых Правах в Стандартах,
которые следует добавить в перечень Перечня A (Schedule A).
Правообладатель считает и подтверждает, что получит выгоды,
позволяя ISOC и интернет-сообществу реализовывать Стандарты и
работать в соответствии с ними без препятствий со стороны любых
Прав. Политика ISOC состоит в том, чтобы не предлагать, не
принимать и не продолжать поддерживать Стандарты, если Правообладатель не предоставит письменные заверения в отношении
проприетарных прав. Соответственно, принимая во внимание указанные
выше выгоды и иное надлежащее и ценное встречное предоставление,
Правообладатель предоставляет изложенные в настоящем документе
заверения.
Правообладатель предоставляет ISOC безвозмездную, бессрочную,
неисключительную, всемирную лицензию в отношении Прав для
реализации Стандартов и работы в соответствии с ними. Лицензия
распространяется без ограничений на все действия ISOC, связанные
со Стандартами, включая права воспроизводить, распространять,
предлагать, испытывать, разрабатывать, анализировать,
усовершенствовать, пересматривать, принимать, поддерживать,
отзывать, публично исполнять и демонстрировать, а также создавать
производные произведения в любой форме и на всех языках, и
разрешать это другим. Правообладатель также предоставляет ISOC
разрешение использовать имя и адрес Правообладателя в связи со
Стандартами.
Правообладатель отказывается от любого права или притязания
на любую коммерческую тайну, являющуюся частью Прав, и делает
коммерческие тайны доступными интернет-сообществу без ограничений.
Правообладатель настоящим признаёт, что ISOC не принимает на себя
обязательство сохранять конфиденциальность в отношении какого-либо
аспекта Стандартов, и гарантирует, что Стандарты не нарушают прав
третьих лиц.
Правообладатель заверяет ISOC, что Правообладатель предоставит
любому члену интернет-сообщества как выгодоприобретателю по этому
соглашению неисключительную, бессрочную, всемирную лицензию в
отношении Прав для работы в соответствии со Стандартами за
разумное лицензионное вознаграждение и на иных условиях, разумных
с учётом цели ISOC обеспечить, чтобы все члены интернет-сообщества
могли работать в соответствии со Стандартами с минимальными
расходами. Рассматриваемая в данном абзаце лицензия должна
позволять лицензиату изготавливать, поручать изготовление,
испытывать, усовершенствовать, реализовывать и использовать
методы, произведения, компьютерные программы и аппаратные
средства, необходимые или желательные для работы в соответствии
со Стандартами. Каждая лицензия должна содержать условие,
автоматически изменяющее условия лицензии так, чтобы они были не
менее благоприятными, чем условия любой другой лицензии в
отношении Прав, ранее или позднее предоставленной Правообладателем.
Форма лицензии всегда должна быть публично доступной в
Интернете и вступает в силу незамедлительно, когда член интернет-сообщества оформляет её и направляет для доставки Правообладателю
либо по почте, либо электронным способом. Первоначальная версия
лицензии должна иметь форму, приложенную как Перечень B к
соглашению (Schedule B).
Правообладатель заявляет и гарантирует, что его прав достаточно, чтобы позволить ему предоставить лицензии и дать иные заверения, изложенные в настоящем соглашении. Правообладатель далее заявляет и гарантирует, что ему не известно о каких-либо правах любой другой стороны в какой-либо стране, которые заблокировали бы или препятствовали способности ISOC и интернет-сообщества осуществлять внедрение или функционировать в соответствии со Стандартами, либо которые не позволили бы Правообладателю предоставить лицензии и иные заверения, предусмотренные настоящим соглашением.
Настоящее соглашение не должно толковаться как возлагающее на ISOC обязательство предлагать, принимать, разрабатывать или поддерживать какие-либо из Стандартов либо любой иной стандарт.