diff --git a/0.-planirovanie/0.-planirovanie.md b/0.-planirovanie/0.-planirovanie.md
index 020e3de..74a9da3 100644
--- a/0.-planirovanie/0.-planirovanie.md
+++ b/0.-planirovanie/0.-planirovanie.md
@@ -343,10 +343,11 @@ Hostname, IP-адрес управления, маршрут в сеть упр
 <a name="XML"></a>
 <h2>Компонент 6. Вендор-интерфейс специфичный драйвер</h2>
 Не стоит тешить себя надеждами на то, что когда-то настраивать циску можно будет точно так же, как джунипер, просто отправив на них абсолютно одинаковые вызовы. Несмотря на набирающие популярность whitebox'ы и на появление поддержки NETCONF, RESTCONF, OpenConfig, конкретный контент, который этими протоколами доставляется, отличается от вендора к вендору, и это одно из их конкурентных отличий, которое они так просто не сдадут.  
-Это примерно точно так же, как OpenContrail и OpenStack, имеющие RestAPI в качестве своего NorthBound-интерфейса, ожидают совершенно разные вызовы. 
+Это примерно точно так же, как OpenContrail и OpenStack Neutron API, имеющие RestAPI в качестве своего NorthBound-интерфейса, ожидают совершенно разные вызовы.(Сетевой сервис опенстака называется Нейтрон)
+
+Итак, на пятом шаге вендоронезависимая модель должна принять ту форму, которой максимально унифицированно и удобно можно будет описать конфгирурацию устройства без привязки к конкретной модели и конкретному интерфейсу. В дальнейшем из этой универсальной формы нам нужно как-то создать конфигурацию под конкретный случай, и здесь все средства хороши (нет): CLI, NETCONF, RESTCONF, SNMP простихоспаде.
+(зацепился глаз, навскидку кажется, чтобы мы дожны будем отправить вендор-агностик конфиг прям на железку)
 
-Итак, на пятом шаге вендоронезависимая модель должна принять ту форму, в которой она поедет на железо.  
-И здесь все средства хороши (нет): CLI, NETCONF, RESTCONF, SNMP простихоспаде.
 
 Поэтому нам понадобится драйвер, который результат предыдущего шага переложит в нужный формат конкретного вендора: набор CLI команд, структуру XML.
 
@@ -356,7 +357,7 @@ Hostname, IP-адрес управления, маршрут в сеть упр
 <hr>
 
 <a name="MAKES"></a>
-<h2>Компонент 7. Механизм доставки конфигурации на устройство</h2>
+<h2>Компонент 7. Механизм и инструмент доставки конфигурации</h2>
 Конфигурацию-то мы сгенерировали, но её ещё нужно доставить на устройства - и, очевидно, не руками.  
 <b>Во-первых</b>, перед нами тут встаёт вопрос, какой транспорт будем использовать? А выбор на сегодняшний день уже не маленький:
 <ul>
diff --git a/5.-interfaces/0.-history.md b/5.-interfaces/0.-history.md
index 3415a7f..6b9f5e5 100644
--- a/5.-interfaces/0.-history.md
+++ b/5.-interfaces/0.-history.md
@@ -71,7 +71,7 @@ CLI может быть структурированным и логичным,
 
 Ещё одна особенность CLI - отсутствие контроля состояния. CLI делает то, что ему сказали. Если ты не побеспокоился о том, чтобы удалить лишнего пира специальной командой - он и не почешется. Контроль состояния - ответственность инженера.
 
-С другой стороны CLI - это на сегодняшний день (и долго ещё так будет) единственный вариант, который на 100% современных железок позволит настроить 100% предоставляемого ими функционала. 
+С другой стороны CLI - это на сегодняшний день (и долго ещё так будет) единственный вариант, который на 100% современных железок позволит настроить 100% предоставляемой ими функциональности. 
 Учитывая, что компаний, которые сейчас строят сеть с нуля и могут выбрать только то оборудование, которое поддерживает полноценный NETCONF/gNMI, очень и очень немного, всем остальным нужно уметь поддерживать зоопарк оборудования разного возраста и уровня.
 Собственно Яндекс именно тем, что CLI работает в буквальном смысле на всём, и воспользовались. <a href="https://www.youtube.com/watch?v=cMllUl73iZg" target="_blank">Аннушка настраивает сетёвку</a> именно через CLI.
 
