[NETCONF-904] Data sent via yang-patch is validated in a different way than PUT / POST Created: 07/Oct/22  Updated: 24/Nov/22  Resolved: 24/Nov/22

Status: Resolved
Project: netconf
Component/s: restconf-nb
Affects Version/s: None
Fix Version/s: 2.0.11

Type: Bug Priority: Medium
Reporter: Lena Peuker Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Data that is sent via yang-patch is validated in a different way than sending it via simple PUT/POST request:

{    
     "ietf-restconf:yang-patch": {        
         "patch-id": "patch-1",        
         "edit": [            
             {                
               "edit-id": "edit1",                
               "operation": "replace",                
               "target": "/",                
               "value": {                    
                   <config>   
               }            
              }        
          ]    
      }
}  

Opendaylight returns following error when data is sent via yang-patch:

{
    "errors": {
        "error": [
            {
                "error-type": "protocol",
                "error-tag": "malformed-message",
                "error-message": "Error parsing json input: Expected BEGIN_OBJECT but was NUMBER at line 22 column 63 path $.ietf-restconf:yang-patch.edit[0].value.<...>",
                "error-info": "Expected BEGIN_OBJECT but was NUMBER at line 22 column 63 path $.ietf-restconf:yang-patch.edit[0].value.data[0].<...>"
            }
        ]
    }
} 

For yang-patch all NUMBERS / BOOLEAN-values needs to be converted in order that it is acceppted from Opendaylight.

"Simple" PUT / POST request accepts different types of values (number / boolean).



 Comments   
Comment by Ivan Hrasko [ 12/Oct/22 ]

lenapeuk

Expected BEGIN_OBJECT but was NUMBER at line 22 column 63

But the input is too short, it does not contain line 22.

Can you please provide us with example of successful PUT/POST and unsuccessful PATCH with the same values/data?

Comment by Arne Chrestin [ 21/Nov/22 ]

Example using the o-ran-delay-management module of the O-RAN simulator:

PUT
/rests/data/network-topology:network-topology/topology=topology-netconf/node=nts-ng-sim/yang-ext:mount/o-ran-delay-management:delay-management

{
    "o-ran-delay-management:delay-management": {
        "adaptive-delay-configuration": {
            "bandwidth-scs-delay-state": [
                {
                    "bandwidth": 3000,
                    "subcarrier-spacing": 20,
                    "o-du-delay-profile": {
                        "tx-max": 100,
                        "ta4-max": 100,
                        "t1a-max-up": 100,
                        "rx-max": 100,
                        "t1a-max-cp-dl": 100
                    }
                }
            ]
        }
    }
}

Corresponding PATCH
/restconf/config/network-topology:network-topology/topology/topology-netconf/node/nts-ng-sim/yang-ext:mount/
 

{
    "ietf-restconf:yang-patch": {
        "patch-id": "patch-1",
        "edit": [
            {
                "edit-id": "edit1",
                "operation": "merge",
                "target": "/o-ran-delay-management:delay-management/o-ran-delay-management:adaptive-delay-configuration",
                "value": {
                    "adaptive-delay-configuration": {
                        "bandwidth-scs-delay-state": [
                            {
                                "bandwidth": 3000,
                                "subcarrier-spacing": 20,
                                "o-du-delay-profile": {
                                    "tx-max": 100,
                                    "ta4-max": 100,
                                    "t1a-max-up": 100,
                                    "rx-max": 100,
                                    "t1a-max-cp-dl": 200
                                }
                            }
                        ]
                    }
                }
            }
        ]
    }
}

error message:

{
    "errors": {
        "error": [
            {
                "error-type": "protocol",
                "error-tag": "malformed-message",
                "error-message": "Error parsing json input: Expected BEGIN_OBJECT but was NUMBER at line 13 column 50 path $.ietf-restconf:yang-patch.edit[0].value.adaptive-delay-configuration.bandwidth-scs-delay-state[0].bandwidth",
                "error-info": "Expected BEGIN_OBJECT but was NUMBER at line 13 column 50 path $.ietf-restconf:yang-patch.edit[0].value.adaptive-delay-configuration.bandwidth-scs-delay-state[0].bandwidth"
            }
        ]
    }
}

If all numerical values are submitted as strings (e.g. "bandwidth: "3000"), the PATCH request is executed.

Comment by Ivan Hrasko [ 22/Nov/22 ]

Thanks!

Comment by Ivan Hrasko [ 23/Nov/22 ]

achrestin You are using tow different versions of RESTCONF.

With rests/data you are using RFC8040 version what is better for you

With restconf/config you are using bierman-02 version - which is deprecated and in recent ODL version removed.

Please use /rests/data/network-topology:network-topology/topology=topology-netconf/node=nts-ng-sim/yang-ext:mount as URI in your PATCH request and everything will be ok.

Comment by Arne Chrestin [ 23/Nov/22 ]

Thanks for the clarification!

Just a small addition:

It seems that for the bierman-02 version, the Content-Type header field must be set to "application/yang.patch+json", while it must be "application/yang-patch+json" for the RFC8040 version.

Comment by Robert Varga [ 23/Nov/22 ]

Yes, RFC8040 follows RFC8072, bierman02 follows draft-ietf-netconf-patch-XX, where XX is a number I do not remember.

The evolution of media types is evident in the draft changelog .

Comment by Ivan Hrasko [ 24/Nov/22 ]

Please use the same version of RESTCONF when you expect the same results.

Comment by Ivan Hrasko [ 24/Nov/22 ]

It looks there is no bug.

Generated at Wed Feb 07 20:16:12 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.