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. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
