Dialup по ТМС

Связной (C), РД 129-2000. Так, едем дальше значит. :vertag:

ТМ службы могут взаимодействовать и на 7 уровне OSI (раз уж мы его коснулись) - прикладном и обеспечивать интерфейсы соответственно электронной передачи сообщений, службы справочника и т.п.
Ну ладно, не об этом речь.

Взглянем на пункты 5.4.2.1. и 5.4.2.2. РД 129 (в последнем указано что доп. услугой !!! является маршрутизация запроса (3 уровень OSI). Т.е. услуга заключается в формировании ответа на запрос пользователя и передача его в адреса, указанные им.

То есть, по смыслу данного документа, пользователь взаимодействует с сервером своего провайдера, а не с серверам ТМ других операторов. Такой уж кривой документ. Пользователь получает любой ресурс в форме запроса, а сервер провайдера формирует ответ на запрос. И все. Ждем новый РД. ;-)

А еще есть прокси сервера... ;)
Тогда все поднимается с 3го уровня до прикладного... И полностью соотвествует текущим правилам... ;)
Так ?

Iiazik, Вот-вот, прокси - это мощЬ:)
Где бы только найти проксю в AS5300

Я еще раз призываю Вас руководствоваться ДЕЙСТВУЮЩИМИ документами. Рассуждать можно долго и я согласен со всеми (я точно также думаю), НО по ДЕЙСТВУЮЩИМ документам ситуация иная. Какая модель OSI? Как ее к делу "пришить"? Где о ней говорится?

РД 45.134.2000
Средства технические телематических служб
Общие технические требования
Настоящие общие технические требования распространяются на технические средства следующих телематических служб:
службы обмена электронными сообщениями в части службы электронной почты (по протоколам SMTP, POP3, IMAP4);
службы доступа к информационным ресурсам (по протоколам HTTP, NNTP, FTP).
А эти протоколы какому уровню относятся. Правильно прикладному.

Вот-вот, прокси - это мощЬ

Кстати! А чем вообще проки регламентрованно?

Пользователь получает любой ресурс в форме запроса, а сервер провайдера формирует ответ на запрос.

читаем
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ ДОСТУПА К ИНФОРМАЦИОННЫМ РЕСУРСАМ ПО ПРОТОКОЛУ HTTP
3.4. Ответы
3.4.1. Структура ответов сервера должна соответствовать п. 5.5.
5.5. Ответ

После получения и обработки сообщения запроса сервер отвечает сообщением ответа:

Response ::= Status-Line
*( general-header
| response-header
| entity-header )
CRLF
[ message-body ]

5.5.1. Status-Line (Строка статуса)

Строка статуса содержит версию протокола и дополнительную текстовую фразу. Строка статуса не может разрываться символами CR или LF.
Status-Line ::= HTTP-Version SP Status-Code SP Reason-Phrase CRLF

5.5.1.1. Status-Code (код статуса)

Status-Code ::= "100" ; Продолжить
| "101" ; Коммутируемые протоколы
| "200" ; OK
| "201" ; Создан
| "202" ; Принят
| "203" ; Ненадежная информация
| "204" ; Нет содержимого
| "205" ; Переустановить содержимое
| "206" ; Частичное содержимое
| "300" ; Много выборов
| "301" ; Перемещен на постоянный срок
| "302" ; Временно перемещен
| "303" ; См. другие
| "304" ; Не изменен
| "305" ; Используй прокси
| "400" ; Плохой запрос
| "401" ; Неавторизован
| "402" ; Требуется оплата
| "403" ; Запрещено
| "404" ; Не найдено
| "405" ; Метод не разрешен
| "406" ; Неприменим
| "407" ; Требуется идентификация на прокси
| "408" ; Тайм-аут запроса
| "409" ; Конфликт
| "410" ; Ушел
| "411" ; Требуется длина
| "412" ; Ошибка предварительной обработки
| "413" ; Сущность запроса слишком велика
| "414" ; URI запроса слишком велико
| "415" ; Тип информации не поддерживается
| "500" ; Внутренняя ошибка сервера
| "501" ; Не реализовано
| "502" ; Плохой шлюз
| "503" ; Служба недоступна
| "504" ; Тайм-аут шлюза
| "505" ; Версия HTTP не поддерживается
| extension-code

extension-code ::= 3DIGIT
Reason-Phrase ::= *<TEXT, включая CR, LF>
Так какой сервер формирует эти ответы? Собственного провайдера или того на чей сервер вы направили запрос.
Рассмотрим стандартную схему, модемный пул далее циска и далее включение в сеть вышестоящего провайдера. Абонент подключился к модемному пулу и дал запрос на подключение к какому то серверу. Кто дает ответы, указанные выше. Модемный пул или циска, НЕТ. Такие Сообщения на запросы могут только формироваться протоколами прикладного уровня. А ваш модемный пул и циска только принимает и маршрутизирует пакеты. Т.Е. с помощью этого оборудования Вы клиенту оказываете только услугу ПД. Или Вы сможете убедить, что Ваш модемный пул формирует эти сообщения-ответы.
А Вы, как владелец такого объекта связи и считающий, что предоставляет услуги ТМС (СДкИР) сможете гарантировать скорость реакции чужого сервера на запрос клиента или бесперебойность работы 24 часа чужого сервера.

кто куда маршрутизирует - если это компьютер с воткнутой в неко мультимодемной платой (в PCI слот... есть такие - INPRO производит) и на этом же компьютере прокси сервер (для HTTP - SQUID/ для аськи SOCKS/ для почты - mailrelay)?

На уровне маршутизации пакетов клиент НИКУДА кроме этого сервара ТМС не попадает. Так где тут маршрутизация ? ;)

Iiazik

