Сегодня получили письменное решение суда первой инстанции. Завтра все отсканирую (решение и протокол РСН) и выложу.
В добавлении о соображениях что писать в аппеляционной жалобе читал-читал модель OSI.
Оказывается, пинг (ICMP) - относится ко второму уровню ISO (то есть это не транспортный уровень!).
цитирую
см. Сетевая_модель_OSI
Семейство TCP/IP имеет три транспортных протокола: TCP, полностью соответствующий OSI, обеспечивающий проверку получения данных, UDP, отвечающий транспортному уровню только наличием порта, обеспечивающий обмен датаграммами между приложениями, не гарантирующий получения данных и SCTP, разработанный для устранения некоторых недостатков TCP и в который добавлены некоторые новшества. (В семействе TCP/IP есть ещё около двухсот протоколов, самым известным из которых является служебный протокол ICMP, используемый для внутренних нужд обеспечения работы; остальные также не являются транспортными протоколами.)
Следовательно, пинг - это не основополагающий протокол передачи данных (так как он не транспортный)!?
Еще аргументы:
цитирую см. ICMP
ICMP — сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных. Протокол ICMP не делает протокол IP средством надёжной доставки сообщений.
Отсюда следует то, что ICMP (далее ping) относится к IP. Читаем дальше про IP:
цитирую IP
Протокол IP (RFC 791) используется для негарантированной доставки данных (разделяемых на так называемые пакеты) от одного узла сети к другому. Это означает, что на уровне этого протокола (третий уровень сетевой модели OSI) не даётся гарантий надёжной доставки пакета до адресата. В частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (когда приходят две копии одного пакета; в реальности это бывает крайне редко), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прибыть вовсе. Гарантии безошибочной доставки пакетов дают протоколы более высокого (транспортного) уровня сетевой модели OSI — например, TCP — которые IP используют в качестве транспорта.
Так что получается? Получается, что IP (в т.ч. ICMP) не гарантированный протокол доставки? В самом RFC сказано, что IP пакеты могут не прибыть вовсе, так как протокол не гарантирует доставки. А если "закон" RFC признает, что ICMP могут не прийти к адресу назначения, то каким образом тогда можно признать потери (то есть неполученный ответы за пинг) показателем качества (ведь icmp не гарантирует доставки, см. выше)?
То есть резюмируя можно сформулировать так (по-человечески):
первый вариант:::
человек, который пингует - "А" кричит второму "Б" --- привет (то есть посылает ему пинг)... "Б" ему отвечает --- привет (то есть дает ответный пинг) - связь состоялась, нормы ок.
второй вариант:::
человек, который пингует - "А" кричит второму "Б" --- привет (то есть посылает ему пинг)... "Б" ему отвечает --- я тебя не понял, плохая связь (то есть дает пинг с ошибкой) - связь состоялась, но в ходе связи были ошибки.
третий вариант:::
человек, который пингует - "А" кричит второму "Б" --- привет (то есть посылает ему пинг)... "Б" ему не отвечает вовсе (так как просто не услышал пинга от А) - связи нет.
Получается, что показатели сети по 113 приказу меряли по третьему варианту событий. Когда принимаемый компьютер просто пинг-запросы не слышал (а это возможно по определению RFC IP - негарантированная доставка), поэтому он ответа и не давал, а первый посчитал это как потерей. Но потеря пакета это вызвана может быть вовсе не качеством сети, а тем, что просто IP протокол не гарантировал доставки. Как пишет RFC "хотите гарантированной доставки? пользуйтесь TCP!"...
Так что, теперь получается, что нас наказали за плохое качество, которое было проверенно НЕкачественным (то есть не гарантирующим доставки, а следовательно и качества связи) протоколом ICMP?
И последний аргумент в пользу обжалования решения суда и РСН.
Как известно, пинг не является транспортным протоколом, то есть в принципе для телематических служб не является протоколом передачи данных (а является исключительно диагностическим средством). Также известно, что существует ОГРОМНАЯ опасность сетевой угрозы, которая называется FLOOD-PING: цитирую: Ping-флуд
ping-флуд — тип атаки на сетевое оборудование, ставящий своей целью отказ в обслуживании. Ключевой особенностью (по сравнению с остальными видами флуд-атак) является возможность осуществления атаки «бытовыми средствами» (программами и утилитами, входящими в состав домашних/офисных версий операционных систем).
Ограничения ICMP флуда
Некоторые провайдеры в договоре оговаривают отдельным пунктом ограничение на скорость ICMP-пакетов, оставляя за собой право прекращения предоставления услуги в случае ICMP флуда, нарушающего работу сетевого оборудования.
Согласно статье 272 Уголовного кодекса России, данная атака может рассматриваться как уголовно-наказуемое преступление.
Противодейcтвие атаке
Для противодействия атаке (помимо блокирования трафика с отдельных узлов и сетей) возможны следующие меры:
отключение ответов на ICMP-запросы (отключение соответствующих служб или предотвращение отклика на определенный тип сообщения) на целевой системе;
Понижение приоритета обработки ICMP-сообщений (при этом весь остальной трафик обрабатывается в обычном порядке, а ICMP-запросы обрабатываются по остаточному принципу, в случае перегрузки ICMP-сообщениями часть из них игнорируется).
Это же было нами написано в опровержении протокола, но ни на суд ни на РСН это не подействовало. То есть, если я (как оператор) не буду ограничивать icmp, то я ставлю под угрозу "жизнь" сети и угрозу безопасности абонентов! Тем более, если icmp - это не транспортный уровень, а следовательно ограничение или запрет пинга не влечет ограничение пользования телематическими услугами.
Получается, что существует УК РФ 272-274 (272. Неправомерный доступ к охраняемой законом компьютерной информации, то есть информации на машинном носителе, в электронно-вычислительной машине (ЭВМ), системе ЭВМ или их сети; 274. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом, имеющим доступ к ЭВМ, системе ЭВМ или их сети), но мы не имеем право (так как этот аргумент суд первой инстанции не воспринял) защищаться от уголовно наказуемых посягательств!? Абсурд...?
---------------------------------------------
И Самые последние доводы...
Переходя к судебной практике, следует отметить Постановление ФАС СЗО[17], который подтверждая недействительность предписания Россвязьнадзора, указал на отсутствие правовых оснований для заключения с оператором ТУС договоров присоединения, установив, что «у оператора телематических услуг отсутствуют средства связи и линии связи как обязательный элемент понятия средства связи. Отсутствие своих средств связи исключает возможность реализации права присоединения сетей связи, предусмотренного ст. 18 Закона о связи.
Иначе говорю, получается, что "у оператора телематических услуг отсутствуют средства связи и линии связи как обязательный элемент понятия средства связи, а следовательно применить Приказ 113 от 27.09.2007 г. невозможно"?