On Sep 30, 2014 5:16 PM, "Andy Bierman" <[email protected]> wrote: > > 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?
Yes and no. The issue is raised in the context of encoding. But it is a more general issue regarding completeness of data types in YANG: - list is an ordered array - container is a static, heterogeneous associate array - key-value store is a dynamic (size unknown at compile time), homogeneous array. It is a commonly used data type. > 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? There are at least two possibilities. Please see previous email. Make sense? Richard > > > >> --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
