Re: [Taps] call for agenda items at TAPS IETF-104

["Aaron Falk" <[e-mail]>]

Seems to me that Michael’s 3) below is a comment on the interface 
specification so I think it could be discussed during the agenda time on 
that doc.

Seems like there is agreement that the questions of whether the wg wants 
to produce a YANG model and how to support multicast are separable and 
worth putting on the agenda for Prague.

Any disagreement?

--aaron

On 7 Mar 2019, at 3:32, Michael Welzl wrote:

> Hi,
>
> Very sorry for the silence. I can only speak for myself, but here's an 
> example of why this one person was silent:
> - When you created your issue on multicast in github, I thought of 
> answering (positively), but then thought that the repo is about to 
> move, and it would probably be better to delay things until the move 
> is finished.
> - Then, the issue was overruled by your email. I read it and found it 
> interesting, but hoped for someone else to answer because, frankly, I 
> was afraid to make a fool of myself ... because I know almost nothing 
> about YANG.
>
> But now I'll be brave  :)   I'll go ahead and ask: how exactly is this 
> YANG proposal more than just a syntax change?  What would it give us?
> (I understand that YANG can be automatically parsed / checked by some 
> tools, but... what does THAT give us?)
>
> Also, I actually see 3 separable things being proposed here:
>
> 1) the YANG model
>
> 2) multicast support  (I find your conclusion that not much needs to 
> change interesting!  Though the example you're giving (joining an SSM 
> channel) is only a part of what we'd need, as you also say...)
>
> 3) applying preferences to addresses and port numbers  (which you seem 
> to take for granted in your draft, but which I don't think is 
> supported by our current document).
> Side note: unless I'm mistaken, this wouldn't fit our structure well: 
> e.g. a port number would then be a Transport Property that has a 
> certain value, but also has a preference, but currently we say that a 
> Transport Property has "one of a set of data types", one of which is a 
> Preference. Isn't that structure too limiting? Or am I missing 
> something?
>
> I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) as 
> separate... maybe there are other use cases for 3) alone ?
> IMO, all of these things are interesting, and would be good to discuss 
> on site. However, I doubt that we can deal with them all in only 15 
> minutes  :-)
>
> Cheers,
> Michael
>
> PS: Travis is down, or something. At least the "Editor's Copy" links 
> don't currently work.
>
>
>
>> On 7 Mar 2019, at 04:55, Holland, Jake <[e-mail]> wrote:
>>
>> Hi taps,
>>
>> (Trying again, but simpler.)
>>
>> I'm looking for a consensus yes or no answer:
>>
>> Is a normative config input format an interesting and useful
>> direction?
>>
>>
>> The idea is to add functionality like this, in taps-interface:
>>
>>  newPre = PreConnection.NewFromJson('''{
>>    "remote-endpoint":{
>>      "hosts":[
>>        { "host":"example.com" }
>>      ]
>>    }
>>  }''')
>>
>> With a fully specified json input format that can provide all the
>> configurable values.
>>
>>
>> If no, I'll move on and assume I just don't understand taps goals.
>>
>> If yes, I'd like 15 minutes to discuss in Prague, and keep reading:
>>
>> I think a full definition of an input json format can be exactly
>> specified by a YANG model. (With xml for free, if you want it.)
>>
>> I tried to sketch a start at what a YANG model for this might look 
>> like:
>> https://tools.ietf.org/html/draft-jholland-taps-api-yang-00#section-3
>>
>> I'm not a YANG expert yet, and it's not much of a model.  And it's 
>> very
>> far from complete.  But it compiles, and all the examples in the 
>> draft
>> validate against that model with libyang.  If it's worthwhile, I 
>> think
>> something like this can be good (and extensible!), if done right.
>>
>> I believe something along these lines would sharpen up taps-interface
>> a lot. (After filling in all the taps-interface properties.)
>>
>>
>> The reason I'm asking is because right now, taps-interface to me
>> seems _almost_ really good, except too confusing and vague to 
>> actually
>> build an API that can replace BSD sockets.  I think with a solid 
>> config
>> format with normative and testable examples, that could be fixed.
>>
>> If consensus says "interesting", I'll want 15 minutes to discuss it, 
>> and
>> to start digging into how to make it good.  (And also to add 
>> multicast
>> support to the model and at least one implementation.)
>>
>> Thanks for your consideration.
>>
>>
>> Cheers,
>> Jake
>>
>>
>>
>> On 2019-03-04, 17:19, "Holland, Jake" <[e-mail]> wrote:
>>
>>    Hi taps folks,
>>
>>    TL;DR: I think the spec should have a YANG model and I want to use 
>> it
>>    to get multicast support in an implementation.
>>
>>
>>    I recently started digging into the taps API with the intent of 
>> adding
>>    multicast support, but it looks like it's basically already there, 
>> as
>>    far as it goes[*].
>>
>>    But I ended up with a higher-level comment, so I thought I'd raise 
>> it
>>    to the wg and ask what you all think.
>>
>>    I found the whole "abstract interface" approach a little too
>>    loosey-goosey, so I thought I'd try to suggest a way to tighten it 
>> up.
>>
>>    My goal with this is to make it much more clear (to the point of 
>> being
>>    mechanically checkable) precisely what a compliant API provides.
>>
>>    I'm not attached to the structure I'm proposing or to any of the
>>    particulars in the straw-man I've posted, but if it's not 
>> tightened up
>>    with something at a similar level of concreteness, I'm concerned 
>> that
>>    different implementations will be not only incompatible in random
>>    underspecified corner cases (like BSD sockets today when you try 
>> to make
>>    cross-platform C code), but also are likely to end up with very 
>> many
>>    important differences that would make the whole taps effort more 
>> or less
>>    moot.
>>
>>    In a world where we end up with a doc at the level of abstraction 
>> I'm
>>    currently seeing in draft-taps-interface, it seems to me that if 2
>>    different API implementations were written in the same language, 
>> it'll
>>    be prohibitively difficult for an app to migrate from using one to 
>> using
>>    the other, just because so many aspects of it are left open to the
>>    implementors.
>>
>>    In that context, I thought a YANG model would be useful here to
>>    provide a cross-platform way to specify what exact properties and
>>    objects exist, an exact format in which the values can be 
>> specified, and
>>    what exact semantics they have, while still allowing for a sane
>>    extension path and language-specific implementation details.
>>
>>    I'm thinking some language a bit like the first bullet in Section 
>> 4.2 of
>>    taps-interface:
>>
>>      A compliant implementation SHOULD provide a language-appropriate 
>> way to
>>      configure a PreConnection using YANG instance data for this 
>> model, and
>>      SHOULD provide an API that outputs the YANG instance data for an
>>      established Connection.
>>
>>      An implementation MAY also provide appropriate APIs for directly 
>> editing
>>      the objects without using YANG.  It's RECOMMENDED where possible 
>> to use
>>      names that mechanically translate to the names in the YANG data 
>> model,
>>      using capitalization and punctuation conventions as expected for 
>> the
>>      language of the implementation.
>>
>>    And then of course a YANG model:
>>    https://datatracker.ietf.org/doc/draft-jholland-taps-api-yang/
>>    (draft-jholland-taps-api-yang)
>>
>>    If this seems useful, it will need lots of refining.  I'll be 
>> surprised
>>    if any part of it survives exactly as written.  It's a quick and
>>    dirty attempt to concretize a few of the things I saw listed in
>>    draft-ietf-taps-interface, as a starting point to fill out if it 
>> seems
>>    useful.
>>
>>    But the model parses, and the example data instances in the draft
>>    parse against the model (all with libyang).
>>
>>    One of the main reasons I'm doing this is because it seems to me 
>> what's
>>    specified in taps-interface-02 today is missing some key features, 
>> like
>>    an enumeration of the properties in the Local/RemoteEndpoint 
>> examples in
>>    section 5.1.  And I don't see that listed as an open issue in 
>> github,
>>    which surprised me a bit.
>>
>>    I think oversights like this will become immediately and painfully
>>    obvious when there's a reference implementation that includes a 
>> YANG
>>    parser and an explicit data model, as opposed to the combing of 
>> the
>>    document and a sort of eyeballed comparison to NEAT that I tried
>>    this week to reach that conclusion (which I found challenging even
>>    though I thought both the document and the library were mostly 
>> pretty
>>    well written).
>>
>>    The whole thing at this point just smells to me much more abstract 
>> than
>>    it really has to be or than it's really useful to be, which 
>> bothers me
>>    because the idea of replacing BSD sockets with something usable 
>> seems
>>    like such a great idea.  I'd like this to be something I can 
>> actually
>>    use in a way that makes my life easier someday soon.
>>
>>    But I think I'm at the point where I need a sanity check to see if 
>> I'm
>>    just missing something, or if this seems like a useful direction.
>>
>>    Thoughts?  Suggestions?   Worth discussing in Prague?  (If so, can 
>> I
>>    get a slot?)
>>
>>    Cheers,
>>    Jake
>>
>>    *:
>>    I concluded that there's no reason multicast couldn't be supported
>>    today, if there were an implementation that could reasonably claim 
>> to be
>>    compliant, by just adapting some of the examples in
>>    draft-ietf-taps-interface-02 and understanding the semantic 
>> meaning of
>>    multicast address spaces inside the API.
>>
>>    For example, I couldn't find any reason this can't be expected to 
>> set
>>    up an SSM channel subscription without any further ado, given a 
>> sane
>>    implementation that supports it:
>>
>>      RemoteSpecifier := NewRemoteEndpoint()
>>      RemoteSpecifier.WithIPv4Address(192.0.2.21)
>>
>>      LocalSpecifier := NewLocalEndpoint()
>>      LocalSpecifier.WithPort(30000)
>>      LocalSpecifier.WithIPv4Address(232.252.0.2)
>>
>>      NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(...)
>>
>>    Maybe there's some value in specifying a "JoinSSM()" to override 
>> defaults
>>    in the PreConnection, just to make sure you're specifically asking 
>> for
>>    multicast.  I think that would be fine for native multicast, but 
>> like I
>>    said, a much smaller point than the looseness of the API.
>>
>>    Where it gets a bit more complicated is trying to handle multiple 
>> options
>>    for discovering a usable unicast tunnel for multicast traffic, as
>>    described in Section 2.4.1 of 
>> draft-ietf-mboned-driad-amt-discovery-01.
>>
>>    I'd like to have a decent place to tack on an extension to this 
>> API that
>>    can transparently, within the connection API, discover the best 
>> available
>>    AMT relay and start using it when native joining is unavailable 
>> (and also
>>    to provide normative controls for configuring it when there's
>>    administrative configuration to be added).
>>
>>    But that's a 2nd order question for me at this point, because in 
>> the
>>    current TAPS API I don't see any obviously good spot to put 
>> selection
>>    controls for that kind of tunnel discovery selection, or really a 
>> good
>>    way to explain what it's supposed to do, if I tried to add 
>> controls to
>>    something that's there.
>>
>>    Solving that is my main motivation for being here.  (Well, and 
>> that
>>    the BSD socket API for multicast is kind of a disaster today.)
>>
>>    Anyway, if taps finds the whole YANG suggestion useful, I'll 
>> probably
>>    suggest some new extensions about this, and maybe a few other 
>> points,
>>    especially maybe around trying to put in a structure that can 
>> support
>>    some kind of sane explicit layering.
>>
>>    But I'm not sure I can articulate those suggestions in a way I'm 
>> sure is
>>    meaningful without first getting a more clear specification nailed 
>> down
>>    about what's actually in the taps spec. Because right now I'm 
>> mostly
>>    just confused about what an API implementation would really look 
>> like,
>>    and how you could tell whether it matches the taps-interface spec.
>>
>>
>>
>>    From: Aaron Falk <[e-mail]>
>>    Date: 2019-03-04 at 10:53
>>    To: taps WG <[e-mail]>
>>    Cc: Zaheduzzaman Sarker <[e-mail]>
>>    Subject: [Taps] call for agenda items at TAPS IETF-104
>>
>>    Hi All-
>>    What should we use our time to discuss? Let’s focus on things 
>> that would benefit from f2f discussion, consensus building, or just 
>> argument. :)
>>    • TAPS docs: are there open topics that need group attention? 
>> Seems like we settled most of the remainder at the interim.
>>    • TAPS security: this seems nearly done. Anything to discuss?
>>    • Implementations: a good topic for information sharing but less 
>> important than anything needing agreement
>>    • Mobility: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=pLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=HUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5wd3D5_s&e= 
>> and 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dwesterlund-2D2019-2D01-2D08_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=pLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=
>>    --aaron
>>
>>
>>
>> _______________________________________________
>> Taps mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps
>
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps