Re: [Taps] finishing things

"Holland, Jake" <jholland@akamai.com> Mon, 18 November 2019 03:55 UTC

Return-Path: <jholland@akamai.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 5E607120826 for <taps@ietfa.amsl.com>; Sun, 17 Nov 2019 19:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 PIWKV_GSyrHW for <taps@ietfa.amsl.com>; Sun, 17 Nov 2019 19:55:21 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8C6120850 for <taps@ietf.org>; Sun, 17 Nov 2019 19:55:21 -0800 (PST)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAI3sUX0008360; Mon, 18 Nov 2019 03:55:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=gPcbdtNUjf+4yBuB+eL3+bCWafRYsNDzZcCHNRgrvWs=; b=f3sQFdv/lYEFBNOSy7oPJeYS1LwhXBALqz7ufco8KSDj5RrB/C1pDOl0CCrwnfCmGiq8 h2UDUX8zBbPYPSEoucbrAtZmCcMDSA1IhPfKQXY9PEcoMHvx3b5yhZkFaHkPt9rDAhyB YMQCpiJEmKIlbbR83fclgxV4A2Wa+Q5VoDnC62bqlkiqa1R27fzALSXLPs1Xr67J0HT7 r0V+oidaZGqyPRjXYD9MJgs4OGmx1dNeHLBYL4uykGWUr6qLIO9FtZK8XA7XNiMVcimi LR+3puVhqF/8xO+HIjafLgUlwL+4PF9yHV51PZatJVzLOZSsn4M6ZSOvCx+nMasQfwi5 4g==
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2wafqy6jkr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 03:55:17 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAI3l6wL011970; Sun, 17 Nov 2019 22:55:17 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 2wadayy8gw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Nov 2019 22:55:16 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 21:55:15 -0600
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1473.005; Sun, 17 Nov 2019 21:55:15 -0600
From: "Holland, Jake" <jholland@akamai.com>
To: Aaron Falk <aaron.falk@gmail.com>, tom petch <daedulus@btconnect.com>
CC: taps WG <taps@ietf.org>
Thread-Topic: [Taps] finishing things
Thread-Index: AQHVnE0Tpi9zWVri3UOKosPPqqf7aKeQm5qA//+SOoA=
Date: Mon, 18 Nov 2019 03:55:15 +0000
Message-ID: <8B6B4D22-64F5-451E-AE02-5F66719F5584@akamai.com>
References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com>
In-Reply-To: <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.216.241]
Content-Type: multipart/alternative; boundary="_000_8B6B4D2264F5451EAE025F66719F5584akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-17_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911180030
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-17_05:2019-11-15,2019-11-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxlogscore=999 clxscore=1011 priorityscore=1501 lowpriorityscore=0 bulkscore=0 mlxscore=0 suspectscore=0 impostorscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180031
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/4_BctypWGfWzs41rbZCD1CZxRuU>
Subject: Re: [Taps] finishing things
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: Mon, 18 Nov 2019 03:55:23 -0000

I mostly agree, with a caveat.

A couple of notes as author:

  *   I’d be willing to continue this work as a WG item if the WG would like to adopt it, especially if it means some people will review and assist :)
  *   I think it’s not currently mature enough to integrate into an imminent last-call draft (particularly as regards the security parameters, as mentioned previously on-list, but likely some other areas are weak as well)


And my caveat, not as author but as wg participant:
Although I agree it would be nice to avoid blocking progress on the other drafts, I wouldn’t be surprised if a wider detailed review and discussion of the yang model could bring to light some ambiguities that have been overlooked in the existing drafts, particularly taps-interface.  In that sense, it might make sense to get started quickly, if we intend to do this.

  *   note that the same is true as more-complete API implementations are developed, regardless of whether as a wg the issues are tackled with the yang model.  (The exercise of applying a new level of rigor and specificity to the abstractions written in the current draft is what’s likely to generate some insights that might be best applied to text of the draft, not the yang model specifically).
  *   This is a point in tension with the goal of wrapping up the existing drafts.  Not sure how to handle it, but publishing taps-interface without first trying to nail down specifics in some detail, IMO, will dramatically increase the chances that we’ll need to issue errata or live with regrets on the published language on taps RFCs.  Maybe that’s fine, there are many imperfect RFCs, but worth thinking about.

Best,
Jake

From: Aaron Falk <aaron.falk@gmail.com>
Date: 2019-11-18 at 10:28
To: tom petch <daedulus@btconnect.com>
Cc: taps WG <taps@ietf.org>
Subject: Re: [Taps] finishing things


On 17 Nov 2019, at 22:48, tom petch wrote:

I am not sure which three you have in mind but suspect that it does not
include
draft-jholland-taps-api-yang

Tom Petch

Thanks for bringing this up, Tom. Note that TAPS hasn’t adopted this draft as a working group item. We have some options. It could be absorbed into one of the TAPS docs if a) folks thought it was in-scope and sufficiently useful and b) it was mature enough. If not, we could consider adopting it in TAPS as a new work item. I’d prefer that it did not slow down completion of the 3 wg drafts. Thoughts?

--aaron