Hi, A few answers in line; I'll mark them with MW:
> On 7 Mar 2019, at 20:10, Holland, Jake <[email protected]> wrote: > > Hi Michael, > > Thanks for responding, much appreciated. (And also to Tommy > and Aaron.) > > Based on the replies from you, Tommy, and Aaron, I'll plan > to present something in Prague, and can you please put me > on the schedule, Aaron? > > More responses inline with <jh></jh>, and thanks, these > questions were very helpful to help me focus on what needs > explaining vs. what's obvious. > > > On 2019-03-07, 00:32, "Michael Welzl" <[email protected]> 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. > > <jh> > Thanks for explaining, I'm sympathetic and grateful that you > overcame your concerns. I was in the same place on YANG not > too long ago, and I still have a ways to go, though I now think > I see some of its promise. > > But I don't think I created a multicast issue on github? I just > noticed a few nits while reading and sent a pull request, nothing > really substantial yet. MW: Sorry, that might have just been a response to an issue or PR somewhere, I saw an email flying by, that's all... > </jh> > > 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?) > > <jh> > Syntax plus tool support is the only difference between machine code > and <your favorite programming language>, so even if that's the only > thing we got, it's not to be sneezed at. (And there is a lot of room > for growth here, but there are already tools that can generate API > header code from yang, e.g: > https://wiki.onosproject.org/display/ONOS/YANG+Tools ) > > But I'm actually pushing from the other direction; my understanding > of the current docs is that taps-arch is a high level design and goals > document, and taps-interface (and taps-minset) make an attempt to > lay out the concrete implementation details that would make taps-arch a > reality, if an implementation covers them. > > My claim here is twofold: > - that taps-interface as it stands today is another high level design > document, which will have a necessarily fuzzy mapping to any actual > implementation. > - that taps-interface is _really_ _close_ to laying out the concrete > implementation details in a non-fuzzy way that can be directly used > by implementors, so I'm suggesting that taking that extra step is > highly valuable. > > On the question of benefits: I'll lay out some of the ones > that seem important to me, but I'll first say that in theory, > these benefits could be realized by any concrete configuration > format. The benefit of YANG specifically comes from tool > support and the confidence from existing work that make it clear > it's a reasonable format for networking configuration. > > Basically, because there's so much YANG work already done for > networking, using YANG lets us leverage some of that work in a way > other options don't. > > In particular, there are a bunch of networking-specific concepts > that are already defined in detail. For example, the ipv6-address > type has a complicated regex that many implementors are likely to > get wrong if they try to roll their own (at least, I've certainly > done so, and seen it a bunch of times): > https://tools.ietf.org/html/rfc6991#page-19 > > But by making the obvious choice of using yang tools to parse yang > stuff, implementors automatically get checking against that > (normative!) regex for free without having to notice and check it > themselves. > > There's other side benefits, like that interfaces are themselves > explicitly defined (https://tools.ietf.org/html/rfc8343#section-5), > and so where things like interface types might be used, the past > and future work of people who formalize and extend the set of > interface types gets automatically imported by referencing the > normative yang definition for network interfaces. > > But to list a few of the specific benefits from having an explicit > config format: > > - cross-platform portability: > If I've got a program using a taps api that talks to some service, > and now I want to write a new program in a different language to talk > to that service, I can export the config and load it in my new > program (even in a new language), and I can be reasonably sure > it'll form the same kind of connection. > > Although it's possible to make it work anyway as long as the APIs > have a 1-to-1 mapping, normalizing on a config file format instead > of a list of features seems to me like it'll save me perhaps up to a > day or so of effort each time I have to do this, which when multiplied > by all the implementors in the world over the next decade or 2, starts > to add up. > > - testability: > Again, this mostly saves time, but by having a defined input format, > it's possible for different implementations to use the same suite of > test configuration files to verify the same interpretation of their > contents. If each implementation has its own way of configuring the > features, it's not impossible to design a suite that can test them, > but it's vastly harder. > > - completeness: > One of the points of confusion I had with taps-interface was that the > Local/RemoteEndpoints seemed both critical to an implementation and > very underspecified. Although it's possible to address that by raising > concerns specifically about the Local/Remote Endpoints, I'm not sure > there aren't other underspecified areas of the taps-interface draft. > > I expect that a reference implementation based on parsing a config > format would uncover all such underspecified areas of configuration, > if the config format examples are used to describe all the supported > use cases. > > (So part of my goal with this proposal is to solve this problem in > the general case, which implies that it'll also be solved for the > specific cases of Local/Remote Endpoints, though of course the > details for each instance of incompleteness are separate topics.) > > There might be some other benefits, but I'll stop there, hoping the > point is sufficiently clear. > </jh> MW: Absolutely, yes - some very good arguments here. The "common config format" argument in particular got me excited! > Also, I actually see 3 separable things being proposed here: > > 1) the YANG model > <jh> > I'd phrase the current status of the proposal as an in-principle > "use a YANG model", rather than "use this specific YANG model". > > The current draft is kind of a throw-away example proof of concept, > which is certainly very incomplete, and some of my reading yesterday > suggests that it's actually not very well structured either. I've > probably already made a fool of myself to any actual YANG experts, > that ever try to read it, but such are the risks of posting public > comments... :) > </jh> > > 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...) > <jh> > Fair point, this really is a separate topic. I brought it up > really only because it's a motivating factor in my participation > here, not because it's a primary factor for taps in general. Let's > drop it for this thread, and I'll plan to raise it as a separate > issue when the yang questions are settled and I've got something > more thought out. > </jh> MW: To be clear, there has always been only one argument against multicast in TAPS, and that was: "it's complex, so let's deal with it later." So I think we're all for it... we just didn't get to work on it. > 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). > > <jh> > Yes, this is a case in point for my concerns about incompleteness > on the Endpoint specifications. > > I wasn't sure how to treat this, so I'm not surprised if I got it > wrong. I was sort of pattern-matching on the rest of what the spec > does, plus guessing at intended meanings of this paragraph from > https://tools.ietf.org/html/draft-ietf-taps-interface-02#section-5.1: > > 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. > > By the time I finished making the examples, I had noticed I was > maybe doing it wrong, but I didn't want to bother fixing it unless > people agree it's worth spending effort in this general direction, and > I didn't want to hold off on opening the discussion. Of course, it > should be changed to match the consensus of the wg on what belongs > here. > </jh> > > 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? > > <jh> > I'm not sure. This is part of what I mean when I say I find the > current taps-interface a little too loose. I _think_ what I posted > is a valid (though perhaps not optimal) interpretation of the current > text. I might be wrong about that, so I'd be grateful for a pointer > to the text that prohibits this interpretation. MW: Things have changed so much since the -02 version, including a re-organization of properties... and the latest version doesn't seem to pop up under the "editor's copy" link now, after the move. Therefore, I don't want to point to some specific bit of the text now. Let's get back to this discussion later, on the basis of the next -interface draft version. > But really, that's beside the point. I'd be even more grateful for an > alternate proposal that more closely matches the intended design for > a taps API, with the same level of concreteness. MW: I liked your proposal! It just maybe calls for a change of what we have (rather than changing what you propose). > </jh> > > 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 ? > > <jh> > Yes, I think so. I think I understand an ultimate goal for taps to > be "as an app designer, don't worry about which transport, just > send the magic API to go discover one that works". > > However, it seems to me in the interim that it'll be necessary > to specify port numbers in order to interoperate with a lot of > existing services, especially in cases like RTP (or a lot of > other generalized UDP stuff), where there's not an explicit > service-to-port mapping. (Also to interoperate with a lot of > other deployed systems like firewalls.) > > I have a few nebulous ideas about how explicit layering might be a > good way to solve this, but I think in order to make the ideas sharp > enough to evaluate, I thought I'd first try the easier task of making > taps sharp enough that I can express the ideas as proposed changes > to an existing well-formed concept. > </jh> MW: all of that makes sense to me, too. > 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 :-) > > <jh> > Fair point. > > I propose during the taps meeting to check preliminary consensus about > moving forward with a YANG model within taps, and if so whether to > integrate, replace, or make a paired doc with the existing taps-interface. > Separately, I'll encourage those interested and available to spend some > time in offline clarifying discussion during the week prior. > > Cheers, > Jake > </jh> MW: IMO, making a paired doc seems like a good strategy. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