@@ -230,7 +230,7 @@ RPC - удивительный клиент-серверный механизм,
 Вместе они создали легендарный М40 и лучший в мире интерфейс командной строки. До сих пор никто не сделал ничего лучшего - все только повторяют.
 Операционка, предоставляющая клиенту обычный текстовый интерфейс, на самом деле перекладывает команды в XML, который используется для управления оборудованием..
 
-Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта NETCONF в 2006-м году. Не без участия Juniper Networks, конечно же, появился <a href="https://www.ietf.org/rfc/rfc4741.txt" target="_blank">RFC4741</a>. Будем честны, один только джунипер там и постарался в практической части. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config.
+Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта NETCONF в 2006-м году. Не без участия Juniper Networks, конечно же, появился <a href="https://www.ietf.org/rfc/rfc4741.txt" target="_blank">RFC4741</a>. Будем честны, один только джунипер там и постарался в практической части. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config. (спорное утверждение=/, так как параллельно развитием стандарта занимались и OSS вендоры, например шведский tail-f)
 
 Вот как он был определён в сытые нулевые:
 <blockquote>
@@ -296,10 +296,9 @@ RPC - удивительный клиент-серверный механизм,
    configurations.
 </blockquote>
 
-А через 5 лет, в  2011, исправленное и дополненное издание вышло под номером <a href="https://www.ietf.org/rfc/rfc6241.txt" target="_blank">RFC6241</a>. Там уже потрудились несколько университетов и компаний. Одной из них стала восходящая звезда сетевой автоматизации Tail-f, купленная и погубленная в 2014-м году циской.
+А через 5 лет, в  2011, исправленное и дополненное издание вышло под номером <a href="https://www.ietf.org/rfc/rfc6241.txt" target="_blank">RFC6241</a>. Там уже потрудились несколько университетов и компаний. Одной из них стала восходящая звезда сетевой автоматизации Tail-f, купленная и погубленная в 2014-м году циской.(почему погубленная, как минимум на 2017 год post-tail-f существовал как отдельный BU внутри циски)
 
-И вот в операторские сети на белом коне въезжает NETCONF.
-<ul>
+CLOUD-99973.partial<ul>
     <li>Работает по SSH.</li>
     <li>Представляет данные в структурированном виде.</li>
     <li>Разделяет конфигурационные и операционные данные.</li>
@@ -346,7 +345,7 @@ SSH - это хорошо. Но на сетевую автоматизацию 
 Это помесь RESTAPI и NETCONF, которая была призвана упростить управление сетью для WEB-приложений
 В основе лежит NETCONF, однако в качестве транспорта - HTTP с набором операций CRUD, реализованных через стандартные методы (<i>GET</i>, <i>POST</i>, <i>PUT</i>, <i>PATCH</i>, <i>DELETE</i>).
 Конфигурационные данные передаются в формате JSON или XML. 
-В качестве модели данных используется только YANG - тут уже никакой самодеятельности. 
+В качестве модели данных используется только YANG - тут уже никакой самодеятельности. (диалект для модели данных напрямую не связан с типом транспора, и способом сериализации, кмк лучше убрать это предложение)
 
 С самого начала RESTCONF не затевался как замена NETCONF, а только как более удобный для WEB-приложений способ работать с сетевыми устройствами. То есть они должны сожительствовать. 
 При этом обычно на устройстве реализуется один бэкенд, обрабатывающий запросы на работу с конфигурацией и опер.данными от разных фронотов - NETCONF или RESTCONF. То есть в основе одни и те же datastores, один и тот же движок, вычисляющий конфигурационные дельты, но сложность транзакционности и нескольких разных видов конфигураций (running, candidate, saved) от пользователя скрыта.
@@ -410,7 +409,7 @@ IETF-модель
 Ещё в 2014-м году были сделаны первые коммиты в неё https://github.com/YangModels/yang/tree/main/standard/ietf/RFC !!!
 С тех пор много накоммичено, но мало фактически сделано. Общепризнанно, что IETF -модель очень медленно развивается, у неё низкое покрытие, а схема - так себе.
 С IETF-модели рекомендуют начинать, потому что она якобы проще, а уже потом переходить на OpenConfig, но как по мне - это напрасная трата времени.
