Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2019-05-08

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 <jholland@akamai.com> 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)" <ietf@trammell.ch> 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 <aaron.falk@gmail.com> 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
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
>    _______________________________________________
>    Taps mailing list
>    Taps@ietf.org
>    https://www.ietf.org/mailman/listinfo/taps
> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps