Hi,
On Tue, Sep 30, 2014 at 1:55 PM, Thomas D. Nadeau <[email protected]> wrote: > > I was discussing this very same issue here at the ODL Yangathon > yesterday. Others are stumbling onto this same issue. > > Do you mean you want control over the YANG to JSON mapping? IMO, YANG needs to be independent of the protocol message encoding. The implementation burden on servers is already too high. There should only be 1 mapping for each encoding format. How would you change YANG to get this JSON encoding? --Tom > > > Andy > Hi all, > > A few of us are doing an exercise of defining a YANG module to express the > ALTO protocol (RFC7285). Multiple problems come up and here is one problem > we encounter. > > First, the context. A design decision of the ALTO protocol is to use > key-value stores (maps), which are different from lists or containers. Many > large-scale systems are designed based on key-value stores, and many > programming frameworks provide hash maps. > > A particular example of using key-value map is the network-map, which is > defined as a key-value store to enforce that each named endpoint address > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > "network-map" : { > "PID1" : { > "ipv4" : [ > "192.0.2.0/24", > "198.51.100.0/25" > ] > }, > "PID2" : { > "ipv4" : [ > "198.51.100.128/25" > ] > }, > "PID3" : { > "ipv4" : [ > "0.0.0.0/0" > ], > "ipv6" : [ > "::/0" > ] > } > > One way to express this in YANG is the following: > ===example YANG=== > list network-map { > key "pid"; > leaf pid { > type string; > } > leaf endpoint-address-group ... { > // ... > } > } > ================== > > Following the currently defined json encoding, the output will be: > { > "network-map" : [ > { > "pid" : "PID1", > // ... > }, > { > "pid" : "PID2", > // ... > }, > { > "pid" : "PID3", > // ... > } > ] > } > > But this not what we want, because it is using an array, not a map. One > does not have to use an array to store the map. > > We see two possibilities, if to produce the output. One is in the encoding > process: define such outputs on matching a template: > > list MyList { > key x; > leaf x { > type string; > } > leaf y { > ... > } > } > > The second is that maybe this should be resolved in YANG; i.e., > introducing a new data type (beyond list, container), but something like > key-value store, say named map: > > map MyMap { > key my-key { > ... > }; > value my-value { > } > } > > Note that the second mapping involves work if the key type is not a simple > type (say string or numbers). A typical approach in some software framework > is to define a hash function on key. > > We have discussed the issue with Lada, and now take the issue to the > mailing list. If anyone else has encountered similar problems, please let > us know. We also want to get a sense of any interest in introducing the > data type in YANG. Any comments will be appreciated. > > Thanks! > > Richard > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
