On Thu, Aug 20, 2015 at 7:58 AM, Nadeau Thomas <[email protected]> wrote:
> > > On Aug 20, 2015:10:30 AM, at 10:30 AM, Ladislav Lhotka <[email protected]> > wrote: > > > > > >> On 20 Aug 2015, at 16:00, Nadeau Thomas <[email protected]> > wrote: > ..... > >>> > >>>> o management protocols such as NETCONF or RESTCONF, > >> > >> This is trickier. We are now in agreement that Yang as a language, > is not bound to NETCONF and also RestConf, but it seems the statement above > doesn’t buy into that because its coupling the three things together. > > > > Well, there is still quite a lot of text in 6020bis that has to do with > NETCONF, and some of the existing or proposed extensions clearly affect the > protocol(s). > > > > Lada > > Yes, I know. We should think seriously about re-aligning that. > This is 2 separate issues. There is NETCONF-specific text (e.g. all the insert attributes and how they work in <edit-config>). Then there is the use of extensions as standard keywords. IMO... If (and only if) the extension can be constrained to extra behavior beyond YANG syntax and semantics, can it be used in an RFC. E.g NACM defines access-control extensions. The routing module could define tags that caused a router to treat a route entry a certain way. But if the keyword is related to datastores, protocol operations, message encoding, and cannot be constrained to 1 YANG module, then a regular keyword should be used instead. It doesn't save anything to spread keywords around in YANG modules. It makes understanding what is in YANG much more difficult. Since the "ephemeral" keyword applies to datastores and could apply to any YANG module, it clearly is not OK as an extension. > > —Tom > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
