Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest)

"Brian Trammell (IETF)" <ietf@trammell.ch> Mon, 12 July 2021 08:46 UTC

Return-Path: <ietf@trammell.ch>
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 850FB3A1592 for <taps@ietfa.amsl.com>; Mon, 12 Jul 2021 01:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Level:
X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trammell.ch
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 u5K1iZqSSZ-y for <taps@ietfa.amsl.com>; Mon, 12 Jul 2021 01:45:57 -0700 (PDT)
Received: from smtp-8fae.mail.infomaniak.ch (smtp-8fae.mail.infomaniak.ch [83.166.143.174]) (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 154813A156E for <taps@ietf.org>; Mon, 12 Jul 2021 01:45:56 -0700 (PDT)
Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4GNcmX4hP4zMq07K for <taps@ietf.org>; Mon, 12 Jul 2021 10:45:48 +0200 (CEST)
Received: from smtpclient.apple (unknown [IPV6:2a02:169:17b2:0:842e:5007:33f0:911c]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4GNcmX3Czpzlmrrn for <taps@ietf.org>; Mon, 12 Jul 2021 10:45:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1626079548; bh=cqIlqiyhPYU6VIe5J6WbLAJK2gMKuJrn4PrO7VGg59Q=; h=From:Subject:Date:References:To:In-Reply-To:From; b=oV7Pndi936V1NXuL7o/ooWZPVB/uez6G5dT+LN4/Wev1wbbcWxR0j412EKP9cOPGH Bkzp8V9Fj3skRDAsKXJPUSUDVW7CTW4ttg/p11lZZLJrV37f/kZKdUlOhHSGki61xn fHwvIimCvfrspAJvaXjsSzsvtJryh8Gjv0C5XB6I=
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Mon, 12 Jul 2021 10:45:48 +0200
References: <E1m1lQc-0002yU-5G@magpie.corvid.ch> <CEC3AB5D-86B7-42F7-BAD4-BE5EC5EA88CA@trammell.ch>
To: taps@ietf.org
In-Reply-To: <CEC3AB5D-86B7-42F7-BAD4-BE5EC5EA88CA@trammell.ch>
Message-Id: <4149EF8F-C168-4EDA-A0A5-DF00A2F657D4@trammell.ch>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/QKPLM7ASly_5AWAhQOEY5tddSj4>
Subject: Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest)
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, 12 Jul 2021 08:46:08 -0000

Greetings, all,

I managed to automatically post arch-11, but interface-13 gave me a fair amount of trouble. 

Tag push for interface-13 failed due to "arch-11 already exists" (the good old n-drafts-one-repo problem; I suspect we need to do some manual surgery again to bring the TAPS template up to the state of the QUIC template, for which this works now).

I built a local copy of -13.xml, but there seems to be some format drift between my local toolchain and what the datatracker is expecting, since I had to fill in the date metadata manually, which will require a manual posting by the secretariat.

So tl;dr arch-11 (minor tweaks) is in, interface-13 may or may not make the deadline.

Cheers,

Brian

> On 9 Jul 2021, at 14:30, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> 
> Greetings, all,
> 
> As you can see, I finally found time to close out my editorial backlog; thanks Anna, Colin, Gorry for the editorial suggestions!
> 
> While there are a few other discussions ongoing, I expect those will continue at 111 (have fun without me :( ), and I believe we're ready for the pre-111-deadline submission of the drafts. LMK and I'll go ahead and turn the crank for -arch (which has one minor change: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-taps-arch.txt&url2=https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-arch.txt) and -interface (extensive changes, all editorial, including pervasive section renumbering due to restructuring early in the doc).
> 
> Cheers,
> 
> Brian
> 
>> On 9 Jul 2021, at 10:00, TAPS WG status robot <tapsbot@magpie.corvid.ch> wrote:
>> 
>> Friday July 09, 2021
>> 
>> Issues
>> 
>> ietf-tapswg/api-drafts (+0/-25/💬20)
>> 13 issues received 20 new comments:
>> 
>> 	• #852 Using Multicast Endpoints (7 by mwelzl, gorryfair, GrumpyOldTroll) API
>> 	• #865 Should Endpoint Object identifiers be discoverable? (2 by mwelzl, dhobsd) API
>> 	• #864 Are scoped IPv6 address (and zone indexes in particular) supported? (1 by britram) API
>> 	• #800 Remove use of the word TAPS? (1 by britram) API editorial
>> 	• #802 S3.2: Reference to single namespace is unclear (1 by britram) API editorial
>> 	• #811 S4.2.11. Interface Instance or Type - text clarification needed (1 by britram) API editorial
>> 	• #843 Where are events sent? (1 by britram) API editorial
>> 	• #815 S7.3.2.1. - send replies and map responses to their requests (1 by britram) API
>> 	• #753 Nit: Section 3.1: No such protocol… (1 by gorryfair) Implementation editorial
>> 	• #819 EstablishementError or InitiateError? Both names are used. (1 by britram) API editorial
>> 	• #791 be more concrete about receiving (1 by gorryfair) API
>> 	• #672 Perform a final edit pass on all three docs: normalize capitalization/spelling of keywords, formatting, pseudocode syntax, etc. (1 by britram) API Architecture Implementation editorial ready for text
>> 	• #798 S1.1: Definition of Tuple refers to property before it is defined (1 by britram) API editorial
>> 25 issues closed:
>> 
>> 	• #801 S3.1.3 Wrong event handler in code exampe API editorial
>> 	• #846 unified interface to datagram and connection-oriented transports API editorial
>> 	• #753 Nit: Section 3.1: No such protocol… Implementation editorial
>> 	• #738 argh unbreak circleci again
>> 	• #849 API summary does more than summarise API editorial
>> 	• #851 Scope of the Interface Definition API editorial
>> 	• #854 Endpoint aliases and protocols API editorial
>> 	• #843 Where are events sent? API editorial
>> 	• #850 Can we give the tables names in Appendix B? API editorial
>> 	• #819 EstablishementError or InitiateError? Both names are used. API editorial
>> 	• #820 Convenience Functions - options rather than requirements API editorial
>> 	• #814 S7.1.3.3. Ordered - Default seems to point to wrong Selection Property API editorial
>> 	• #817 S7.3.3.1. UDP(-Lite)-specific Property: ECN - Motivation API editorial
>> 	• #807 S4.2.3. What makes Configure Per-Message Reliability special? API editorial
>> 	• #816 S7.3.2.2. ReceivedPartial Example API editorial
>> 	• #813 6. Managing Connections - overlapping bullets API editorial
>> 	• #811 S4.2.11. Interface Instance or Type - text clarification needed API editorial
>> 	• #805 S4.2 Use of recommended API editorial
>> 	• #803 S3.2.2: Enumeration is a basic type so the two bullets do not read correctly API editorial
>> 	• #802 S3.2: Reference to single namespace is unclear API editorial
>> 	• #799 S2. Very long bullets are hard to read API editorial
>> 	• #798 S1.1: Definition of Tuple refers to property before it is defined API editorial
>> 	• #859 When are objects frozen? API Implementation
>> 	• #812 S4.2.14. Multipath Transport - why different? API
>> 	• #800 Remove use of the word TAPS? API editorial
>> Pull requests
>> 
>> ietf-tapswg/api-drafts (+6/-9/💬4)
>> 6 pull requests submitted:
>> 
>> 	• #871 Resolve #872: text disclaiming multicast rendezvous (by GrumpyOldTroll) 
>> 	• #870 editorial rollup number three (by britram) 
>> 	• #869 section refactor (by britram) 
>> 	• #868 More editorial fixes. (by britram) 
>> 	• #867 Many editorial fixes (rollup 1) (by britram) 
>> 	• #866 Preconnections are just structs (by mwelzl) API
>> 3 pull requests received 4 new comments:
>> 
>> 	• #862 Help UDP fit wrt connection (2 by gorryfair, csperkins) Architecture
>> 	• #869 section refactor (1 by britram) 
>> 	• #863 Re-group managing properties & protocol instances (1 by gorryfair) API editorial
>> 9 pull requests merged:
>> 
>> 	• #870 editorial rollup number three
>> 	• #869 section refactor
>> 	• #856 Editorial nits API editorial
>> 	• #868 More editorial fixes.
>> 	• #867 Many editorial fixes (rollup 1)
>> 	• #866 Preconnections are just structs API
>> 	• #857 Fixes #812 API
>> 	• #862 Help UDP fit wrt connection Architecture
>> 	• #863 Re-group managing properties & protocol instances API editorial
>> Repositories tracked by this digest:
>> 
>> 	• https://github.com/ietf-tapswg/api-drafts
>> _______________________________________________
>> 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