Subject: [Taps] Updated draft-jholland-taps-api-yang

From: "Holland, Jake" <[email-masked]>
Date: Sun, 10 Mar 2019 06:09:29 +0000

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

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 15 Mar 2019 08:58:05 -0700

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-masked]> wrote:
> 
> Hi taps,
> 

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.

> 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.
> 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

> if there's a good source to crib from somewhere that lists

That list will likely vary across platforms, so probably needs to be extensible.
> 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.
> also suggest "use this yang model" as a reasonable option for a

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-masked]
> https://www.ietf.org/mailman/listinfo/taps