Опять пытаетесь сослаться на прокси. Как я понял аргументы по поводу что есть доступ к чужим инф. ресурсам без прокси отпадает. А на вопрос

А Вы, как владелец такого объекта связи и считающий, что предоставляет услуги ТМС (СДкИР) сможете гарантировать скорость реакции чужого сервера на запрос клиента или бесперебойность работы 24 часа чужого сервера.

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

На этот вопрос - единственный вариант который проглядывается - брать деньги за трафик. На диалапе это нонсенс конечно... Но тут хоть оправдание есть - не было услуги - не взяты деньги...

Нерубящий инспектор - принципиально я с вами согласен... А вот в деталях - оплачивать за "проект" и экспертизу проекта этого узла по полной - считаю неприемлемым и противоречащим здравому смыслу. Потому обходные пути и ищутся и используются. :(

Нерубящий инспектор - принципиально я с вами согласен... А вот в деталях - оплачивать за "проект" и экспертизу проекта этого узла по полной - считаю неприемлемым и противоречащим здравому смыслу. Потому обходные пути и ищутся и используются. :(

То, что необходимо делать проект с экспертизой при замене восьми портового коммутатора на 16-ти портовый, при увеличении количества абонентов, т.к. изменились зарегестрированные показатели, я тоже считаю дебилизмом.
Но это другой вопрос, Я надеюсь это учтут при разработке новых правил ввода.
Я же пытаюсь объяснить, что услуга провайдера по доступу клиентов к инф. ресурсам расположенным не на собственном сервере прова-это услуга ПД. При этом по барабану способ доступа.
И мне кажется, когда инспектора говорят, что для оказания данной услуги достаточно лицензии на ТМС, они просто не понимают, а не заботятся о своих лицензиатах.

На этот вопрос - единственный вариант который проглядывается - брать деньги за трафик.

А когда услуга СДкИР считается реализована.
Вот как раз при услуге ПД это прокатит

Нерубящий инспектор, :super1:

Как я понял аргументы по поводу что есть доступ к чужим инф. ресурсам без прокси отпадает.

Тут спора нет и соглашусь. Вопрос в том, что в большинстве своем используются прокси, а более того сервера кэшируют информацию, а вот здесь уж телематика в полном объеме. Вопрос ведь в том, чтобы "облегчить жизнь" оператору. Ну зачем ему городить 2 лицензии, если у него 1 узел на 8 линий? Кто его заставит получать лицензию на ПД? Возможно местный ТУ ФСНСС, а нам это надо ? ;-)

Мне лично нет. И отговорку тоже можно придумать, стоит прокси, все кэшируется ...бла-бла-бла...

сервера кэшируют информацию

Без базара, но кто предоставляет услуги, ВОТ ГДЕ СОБАКА ПОРЫЛАСЬ.

Сам спор свидетельствует о том, что относить ТМС к услугам связи методологически неверно. А из ложного утверждения, как известно, вытекает все, что угодно.

Хоть кто-нибудь в Мининформсвязи понимает, чем ТИП услуги отличается от КЛАССа услуги, что такое "класс эквивалентности", бинарные отношения и всякие прочие логические понятия, без знания которых невозможно построить непротиворечивую типологию и классификацию услуг связи?

Здесь только что на примерах, эмпирически, показали эквивалентность ТМС и ПД. Это вообще неверно, следовательно неверно определен тип (признак эквивалентности).

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

Это уже не телематика - это СОРМ :spez:

Вопрос ведь в том, чтобы "облегчить жизнь" оператору.

Если Вы о 113, то он напрочь забыл своего прадеда 146-го. ПД до 128 к.

Раз в данной версии лицензируемых видов деятельности не объединили - значит что-то за пазухой...

Здесь только что на примерах, эмпирически, показали эквивалентность ТМС и ПД. Это вообще неверно, следовательно неверно определен тип (признак эквивалентности).

Вот действительно так и получается. Задачей РД должно было стать четкое определение понятий, и определение тех признаков, по которым можно было бы четко разграничить эти услуги, а не методом исключения. Ну почему операторам, госслужащим и остальным людям должно быть сложно понять что к чему, лезть в дебри, документы сопутствующие читать типа рекомендаций IETF? Ведь все должно быть в РД. Можно же было вообще просто ограничиться перечислением услуг ТМ. И не включать туда спорные и сложные в разграничении услуги.

Вот сейчас кому на ум пришло включать в лицензионные виды деятельности услуги связи по передаче голосовой информации в СЕТИ ПЕРЕДАЧИ ДАННЫХ? Зачем надо было включать сюда слова "В СЕТИ ПЕРЕДАЧИ ДАННЫХ"? Я лично не понимаю.

меня ещё квартальные отчеты РСН и их формы добивают :kip:

какой высший ум такое мог придумать :обморок:

меня ещё квартальные отчеты РСН и их формы добивают
какой высший ум такое мог придумать :обморок:

Прохожий, это еще мелочи. Попробуй заполнить статотчетность для оператора ПД и ТМС. Меня как то попросили помочь, вот тут то... я и понял почему нелюбят наше рукойводство. Ну нахрена кому то понадобилось узнать сколько выходов в Интернет было сделано у кокого нибудь прова (в млн. ).

Нерубящий инспектор писал(а): Меня как то попросили помочь, вот тут то... я и понял почему нелюбят наше рукойводство.

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

Одного набольшого, кстати, уже прозвали Бенефициар Д-ч.
Но глупость, увы, первична. Иногда - аж страшновато становится. Впрочем, еще Л. И. Брежнев экспериментально доказал, что страной можно и вообще не управлять. Как показывает административная реформа, без регулятора в стране только лучше становится. :!:

Dialup по ТМС

Кто сейчас на конференции