> On 25 Nov 2015, at 12:02, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> wrote: >> >>> On 25 Nov 2015, at 11:16, Martin Bjorklund <[email protected]> wrote: >>> >>> Ladislav Lhotka <[email protected]> wrote: >>>> Hi, >>>> >>>> I'd like to resolve this issue. Here is a complete example (valid, I >>>> believe): >>>> >>>> module context { >>>> namespace "http://example.com/context";; >>>> prefix ctx; >>>> >>>> leaf foo { >>>> config false; >>>> type uint32; >>>> } >>>> rpc oper { >>>> output { >>>> must "/foo mod foo = 0"; >>>> leaf foo { >>>> type uint32; >>>> } >>>> } >>>> } >>>> } >>>> >>>> 1. What does the accessible tree look like? >>> >>> Note that the anser to this depends on the outcomne of Y04. Andy has >>> strong objections to Y04-02, and proposed Y04-04 instead. >> >> Yes, I know. >> >>> >>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's >>> result has foo = 10, the accessible tree would look like this: >>> >>> <root> >>> +-- oper >>> | +-- foo = 10 >>> +-- foo = 20 >>> >>> >>> (If we instead move back to Y04-04, the accessible tree would be: >>> >>> <root> >>> +-- oper >>> +-- foo = 10 >> >> IMO, neither option works. The accessible tree has to consist of existing >> instances of data nodes and <ctx:oper> doesn't exist in a RPC reply (as >> opposed to the corresponding RPC request), which is only >> >> <nc:rpc-reply> >> <ctx:foo>42</ctx:foo> >> </nc:rpc-reply> >> >> Do you see what I mean? > > Yes, but this is NETCONF-specific. We need to have a solution that > works for other protocol. IMO, the peer must conceptually build a > tree that looks like the one I showed above.
OK, but if so, it has to be described in the spec. If we don't combine the input/output trees with configuration and state data (Y04-04), then the accessible tree in my example could be simply <root> +-- foo = 10 Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