-Она мертворождённая и никому особо не нужна. Хотя вендоры поддерживают.
+Она мертворождённая и никому особо не нужна. Хотя вендоры поддерживают. (ЕМНИП OpenConfig построен вокруг IETF, но могу ошибаться)
 
 Заказчиков и пользователей беспокоили ущербность модели и инертность IETF, но один в поле не воин - тысячи разрозненных автоматизаторов по всему миру не могли ничего с этим сделать. А вот большие компании могли.
 Когда надо настроить тысячу свитчей, а каждый месяц запускать новый датацентр, когда на сети 5 разных поколений дизайна, а катить изменения нужно дважды в день, начинаешь несколько иначе смотреть на все этим ваши сиэлаи и вендор-специфичные эксэмали.
@@ -520,7 +519,7 @@ gRPC
 При этом не забываем, что на проприетарные джуносы, иосы и врп никто не притащит свой бинарничек, чтобы удобный для себя интерфейс реализовать. Это значит, что white-box коммутаторы с собственной linux OS у гугла появились задолго до того как их увидел мир. 
 Что и неудивительно - с железом они работать умеют, с Linux и подавно - дело было за малым - собрать команду Network R&D, в которой будут ребята, которые занимались разработкой своих серверов и адаптацией интерфейсов и инструментов, и найти достаточно гибкого вендора. А за последним дело не встанет, когда вы закупаете килограм свичтей в секунду.
 
-Вообще для обывателей всё началось 24 сентября 2015, когда OpenConfig consortium выпустил OpenConfig в мир. Весь FANG (кроме Amazon) поучаствовал в этом консорциуме. Но начал всю заварушку и продолжает её паровозить гугл. Естественно среди них и крупные телекомы, вроде Level3, AT&T, Verizon, Bell. 
+Вообще для обывателей всё началось 24 сентября 2015, когда OpenConfig consortium выпустил OpenConfig в мир. Весь FANG (кроме Amazon) поучаствовал в этом консорциуме. Но начал всю заварушку и продолжает её паровозить гугл. Естественно среди них и крупные телекомы, вроде Level3, AT&T, Verizon, Bell. (мб FAANG, а не FANG ?)
 
 И пока OpenConfig прокладывал себе дорогу, раскидывая в сторону вендорские и IETF модели, гугл сделал следующий шаг - как раз таки реализовал gNMI.
 
@@ -565,7 +564,7 @@ gNMI в мир пришёл под руку с OpenConfig, но неразрыв
 Day-N у кого-то решается в полностью ручном режиме, иные раскатывают обновления скриптом или простым Ansible playbook'ом, кто-то даже готовит развесистые плейбуки, основанные на модулях, "поддерживающих" состояние.
 У кого-то есть крутая CLI-автоматизация, умеющая по-настоящему поддерживать состояние.
 Самые продвинутые укладывают всё в NETCONF, собрав полноценный замкнутый цикл релиза конфигурации.
-А совсем оторванные от земли заставляют производителей поддерживать новый функционал в OpenConfig. 
+А совсем оторванные от земли заставляют производителей поддерживать новую функциональность в OpenConfig. 
 
 В целом описать всё многообразие проявлений автоматизаторской фантазии сегодня просто невозможно. Мы сейчас в мире, в котором чёрный параллелепипед ещё не был признан стандартом в области форм-фактора смартфонов.
 
@@ -689,7 +688,7 @@ Gateway навешивает сервисную метку MPLS и ещё све
 
 
 Вот вам казус: 
-Янг нацелен только на нетконф зачем?
+Янг нацелен только на нетконф зачем? // Штааа ?
 
 
 
diff --git a/5.-interfaces/1.-interfaces.md b/5.-interfaces/1.-interfaces.md
index f202a08..906f661 100644
--- a/5.-interfaces/1.-interfaces.md
+++ b/5.-interfaces/1.-interfaces.md
@@ -99,7 +99,7 @@
     </li>
 </ul>
 
