Re: [Taps] Draft-ietf-taps-arch-08 review

Tommy Pauly <tpauly@apple.com> Wed, 05 August 2020 15:48 UTC

Return-Path: <tpauly@apple.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 CB40F3A0A9F for <taps@ietfa.amsl.com>; Wed, 5 Aug 2020 08:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=apple.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 dLlD75c18iWd for <taps@ietfa.amsl.com>; Wed, 5 Aug 2020 08:48:15 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 631853A0A06 for <taps@ietf.org>; Wed, 5 Aug 2020 08:48:15 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 075Fdp0G002992; Wed, 5 Aug 2020 08:48:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=iOXh02auXHVCU1+PneD2jOOfTq6OYh/vpBscjIvdtEA=; b=QAwpBYQzhsXDf81w4a4FgZ2EdwK9RNbHewJffDtS6iuFBGcPZuxzP6OBQB3iwrIGrw+5 ZwAglZyS5rd+jK1VcAA6eUSde0YQoz/0zAYoEBf/+E7Dhy5agf2u6Oh6MRp03oBV5jDr aQo3eFbXdz2mIBUFtka6aixvKUWd/QkmKLLtKRhezVFyqTRfM3Q4TJ8udQU8s00VJqkB 970iC9Nqii2YqBlBLMKFjNek3C+O7w7M0n171OpTnRbvUKY6CTS3EM/PdqxZx+nWXBDt AsRjBm/UqcfkFxOYNeVAKCq9rWxXXQAn0kV6Dml/lwyY/ohGaTgxf5oON9S4Kp5ajwHK MQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp01.apple.com with ESMTP id 32nvffj45h-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 05 Aug 2020 08:48:13 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QEL011IZL8CXB10@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 05 Aug 2020 08:48:12 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QEL00500KUB5O00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 05 Aug 2020 08:48:09 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 8d45deca0a60b8e84b634a23cb93b003
X-Va-E-CD: 29fe15a9f4936c336621990590fa901b
X-Va-R-CD: d043d6b811de3387417919956bc30993
X-Va-CD: 0
X-Va-ID: 65597b1d-c74c-4202-a028-eff35d626faa
X-V-A:
X-V-T-CD: 8d45deca0a60b8e84b634a23cb93b003
X-V-E-CD: 29fe15a9f4936c336621990590fa901b
X-V-R-CD: d043d6b811de3387417919956bc30993
X-V-CD: 0
X-V-ID: 1e990df2-af7c-465d-b960-1f521009c9eb
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_10:2020-08-03, 2020-08-05 signatures=0
Received: from [17.234.104.58] (unknown [17.234.104.58]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QEL010JBL845H00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 05 Aug 2020 08:48:05 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <CE4803B9-A156-4836-8D0C-1D644DE72E5F@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_419BE93A-385E-48B3-A4A3-2F6AD95F4555"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Date: Wed, 05 Aug 2020 08:48:04 -0700
In-reply-to: <CAM4esxTySUBDZoXoMpi5T5i=Zhwdp+Lxg+Zjccw+hrd=fesZAA@mail.gmail.com>
Cc: taps WG <taps@ietf.org>
To: Martin Duke <martin.h.duke@gmail.com>
References: <CAM4esxSag_6R9Wyz2znwuphw-LySqYLhhS43GZn4JE67tX+6tQ@mail.gmail.com> <CAM4esxTySUBDZoXoMpi5T5i=Zhwdp+Lxg+Zjccw+hrd=fesZAA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_10:2020-08-03, 2020-08-05 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/QadnK7VEduAdlAEOWXkmHIYsNQo>
Subject: Re: [Taps] Draft-ietf-taps-arch-08 review
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: Wed, 05 Aug 2020 15:48:17 -0000

Hi Martin,

On the author/editor side, please note that Brian and myself are already the editors for this document. The API and implementation documents also have two editors each.

For background see: https://github.com/ietf-tapswg/api-drafts/issues/184 <https://github.com/ietf-tapswg/api-drafts/issues/184>

I have been arguing for just having the editors being on the byline, with the rest of the authors in the document. It’s gotten to the point where we need to do manual submission of metadata since the data tracker doesn’t correctly parse dates when there are this many authors. But I was unable to gain agreement on this issue previously.

Regarding your comment about extensibility, I think we could add a sentence or two to Sections 3.1 and 3.2. The main extensibility point describe is in having transport-specific features that are impementation-specific. If there are entirely new functionalities that should become part of the standard/common API across implementations, then I imagine that would need to be an extension/bis to TAPS. 

Thanks,
Tommy

> On Aug 5, 2020, at 8:31 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Also the authors should nominate a handful of editors to limit the byline.
> 
> On Tue, Aug 4, 2020 at 3:26 PM Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> wrote:
> I have read this document and believe it is ready for publication.
> 
> However, is it worthwhile to include something here about extensibility? If new transports introduce new concepts, should we any requirements of the api to have extension points for those concepts?
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps