Hi Jake, Thanks for updating the document! It's really useful to see things written out this way. Comments inline, responding to your "oddities".
> On Mar 9, 2019, at 10:09 PM, Holland, Jake <[email protected]> wrote: > > 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. I think that the Interface being a property of the Connection, rather than the Endpoint, is the most important item to support. There is a bit of a fundamental messiness in where the interface goes, as in our Network.framework API we've encountered. Primarily, we expose the ability to require/prohibit a given interface on the generic properties, but it's also possible in IPv6 for an interface to be specified in the scope ID field. Similarly, endpoints that have been resolved on a very particular interface (such as bonjour) carry their own interface scoping, since they are not applicable to other interfaces. In the Network.framework implementation today, the required interface on the overall instance properties takes precedence, but if it is unspecified, we will look to see if there an interface specified as part of the endpoint itself. > > 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'd tend to agree with this, but I'd like to have a discussion on it. > > 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. Do you mean how you have the definitions for "tcp", "udp", etc? I think that is indeed a necessity of a practical implementation, although it in a purist model of TAPS it shouldn't be required. The levels of specificity that are possible are: - Require the protocol named "tcp" - Require one of these protocols: "tcp", "quic", "sctp" - Require some protocol that provides a reliable, in-order stream abstraction > > 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? That list will likely vary across platforms, so probably needs to be extensible. > > 5. Likewise I wasn't sure what to do with the Session Cache > Policy, is there a list of good choices on those somewhere? That's something we're still discussing and fleshing out in the documents, so stay tuned. > > > 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. Seems like the best starting point we have so far for a yang model, certainly! Best, Tommy > > See you in Prague. > > Cheers, > Jake > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
