YANG: как моделировать данные конфигурации вложенных списков без ключа

Question

Я пытаюсь построить модель YANG для этого файла конфигурации, который имеет списки без ключей. Однако из-за необходимости ввода ключа в список YANG я не смог построить точную модель YANG. Есть ли идея, как представить список списка без ключа в YANG.

Файл включает в себя acls, в котором может быть много acl, таких как acl1, acl2, названных пользователями, и имеет правила, как в примере ниже.

acls:
  acl1:
  - rule:
      nw_src: 192.168.1.1/24  
      actions:
        allow: 1
  - rule:
      actions:
        allow: 0
  acl2:
  - rule:
      nw_src: 192.168.1.1/24  
      actions:
        allow: 0
  - rule:
      actions:
        allow: 1

Моя модель ян

list acls{
     description "list of acls ";
      key "acl-name";
      ordered-by user;
      leaf acl-name {
        type string {
          length "1..64";
        }
      }
 list acle {
      description "This is a list of users in the system.";
      key "acle-name";
      ordered-by user;
      leaf acle-name {
        type string {
          length "1..64";
        }
        description
          "The name of access-list. A device MAY restrict the length
           and value of this name, possibly space and special
           characters are not allowed.";
      }

      container actions {
        description "actions for this acl entry ";    
        leaf allow {
          type uint8;
         }              
      } // end actions container       
   container match{
        description "match fields for this acl entry ";
    leaf nw_src{
         type inet:ipv4-address;
         }
    }
 }//match cont
 }//acle
} //acls

И, следовательно, соответствующий действительный файл данных имеет дополнительные поля, которые необходимы для YANG, но не существуют в моем исходном файле конфигурации выше, например (aclname, acle, aclename).

acls:
  acl1:
    aclname: acl1
    acle:
      rule11:
        aclename: rule11
        nw_src: 192.168.1.1/24
        actions:
          allow: 1
      rule12:
        aclename: rule12
        actions:
          allow: 0
  acl2:
    aclname: acl2
    acle:
      rule21:
        nw_src: 192.168.1.1/24    
        aclename: rule21
        actions:
          allow: 0
      rule22:
        aclename: rule22
        actions:
          allow: 1

Answer 1

RFC7950, 7.8.2. "Ключ" Заявление списка

Оператор "key", который ДОЛЖЕН присутствовать, если список представляет конфигурацию, и МОЖЕТ присутствовать в противном случае, принимает в качестве аргумента строку, которая задает разделенный пробелами список одного или нескольких листовых идентификаторов этого списка. Идентификатор листа НЕ ДОЛЖЕН появляться в ключе более одного раза. Каждый такой листовой идентификатор ДОЛЖЕН ссылаться на дочерний лист списка. Листья могут быть определены непосредственно в подстановках к списку или в группировках, используемых в списке.

Объединенные значения всех листьев, указанных в ключе, используются для однозначной идентификации записи в списке. Все ключевые листы ДОЛЖНЫ иметь значения при создании записи в списке. Таким образом, любые значения по умолчанию в ключевых листах или их типах игнорируются. Любые "обязательные" операторы в ключевых листах игнорируются.

Перечисляет, что данные конфигурации модели (вложенные или нет) должны иметь ключ. Обойти это невозможно, потому что каждый экземпляр списка конфигурации должен быть уникально идентифицируемым, чтобы instance-identifiers работать как положено. Вам было бы трудно сказать устройству изменить (или даже просто получить) конкретную запись в вашей конфигурации, если бы не было ключей. Поэтому то, что вы предлагаете сделать, недостижимо - это не ЯНГ.

Только данные состояния (config false;) списки могут существовать без ключей, поскольку их не нужно изменять стандартным способом - их создание / модификация / удаление зависит от деталей реализации устройства.

Кроме того, вы уже используете ключи в своем примере. "Acl1" и "acl2" явно являются экземплярами списка "acl", ключ которого закодирован в их имени.