iffy50
commented
5 years ago Added mandatory to server-unicast-address.
For lists w. ID vs. leaf-lists, lists with ID allow for the editing of an individual entry, whereas leaf-lists need to be edited en masse. I think it's also right to an ID when the ordering of the values is important (e.g. list of SIP servers domain/address - this affects the order of servers that the client will attempt to connect to.)
Updated the sip-server-domain-list to be a list (w. ID).
For the comment about operator-option-ipv6-address, do you mean that this should be an option definition for a single IPv6 address (remove the list) and a second option format (operator-option-ipv6-addresses) should be defined with a list of IPv6 addresses? Same question for operator-option-textstring etc.
For all of the operator options, I have added the following leaf to define the option code: leaf option-code { descrtiption "Operator defined DHCPv6 option code allocated for this option."; type uint16; } The above does not enforce uniqueness. Is this something that we should do?
In server-unicast-option the server-address should be mandatory
Use lists with id (key) and value seems to be far more complex than a leaf-list. Is there a reason for this choice?
In sip-server-domain-name-list-option as the name suggests the domain-names are in a list
operator-option-ipv6-address should be operator-option-ipv6-addresses according the RFC7227, now IMHO it is better to add the addresses operator than to change the address into addresses. And please address this as it is a common format.
Same for operator-option-textstring (add operator-option-textstrings) and operator-option-dns-wire (operator-option-dns-list-wire). For the last one (dns list) DHCPv4 allows in some cases compression, fortunately this was dropped in DHCPv6.
For all operators I think the id is in fact the code (with uint16 type, not uint8).