Hi taps, Thanks for the feedback to all who commented, and since it seems maybe there's a chance it'll be useful, I updated the yang draft: https://tools.ietf.org/html/draft-jholland-taps-api-yang-01
I think this is a much cleaner structure for the model, or at least much more normal relative to other yang models. And I think it's somewhat closer to a complete rendition of the PreConnection config from taps-interface, though there's a few oddities I noticed along the way (listed below). Here's the repo I'm building from: https://github.com/GrumpyOldTroll/ietf-taps-yang I tweaked the Makefile setup and the i-d-template for yang-editing sanity, so it's pointing to my fork of Martin's lib repo, and it's anyone's guess whether the build will work properly on your system, all I know yet is it works on mine (and it needs cmake to build libyang). So let me know if you want to try it and have any trouble. Or better yet, send a fix :) Here's the oddities I mentioned: 1. Interface name is passed to LocalEndpoint as an example in Section 5.1, but also Interface Instance is a transport property in Section 5.2.8. I think(?) this is redundant, so I only did the Interface Instance Transport property. 2. I still wasn't sure how best to interpret the objects passed to LocalSpecifier and RemoteSpecifier in the examples. I thought the cleanest for the model was to generalize their AddXXX functions as Transport Properties, and plan to raise an error if there's a problem satisfying the constraints. I liked it this way better than a separate local-endpoint and remote-endpoint object, with separate lists of addresses and ports, but I wouldn't be surprised if there's another better way. Discussion and pull requests welcome. 3. I added protocol types as transport properties, even though it wasn't in the interface spec, basically because I saw it in the NEAT project property json config, and because it seems probably necessary to me. Sorry if that's opposite of consensus or something, I missed the interim, so I might be a little out of date. It can of course be removed or changed as necessary, but I think it makes for relatively clean configuration input where you need it. I'd be interested to see comments on the examples, and alternate suggestions. 4. I don't have any Provisioning Domain types. I'm not sure if there's a good source to crib from somewhere that lists reasonable types? 5. Likewise I wasn't sure what to do with the Session Cache Policy, is there a list of good choices on those somewhere? Anyway, I think this model is in much better shape than the last one, so now I'll change my position, and if it happens that we reach a consensus for yes on "use a yang model", then I'll also suggest "use this yang model" as a reasonable option for a starting point. See you in Prague. Cheers, Jake _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
