Re: [Taps] call for agenda items at TAPS IETF-104
"Aaron Falk" <aaron.falk@gmail.com> Thu, 07 March 2019 20:54 UTC
Return-Path: <aaron.falk@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B47130F1E for <taps@ietfa.amsl.com>; Thu, 7 Mar 2019 12:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHk7VVivwJue for <taps@ietfa.amsl.com>; Thu, 7 Mar 2019 12:54:50 -0800 (PST)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A164128701 for <taps@ietf.org>; Thu, 7 Mar 2019 12:54:50 -0800 (PST)
Received: by mail-qt1-x844.google.com with SMTP id f11so1576314qti.7 for <taps@ietf.org>; Thu, 07 Mar 2019 12:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=sardAOco9bFJbi8WYEMHls4tX5eB9L+y2TX2vs5k0z4=; b=kKTYcpqkHHqTim9MCALUDsK5NIfPu3vbbJotTrpPAhlEau/X7IqrKFqICqavBHTX6L IbrF4q4FJhQHLB7yoRgReNdz7oQL6FaMqFPl8g/wwP1JNDhgosFppRu0GpGPGgwI4+1y nQFXPEgBVMJ0XubX6/wzwUToLeAIXy6LWFjxD4ZQqbVUyG5ywNT56WY3fF/L1liX7+K0 2RUPj8IIP64NTpdh6o4g0pV/ffh31GCjNSwQoeNSh5UM3BAsMTuaPvbMQTuaKlRZR1Wq klwevDSbx/eTfq/vKd8Ua5svihb528syLU2JWlMN1BTgW4/1r/0yTJioE7hmHOvOqeVg Je5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=sardAOco9bFJbi8WYEMHls4tX5eB9L+y2TX2vs5k0z4=; b=J0DI30OxLm6oQ0j34XhFYdO6uMNPWNvfs0vX0iXbAs2ZaQ4clgVj7in18qYnCK6YhI THls/8jP2lsI27l/gaUJDHTF7Nm8dV/0Nj3Pj/P8hZtomVT54+FRNdEiQh33tMvcG++c 5CShqMmWFZBebdbci9IuDgUxTbG6yh3AEo9fl0Ll1DAKxCYsvNW4pGE1WsebLX3AMPOj Tnp9gf+psNIereaVioTtC8usEAKIDyZqSFUggrWrgQ9RBh20TT6rcdTdyLTV4r+D9VKP haetvZcGRhuVLsX1WKfM2FseiwfkCT+CEDjlTAk15yf9XXQrFq6ygXxI2YUm/OSznGyM XtuA==
X-Gm-Message-State: APjAAAXxWd4BnWCZn01ouJHeenzqs1T0DgXB5BX7ekBCz9Kx5rFctjuR Ij7/1PTKVnLJU+zUmBQNmgU=
X-Google-Smtp-Source: APXvYqxPS90woEuRLgk2YgZ/lLmys1qwlKbZE23qAPKwG3iHXx7OLWrKT5HVkIkRkxF+IbOUEo62BQ==
X-Received: by 2002:ac8:2b51:: with SMTP id 17mr11708925qtv.328.1551992088909; Thu, 07 Mar 2019 12:54:48 -0800 (PST)
Received: from [172.19.37.49] ([2001:4878:a000:3000:d113:abb9:4bf3:8f75]) by smtp.gmail.com with ESMTPSA id t1sm3602001qtj.54.2019.03.07.12.54.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 12:54:47 -0800 (PST)
From: Aaron Falk <aaron.falk@gmail.com>
To: "Holland, Jake" <jholland@akamai.com>
Cc: taps WG <taps@ietf.org>, Michael Welzl <michawe@ifi.uio.no>
Date: Thu, 07 Mar 2019 15:54:45 -0500
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <852D2DBC-3C7D-4D54-82CB-0956F3844E58@gmail.com>
In-Reply-To: <AF7DD2EF-6FF3-4C26-8BA9-37D3D03E1139@akamai.com>
References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> <F0D3C2AF-7A8E-4BA5-8255-907479CA3843@ifi.uio.no> <AF7DD2EF-6FF3-4C26-8BA9-37D3D03E1139@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_72DE4123-A867-4751-B300-DA4767929743_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/ufv1VmNFMadUldhf7eFv1E2BClU>
Subject: Re: [Taps] call for agenda items at TAPS IETF-104
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 20:54:56 -0000
Jake- I’m unclear, do you want to discuss multicast in Prague or just YANG? --aaron On 7 Mar 2019, at 14:10, Holland, Jake 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" <michawe@ifi.uio.no> 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. > </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> > > 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> > > 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. > > 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. > </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> > > 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> > > 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 <jholland@akamai.com> > 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" <jholland@akamai.com> > 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 <aaron.falk@gmail.com> > > Date: 2019-03-04 at 10:53 > > To: taps WG <taps@ietf.org> > > Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> > > 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 > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
- [Taps] call for agenda items at TAPS IETF-104 Aaron Falk
- Re: [Taps] call for agenda items at TAPS IETF-104 Tommy Pauly
- Re: [Taps] call for agenda items at TAPS IETF-104 Holland, Jake
- Re: [Taps] call for agenda items at TAPS IETF-104 Holland, Jake
- Re: [Taps] call for agenda items at TAPS IETF-104 Michael Welzl
- Re: [Taps] call for agenda items at TAPS IETF-104 Tommy Pauly
- Re: [Taps] call for agenda items at TAPS IETF-104 Aaron Falk
- Re: [Taps] call for agenda items at TAPS IETF-104 Brian Trammell (IETF)
- Re: [Taps] call for agenda items at TAPS IETF-104 tom petch
- Re: [Taps] call for agenda items at TAPS IETF-104 Holland, Jake
- Re: [Taps] call for agenda items at TAPS IETF-104 Aaron Falk
- Re: [Taps] call for agenda items at TAPS IETF-104 Christopher Wood
- Re: [Taps] call for agenda items at TAPS IETF-104 Holland, Jake
- Re: [Taps] call for agenda items at TAPS IETF-104 Michael Welzl