> On 30 Jul 2015, at 13:41, Jernej Tuljak <jern...@mg-soft.si> wrote: > > Ladislav Lhotka je 30.7.2015 ob 13:35 napisal: >>> On 30 Jul 2015, at 13:31, Jernej Tuljak <jern...@mg-soft.si> wrote: >>> >>> Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >>>>> On 30 Jul 2015, at 01:12, Andy Bierman <a...@yumaworks.com> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <m...@tail-f.com> >>>>> wrote: >>>>> Andy Bierman <a...@yumaworks.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I understand the intent is that an implementation of NACM >>>>>> has to understand these NACM extensions. I agree with Lada >>>>>> that the YANG text about MAY ignore extensions casts doubt whether >>>>>> this sort of NACM rule is enforceable or specified correctly. >>>>> So do you agree that it would be a good idea to clarify this >>>>> according to Juergen's suggestion? >>>>> >>>>> >>>>> >>>>> Not really. >>>>> Pretending the extension is just another description-stmt >>>>> does not really fix anything. >>>> In fact, generic tools like pyang ignore what’s written in descriptions. >>> Where does RFC6020 say that description-stmt may be used for defining >>> additional semantics? The only instance where I can find >> Nowhere. That’s why I also proposed to add the following sentence to the >> section about “description” statement: >> >> Constraints and rules stated in the text of a “description” statement are an >> integral and binding part of the data model. > > Wait, what? This would make a client broken if it chokes after receiving a > message, where a container data node instance has a text value set and the > container's description in the module claims: "This container MUST be treated > as a leaf under X Y conditions”.
Or this: description “This leaf is only valid on Friday”; My understanding is that it is only the server that’s supposed to validate data (BTW, I don’t like this assumption), and the server software has to be coded so that constraints expressed in descriptions are checked, too. Lada > > It is in this WG interest for YANG modules to be interpreted without human > presence, right? Automation? If it isn't, it would be best to drop YANG and > write human readable specifications instead. Models that cannot be consumed > by machines are pointless, IMHO. > > Jernej > >> >> Lada >> >>> "description" and "semantics" or "meaning" in the same sentence, is in the >>> section that describes module updates. This is what a YANG description is: >>> >>> The "description" statement takes as an argument a string that >>> contains a human-readable textual description of this definition. >>> The text is provided in a language (or languages) chosen by the >>> module developer; for the sake of interoperability, it is RECOMMENDED >>> to choose a language that is widely understood among the community of >>> network administrators who will use the module. >>> >>> A textual description for humans. A docstring. I don't see semantics being >>> mentioned anywhere, so where is all this coming from? >>> >>> Jernej >>> >>>> Lada >>>> >>>>> A real YANG statement like config-stmt or a new statement >>>>> called ephemeral-stmt can be modified with refine-stmt >>>>> or deviate-stmt. This can never happen for >>>>> an external statement. >>>>> >>>>> >>>>> IMO ephemeral data support needs to be a real statement >>>>> that can be used with refine-stmt and deviate-stmt. >>>>> It is a real property of a data node. >>>>> >>>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund <m...@tail-f.com> >>>>>> wrote: >>>>>> >>>>>>> Andy Bierman <a...@yumaworks.com> wrote: >>>>>>>> The real difference is that extensions can be ignored by all >>>>>>>> YANG tools and real statements cannot be ignored. >>>>>>> Are you saying that a server that advertises both ietf-system and nacm >>>>>>> is free to ignore the nacm statements in ietf-system, and for example >>>>>>> by default provide read-access to >>>>>>> /system/radius/server/udp/shared-secret? >>>>>>> >>>>>>> >>>>>>> /martin >>>>>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
