Re: [netmod] RPC input parameter definition order (uses augment)

[Jernej Tuljak <[e-mail]>]

On 04/04/2022 17:16, Andy Bierman wrote:
>
>
> On Mon, Apr 4, 2022 at 4:48 AM Jernej Tuljak 
> <[e-mail]> wrote:
>
>     On 01/04/2022 15:49, Andy Bierman wrote:
>>
>>
>>     On Fri, Apr 1, 2022 at 4:24 AM Kent Watsen <[e-mail]> wrote:
>>
>>
>>         Hi Jernej,
>>
>>         > RFC7950, 7.14.4. says:
>>         >
>>         >    Input parameters are encoded as child XML elements to
>>         the rpc node's
>>         >    XML element, in the same order as they are defined
>>         within the "input"
>>         >    statement.
>>         >
>>         > For the following model:
>>         >
>>         > module b {
>>         >   namespace "b:uri";
>>         >   prefix b;
>>         >
>>         >   grouping params {
>>         >     container params {
>>         >       leaf x {
>>         >         type string;
>>         >       }
>>         >     }
>>         >   }
>>         >
>>         >   rpc foo {
>>         >     input {
>>         >       uses params {
>>         >         augment params {
>>         >           leaf y {
>>         >             type string;
>>         >           }
>>         >         }
>>         >       }
>>         >     }
>>         >   }
>>         > }
>>         >
>>         > If both "leaf" data nodes are instantiated (XML encoding)
>>         as part of <rpc> for "foo", does <x> come before or after <y>
>>         (in document order)?
>>
>>         Augmented-in nodes come after other nodes.
>>
>>
>>
>>     Maybe this is an implementation convention, but the RFC says they
>>     are encoded in any order.
>>     https://datatracker.ietf.org/doc/html/rfc7950#section-7.17.2
>>
>
>     You are referring to this:
>
>        When a node is augmented, the augmenting child nodes are encoded as
>        subelements to the augmented node, in any order.
>
>     This implies interleaving of augmenting and non-augmenting child
>     nodes within "input" parameters for XML encoding?
>
>
> There is no data node order defined except in 4 places:
>   - rpc or action input (just the child nodes or all descendants?)
>   - rpc or action output  (just the child nodes or all descendants?)
>   - ordered by user applies to list and leaf-list entries
>     (not the nodes within a list, just the list entries themselves)
>   - list key leafs are encoded in key-stmt order, before other list 
> child nodes.
>     This is true even if the list is affected by previous 3 rules (but 
> this is not specified)

Additionally, there are interleaving rules for list and leaf-list entries.

    The XML elements representing
    list entries MAY be interleaved with elements for siblings of the
    list, unless the list defines RPC or action input or output
    parameters.

    The XML elements
    representing leaf-list entries MAY be interleaved with elements for
    siblings of the leaf-list, unless the leaf-list defines RPC or action
    input or output parameters.

Until augmentation comes along?

>
> It is not clear if the phrase "in any order" (appearing about a dozen 
> times)
> is in addition to these rules or instead of them.

I'm not convinced of your interpretation of "in any order" in text you 
were originally referring to (and I later quoted). No matter how many 
times I read that, the "in any order" there only becomes relevant if 
there is more than one augmenting child present - to me, the intention 
behind that text was to handle multiple augments targeting the same 
node, not to introduce interleaving with non-augmenting children.

There should be text present in that section clarifying what that 
sentence means in contexts where order matters.

>
> What about an 'anyxml' or  'anydata' for a <config> node?
> Since it is a terminal node, it could be interpreted that it is ordered,
> but it is converted to regular nodes when applied to a datastore.

The way I see it, only the node representing the <config> node is an 
input/output parameter. The content is an opaque blob of data. No 
different to a leaf of type binary, which contains bytes of an XML document.

With such ambiguity in the RFC it would not be surprising if 
implementations chose to ignore these rules entirely and just accepted 
RPC payloads with arbitrary order of their content, even for the cases 
where things are somewhat clear. Or hope that all other implementations 
follow the same implementation convention.

Jernej

>
>
> Andy
>
>
>
>     Jernej
>
>>
>>         I’ve always wished there were a way to specify where they’re
>>         placed, for readability, but it’s too inconsequential to
>>         raise as an issue here.
>>
>>
>>     There is no canonical order defined for any schema nodes.
>>     There is no order at all defined for top-level or augmenting
>>     schema nodes.
>>
>>
>>
>>         > Jernej
>>
>>         Kent
>>
>>
>>     Andy
>>
>>         _______________________________________________
>>         netmod mailing list
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/netmod
>>
>