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 <[email protected]> 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" <[email protected]> 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 <[email protected]> > Date: 2019-03-04 at 10:53 > To: taps WG <[email protected]> > Cc: Zaheduzzaman Sarker <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
