Re: [Taps] call for agenda items at TAPS IETF-104
tom petch <daedulus@btconnect.com> Thu, 07 March 2019 17:28 UTC
Return-Path: <daedulus@btconnect.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 CB50D12AF7B for <taps@ietfa.amsl.com>; Thu, 7 Mar 2019 09:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 ByiRbKTSf0Ie for <taps@ietfa.amsl.com>; Thu, 7 Mar 2019 09:28:42 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30136.outbound.protection.outlook.com [40.107.3.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCF91310A1 for <taps@ietf.org>; Thu, 7 Mar 2019 09:28:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OIUHFyabX3JKTE2ZHQrGUu+pazZkUlHIQhX4Lrn76QY=; b=Yi5k3sPpcGiZEOzA7rH+mG7kvznbz8ZBnYk7hCqnK7Y+rmm3vv46KdGoE9O0hkKroFxcUyhRh0Ad4ZKHuHIULXVVQf6NL+3X8EoEoSg/AR/t3ryqf8ljgvqKQj8agVlsEzkpBzIgKxW9kdm/CIb8UOGHE9zoQTHFLYss4UiQmAE=
Received: from DB6PR0701MB2182.eurprd07.prod.outlook.com (10.168.55.16) by DB6PR0701MB2294.eurprd07.prod.outlook.com (10.168.77.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.6; Thu, 7 Mar 2019 17:28:31 +0000
Received: from DB6PR0701MB2182.eurprd07.prod.outlook.com ([fe80::2ca5:1eed:afe4:86ea]) by DB6PR0701MB2182.eurprd07.prod.outlook.com ([fe80::2ca5:1eed:afe4:86ea%11]) with mapi id 15.20.1686.016; Thu, 7 Mar 2019 17:28:31 +0000
From: tom petch <daedulus@btconnect.com>
To: Michael Welzl <michawe@ifi.uio.no>, "Holland, Jake" <jholland@akamai.com>
CC: taps WG <taps@ietf.org>
Thread-Topic: [Taps] call for agenda items at TAPS IETF-104
Thread-Index: AQHU1QsuujEGBYzapkKtLlT0v3ohmQ==
Date: Thu, 07 Mar 2019 17:28:30 +0000
Message-ID: <006501d4d50a$e421da00$4001a8c0@gateway.2wire.net>
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>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0031.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:61::19) To DB6PR0701MB2182.eurprd07.prod.outlook.com (2603:10a6:4:4a::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.156.84.54]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a7860e19-d839-46e6-3416-08d6a3225129
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6PR0701MB2294;
x-ms-traffictypediagnostic: DB6PR0701MB2294:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <DB6PR0701MB229499B1F88C3056B14337AEC64C0@DB6PR0701MB2294.eurprd07.prod.outlook.com>
x-forefront-prvs: 096943F07A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(376002)(366004)(396003)(199004)(189003)(53754006)(52314003)(51444003)(13464003)(4720700003)(81166006)(84392002)(81816011)(2906002)(316002)(52116002)(61296003)(4326008)(7736002)(561944003)(76176011)(14496001)(446003)(476003)(97736004)(8676002)(93886005)(53946003)(86362001)(30864003)(110136005)(8936002)(229853002)(66066001)(486006)(71200400001)(14444005)(6486002)(44736005)(81156014)(99286004)(25786009)(186003)(105586002)(5024004)(86152003)(71190400001)(9686003)(68736007)(5660300002)(6512007)(6306002)(6436002)(3846002)(386003)(305945005)(62236002)(14454004)(26005)(6246003)(6346003)(106356001)(1556002)(478600001)(50226002)(44716002)(102836004)(6506007)(53546011)(53936002)(966005)(256004)(81686011)(6116002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2294; H:DB6PR0701MB2182.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Fk2Z+5Bhcnzbu00XjL33aODnWvHDgkJzwbZqSqV2Gw+rABAftQeY35gK0XdgtlJKHfvgzPwcA1QZZktNhzfoY+yLCHcBnl7+O+veAwjW69hWukyBF6F84WaxXVZmspEpsPcA3O7fDi3NeDs9GxUADcRduPPm8d7pLCPsoBCNIN98Y26HVUNMpv/ZPrgAvFPDoOClFsQ2mcwn2ChHcaMr6XsoPALrfrTXs79cDjJTqhLk0ZDWbHVCM1UCQV68v2YsBfh1KQifHoruFRpoWsz3ksrjMCBg550QoDhZpnSbkSKxAMAB70hq5di+uJvjDdU3h3W6wFpmK4ctFvYt0BVnFLdRV+IzD8EHjuMV8sPy/QjG2F3VVwOd6SSVrmHAQOgV057Tw2AaV6WFCE21fHeHe+x+QB/uG+Rksl3akyUFXjY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <648146E59ED5A349A0C2A8276188072D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7860e19-d839-46e6-3416-08d6a3225129
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 17:28:30.9797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2294
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/tPO9vMVlncGniVbNY9Bfqsuf3Dw>
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 17:28:50 -0000
----- Original Message ----- From: "Michael Welzl" <michawe@ifi.uio.no> Sent: Thursday, March 07, 2019 8:32 AM > > 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?) Yes, indeed. YANG is a DDL created to provide definitions of data structures that need to be read and/or written when managing networks or similar systems, so it matches well with BGP or LISP, NAT or QOS. It is verbose (a reaction IMHO to ASN.1). It lacks, for me, rigour, formal underpinnings, which shows up in quirks, corner cases and in the lengthy ABNF definition of it. It has got constraints - 'must' 'when' range of values or length - so you can specify that the MTU must be present and be in a different range depending on which interface type is referenced. It is closely tied to XML and Netconf (as a most fleeting glance at RFC7950 shows); repeated talk of decoupling it have yet to lead to action. The syntax was chosen to be C-like (but not C). It has no sense of document order. The permitted range of values can be tied to what you might see in an IETF protocol (although a string can be 18446744073709551615). Enumerations can specify a value (along with a string) but the value is documentation only - it does not appear on the wire. There is no sense of precedence between, say, Prefer and Require. Capital letters are not prohibited, rather discouraged so few people use them. What does it offer TAPS? Mmm I thought TLS foolish when it defined its own DDL but over time, have come to appreciate that choice. Tom Petch > 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 <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=96ZbZZcaMF4w0F 4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=pLW5gSyetfVe_ix G4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=HUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5wd3D5 _s&e= and https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.or g_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dwes terlund-2D2019-2D01-2D08_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo _4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=pLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2B gM2rpQo&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