[Taps] YANG model for TAPS (was: Re: Transport Services (taps) WG Virtual Meeting: 2019-05-08)

["Philipp S. Tiesel" <[e-mail]>]

Hi Jake,

thanks on your work on PyTAPS and the YANG model!
I love the idea of having a implementation-agnostic way to specify endpoints and transport properties.

I have not reviewed the work on PyTAPS yet, but have some comments on the updated YANG model.
It is far better than the first version, especially with regards to the endpoint definition.

With regards to the properties, I think the modelling of transport properties still does
not work as the transport properties in the draft. The transport properties in the YANG
model model only a subset of the selection properties.

For the actual preferences, I’d rather expected something like:

container transport-properties {

  leaf reliability {
    description "Reliable Transport";
    type preference-level;
  }
  leaf per-message-reliability {
    description "Per-message Reliable Transport";
    type preference-level;
  }
  leaf preserve-order {
    description "Per-message Reliable Transport";
    type preference-level;
  }
  leaf zero-rtt-establishment {
    description "Use 0-RTT session establishment with an idempotent Message";
    type preference-level;
  }

  list iftype {
    leaf type {
        when "derived-from-or-self(../type,
            'taps:local-interface-selection')";
        type identityref {
          base "ianaift:iana-interface-type";
        }
    }
    leaf preference {
        type preference-level;
    }
    description "interface type constraint for local interface selection";
    reference "RFC 7224 Section 2";
}

But maybe we should discuss details off-line…

> On 7. May 2019, at 03:00, Holland, Jake <[e-mail]> 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)" <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps
> 
>    _______________________________________________
>    Taps mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/taps
> 
> 
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps

AVE!
   Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/