On Wed, Nov 01, 2017 at 06:00:15PM +0000, Alexander Clemm wrote: > > > -----Original Message----- > ... > > > That is an interesting question. > > > > > > To describe this as a concrete example, if you have a single config > > > true YANG list for dynamic/configuration subscriptions then a > > > subscription can be created either via configuration or as an RPC > > > operation. > > > > > > I would probably classify this as "learned", and I think that we could > > > extend the definition of the "learned" origin to cover this case. > > > > I do not think any changes are needed, section 5.3.4 is pretty clear that > > the > > origin 'intended' applies to configuration provided by <intended>. If you at > > the options, there is pretty much only 'learned' applicable. > > > > It may be clear that "intended" may not be the right choice, but what is? I > think it does not hurt to be explicit about it. This way, people don't have > to guess if it should be learned, or maybe system, or possibly even unknown. > In its current definition, "learned" only talks about "protocol interactions > with other systems ... such as routing protocols, DHCP, etc." If it is > "learned" then update its definition to something like > > learned: represents configuration that has been learned via > protocol interactions with other systems, including protocols such > as link-layer negotiations, routing protocols, DHCP, etc, or as a side > effect of RPCs. >
I do think that the choice is clear enough if you read the origin value definitions. The point is that we can't cover all cases. Even if we name side effects of RPCs (which is BTW not correct since some RPCs do as a side effect modify configuration datastores), the next person is going to say we do not cover YANG actions or certain SNMP sets or. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
