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

[Michael Welzl <[e-mail]>]

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