[YANGTOOLS-834] Duplicated list key in RESTCONF payload does not produce ERROR Created: 14/Nov/17  Updated: 20/Feb/18

Status: Open
Project: yangtools
Component/s: codecs
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Luis Gomez Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Current yang parser does not throw any error if user enters duplicated list key in config DS. Moreover the yang parser merges the overlapping data without notifying the user/application about the original data modification.

To reproduce:

1) Install openflow feature:

feature:install odl-openflowplugin-flow-services-rest

2) Send following request with duplicated key (id) and check controller does not reject the request:

POST http://192.168.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0
{
      "flow": [
        {
          "id": "1",
          "match": {
            "ethernet-match": {
              "ethernet-type": {
                "type": 2048
              }
            },
            "ipv4-destination": "10.0.10.0/24"
          },
          "priority": 2,
          "table_id": 0
        },
        {
          "id": "1",
          "match": {
            "ethernet-match": {
              "ethernet-type": {
                "type": 2048
              }
            },
            "ipv4-destination": "10.0.20.0/24"
          },
          "priority": 2,
          "table_id": 0
        }
      ]
}

3) Check parser has merged 2 list objects in one:

GET http://192.168.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0
{
    "flow-node-inventory:table": [
        {
            "id": 0,
            "flow": [
                {
                    "id": "1",
                    "match": {
                        "ethernet-match": {
                            "ethernet-type": {
                                "type": 2048
                            }
                        },
                        "ipv4-destination": "10.0.10.0/24"
                    },
                    "priority": 2,
                    "table_id": 0
                }
            ]
        }
    ]
}


 Comments   
Comment by Robert Varga [ 14/Nov/17 ]

My understanding is that the parser picked the first one and propagated that. JSON parser is supposed to be compliant with https://tools.ietf.org/html/rfc7951#section-5.4, which does not specify behavior when malformed JSON is encountered. As far as I can tell this is not a valid encoding and neither RFC7159 nor RFC7951 define a behaviour in this case.

Are you proposing we define a behavior? If so, can you please specify the expected behaviour in formal terms consistent with above specifications, please?

Comment by Luis Gomez [ 14/Nov/17 ]

I see same behavior with XML so I believe this issue is independent of JSON/XML encoding.

If I look at RFC 6020 section 7.8.2 https://tools.ietf.org/html/rfc6020#page-68 : "The combined values of all the leafs specified in the key are used to uniquely identify a list entry."

The above seems to infer a duplicated key in a list is an invalid input and therefore I think the right thing to do is to reject the request instead of accepting it and propagate a different input.

Comment by Robert Varga [ 20/Feb/18 ]

It is true the issue is not dependent on encoding, as all the specifications involved do not say anything about conflicting entries being present on input – hence we are moving in a grey area where compliance is concerned.

In this case Postel's Law applies, I think and this should be an explicit opt-in, if anything.

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