As far as I recall, you can define origin attributes anywhere in the hierarchy to inherit them downwards towards the leaves. This does not mean that the origin attribute applies to all nodes. Hence I do not think this example has a problem, it just says the default origin for everything below <bgq/> is intended unless this is overwritten (and for non-presence containers, the origin does not apply - since they essentially come and go as needed).
/js On Mon, Jul 25, 2022 at 08:23:16PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > HI all, > > RFC 8526 section 3.1.1.4 seems to have an origin against a container > (container bgp, from C.2 in RFC 8342): > > <rpc-reply message-id="102" > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"> > <bgp xmlns=http://example.com/ns/bgp > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > or:origin="or:intended"> > <peer> > <name>2001:db8::2:3</name> > <local-port or:origin="or:system">60794</local-port> > <state>established</state> > </peer> > </bgp> > </data> > </rpc-reply> > > But that seems to contradict the statement in section 5.3.4: > The origin applies to all configuration nodes except non-presence containers. > > I assume that is an error in section 3.1.1.4 ? > > Jason (he/him) > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
