NSO APIs does not expose a leaf

[Fantolino]

I created an action that exposes a set of parameters. Most of them are accessibile via RESTCONF API but some does not

If the action is invoked from CLI it is OK:

cisco@ncs> request HCW SetIpslaSrc tir TIR-0 tecnologia CiscoXe ipslaSrc { ipslaId 758 ipslaType udpJitter responder 1.2.3.4 ipSrc 14.3.2.1 pktNum 40 pktLen 300 interval 100 freq 120 tos IPP2 tag ConfiguratoDaCLI vrf LaVPNseServe udpPort 4444 }
result Completed.

If the same action is invoked via RESTCONF API the parameter "udpPort" is not accepted

[cisco@phtir ~]$ curl --location --request POST 'http://163.162.45.117:8080/api/operations/HCW/SetIpslaSrc/' \
> --header 'Content-Type: application/vnd.yang.operation+xml' \
> --header 'Media-Type: application/vnd.yang.operation' \
> --header 'Authorization: Basic Y2lzY286dHJAcHBvbGE=' \
> --data '<input>
> <tir>TIR-0</tir>
> <tecnologia>CiscoXe</tecnologia>
> <ipslaSrc xmlns="http://tim.it/SDN/tiripsla" xmlns:y="http://tail-f.com/ns/rest" xmlns:timhcw="http://tim.it/SDN/tiripsla">
> <ipslaId>759</ipslaId>
> <ipslaType>udpJitter</ipslaType>
> <responder>1.2.3.4</responder>
> <ipSrc>14.3.2.1</ipSrc>
> <pktNum>40</pktNum>
> <pktLen>300</pktLen>
> <interval>100</interval>
> <freq>120</freq>
> <tos>IPP2</tos>
> <tag>ConfiguratoDaPostman</tag>
> <vrf>LaVPNseServe</vrf>
> <udpPort>5566</udpPort>
> </ipslaSrc>
> </input>'

<errors xmlns="http://tail-f.com/ns/tailf-rest-error">
<error>
<error-tag>malformed-message</error-tag>
<error-urlpath>/api/operations/HCW/SetIpslaSrc</error-urlpath>
<error-message>udpPort cannot occur here as a child to ipslaSrc.</error-message>
</error>
</errors>

The same beahavior occurs using REST API.

If the offending parameter is omitted it works.

No useful log is produced

[snovello]

Hello,
Please share the yang definition for this action. That might give a clue as to why the port is not available.

[Fantolino]

Find below the yang model (and file attached)

// *********************** GROUPINGS ***********************************
grouping List_ipslaSrc {
list ipslaSrc {
description "Lista delle sonde IP SLA configurate sulla TIR.";
key ipslaId;

leaf ipslaId {
tailf:info "Numero Identificativo della sonda IP SLA.";
type uint32;
}

leaf ipslaType {
mandatory true;
tailf:info "Tipo di misura IP SLA.";
type enumeration {
enum icmpEcho;
enum icmpJitter;
enum udpJitter;
}
}
leaf responder {
mandatory true;
tailf:info "Indirizzo che opera come risponditore IP SLA.";
type inet:ip-address;
}
leaf udpPort {
tailf:info "Porta UDP usata per la sonda IP SLA.";
type uint16;
}
leaf ipSrc {
tailf:info "Indirizzo IP usato sorgente nei pacchetti sonda.";
type inet:ip-address;
}
leaf pktNum {
tailf:info "Numero di pacchetti inviati per ciascuna misura.";
type uint32;
}
leaf pktLen {
tailf:info "Linghezza del paccketto sonda.";
type uint16;
}
leaf interval {
tailf:info "Intervallo in ms tra due pacchetti.";
type uint32;
}
leaf freq {
tailf:info "Cadenza in secondi delle misure.";
type uint32;
}
leaf timeout {
tailf:info "Timeout in ms sul singolo pacchetto sonda.";
type uint16;
}
leaf tos {
tailf:info "Classe o marcature dei pacchetti di misura.";
type union {
type uint8;
type enumeration {
enum IPP0;
enum IPP1;
enum IPP2;
enum IPP3;
enum IPP4;
enum IPP5;
enum IPP6;
enum IPP7;
}
type enumeration {
enum BE;
enum MC;
enum VOIP;
enum NC;
}
}
}
leaf tag {
tailf:info "Tag testuale che identifica il servizio [HCW].";
type string {
length "1..120";
pattern '[a-zA-Z0-9_][a-zA-Z0-9\-_.]*';
}
}
leaf vrf {
tailf:info "Eventuale VRF in cui inserita la porbe ";
type tsc:idalfanum;
}
leaf threshold {
tailf:info "Impostare eventuale threshold.";
type uint16;
}
leaf schedule {
tailf:info "Flag che abilita l'attivazione della sonda.";
type boolean;
default true;
}
}
}

// ********************* MODELLO ACTION ********************************
tailf:action SetIpslaSrc {
tailf:info "Configura una o più sonde IP SLA";
tailf:actionpoint SetIpslaSrc-action;
input {
description "Parametri di ingresso";
leaf tir {
tailf:info "Nome o indirizzo di gestione della TIR.";
type union {
type tsc:idalfanum;
type inet:ip-address;
}
}
leaf tecnologia {
tailf:info "Costruttore di TIR.";
type enumeration {
enum CiscoXe;
}
mandatory true;
}
uses List_ipslaSrc;
}
output {
leaf result {
type string;
}
}
}

[snovello · Accepted solution]

Hello,

The standard is strict about the ordering of xml elements in the input.


Within this element,

the input parameters are encoded as child XML elements, in the same

order as they are defined within the "input" statement.

That is from rfc7950 7.15.2 and rpcs are handled similar to actions.

Inside the restconf rfc 8040 it says:

Each conceptual YANG data node is encoded according to the

XML Encoding Rules and Canonical Format for the specific

YANG data node type defined in [RFC7950<>].


So your udpPort field is out of order. You can rearrange the order to reflect what is in yang, or if you want ordering freedom use json encoding.