mdns: expose more Avahi configuration settings

[troglobit]

Model proposal

Currently only possible to enable/disable the mDNS responder. Here are a few proposed updates to mDNS configuration support:

  container mdns {
    description "Advertise system and services over mDNS-SD, IPv4 and IPv6.";

    leaf enabled {
      description "Globally enable or disable mDNS/SD on all interfaces.";
      type boolean;
    }

    leaf domain {
      description "LAN domain name to register host name and services in.

                   Most common is .local, but some also use .lan, or .office,
                   usually this setting can be left as-is.";
      default "local";
      type inet:domain-name;
    }

    leaf-list allow-interfaces {
      description "Interfaces to act on, can be combined with deny-interfaces.

                   By defaullt all, except loopback and point-to-pint links.";
      type if:interface-ref;
    }

    leaf-list deny-interfaces {
      description "Interfaces to ignore.

                   Other not specified interfaces will be used, except loopback
                   and point-to-point, unless combined with allow-interfaces.

                   This option takes precedence over allow-interfaces.";
      type if:interface-ref;
    }

    leaf reflector {
      description "Reflect incoming mDNS requests to local interfaces.";
      type boolean;
    }

    leaf-list reflect-filter {
      description "Filter mDNS service names to reflect.

                   Example, for AirPlay and AirTunes, use:

                     - _airplay._tcp.local
                     - _raop._tcp.local

                   For AirPrint use:

                     - _printer._tcp.local
                     - _ipp._tcp.local
                     - _pdl-datastream._tcp.local

                   By defaullt all services are reflected.";
      type string;
    }
  }

Tree view

$ yanglint -f tree ietf-inet-types@2013-07-15.yang infix-services.yang 
module: ietf-inet-types

module: infix-services
  +--rw mdns
  |  +--rw enabled?            boolean
  |  +--rw domain?             inet:domain-name
  |  +--rw allow-interfaces*   if:interface-ref
  |  +--rw deny-interfaces*    if:interface-ref
  |  +--rw reflector?          boolean
  |  +--rw reflect-filter*     string
  +--rw web
     +--rw enabled?     boolean
     +--rw console
     |  +--rw enabled?   boolean
     +--rw netbrowse
     |  +--rw enabled?   boolean
     +--rw restconf
        +--rw enabled?   boolean

[troglobit]

Stretch goal for v24.11.1

[troglobit]

Discuss

Plural vs singular form of allow-interfaces, deny-interfaces, reflect-filters, vs s: allow-interface, deny-interface, reflect-filter. I've used different styles in the proposal above to see if anyone picks up on it.

Consider the following CLI input:

admin@example:/config/mdns/> set allow-interfaces e1
admin@example:/config/mdns/> set allow-interfaces e2
admin@example:/config/mdns/> set allow-interfaces e3

vs the more concise:

admin@example:/config/mdns/> set allow-interface e1
admin@example:/config/mdns/> set allow-interface e2
admin@example:/config/mdns/> set allow-interface e3

[jovatn]

I spot "defaullt" in 'leaf domain' and 'leaf-list reflect-filter'.
@troglobit, is there a default for 'leaf reflector'? true or false?

[jovatn]

I have no strong opinion on the plural or singular question. Do we have some similar setting to compare with? Perhaps "set client-if eth0" for DHCP client?

[troglobit]

I spot "defaullt" in 'leaf domain' and 'leaf-list reflect-filter', is there a default for 'leaf reflector'? true or false?

The default is false, similar to the enabled leaf. But I get what you're going for, in the case of our products maybe true would be a better default?

[troglobit]

I have no strong opinion on the plural or singular question. Do we have some similar setting to compare with? Perhaps "set client-if eth0" for DHCP client?

True, also a homegrown model, although loosely based on the IETF DHCPv6 model(s). Maybe the DHCP option list is also worth mentioning here as an example.

Let's bring it up with the rest of the team today!

[troglobit]

After taking inventory of other (IETF) models, as well as looking at the YANG 1.1 RFC, it seems singular is the way to go. However, we'll side step the issue tough and go for a container interface { allow, deny } and a presence container for the reflector.