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) <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
