> On 31 Aug 2016, at 13:10, Balazs Lengyel <balazs.leng...@ericsson.com> wrote: > > Hello, > > The problem is not just about identities. It can be a value range. Sometimes > we have a generic module like iana-interface type that
A value range is IMO a good candidate for a deviation. > list a lot of identities, and I don't want to have one YAM file per > identity, to allow a fine control. Also sadly it is not possible to have a > deviation removing identities. IMHO would be needed. What you can do is to bundle the identity in the same module with config and state data corresponding to that identity. This is what the routing model does with address families: "ipv4-unicast" identity is defined in "ietf-ipv4-unicast-routing", and "ipv6-unicast" identity is defined in "ietf-ipv6-unicast-routing". This is IMO far better than mirroring http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml in a module. > > I would be more interested in having an extension saying static-data. This > would state that that part of config is set by the system, and can not be > modified by the user. So I could have conditions based on it, but the user > might not modify it. This is something like system-controlled interfaces, no? Lada > > regards Balazs > > > On 2016-08-31 12:38, Ladislav Lhotka wrote: >>> On 31 Aug 2016, at 11:10, Vladimir Vassilev <vladi...@transpacket.com> >>> wrote: >>> >>> If you design your models using identityref and define the identities in >>> separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you >>> can just chose not to load the particular YANG models containing the >>> identities not supported when your device starts. >> Right, and I have proposed this approach several times in the past. However, >> some people prefer that the modules defining identities mirror IANA and >> similar registries. In the case of iana-interface-types it also means that >> implementations have to deal with obsolete, obscure and experimental >> interface types that happen to be in the IANA registry but nobody will ever >> want to use. >> >> Lada >> >>> If you absolutely can not define your identities in separate YANG files >>> (better modularity is indeed the edge YANG has over other modeling >>> languages and it should be used) you can use feature with some limitations >>> e.g. instead of leaf of type enumeration you will have a choice with each >>> case containing if-feature and presence container for example. >>> >>> If you can not change the model to be modular and your implementation does >>> not support it 100% then you are not supporting the model and you are free >>> to be creative with the workaround but then YANG is not the problem. >>> >>> I also see alternative discussion value in the subject line. Lets say one >>> would like to specify in a standard way a list of values supported by a >>> device as valid /interface/interface/name values e.g. ("ge0", "ge1", .... >>> "xe0", "xe1", "me0"). This can be useful in many ways e.g. tab completion. >>> Also the supported types for each of the interface names and so on further >>> reducing the entropy. Does anyone else see value in that? >>> >>> On 08/31/2016 09:35 AM, Balazs Lengyel wrote: >>>> Hello Jan, >>>> >>>> This may be the best solution we have, but nacm rules may be changed, and >>>> then device limits might be edited by the operator, and then we have a >>>> problem. >>>> >>>> The good solution would be to indicate that this is read-only static data, >>>> and allow must, leafref towards it. However I don't see a way to do this >>>> in YANG at the moment short of an ericsson-extension. >>>> >>>> regards Balazs >>>> >>>> >>>> On 2016-08-30 15:14, Jan Lindblad wrote: >>>>> Balazs, >>>>> >>>>>> We have the following design pattern. >>>>>> >>>>>> 1) An enumeration or a set of identities are defined that define a set >>>>>> of options generally supported by Ericsson products. (e.g. supported >>>>>> compression algorithms) >>>>>> 2) The specific node sets in run-time a leaf-list indicating the set of >>>>>> values that this specific node supports (e.g. >>>>>> nodes-supported-compression-types: zip, gzip, bz) >>>>>> 3) For some function the user has to select a specific option value >>>>>> (e.g. leaf file-compression for transferring backup files) >>>>>> >>>>>> Problem: how do you restrict values for (3) - file-compression so that >>>>>> it is one of the nodes-supported-compression-types. The natural solution >>>>>> would be to use a must expression or a leaf-ref, but as >>>>>> nodes-supported-compression-types is config-false data, it is not >>>>>> allowed to constrain the config=true leaf, file-compression, with it. >>>>>> >>>>>> It would be perfectly reasonable because the >>>>>> nodes-supported-compression-types only change during upgrade, but YANG >>>>>> does not allow this. >>>>>> >>>>>> I would still like to have some modeled solution, not just plain English >>>>>> stating the constraint. Any idea how to do it? >>>>> I have seen this use case many times. I usually solve this by making a >>>>> container with device specific limits, lists of supported values, etc, >>>>> which is config true but with nacm rules preventing everyone from making >>>>> changes. Then I have a device specific database initialization file with >>>>> the correct settings for this device, which is loaded into the database >>>>> at first boot. >>>>> >>>>> /jan >>>>> >>> Vladimir >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
