On Sep 30, 2014:2:16 PM, at 2: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? > 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? That isn't what I was getting at - the key-value pair representation was asked about. It is a pain representing this as a list. --Tom > > > > --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 > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
