hey, cool update! regarding your question, should this be a github issue against taps-interface? i’d say yes!
cheers michael Sent from my iPhone > On 7 May 2019, at 03:00, Holland, Jake <[email protected]> wrote: > > Hi taps, > > I haven't updated the docs yet, but if you're interested I can give a > brief report on a basic proof-of-concept for yang and (almost) multicast > SSM running against my fork of python-asyncio-taps. If anyone has some > time to review, I'd love to get feedback. > > I adjusted the yang model to match the existing implementation, and avoided > making any deep changes to the flow inside python-asyncio-taps. > > I haven't yet submitted the updated model to draft-jholland-taps-api-yang, > but you can review the proposed model and a couple of functioning examples > here: > https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/PyTAPS/modules/ietf-taps-api.yang > https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/test-client2.json > https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/test-server2.json > > These replicate the functionality of testServer.py and testClient.py, when > run with: > python yangServer.py -f ./test-server2.json > python yangClient.py -f ./test-client2.json > > It's not beautiful, it uses a C library to interface with libyang for > model validation, because pyang was too painful. > > > The multicast is slightly sketchier, but it issues an IGMP membership report > when running: > python yangServer.py -f ./test-mcastrx.json > https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/test-mcastrx.json > > It was a little awkward and surprising in that some values had to be added > in order to override the implicit defaults. > > > Side note: > > There's a disconnect about the "multiple endpoint identifiers" clause > in the "Specifying Endpoints" section of taps-interface which I think the > current implementation doesn't follow. I didn't try to fix it, but it looks > hard to support without tightening up what the semantics here are, exactly: > > "Multiple endpoint identifiers can be specified for each Local Endpoint and > Remote Endpoint. For example, a Local Endpoint could be configured with two > interface names, or a Remote Endpoint could be specified via both IPv4 and > IPv6 addresses. These multiple identifiers refer to the same transport > endpoint." > > Should this be opened as an issue against taps-interface? > > Cheers, > Jake > > On 2019-05-06, 06:56, "Brian Trammell (IETF)" <[email protected]> wrote: > > I'd suggest we do a scrub of issues in github.com/ietf-tapswg/issues > tagged discuss for the arch and API drafts, as well, and try to make sure all > issues are assigned by the end of the call. This is certainly agenda item 3 > though. > > Cheers, > > Brian > >> On 6 May 2019, at 15:53, Aaron Falk <[email protected]> wrote: >> >> Reminder that we are having an interim meeting this Weds. >> >> • Do we have any additional topics to add to the agenda? >> • For existing topics below, who should lead the discussion? >> --aaron >> >> On 10 Apr 2019, at 8:10, IESG Secretary wrote: >> >> The Transport Services (taps) Working Group will hold >> a virtual interim meeting on 2019-05-08 from 11:00 to 13:00 America/New_York. >> >> Agenda: >> Topics: >> * Framing >> * Implementation draft - >> https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ >> >> Information about remote participation: >> https://ietf.webex.com/join/taps | 316 448 940 >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