-
+представляю
 <img src="https://fs.linkmeup.ru/images/adsm/5/humor.png" width="800"><br>
 <i>Источник: доклад на Cisco Live!!!!</i>
 
@@ -107,7 +107,7 @@
 
 <b>CLI</b> - <i>сиэлай, кли, сли, слай, слаи, консоль, терминал, командная строка</i>. Этому механизму уже лет 60. И он никуда не делся. Он живее всех живых - где-то для отладки, где-то для эксплуатации, зачастую для конфигурации и даже для ежедневной работы. 
 На компьютерах, серверах, виртуальных машинах, коммутаторах, маршрутизаторах, фаерволах, АТС, базовых станциях. Трудно найти такое оборудование, где нет CLI, пусть даже хорошо спрятанного.
-И в этом его сила - 100% функционала на 100% сетевых устройств можно настроить через CLI. Ладно 99,9% - придётся выкинуть некоторое альтернативное оборудование. 
+И в этом его сила - 100% функциональности на 100% сетевых устройств можно настроить через CLI. Ладно 99,9% - придётся выкинуть некоторое альтернативное оборудование. 
 
 Это породило миллионы строк кода на Perl, PHP, Python, Go, Ruby, развесистые джинджа-шаблоны и по 300 экспектов в каждом файле.
 И дало работу тысячам кодеров, выросших из сетевиков и админов.
@@ -329,7 +329,7 @@ eucariot@sas-0ca0> show version | display xml rpc
     <cli>
         <banner>{master:0}</banner>
     </cli>
-</rpc-reply>
+</rpc-reply>функционала
 ```
 
 Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта. Не без участия Juniper Networks, конечно же, появился RFC4741!!! Будем честны, один только джунипер там и постарался. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config.
@@ -582,7 +582,7 @@ ssh kazan-spine-0.juniper -s netconf
 
 Но давайте разбираться с тем, что же в себе интересного таит XML. 
 У меня нет задачи подвергнуть читателя пыткам и мучительной смерти через зачитывание стандартов, поэтому сильно глубоко мы погружаться не будем, но какую-то скучную базу дать придётся.
-XML сам по себе не делает ничего - это только формат хранения информации, в отличие от HTML, который как раз таки призван отрисовать содержимое. 
+XML сам по себе не делает ничего - это только формат представления информации, в отличие от HTML, который как раз таки призван отрисовать содержимое. 
 XML описывает что за данные внутри, а его теги не определены заранее, опять же в отличие от HTML.
 То есть это два брата, похожих друг на друга внешне, но очень разных внутри.
 
@@ -3479,6 +3479,8 @@ Model Driven означает тут, что мы
     <li>Проприетарный язык, придуманный вендором и не описанный в документации</li>
  </ul>
 
+Вопрос от меня: А чем отличается Способ описания спецификации от Языки описания моделей ?
+
 <img src="https://fs.linkmeup.ru/images/adsm/5/interfaces.png" width="800">
 
 <h2>И ещё другими словами</h2>
@@ -3487,7 +3489,7 @@ Model Driven означает тут, что мы
     <li><b>YANG-модели</b> - конкретные модели, написанные на языке YANG, но ещё не сами данные,</li>
     <li><b>OpenConfig</b> - вендор-независимая YANG-модель данных конфигурации сетевого оборудования,</li>
     <li><b>Native-модели</b> - вендорские проприетарные YANG-модели данных сетевой конфигурации,</li>
-    <li><b>XML, JSON, Protobuf</b> - способы представления данных в виде структуры, </li>
+    <li><b>XML, JSON, Protobuf</b> - способы представления данных в виде структуры, </li> (синтаксис по представлию структур данных в виде, пригодном для передачи(например строка), иными словами - сериализация)
     <li><b>XML-схемы, JSON-схемы, proto-спецификации</b> - репрезентация YANG-модели в соответствующем формате, </li>
     <li><b>NETCONF</b> - протокол взаимодействия с сетевым железом, работающий поверх SSH. В качестве формата данных использует XML. Структура XML может быть основана на YANG-модели, но не обязательно, </li>
     <li><b>RESTCONF</b> - аналог NETCONF, но работающий через HTTP. Данные представляются в JSON или XML на основе какой-либо YANG-модели, </li>