Repositories tracked by this digest:

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 2241F120052 for ; Tue, 7 Jan 2020 07:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 DykdHzLtaSDF for ; Tue, 7 Jan 2020 07:51:04 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906A212012E for ; Tue, 7 Jan 2020 07:50:58 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id r14so43013513qke.13 for ; Tue, 07 Jan 2020 07:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=yNhQgBIEh4TTBiKkVFGktSx5jX4ZJVpWlidmgcIo1D4=; b=EX5X9B1EswunguqDfHwG3LE8VD7v4rn44yrVZPNmhJ7Ce7HQ/dePi9MXEH/sfxAz6d +csHsafWGm/YKF3Q7TAjlE6Joz6scwkeLr3q6Dn2GNO10bYWw2NKG6i6kTV0vrihF826 d7o8mfxYAnbh7VDXkU0/47jmmTmMz05BtYIv4KESIDgBirW4myZfdxy87HpXyUo5afwZ V995f5erMPJ5yQHX9wq/RTO8Mmgi4gc8NEF55MUxQchkqFnuJDbB0WizDdrtFWrsBR2E Bs/6PVTjfdpgV0xvjL3tN/hRHv4dbl6BPwhJTdOXIylgz5pSgcQQ3P+1eEp1a0MAi9m4 41NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=yNhQgBIEh4TTBiKkVFGktSx5jX4ZJVpWlidmgcIo1D4=; b=h5JmB5J+XPOhyGJXfikgWx5UX5i+gcWARXiZ3+owFhRsh9OVQtBi3jAncdAlRQDbGu 0ZxhcVDbEWo9+U3TiJhtPKRm2VGzKiHCEWN9st6eKIe5tOS5hYj6fJ4eai4s+8vEgSeV 6csnELUgjJslHNizmzz+/HA008OdmcagNFYUWpKYY9unwP8B0g4t4mrAHxviTxVwCNmy vpmnyNPNiEUoH52qyOcH6aiLuSYDy3qG9UrzY+O3hLGKNGOYHsZ6lQdKAVbhTbQtnRdp WOfUC8HPpUgbmSWlIEO2zw/p+IpgcaA3tLcUTq26V4qagVv+ybBhqLNU1s+rsNsw64DZ 3Jdg== X-Gm-Message-State: APjAAAW/KyMFTawgL6T6zQ/ydY+xULJGARs5WHvWPEdmaae9dSWAm0g7 KQ/VymGM7GPJa8Gi/9S8GSzar/Jqty4= X-Google-Smtp-Source: APXvYqz/g7c7Mcg7tIxdF5hjTHX4yjRpQtfNxvKlGsj7F60kk8udU9HbjULNKxRD+43Aibi1fy7DGw== X-Received: by 2002:a37:8182:: with SMTP id c124mr77765325qkd.165.1578412257306; Tue, 07 Jan 2020 07:50:57 -0800 (PST) Received: from [172.19.115.107] ([2001:4878:a048:3000:8803:c6a:bd69:d259]) by smtp.gmail.com with ESMTPSA id 206sm22504021qkf.132.2020.01.07.07.50.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 07:50:56 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Magnus Westerlund" Date: Tue, 07 Jan 2020 10:50:55 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_126BFAE1-1997-4A35-8D9B-23A0A455019A_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 15:51:09 -0000 --=_MailMate_126BFAE1-1997-4A35-8D9B-23A0A455019A_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit This is notice to open working group last call for “An Architecture for Transport Services”, to conclude January 20, 2020. Please review this document and send comments to the list, preferably with an indication of whether it is ready for publication and, if not, what your concerns are. https://www.ietf.org/id/draft-ietf-taps-arch-06 --aaron TAPS wg co-chair --=_MailMate_126BFAE1-1997-4A35-8D9B-23A0A455019A_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= p dir=3D"auto">This is notice to open working group last call for =E2=80=9C= An Architecture for Transport Services=E2=80=9D, to conclude January 20, = 2020. Please review this document and send comments to the list, prefera= bly with an indication of whether it is ready for publication and, if not= , what your concerns are.

https://www.ietf.org/id/draft-ietf-taps-arch-0= 6

--aaron
TAPS wg co-chair

--=_MailMate_126BFAE1-1997-4A35-8D9B-23A0A455019A_=-- From nobody Sat Jan 11 03:18:53 2020 Return-Path: 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 86FC91200C3 for ; Sat, 11 Jan 2020 03:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 QP4w_wqzUz3D for ; Sat, 11 Jan 2020 03:18:49 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id C3E8C120096 for ; Sat, 11 Jan 2020 03:18:48 -0800 (PST) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7B6801B002A9 for ; Sat, 11 Jan 2020 11:18:45 +0000 (GMT) To: taps WG References: From: Gorry Fairhurst Message-ID: <54a63e55-a02e-00b6-430e-f5dc93a5a2d2@erg.abdn.ac.uk> Date: Sat, 11 Jan 2020 11:18:44 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BD77A69F4A6526683B01CCE3" Content-Language: en-GB Archived-At: Subject: Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 11:18:51 -0000 This is a multi-part message in MIME format. --------------BD77A69F4A6526683B01CCE3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have some minor editorial comments from a careful reading (see below). Best wishses, Gorry (P.S. I'm an editor for this document and I do think the I-D is ready to proceed). --- In Section 2: /The Socket API/ The text uses /sockets/, but previously the text in 2.1 talks about the Socket API. I didn’t see a problem here while we were working on the spec, but I think it world be better is section 2 explicating introduced the word /sockets/ and defined the Socket API as a definition of the sockets method. At least /sockets/ needs to be explained before it is used in Sections 2.1 2.2, 2.3, etc. --- In Section 3.2 /handover or failover for a Connection/ - should this use a lower case letter ‘c’ for connection. This seems to be before the document defines a specific meaning for a TAPS Connection. --- In Title of Figure 4: Title: /The lifetime of a connection/ - I think this does warrant a capital letter ‘C’ for connection? or alternatively a re-wording to say something abstract, like: /The lifetime of a connection in the TAPS archicture/ --- In Section 4.1.1. /A Preconnection object is a representation of a potential connection./ - Does this warrant a capital letter ‘C’ for connection? (if not then I think it should say a /connection to be established? or similar). --- In Section 4.1.2. / requirements around the Maximum Transmission Unit (MTU) or path MTU (PMTU),/ - The example is OK, but the words are not really correct. I don’t think general purpose apps need to know about the local MTU ever, they may care bout the PMTU - but really they care about the maximum packet size they can send along a path. That’s an application-layer quantity, and isn’t related to the ultimate size of packet emitted by an interface. In writing the DPLPMTUD spec we have ben encouraged to make this difference more explicit, and I think TAPS should also not confuse interface limits, network limits and application limits. Packet Size anyway have little bearing on transports that perform message segmentation and are hugely important when they don’t. My suggested text would be: / requirements around the largest packet that can be sent,/ --- In Section 4.2: / A single stack can be simple (a single transport protocol instance over IP), or complex (multiple application protocol streams going through a single security and transport protocol, over IP; or, a multi-path transport protocol over multiple transport sub-flows). / - This has become quite a long and complex sentence! I’d really prefer to use numbers or some way to highlight the two concepts of simple and complex. I don’t know what is best. Another possibility could be to make it even longer, but more clear: / A single stack can be either simple (a single transport protocol instance over IP), or it can be complex (multiple application protocol streams going through a single security and transport protocol, over IP; or, a multi-path transport protocol over multiple transport sub-flows). --- In Section 4.2: Candidate Path: The clause: /, of which there can be several./ appears in bullet two for Candidate Protocol Stack:, but not for Candidate Path. I expect there be multiple candidate paths also in this case, can we add this? --- In Section 4.2: Candidate Protocol Selection /represents the act of choosing one or more sets of protocol stacks/ - why not capitilised /Protocol Stacks/? --- In Section 4.2: Remote Endpoint Racing: /that differ based on the specific representation of the Remote Endpoint, such as IP addresses resolved from a DNS hostname./ - do we have use of singular/plural correct here, or should this be more like: /that differ based on the specific representation of the Remote Endpoint, such as a specific IP address that was resolved from a DNS hostname./ --- In Section 4.2.3: Protocol Stack Equivalence /The Transport Services architecture defines a mechanism that allows applications to easily use different network paths and Protocol Stacks./ - Is this /use/ , i.e. are we talking about how to use these - which looks like just multipath, or is this better as: /The Transport Services architecture defines a mechanism that allows applications to easily communicate when there can be different network paths and Protocol Stacks./ --- In Section 4.2.4: / The interface to specify these groups MAY expose fine-grained tuning for which properties and cached state is allowed to be shared with other Connections. / - I think it would be nice if this sentence actually was self-contained, since it contains a RFC2119 keyword. Perhaps we could say: / The interface to specify a Connection Group MAY expose fine-grained tuning for which properties and cached state is allowed to be shared with other Connections. / --- On 07/01/2020 15:50, Aaron Falk wrote: > > This is notice to open working group last call for “An Architecture > for Transport Services”, to conclude January 20, 2020. Please review > this document and send comments to the list, preferably with an > indication of whether it is ready for publication and, if not, what > your concerns are. > > https://www.ietf.org/id/draft-ietf-taps-arch-06 > > --aaron > TAPS wg co-chair > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------BD77A69F4A6526683B01CCE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I have some minor editorial comments from a careful reading (see below).

Best wishses,

Gorry

(P.S. I'm an editor for this document and I do think the I-D is ready to proceed).

---

In Section 2:
/The Socket API/
The text uses /sockets/, but previously the text in 2.1 talks about the Socket API.
I didn’t see a problem here while we were working on the spec, but I think it world be better is section 2 explicating introduced the word /sockets/ and defined the Socket API as a definition of the sockets method. At least /sockets/ needs to be explained before it is used in Sections 2.1 2.2, 2.3, etc.
---
In Section 3.2
/handover or failover for a Connection/
- should this use a lower case letter ‘c’ for connection. This seems to be before the document defines a specific meaning for a TAPS Connection.
---
In Title of Figure 4:
Title: /The lifetime of a connection/
- I think this does warrant a capital letter ‘C’ for connection? or alternatively a re-wording to say something abstract, like: /The lifetime of a connection in the TAPS archicture/
---
In Section 4.1.1.
/A Preconnection object is a representation of a
potential connection./
- Does this warrant a capital letter ‘C’ for connection? (if not then I think it should say a /connection to be established? or similar).
---
In Section 4.1.2.
/ requirements around the Maximum Transmission Unit (MTU) or path
      MTU (PMTU),/
- The example is OK, but the words are not really correct. I don’t think general purpose apps need to know about the local MTU ever, they may care bout the PMTU - but really they care about the maximum packet size they
can send along a path. That’s an application-layer quantity, and isn’t related to the ultimate size of packet emitted by an interface. In writing the DPLPMTUD spec we have ben encouraged to make this difference more explicit, and I think TAPS should also not confuse interface limits, network limits and application limits. Packet Size anyway have little bearing on transports that perform message segmentation and are hugely important when they don’t.
My suggested text would be:
/ requirements around the largest packet that can be sent,/
---
In Section 4.2:
/ A single stack can be simple (a single transport
      protocol instance over IP), or complex (multiple application
      protocol streams going through a single security and transport
      protocol, over IP; or, a multi-path transport protocol over
      multiple transport sub-flows).
/
- This has become quite a long and complex sentence! I’d really prefer to use numbers or some way to highlight the two concepts of simple and complex. I don’t know what is best. Another possibility could be to make it even longer, but more clear:
/ A single stack can be either simple (a single transport
      protocol instance over IP), or it can be complex (multiple application
      protocol streams going through a single security and transport
      protocol, over IP; or, a multi-path transport protocol over
      multiple transport sub-flows).
---
In Section 4.2: Candidate Path:
The clause:
/, of which there can be several./
appears in bullet two for Candidate Protocol Stack:, but not for Candidate Path. I expect there be multiple candidate paths also in this case, can we add this?
---
In Section 4.2: Candidate Protocol Selection
/represents the act of choosing one or more sets of protocol stacks/
- why not capitilised /Protocol Stacks/?
---
In Section 4.2: Remote Endpoint Racing:
/that differ based on the specific
      representation of the Remote Endpoint, such as IP addresses
      resolved from a DNS hostname./
- do we have use of singular/plural correct here, or should this be more like:
/that differ based on the specific
      representation of the Remote Endpoint, such as a
      specific IP address that was
      resolved from a DNS hostname./
---
In Section 4.2.3: Protocol Stack Equivalence
/The Transport Services architecture defines a mechanism that allows
   applications to easily use different network paths and Protocol
   Stacks./
- Is this /use/ , i.e. are we talking about how to use these - which looks
like just multipath, or is this better as:
/The Transport Services architecture defines a mechanism that allows
   applications to easily communicate when there can be different network paths and Protocol Stacks./
---
In Section 4.2.4:
/   The interface to specify these groups MAY expose fine-grained tuning
   for which properties and cached state is allowed to be shared with
   other Connections. /
- I think it would be nice if this sentence actually was self-contained, since it contains a RFC2119 keyword. Perhaps we could say:
/   The interface to specify a Connection Group MAY expose fine-grained tuning for which properties and cached state is allowed to be shared with   other Connections. /
---

On 07/01/2020 15:50, Aaron Falk wrote:

This is notice to open working group last call for “An Architecture for Transport Services”, to conclude January 20, 2020. Please review this document and send comments to the list, preferably with an indication of whether it is ready for publication and, if not, what your concerns are.

https://www.ietf.org/id/draft-ietf-taps-arch-06

--aaron
TAPS wg co-chair
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--------------BD77A69F4A6526683B01CCE3-- From nobody Tue Jan 14 13:25:02 2020 Return-Path: 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 8D1F8120113 for ; Tue, 14 Jan 2020 13:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, 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 fjPpxk3MpdRw for ; Tue, 14 Jan 2020 13:24:58 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 F3710120110 for ; Tue, 14 Jan 2020 13:24:57 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00EKw9aV063069; Tue, 14 Jan 2020 13:24:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=1K6JevexIA7PSjLhVIonYwd4fSeALwIiItZM+u/YDGI=; b=KKGWHfoKQwxHNmTLrXzHzsFeMgd14uhlAaFz25ICBHo+us1ABTTG0MC4FyHcNszX1jlx 0J/vXfDuSYzdBa2IEAy6bIB8EWQnm3sD2Sy5Busn2ehpJwYTKGBprWCbNJNZaLzgIYZt JQjfG0yg6pXLOkRC8Zpthf9Pi51+2QdHMD+1OPCpUpBaxybAC7vLuhZaBfwWZfDNBf+G zN+Ql6wtmyp68G3VYJX2uIcWlNY2CPmhVdynX65bVn8mQc2qg2pbiLsCcqcztlDiNAVT gAnnDHSx1uSMCyhDtEtWRl4hrtFm4s/N8MSTy+9iO9HqlCUhJldg0XjZJzZT1VOG9GZ9 HQ== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2xfbwx7phw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Jan 2020 13:24:53 -0800 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4400AU28TGUR20@ma1-mtap-s02.corp.apple.com>; Tue, 14 Jan 2020 13:24:53 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q44006008QDED00@nwk-mmpp-sz09.apple.com>; Tue, 14 Jan 2020 13:24:52 -0800 (PST) X-Va-A: X-Va-T-CD: ee4b87190de6b996ba9548e5d106c4a1 X-Va-E-CD: 7ab32942004e63dd1658bc6284e88af9 X-Va-R-CD: 73e6ba5e086520a60639d5438b467781 X-Va-CD: 0 X-Va-ID: 02353580-bbb0-4801-a499-051174667861 X-V-A: X-V-T-CD: ee4b87190de6b996ba9548e5d106c4a1 X-V-E-CD: 7ab32942004e63dd1658bc6284e88af9 X-V-R-CD: 73e6ba5e086520a60639d5438b467781 X-V-CD: 0 X-V-ID: ff855435-78fb-44f8-9441-e2d3454bd5a8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-14_06:,, signatures=0 Received: from [17.234.71.35] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4400E968T76U30@nwk-mmpp-sz09.apple.com>; Tue, 14 Jan 2020 13:24:50 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_C925A3DF-BD41-49E7-97DB-798F4D9DBAB1" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Tue, 14 Jan 2020 13:24:40 -0800 In-reply-to: <54a63e55-a02e-00b6-430e-f5dc93a5a2d2@erg.abdn.ac.uk> Cc: taps WG To: Gorry Fairhurst References: <54a63e55-a02e-00b6-430e-f5dc93a5a2d2@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-14_06:, , signatures=0 Archived-At: Subject: Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 21:25:01 -0000 --Apple-Mail=_C925A3DF-BD41-49E7-97DB-798F4D9DBAB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Gorry, Thanks for the comments! I've created a pull request here: = https://github.com/ietf-tapswg/api-drafts/pull/411 I am including comments inline to respond to the individual points. Best, Tommy > On Jan 11, 2020, at 3:18 AM, Gorry Fairhurst = wrote: >=20 > I have some minor editorial comments from a careful reading (see = below). >=20 > Best wishses, >=20 > Gorry >=20 > (P.S. I'm an editor for this document and I do think the I-D is ready = to proceed). >=20 > --- >=20 > In Section 2: > /The Socket API/ > The text uses /sockets/, but previously the text in 2.1 talks about = the Socket API.=20 > I didn=E2=80=99t see a problem here while we were working on the spec, = but I think it world be better is section 2 explicating introduced the = word /sockets/ and defined the Socket API as a definition of the sockets = method. At least /sockets/ needs to be explained before it is used in = Sections 2.1 2.2, 2.3, etc. >=20 The "BSD Socket" interface and "socket" in general is described in the = first paragraph of the Introduction. That seems to introduce the notion = early enough. Let me know if you don't feel that is sufficient. > --- > In Section 3.2 > /handover or failover for a Connection/ > - should this use a lower case letter =E2=80=98c=E2=80=99 for = connection. This seems to be before the document defines a specific = meaning for a TAPS Connection. >=20 Made this lowercase. > --- > In Title of Figure 4:=20 > Title: /The lifetime of a connection/ > - I think this does warrant a capital letter =E2=80=98C=E2=80=99 for = connection? or alternatively a re-wording to say something abstract, = like: /The lifetime of a connection in the TAPS archicture/ >=20 Made this "The lifetime of a Connection object", to match the other = text. > --- > In Section 4.1.1. > /A Preconnection object is a representation of a > potential connection./ > - Does this warrant a capital letter =E2=80=98C=E2=80=99 for = connection? (if not then I think it should say a /connection to be = established? or similar). >=20 Used "Connection" here and in other places in this paragraph. > --- > In Section 4.1.2. > / requirements around the Maximum Transmission Unit (MTU) or path > MTU (PMTU),/ > - The example is OK, but the words are not really correct. I don=E2=80=99= t think general purpose apps need to know about the local MTU ever, they = may care bout the PMTU - but really they care about the maximum packet = size they > can send along a path. That=E2=80=99s an application-layer quantity, = and isn=E2=80=99t related to the ultimate size of packet emitted by an = interface. In writing the DPLPMTUD spec we have ben encouraged to make = this difference more explicit, and I think TAPS should also not confuse = interface limits, network limits and application limits. Packet Size = anyway have little bearing on transports that perform message = segmentation and are hugely important when they don=E2=80=99t. > My suggested text would be: > / requirements around the largest packet that can be sent,/ >=20 Used "requirements around the largest Message that can be sent," > --- > In Section 4.2: > / A single stack can be simple (a single transport > protocol instance over IP), or complex (multiple application > protocol streams going through a single security and transport > protocol, over IP; or, a multi-path transport protocol over > multiple transport sub-flows). > / > - This has become quite a long and complex sentence! I=E2=80=99d = really prefer to use numbers or some way to highlight the two concepts = of simple and complex. I don=E2=80=99t know what is best. Another = possibility could be to make it even longer, but more clear: > / A single stack can be either simple (a single transport > protocol instance over IP), or it can be complex (multiple = application > protocol streams going through a single security and transport > protocol, over IP; or, a multi-path transport protocol over > multiple transport sub-flows). >=20 Used your suggested text! > --- > In Section 4.2: Candidate Path: > The clause: > /, of which there can be several./=20 > appears in bullet two for Candidate Protocol Stack:, but not for = Candidate Path. I expect there be multiple candidate paths also in this = case, can we add this? > --- > In Section 4.2: Candidate Protocol Selection > /represents the act of choosing one or more sets of protocol stacks/ > - why not capitilised /Protocol Stacks/? >=20 Capitalized as suggested. > --- > In Section 4.2: Remote Endpoint Racing:=20 > /that differ based on the specific > representation of the Remote Endpoint, such as IP addresses > resolved from a DNS hostname./ > - do we have use of singular/plural correct here, or should this be = more like: > /that differ based on the specific > representation of the Remote Endpoint, such as a > specific IP address that was > resolved from a DNS hostname./ >=20 Used the suggested text. > --- > In Section 4.2.3: Protocol Stack Equivalence > /The Transport Services architecture defines a mechanism that allows > applications to easily use different network paths and Protocol > Stacks./ > - Is this /use/ , i.e. are we talking about how to use these - which = looks > like just multipath, or is this better as: > /The Transport Services architecture defines a mechanism that allows > applications to easily communicate when there can be different = network paths and Protocol Stacks./ >=20 I'm not sure if "communicate when there can be different network paths" = is clearer here. Would receives the communication? I think it is indeed "use": not just multipath, but in terms of sending = packets for racing, etc. > --- > In Section 4.2.4: > / The interface to specify these groups MAY expose fine-grained = tuning > for which properties and cached state is allowed to be shared with > other Connections. / > - I think it would be nice if this sentence actually was = self-contained, since it contains a RFC2119 keyword. Perhaps we could = say: > / The interface to specify a Connection Group MAY expose = fine-grained tuning for which properties and cached state is allowed to = be shared with other Connections. / > --- >=20 Fixed as suggested! >=20 >=20 > On 07/01/2020 15:50, Aaron Falk wrote: >> This is notice to open working group last call for =E2=80=9CAn = Architecture for Transport Services=E2=80=9D, to conclude January 20, = 2020. Please review this document and send comments to the list, = preferably with an indication of whether it is ready for publication = and, if not, what your concerns are. >>=20 >> https://www.ietf.org/id/draft-ietf-taps-arch-06 = >> --aaron >> TAPS wg co-chair >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_C925A3DF-BD41-49E7-97DB-798F4D9DBAB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Gorry,

Thanks for = the comments! I've created a pull request here: https://github.com/ietf-tapswg/api-drafts/pull/411

I am including = comments inline to respond to the individual points.

Best,

Tommy

On Jan 11, 2020, at 3:18 AM, = Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

=20 =20
I have some minor editorial comments = from a careful reading (see below).

Best wishses,
Gorry
(P.S. I'm an editor for this document and I do think the I-D = is ready to proceed).
---

In Section 2:
/The Socket API/
The text uses /sockets/, but previously the text in 2.1 talks about the Socket API.
I didn=E2=80=99t see a problem here while we were working on the = spec, but I think it world be better is section 2 explicating introduced the word /sockets/ and defined the Socket API as a definition of the sockets method. At least /sockets/ needs to be explained before it is used in Sections 2.1 2.2, 2.3, etc.

The "BSD Socket" interface = and "socket" in general is described in the first paragraph of the = Introduction. That seems to introduce the notion early enough. Let me = know if you don't feel that is sufficient.

---
In Section 3.2
/handover or failover for a Connection/
- should this use a lower case letter =E2=80=98c=E2=80=99 for = connection. This seems to be before the document defines a specific meaning for a TAPS Connection.

Made this = lowercase.

---
In Title of Figure 4:
Title: /The lifetime of a connection/
- I think this does warrant a capital letter =E2=80=98C=E2=80=99 = for connection? or alternatively a re-wording to say something abstract, like: /The lifetime of a connection in the TAPS archicture/

Made this "The lifetime of = a Connection object", to match the other text.

---
In Section 4.1.1.
/A Preconnection object is a representation of a
potential connection./
- Does this warrant a capital letter =E2=80=98C=E2=80=99 for = connection? (if not then I think it should say a /connection to be established? or similar).

Used "Connection" here and = in other places in this paragraph.

---
In Section 4.1.2.
/ requirements around the Maximum Transmission Unit (MTU) or = path
MTU (PMTU),/
- The example is OK, but the words are not really correct. I = don=E2=80=99t think general purpose apps need to know about the local MTU ever, they may care bout the PMTU - but really they care about the maximum packet size they
can send along a path. That=E2=80=99s an application-layer = quantity, and isn=E2=80=99t related to the ultimate size of packet emitted by an interface. In writing the DPLPMTUD spec we have ben encouraged to make this difference more explicit, and I think TAPS should also not confuse interface limits, network limits and application limits. Packet Size anyway have little bearing on transports that perform message segmentation and are hugely important when they don=E2=80=99t.
My suggested text would be:
/ requirements around the largest packet that can be = sent,/

Used "requirements around the largest = Message that can be sent,"

---
In Section 4.2:
/ A single stack can be simple (a single transport
      protocol instance over IP), or = complex (multiple application
      protocol streams going through a = single security and transport
      protocol, over IP; or, a multi-path = transport protocol over
      multiple transport sub-flows).
/
- This has become quite a long and complex sentence! I=E2=80=99d = really prefer to use numbers or some way to highlight the two concepts of simple and complex. I don=E2=80=99t know what is best. Another = possibility could be to make it even longer, but more clear:
/ A single stack can be either simple (a single transport
      protocol instance over IP), or it = can be complex (multiple application
      protocol streams going through a = single security and transport
      protocol, over IP; or, a multi-path = transport protocol over
      multiple transport sub-flows).

Used your suggested = text!

---
In Section 4.2: Candidate Path:
The clause:
/, of which there can be several./
appears in bullet two for Candidate Protocol Stack:, but not for Candidate Path. I expect there be multiple candidate paths also in this case, can we add this?
---
In Section 4.2: Candidate Protocol Selection
/represents the act of choosing one or more sets of protocol stacks/
- why not capitilised /Protocol Stacks/?

Capitalized as = suggested.

---
In Section 4.2: Remote Endpoint Racing:
/that differ based on the specific
      representation of the Remote = Endpoint, such as IP addresses
      resolved from a DNS hostname./
- do we have use of singular/plural correct here, or should this be more like:
/that differ based on the specific
      representation of the Remote = Endpoint, such as a
      specific IP address that was
      resolved from a DNS hostname./

Used the suggested = text.

---
In Section 4.2.3: Protocol Stack Equivalence
/The Transport Services architecture defines a mechanism that allows
   applications to easily use different network paths = and Protocol
   Stacks./
- Is this /use/ , i.e. are we talking about how to use these - which looks
like just multipath, or is this better as:
/The Transport Services architecture defines a mechanism that allows
   applications to easily communicate when there can be = different network paths and Protocol Stacks./

I'm not sure if = "communicate when there can be different network paths" is clearer here. = Would receives the communication?

I think it is indeed "use": = not just multipath, but in terms of sending packets for racing, = etc.

---
In Section 4.2.4:
/   The interface to specify these groups MAY expose = fine-grained tuning
   for which properties and cached state is allowed to = be shared with
   other Connections. /
- I think it would be nice if this sentence actually was self-contained, since it contains a RFC2119 keyword. Perhaps we could say:
/   The interface to specify a Connection Group MAY = expose fine-grained tuning for which properties and cached state is allowed to be shared with   other Connections. /
---

Fixed as suggested!

On 07/01/2020 15:50, Aaron Falk = wrote:
This is notice to open working group last call for =E2=80=9CAn Architecture for Transport Services=E2=80=9D, = to conclude January 20, 2020. Please review this document and send comments to the list, preferably with an indication of whether it is ready for publication and, if not, what your concerns are.
https://www.ietf.org/id/draft-ietf-taps-arch-06
--aaron
TAPS wg co-chair
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/m=
ailman/listinfo/taps
_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_C925A3DF-BD41-49E7-97DB-798F4D9DBAB1-- From nobody Wed Jan 15 07:24:15 2020 Return-Path: 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 34D951200C3 for ; Wed, 15 Jan 2020 07:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 d1lrCfSya4Uv for ; Wed, 15 Jan 2020 07:23:24 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80070.outbound.protection.outlook.com [40.107.8.70]) (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 D9609120090 for ; Wed, 15 Jan 2020 07:23:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ptit3lqdqUxauG++pUcHpH9xmuBGi1kTA974XvUW9NfgoGbbJRfwtbzxuhpUeC6c2VYRkHSjfZzNSOdqoGXtwxhWFuxtJQR6hh4usJPAgkMPMiMbBBtT6OjqFDfae/lQ0lrg8fp8+/GAFDToxsATq5WFTyJBE8vBkiCZK95dLbfg7CZnZLagkTfxbfDcC+ldd+ok7W01+TW2jEFBjcdhSdHhXFjG9QGLVOVO1OhLRaBt8dftVIVgMHRRughgBmNvIzb22o5Gg1qM9d4KWx9Hae59WVZvtj7ieNn5PsSF7xMMW4pLByiYjzbt3h2Eg6giGnCxPxEjHDfdrjKAXXjH1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XZ7Im3jUorDmVD5jq8BRli1Z8+U/pWfk/Lcn7j+2ZIY=; b=harThCH4pXbQWuqR6sUeaIFWzp7OXMjmEgp+dxquBlNLkENRba5Jmt9lpjuJyZXcqNVIse4WmlfFPO1nnk6UE3RTUEUFLMcZJTtVLgluxOfzDUH+cEnMYyL+DBDNBkUwvO5CHk3D3pxSsl8eEUT+dN8b3biV4aCkKZeGLdNQE0+HfU3fYEhGAIZcFphXQz54Cvpagt2knCUXMjzVUbADBG/8uWC+7w6SwgJsTzndYgJGLctz0Y7vzhG/M/+APJZFkZBxaxBM68DY91Jofqkn+IYebfT+8VgDJSQmFX3xI7zSZmzenSIA9vwqbhDwX3mKrpx7P1hckHGv6ksWyLwBpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XZ7Im3jUorDmVD5jq8BRli1Z8+U/pWfk/Lcn7j+2ZIY=; b=KoqWR7exbA2iTdo+0DD2D7eGQ8LFPjJ2LA+Zq+LEkp2B54b4X+EaWhOO/3yITjIRP0Bq3qReU5RvFE/pF0XxV+d5HGpp6N7rb97NhP98p4mPq8EdYkRC/dklcTIm3f+MGiancbCYzau88HjFkGJav/W32jZNYThQXX313xxD3pw= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6275.eurprd07.prod.outlook.com (10.186.173.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.6; Wed, 15 Jan 2020 15:23:21 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7%7]) with mapi id 15.20.2644.015; Wed, 15 Jan 2020 15:23:21 +0000 From: Mirja Kuehlewind To: taps WG CC: Magnus Westerlund , Zaheduzzaman Sarker , Aaron Falk Thread-Topic: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) Thread-Index: AQHVxXJX7ZLOQTOArkSWLoHEY4Jxlqfr9U+A Date: Wed, 15 Jan 2020 15:23:21 +0000 Message-ID: <02CDE084-00C9-403F-A4AC-7ECE9E608E78@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [129.192.10.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a25d52fa-2953-4fad-5383-08d799cedb2c x-ms-traffictypediagnostic: AM0PR07MB6275:|AM0PR07MB6275: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(346002)(396003)(376002)(136003)(189003)(199004)(8936002)(6506007)(478600001)(2906002)(6512007)(64756008)(66556008)(86362001)(53546011)(91956017)(66446008)(26005)(6916009)(5660300002)(2616005)(4326008)(36756003)(44832011)(54906003)(81156014)(71200400001)(33656002)(66476007)(186003)(81166006)(966005)(316002)(76116006)(6486002)(66946007)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6275; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y2lTL/4SKxcwS9kxO84EWaOe3/oE9t6df3mRUYjDBDrHxKODC/fWZp1wSWWqjzeH9A1BBNaTnXqZu46cJDGYfw3dx8ARwnPVgw6ExegsTR5keGg6+giSijo75H/B9Qi+nGX20tFhRHxgTcG5bYcDmJeTK8cH1Jz97NEMwngy18Mv6hzhqtFY7Mng0mt1Y8iub44cqP/lAIg1KS0y7TRagD+VDSoCQTsqiWuC3bwSIA6oTa3eWpKz0agyjgo7bujEmPiTHPbOyjLBAHtfqegNrPFiiwxPUrxyJo1E7u9wtSnWN8gFP4C+SZEsXa65i+Z35DhbfkxyZ9VpJb9iFNP+TQiLmeNO3JruyN2SgrObDijaNQ6rf913NDZGfUzjXz4+6x+hMjZE1Ak/Qp/Citwr/zoElkdXB1pvkECidPI+isBfeQik+SjGR0GgBbHxttzWc8zhLxzAVSKeRPfe9anbji5SOMQM63AXEHZCY+OUMyU= Content-Type: multipart/alternative; boundary="_000_02CDE08400C9403FA4AC7ECE9E608E78ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a25d52fa-2953-4fad-5383-08d799cedb2c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 15:23:21.4773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TDYGEPIz38iW9ZJ4jhop3cAWd2+N9WBNeD931odWgnemWzRT02lujWi/kMcV6SGp+VsgwWLfIUS97ZWzCSIaFmK+0vlRohD0ptbIiew28Jg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6275 Archived-At: Subject: Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 15:23:29 -0000 --_000_02CDE08400C9403FA4AC7ECE9E608E78ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHJldmlld2VkIHRoZSBkcmFmdCBhZ2FpbiBhbmQgdGhpbmsgaXTigJhzIHJl YWR5IGZvciBwdWJsaWNhdGlvbiEgVGhhbmtzIGV2ZXJ5Ym9keSBmb3IgYWxsIHRoZSB3b3JrIGFu ZCB0aGlzIHdlbGwtd3JpdHRlbiBkb2N1bWVudCENCg0KQXMgb25lcyBkb2VzIHdoZW4gcmV2aWV3 aW5nIGEgZG9jLCBJIGRpZCBvcGVuIGEgZmV3IHNtYWxsIGlzc3VlcyBvbiBnaXRodWIuIEkgdGhp bmsgbW9zdCBvZiB0aGVtIGFyZSBub3RoaW5nIGJpZyBhbmQgY291bGQgZW5kIHVwIGluIGFkZGlu ZyBhIHNlbnRlbmNlIGhlcmUgYW5kIHRoZXJlIG9yIG5vdC4NCg0KSG93ZXZlciwgSSB0aGluayB0 aGVyZSBpcyBvbmUgdGhpbmcgd2UgbmVlZCB0byBkZWNpZGUgYmVmb3JlIHdlIGZpbmFsbHkgbW92 ZSBvbiBhbmQgdGhhdOKAmXMgdGhlIGFsd2F5cyBleGNpdGluZyBxdWVzdGlvbiBhYm91dCB1c2Ug b2Ygbm9ybWF0aXZlIGxhbmd1YWdlLiBJIHRoaW5rIGN1cnJlbnRseSB3ZSBkb27igJl0IHVzZSBu b3JtYXRpdmVseSBsYW5ndWFnZSB2ZXJ5IGNvbnNpc3RlbnRseS4gU28gZWl0aGVyIHdlIG1ha2Ug YSBwYXNzIGFuZCBhZGQgc29tZSBtb3JlIE1VU1RzLCBTSE9VTERzLCBhbmQgTUFZcyBvciB3ZSBk ZWNpZGUgdG8gbm90IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgYXQgYWxsLiBJIGFsc28gb3BlbmVk IGFuIGlzc3VlIGZvciB0aGF0LCBzbyB5b3UgY2FuIGFsc28gY29tbWVudCB0aGVyZSBpcyB5b3Ug cHJlZmVyIQ0KDQpNaXJqYQ0KDQoNCkZyb206IFRhcHMgPHRhcHMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIEFhcm9uIEZhbGsgPGFhcm9uLmZhbGtAZ21haWwuY29tPg0KRGF0ZTogVHVl c2RheSwgNy4gSmFudWFyeSAyMDIwIGF0IDE2OjUxDQpUbzogdGFwcyBXRyA8dGFwc0BpZXRmLm9y Zz4NCkNjOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t PiwgWmFoZWR1enphbWFuIFNhcmtlciA8emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20+ DQpTdWJqZWN0OiBbVGFwc10gV0dMQyBmb3IgZHJhZnQtaWV0Zi10YXBzLWFyY2ggKEphbiA3LTIw LCAyMDIwKQ0KDQoNClRoaXMgaXMgbm90aWNlIHRvIG9wZW4gd29ya2luZyBncm91cCBsYXN0IGNh bGwgZm9yIOKAnEFuIEFyY2hpdGVjdHVyZSBmb3IgVHJhbnNwb3J0IFNlcnZpY2Vz4oCdLCB0byBj b25jbHVkZSBKYW51YXJ5IDIwLCAyMDIwLiBQbGVhc2UgcmV2aWV3IHRoaXMgZG9jdW1lbnQgYW5k IHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QsIHByZWZlcmFibHkgd2l0aCBhbiBpbmRpY2F0aW9u IG9mIHdoZXRoZXIgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFuZCwgaWYgbm90LCB3aGF0 IHlvdXIgY29uY2VybnMgYXJlLg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXRhcHMtYXJjaC0wNg0KDQotLWFhcm9uDQpUQVBTIHdnIGNvLWNoYWlyDQo= --_000_02CDE08400C9403FA4AC7ECE9E608E78ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <1BC7CCA45B5E464FB6B7D856409B4D0E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHJldmlld2VkIHRoZSBkcmFmdCBhZ2Fp biBhbmQgdGhpbmsgaXTigJhzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiEgVGhhbmtzIGV2ZXJ5Ym9k eSBmb3IgYWxsIHRoZSB3b3JrIGFuZCB0aGlzIHdlbGwtd3JpdHRlbiBkb2N1bWVudCE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBvbmVzIGRvZXMgd2hlbiByZXZpZXdpbmcgYSBk b2MsIEkgZGlkIG9wZW4gYSBmZXcgc21hbGwgaXNzdWVzIG9uIGdpdGh1Yi4gSSB0aGluayBtb3N0 IG9mIHRoZW0gYXJlIG5vdGhpbmcgYmlnIGFuZCBjb3VsZCBlbmQgdXAgaW4gYWRkaW5nIGEgc2Vu dGVuY2UgaGVyZSBhbmQgdGhlcmUgb3Igbm90Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SG93ZXZlciwgSSB0aGluayB0aGVyZSBpcyBvbmUgdGhpbmcgd2UgbmVlZCB0byBkZWNp ZGUgYmVmb3JlIHdlIGZpbmFsbHkgbW92ZSBvbiBhbmQgdGhhdOKAmXMgdGhlIGFsd2F5cyBleGNp dGluZyBxdWVzdGlvbiBhYm91dCB1c2Ugb2Ygbm9ybWF0aXZlIGxhbmd1YWdlLiBJIHRoaW5rIGN1 cnJlbnRseSB3ZSBkb27igJl0IHVzZQ0KIG5vcm1hdGl2ZWx5IGxhbmd1YWdlIHZlcnkgY29uc2lz dGVudGx5LiBTbyBlaXRoZXIgd2UgbWFrZSBhIHBhc3MgYW5kIGFkZCBzb21lIG1vcmUgTVVTVHMs IFNIT1VMRHMsIGFuZCBNQVlzIG9yIHdlIGRlY2lkZSB0byBub3QgdXNlIG5vcm1hdGl2ZSBsYW5n dWFnZSBhdCBhbGwuIEkgYWxzbyBvcGVuZWQgYW4gaXNzdWUgZm9yIHRoYXQsIHNvIHlvdSBjYW4g YWxzbyBjb21tZW50IHRoZXJlIGlzIHlvdSBwcmVmZXIhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+TWlyamE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRhcHMgJmx0O3RhcHMtYm91bmNlc0BpZXRm Lm9yZyZndDsgb24gYmVoYWxmIG9mIEFhcm9uIEZhbGsgJmx0O2Fhcm9uLmZhbGtAZ21haWwuY29t Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCA3LiBKYW51YXJ5IDIwMjAgYXQgMTY6NTE8 YnI+DQo8Yj5UbzogPC9iPnRhcHMgV0cgJmx0O3RhcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj5NYWdudXMgV2VzdGVybHVuZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t Jmd0OywgWmFoZWR1enphbWFuIFNhcmtlciAmbHQ7emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nv bi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltUYXBzXSBXR0xDIGZvciBkcmFmdC1pZXRm LXRhcHMtYXJjaCAoSmFuIDctMjAsIDIwMjApPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgbm90aWNlIHRvIG9wZW4gd29ya2luZyBncm91cCBsYXN0 IGNhbGwgZm9yIOKAnEFuIEFyY2hpdGVjdHVyZSBmb3IgVHJhbnNwb3J0IFNlcnZpY2Vz4oCdLCB0 byBjb25jbHVkZSBKYW51YXJ5IDIwLCAyMDIwLiBQbGVhc2UgcmV2aWV3IHRoaXMgZG9jdW1lbnQg YW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QsDQogcHJlZmVyYWJseSB3aXRoIGFuIGluZGlj YXRpb24gb2Ygd2hldGhlciBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYW5kLCBpZiBub3Qs IHdoYXQgeW91ciBjb25jZXJucyBhcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWlldGYtdGFwcy1hcmNoLTA2Ij48c3BhbiBzdHlsZT0iY29sb3I6IzM5ODNDNCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi10YXBzLWFyY2gtMDY8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tLWFhcm9uPGJyPg0K VEFQUyB3ZyBjby1jaGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_02CDE08400C9403FA4AC7ECE9E608E78ericssoncom_-- From nobody Fri Jan 17 00:02:31 2020 Return-Path: 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 35531120273 for ; Fri, 17 Jan 2020 00:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 V8GPHyARoaso for ; Fri, 17 Jan 2020 00:02:22 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 16595120812 for ; Fri, 17 Jan 2020 00:02:21 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1isMY7-00035f-0E for taps@ietf.org; Fri, 17 Jan 2020 08:00:11 +0000 Content-Type: multipart/alternative; boundary="===============9217148469881607205==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 17 Jan 2020 08:00:11 +0000 Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 08:02:29 -0000 --===============9217148469881607205== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+22/-0/=F0=9F=92=AC23) 22 issues created: - Message size (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/443 = - Questions on Connection Groups (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/441 = - Why do we use functions to set security parameters... (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/440 = - Retransmit notify (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/438 [API] = - Configuring MP use (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/437 = - Local Address Preference always only preferred? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/436 = - Default values for Interface Instance and PvD (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/435 = - type of properties (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/434 = - section algorithm (text in API doc) (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/429 [API] = - API, sec 5: SHOULD add Framers (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/427 = - Syntax Preconnection (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/426 = - Where to define Connection Group? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/420 [Architecture] [ed= itorial] = - Acknowledgements in Arch (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/419 [Architecture] = - Use of normative language in Arch (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/418 [Architecture] = - Add Framer to Figure 4? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/417 = - add example for "information about the received Message"? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/416 [Architecture] = - Is the Local Endpoint "optional"? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/414 = - Do we need to say more about authentication and encryption? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/413 = - API: Specifying local interfaces as Local Endpoint VS. as a Selection P= roperty (by theri) https://github.com/ietf-tapswg/api-drafts/issues/410 = - Security: Connection and Post-Connection Interfaces (by theri) https://github.com/ietf-tapswg/api-drafts/issues/409 = - Minor issues with Message Contexts (by theri) https://github.com/ietf-tapswg/api-drafts/issues/408 = - Event handlers: MUST they always be registered? (or else..?) (by mwelz= l) https://github.com/ietf-tapswg/api-drafts/issues/404 [API] = 12 issues received 23 new comments: - #404 Event handlers: MUST they always be registered? (or else..?) (6 b= y mwelzl, csperkins, philsbln, theagilepadawan, tfpauly, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/404 [API] = - #429 section algorithm (text in API doc) (3 by mirjak, gorryfair, theri) https://github.com/ietf-tapswg/api-drafts/issues/429 [API] = - #443 Message size (3 by mirjak, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/443 = - #438 Retransmit notify (2 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/438 [API] = - #414 Is the Local Endpoint "optional"? (2 by mirjak, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/414 [Architecture] = - #417 Add Framer to Figure 4? (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/417 = - #418 Use of normative language in Arch (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/418 [Architecture] = - #426 Syntax Preconnection (1 by theri) https://github.com/ietf-tapswg/api-drafts/issues/426 [API] = - #398 Per-protocol behavior needs to be normative (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/398 [Implementation] = - #434 type of properties (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/434 [API] = - #222 Reusing Preconnections? (1 by theri) https://github.com/ietf-tapswg/api-drafts/issues/222 [API] [ready for t= ext] = - #440 Why do we use functions to set security parameters... (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/440 = Pull requests ------------- * ietf-tapswg/api-drafts (+19/-9/=F0=9F=92=AC6) 19 pull requests submitted: - Add one more pointer to Framers (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/442 = - Boolean property can not be set to Ignore (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/439 = - Editorial nits to improve consistency (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/433 = - "must provide sensible defaults" (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/432 = - More MAYs? (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/431 = - Too many commas (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/430 = - Local/Remote Endpoint type or Object? (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/428 = - Normative language for property namespace (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/425 = - Protocol Specific Properties are not well defined (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/424 = - editorial: be more concrete about phases in Arch doc (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/423 = - minor edit to sec 4 (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/422 = - Proposed alternative intro text for API doc (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/421 = - nit - "within a message" twice (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/415 = - Add one sentence about fallback in sec 2.3 (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/412 = - Address on Gorry's WGLC comments (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/411 [Architecture] = - API draft: Replace "Protocol Properties" with updated terms (by theri) https://github.com/ietf-tapswg/api-drafts/pull/407 = - Add a reference to DPLPMTUD for Message Size before fragmentation (by a= dventureloop) https://github.com/ietf-tapswg/api-drafts/pull/406 = - API draft: Minor fixes (by theri) https://github.com/ietf-tapswg/api-drafts/pull/405 = - Some small proposed fixes (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/403 = 3 pull requests received 6 new comments: - #432 "must provide sensible defaults" (3 by mirjak, abrunstrom, mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/432 [API] = - #421 Proposed alternative intro text for API doc (2 by abrunstrom, mwel= zl) https://github.com/ietf-tapswg/api-drafts/pull/421 [API] = - #425 Normative language for property namespace (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/425 [API] = 9 pull requests merged: - editorial: be more concrete about phases in Arch doc https://github.com/ietf-tapswg/api-drafts/pull/423 [API] = - Boolean property can not be set to Ignore https://github.com/ietf-tapswg/api-drafts/pull/439 = - minor edit to sec 4 https://github.com/ietf-tapswg/api-drafts/pull/422 [API] = - Add a reference to DPLPMTUD for Message Size before fragmentation https://github.com/ietf-tapswg/api-drafts/pull/406 [API] = - API draft: Replace "Protocol Properties" with updated terms https://github.com/ietf-tapswg/api-drafts/pull/407 [API] = - API draft: Minor fixes https://github.com/ietf-tapswg/api-drafts/pull/405 [API] = - Too many commas https://github.com/ietf-tapswg/api-drafts/pull/430 [API] = - nit - "within a message" twice https://github.com/ietf-tapswg/api-drafts/pull/415 [Architecture] = - Address on Gorry's WGLC comments https://github.com/ietf-tapswg/api-drafts/pull/411 [Architecture] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============9217148469881607205== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday January 17, 2020

Issues

ietf-tapswg/api-drafts (+22/-0/=F0=9F=92=AC23)

22 issues created:

#443 Message size (by mirjak)
#441 Questions on Connection Groups (by mirjak)
#440 Why do we use functions to set security parameters... (by mirjak)
#438 Retransmit notify (by mirjak) API
#437 Configuring MP use (by mirjak)
#436 Local Address Preference always only preferred? (by mirjak)
#435 Default values for Interface Instance and PvD (by mirjak)
#434 type of properties (by mirjak)
#429 section algorithm (text in API doc) (by mirjak) API
#427 API, sec 5: SHOULD add Framers (by mirjak)
#426 Syntax Preconnection (by mirjak)
#420 Where to define Connection Group? (by mirjak) Architecture editor= ial
#419 Acknowledgements in Arch (by mirjak) Architecture
#418 Use of normative language in Arch (by mirjak) Architecture
#417 Add Framer to Figure 4? (by mirjak)
#416 add example for "information about the received Message"? (b= y mirjak) Architecture
#414 Is the Local Endpoint "optional"? (by mirjak)
#413 Do we need to say more about authentication and encryption? (by mirjak= )
#410 API: Specifying local interfaces as Local Endpoint VS. as a Selection Prop= erty (by theri)
#409 Security: Connection and Post-Connection Interfaces (by theri)
#408 Minor issues with Message Contexts (by theri)
#404 Event handlers: MUST they always be registered? (or else..?) (by mwel= zl) API

12 issues received 23 new comments:

#404 Event handlers: MUST they always be registered? (or else..?) (6 by mw= elzl, csperkins, philsbln, theagilepadawan, tfpauly, MaxF12) API
#429 section algorithm (text in API doc) (3 by mirjak, gorryfair, theri) API=
#443 Message size (3 by mirjak, gorryfair)
#438 Retransmit notify (2 by mirjak, mwelzl) API
#414 Is the Local Endpoint "optional"? (2 by mirjak, MaxF12) Archi= tecture
#417 Add Framer to Figure 4? (1 by mirjak)
#418 Use of normative language in Arch (1 by gorryfair) Architecture =
#426 Syntax Preconnection (1 by theri) API
#398 Per-protocol behavior needs to be normative (1 by philsbln) Implementat= ion
#434 type of properties (1 by mirjak) API
#222 Reusing Preconnections? (1 by theri) API ready for text =
#440 Why do we use functions to set security parameters... (1 by mirjak)

Pull requests

ietf-tapswg/api-drafts (+19/-9/=F0=9F=92=AC6)

19 pull requests submitted:

#442 A= dd one more pointer to Framers (by mirjak)
#439 B= oolean property can not be set to Ignore (by mirjak)
#433 E= ditorial nits to improve consistency (by mirjak)
#432 &= quot;must provide sensible defaults" (by mirjak)
#431 M= ore MAYs? (by mirjak)
#430 T= oo many commas (by mirjak)
#428 L= ocal/Remote Endpoint type or Object? (by mirjak)
#425 N= ormative language for property namespace (by mirjak)
#424 P= rotocol Specific Properties are not well defined (by mirjak)
#423 e= ditorial: be more concrete about phases in Arch doc (by mirjak)
#422 m= inor edit to sec 4 (by mirjak)
#421 P= roposed alternative intro text for API doc (by mirjak)
#415 n= it - "within a message" twice (by mirjak)
#412 A= dd one sentence about fallback in sec 2.3 (by mirjak)
#411 A= ddress on Gorry's WGLC comments (by tfpauly) Architecture
#407 A= PI draft: Replace "Protocol Properties" with updated terms (b= y theri)
#406 A= dd a reference to DPLPMTUD for Message Size before fragmentation (by ad= ventureloop)
#405 A= PI draft: Minor fixes (by theri)
#403 S= ome small proposed fixes (by mwelzl)

3 pull requests received 6 new comments:

#432 &= quot;must provide sensible defaults" (3 by mirjak, abrunstrom, mwe= lzl) API
#421 P= roposed alternative intro text for API doc (2 by abrunstrom, mwelzl) API=
#425 N= ormative language for property namespace (1 by mirjak) API

9 pull requests merged:

#423 e= ditorial: be more concrete about phases in Arch doc API
#439 B= oolean property can not be set to Ignore
#422 m= inor edit to sec 4 API
#406 A= dd a reference to DPLPMTUD for Message Size before fragmentation API =
#407 A= PI draft: Replace "Protocol Properties" with updated terms API
#405 A= PI draft: Minor fixes API
#430 T= oo many commas API
#415 n= it - "within a message" twice Architecture
#411 A= ddress on Gorry's WGLC comments Architecture

Repositories tracked by this digest:

https://github.= com/ietf-tapswg/api-drafts

--===============9217148469881607205==-- From nobody Mon Jan 20 04:28:27 2020 Return-Path: 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 CC06B120059 for ; Mon, 20 Jan 2020 04:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=tenghardt.net 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 3FQhqVbg-V4F for ; Mon, 20 Jan 2020 04:28:21 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBB61200E5 for ; Mon, 20 Jan 2020 04:28:20 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id A43D9B9; Mon, 20 Jan 2020 13:28:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1579523299; bh=IpCuI4Ldt8/vjdjJz4hmqfoB/ALLO+9elwPuebbsKqw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XTvsnL/JCRQJh7QTFBU6BzTT4OXdgrKG8FsYL1gvmHL8Hx126Kzk4nRdprJ3XJZtW L92Ki+8mIWNc3UBFjER5aCjbklVqIdWuJoQk/yg/D4bDty2QLsk4kNEkkLeFosJOAr 6SZlUV2igi/XhvzlKu2Gfz1fRzWfG73nGPXxnNXkcjvkjq4Ngd7PMoIEHTHzx96ejh 62iGQ/f0vdJJAV/BiTKrGXw/+U5TV5yHBiGf42jgF/qlpLinY1K0kmeM7JEyr5bk+d dy9LQNPx5os6QeGKHumxydtSFt5M1j1ZzRxmqwaZMQ8OuWulx39NQvuwYtuw3XJv8G DnlakkMdOXZjw== To: taps WG Cc: Aaron Falk , Magnus Westerlund , Zaheduzzaman Sarker References: From: Theresa Enghardt Message-ID: Date: Mon, 20 Jan 2020 13:28:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B0E0CB9FEEB1E03A6A93FF5A" Content-Language: en-US Archived-At: Subject: Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 12:28:26 -0000 This is a multi-part message in MIME format. --------------B0E0CB9FEEB1E03A6A93FF5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, I reviewed the document again and I think it's ready for publication once we have the normative language sorted out and once the remaining minor editorial issues have been fixed, see Github. Best, Theresa On 07.01.20 16:50, Aaron Falk wrote: > > This is notice to open working group last call for “An Architecture > for Transport Services”, to conclude January 20, 2020. Please review > this document and send comments to the list, preferably with an > indication of whether it is ready for publication and, if not, what > your concerns are. > > https://www.ietf.org/id/draft-ietf-taps-arch-06 > > --aaron > TAPS wg co-chair > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------B0E0CB9FEEB1E03A6A93FF5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

I reviewed the document again and I think it's ready for publication once we have the normative language sorted out and once the remaining minor editorial issues have been fixed, see Github.

Best,
Theresa

On 07.01.20 16:50, Aaron Falk wrote:

This is notice to open working group last call for “An Architecture for Transport Services”, to conclude January 20, 2020. Please review this document and send comments to the list, preferably with an indication of whether it is ready for publication and, if not, what your concerns are.

https://www.ietf.org/id/draft-ietf-taps-arch-06

--aaron
TAPS wg co-chair
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--------------B0E0CB9FEEB1E03A6A93FF5A-- From nobody Mon Jan 20 07:43:46 2020 Return-Path: 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 BC2FC120801 for ; Mon, 20 Jan 2020 07:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 D30WcYlhXNpO for ; Mon, 20 Jan 2020 07:43:39 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D5612029C for ; Mon, 20 Jan 2020 07:43:38 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id e12so125723qto.2 for ; Mon, 20 Jan 2020 07:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ddK4250Sd9B498L0G0AKlUltV/ImCZecnMKaGTJu960=; b=jiFSgdNpvj6Q+Q3++PAOmnl9sckqlAsetVkfkBUoFDJzZNjGgMU4TMJNctf1K920bO 6IiWoXXDO59n5cvv2ax9IeB8R/Sriz1gVOSt7u/SsTBchTZMuHaqVJNeNwiUarxuYdGQ G0/7cZS4F5ywCMg6mWf37/qTpYzXELkmG8SuI7vd5X74cTalJGGrrXuszQZw7Fzz8bii m4KjLelPrY4J1vMs5GQCQhuXX/rmmEtxh/5y1lQOWX9SobBA/ERUPOcREAnRJCquFFAg A1S+LlmDXaRDDl84CT0ERSVYW0rTrp2qe/hB5t/rd5BG1j/msMz1IKjHZ+H54NHjAYgd E4uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ddK4250Sd9B498L0G0AKlUltV/ImCZecnMKaGTJu960=; b=tkWySPbjS1rfAAwNcEAr9AWUuGMyQv7gLYe1/j0rE4CPeb/Bvm+Op57tFwdQKL06qe AVzF7YGqdvKGOyezNQYdAgqSkKjFYeId/OvPq18iQ7ZEs7AQLbQUHnH3aBuISRGcXzbX xE9shRiLcO3Hfr34l/A/b3AwN9Fn3qiD48yO9mgAt3LW2A3SXTEEKX5SbZknDpN4NVFM SPE4hOkADZ8uDCxAF4J4sUwYuTpgkNU7IPZCtO3hon9uq1AXdNR0rcULBlK3nw6we4pa Mzg8VU65cjaPqYvmMTUaLD1jkON2DQbg8LdFKaDUk3wBBVN70pzJfqz3w0v9egHH8C6T 2brw== X-Gm-Message-State: APjAAAUesLwyGbqbyASXRFud0MdldhT+1+cjHI+6ysXMJ5PVK3gih54v AuKNHEcao611OmtEfiWkorPqE4Ri6i4= X-Google-Smtp-Source: APXvYqyxA7i0zWmwF3pwl+TwW81CwIz7fOQuAghoViRH0t3j5O2ZEYMPTI0N0Dq5kadwiAk76ISrGQ== X-Received: by 2002:ac8:5159:: with SMTP id h25mr21533650qtn.249.1579535017736; Mon, 20 Jan 2020 07:43:37 -0800 (PST) Received: from [172.19.114.45] ([2601:184:4881:2420:7cb3:60ea:fbc8:7b22]) by smtp.gmail.com with ESMTPSA id 3sm17661805qte.59.2020.01.20.07.43.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 07:43:37 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Magnus Westerlund" Date: Mon, 20 Jan 2020 10:43:36 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: <12D5830C-6CF2-4679-A77A-94330E56F10F@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_F8BB3D3E-D62F-43A8-9826-4DFDA4662A74_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 15:43:45 -0000 --=_MailMate_F8BB3D3E-D62F-43A8-9826-4DFDA4662A74_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Last call concludes today. Please send recommendations to publish or comments requiring revision ASAP. --aaron On 7 Jan 2020, at 10:50, Aaron Falk wrote: > This is notice to open working group last call for “An Architecture > for Transport Services”, to conclude January 20, 2020. Please > review this document and send comments to the list, preferably with an > indication of whether it is ready for publication and, if not, what > your concerns are. > > https://www.ietf.org/id/draft-ietf-taps-arch-06 > > --aaron > TAPS wg co-chair --=_MailMate_F8BB3D3E-D62F-43A8-9826-4DFDA4662A74_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= p dir=3D"auto">Last call concludes today. Please send recommendations to= publish or comments requiring revision ASAP.

--aaron

On 7 Jan 2020, at 10:50, Aaron Falk wrote:

This is notice to open working grou= p last call for =E2=80=9CAn Architecture for Transport Services=E2=80=9D,= to conclude January 20, 2020. Please review this document and send comm= ents to the list, preferably with an indication of whether it is ready fo= r publication and, if not, what your concerns are.

https://www.ietf.org/id/draft-ietf-taps-arch-06

--aaron
TAPS wg co-chair

--=_MailMate_F8BB3D3E-D62F-43A8-9826-4DFDA4662A74_=-- From nobody Mon Jan 20 09:41:11 2020 Return-Path: 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 0863D12080B for ; Mon, 20 Jan 2020 09:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 n1e9DDKNgo3z for ; Mon, 20 Jan 2020 09:41:05 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 CA831120289 for ; Mon, 20 Jan 2020 09:41:05 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00KHbU1v019677; Mon, 20 Jan 2020 09:41:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=YdhNGAbtWOvS70VdBe0WfJ5LgDQIrMoZwtn80hJyr1M=; b=W5IRz+KVV3sMmPpfXvh9ytZrqe2xerGTiLK6CgLgFW2XT9sl5eNfTLOW8tNRgd+sNgE0 cO2zEOgJ/qehxRRviqJXViYvKPEvEIT8s0VRIxNi5A+oolRC3UfyqkQnL6lq92N6oxVX Guez1+69h6Vimn5pBqnD/AUogaKuv1NP8Lo48//KJMIkvnqnj+684neBlbR4deibur2Q iaBinZqonQV5WTpiE/+d3+H24zIkmXKX5gwOdGS3FsGRsIHRnTcKST9ZfY6mn7GteoBh hDovEcqig2YZINFmUQ4oYQs80q98FVcquNeA7uQyRzV4y4gTbKu33cxqWMNvQODzk9tb wQ== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2xm1j7r4u9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Jan 2020 09:41:02 -0800 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4F005ZQ2GDL710@mr2-mtap-s03.rno.apple.com>; Mon, 20 Jan 2020 09:41:01 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4F00I001S8AF00@nwk-mmpp-sz12.apple.com>; Mon, 20 Jan 2020 09:41:01 -0800 (PST) X-Va-A: X-Va-T-CD: d260a3dbc091c2724d0bf0ff714ffebc X-Va-E-CD: 7ab32942004e63dd1658bc6284e88af9 X-Va-R-CD: 73e6ba5e086520a60639d5438b467781 X-Va-CD: 0 X-Va-ID: 3d6f2341-9272-41c1-8288-75abacb04de4 X-V-A: X-V-T-CD: d260a3dbc091c2724d0bf0ff714ffebc X-V-E-CD: 7ab32942004e63dd1658bc6284e88af9 X-V-R-CD: 73e6ba5e086520a60639d5438b467781 X-V-CD: 0 X-V-ID: 86ecd0fa-a180-45e5-909e-c1ebf6d55b1e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-20_07:,, signatures=0 Received: from [17.235.13.58] (unknown [17.235.13.58]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4F00GK72GDC560@nwk-mmpp-sz12.apple.com>; Mon, 20 Jan 2020 09:41:01 -0800 (PST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary=Apple-Mail-CFBFC978-0BEB-432F-89A0-1F1B9C5F9DB2 Content-transfer-encoding: 7bit From: Tommy Pauly MIME-version: 1.0 (1.0) Date: Mon, 20 Jan 2020 09:41:00 -0800 Message-id: <5BB3E183-2260-4180-BA81-5869936090C6@apple.com> References: Cc: taps WG , Aaron Falk , Magnus Westerlund , Zaheduzzaman Sarker In-reply-to: To: Theresa Enghardt X-Mailer: iPhone Mail (18A204a) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-20_07:, , signatures=0 Archived-At: Subject: Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 17:41:10 -0000 --Apple-Mail-CFBFC978-0BEB-432F-89A0-1F1B9C5F9DB2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for your review Theresa! We=E2=80=99ll incorporate your GitHub commen= ts soon. As editor, I think this document should be ready to publish with th= ese minor changes added in.=20 Thanks, Tommy > On Jan 20, 2020, at 4:28 AM, Theresa Enghardt wrote: >=20 > =EF=BB=BF > Hi all, >=20 > I reviewed the document again and I think it's ready for publication once w= e have the normative language sorted out and once the remaining minor editor= ial issues have been fixed, see Github. >=20 > Best, > Theresa >=20 >=20 >> On 07.01.20 16:50, Aaron Falk wrote: >> This is notice to open working group last call for =E2=80=9CAn Architectu= re for Transport Services=E2=80=9D, to conclude January 20, 2020. Please rev= iew this document and send comments to the list, preferably with an indicati= on of whether it is ready for publication and, if not, what your concerns ar= e. >>=20 >> https://www.ietf.org/id/draft-ietf-taps-arch-06 >>=20 >> --aaron >> TAPS wg co-chair >>=20 >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail-CFBFC978-0BEB-432F-89A0-1F1B9C5F9DB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks for your review The= resa! We=E2=80=99ll incorporate your GitHub comments soon. As editor, I thin= k this document should be ready to publish with these minor changes added in= .

Thanks,

Tommy

On Jan 2= 0, 2020, at 4:28 AM, Theresa Enghardt <ietf@tenghardt.net> wrote:
<= br>

=EF=BB=BF =20 =20 =20
Hi all,

I reviewed the document again and I think it's ready for publication once we have the normative language sorted out and once the remaining minor editorial issues have been fixed, see Github.

Best,
Theresa

On 07.01.20 16:50, Aaron Falk wrote:
This is notice to open working group last call for =E2=80=9CAn Architecture for Transport Services=E2=80=9D, to= conclude January 20, 2020. Please review this document and send comments to the list, preferably with an indication of whether it is ready for publication and, if not, what your concerns are.

https://www.ietf.= org/id/draft-ietf-taps-arch-06

--aaron
TAPS wg co-chair
_______________________________=
________________
Taps mailing list
Taps@iet=
f.org
https://www.ietf.org/mailman/listinfo/taps
=20 _______________________________________________
Taps m= ailing list
Taps@ietf.org
https://www.ietf.o= rg/mailman/listinfo/taps

= --Apple-Mail-CFBFC978-0BEB-432F-89A0-1F1B9C5F9DB2-- From nobody Thu Jan 23 13:25:03 2020 Return-Path: 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 C3C181200F1 for ; Thu, 23 Jan 2020 13:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 8ijwvTr2oX6C for ; Thu, 23 Jan 2020 13:24:59 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AC21201DB for ; Thu, 23 Jan 2020 13:24:59 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id i13so3712627qtr.3 for ; Thu, 23 Jan 2020 13:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=87W/aXT/8UbZZm83k8This7sJYPtA08Uz5cUH3ZdmOA=; b=RckXUtohWkmapp5qXY3gKmopZeTWfb/AqfeRhWQtDZy3ghgGYWuxiW0RlkTe4TQCGf Azf/9FBStlDiZ3lpWg7zAImOk0HgH6HDGjwZE9OGLDIJgcmcQha5cZnrD6OMHB4idl79 AgStse+8+nOx2tJY7XicT1aLF+e3AQJ48EdsqAaW6wm5+pSLiu9rwtZ+m+dJmSUoB22S Ss8VWrx5eN1srBBQ+KCuZ/PsQkOXdcQlmfeHNLL55JAw6XUN3h6InzGMgromBtdP5H3K Zmul3v+Qc0zu+UDHvLOfxqRmND8nsSEtMKFXXVv/Fdbu4ipc9yeIOvHkz+d6/gUfLIo6 luTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=87W/aXT/8UbZZm83k8This7sJYPtA08Uz5cUH3ZdmOA=; b=D7MfEtYmCnNpoRR60GP95YhWS6YOAhiGgm06ZQ3wNXPK4ROKURm+65LHItVSYvADOm NlGAEX2dGsq6SVVlhgv2qJDop3Xrd+GyphCi9PRCx/jmqHd1CVGTeuynyDzw2oaM2rEB fcS+2kyOy4UdRp+UPbEI7+1Ch1xEoCFNPPtaa5fvdOXovFzdOW0V0Arpb3c8WSqegQP/ SJqR0JOwdTHybnDFLFQh9BaFTtT+fOhvOlsAPfIYZZXy4V5PjpZtbmF2XCfa+6FE7gg6 9VprAVH0+s87h5waajAH+1gCe4NQ6QjuBGFrFRNIAz00XqDAMBmIilAB9ZyWgNJJyGyX BcpA== X-Gm-Message-State: APjAAAVHRAK+Z7kIgvw7NW9C6KdXqQ4xezDHlE/Ta0Cq9xkkdsECCEif 3Nwv8mpg0/s8mg1GG0Opp+qlcMadTAA= X-Google-Smtp-Source: APXvYqzfd9qrrwkYNXZY+Tb8x6tP647xV1Bh3oLOqwon2PN6Dwr9KtFhZDmzy/0VXWKJOaZHg58hPw== X-Received: by 2002:aed:3fb7:: with SMTP id s52mr175432qth.97.1579814698325; Thu, 23 Jan 2020 13:24:58 -0800 (PST) Received: from [172.19.115.93] ([2001:4878:a048:3000:a82d:a366:78b7:99b8]) by smtp.gmail.com with ESMTPSA id x27sm1570462qkx.81.2020.01.23.13.24.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 13:24:57 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Thu, 23 Jan 2020 16:24:54 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: <02F29C03-4727-42FF-AE4D-EA7CDC5EDB12@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_89251624-B082-47D3-8D28-91ED2C4F22C8_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] Reminder: TAPS interim tomorrow (Jan 24) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 21:25:02 -0000 --=_MailMate_89251624-B082-47D3-8D28-91ED2C4F22C8_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit We’re meeting tomorrow at 1100 EST (1600 GMT). Agenda: 1. Pending [-arch](https://www.ietf.org/id/draft-ietf-taps-arch-06.txt) changes following wglc 2. [Open issues](https://github.com/ietf-tapswg/api-drafts/issues) for [-interface](https://www.ietf.org/id/draft-ietf-taps-interface-05.txt) 3. AOB Join: https://ietf.webex.com/meet/taps --=_MailMate_89251624-B082-47D3-8D28-91ED2C4F22C8_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

We=E2=80=99re meeting tomorrow at 1100 EST (1600 GMT).

Agenda:

Pending -arch changes following wglc
Open issues for -inte= rface
AOB

Join: https://ietf.webex.com/meet/taps

--=_MailMate_89251624-B082-47D3-8D28-91ED2C4F22C8_=-- From nobody Thu Jan 23 17:24:35 2020 Return-Path: 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 04D41120105 for ; Thu, 23 Jan 2020 17:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 P4S3CuxHEnXS for ; Thu, 23 Jan 2020 17:24:27 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C1412084B for ; Thu, 23 Jan 2020 17:24:27 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id x18so164136ybk.6 for ; Thu, 23 Jan 2020 17:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=NyplQedjRKCenazNXRaUmpesWc7QkV9R2H08zr5eZ4A=; b=LBY/Tg6gA6jGd0LAyJA0/Y6rg7NHYTdS9E/zYnsAWVLQqotB67kkgnUg6KSwqlW4TK fd2TLTDtCqXPSydqcp7fVHdT5k1/solcBo5AEXFgd+JlO9F1DqCDvVnAXI7mEdzrlF6w c4oJ34tyG6hVeaNUvJ5DjK9/bfBPZJn67W36U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NyplQedjRKCenazNXRaUmpesWc7QkV9R2H08zr5eZ4A=; b=XrZAZKCa+A3NqHEU6d7NiCkZ9WpBrAmO266LPC1DXuC2dAgWieMzqFOuXmz2Ezr56E oyy0k2/ecOTzq1ptseNcU5qsUeGPlGtTl9wcnvsW8PqqV+Gb+d2naxA7HIj2c9W3UK+L /N9jGM1g0ZHiaRMGYz3q0B7xbf/onQImfKo8fZovpWbDA9uu9YRN5/ycf4FJ16FGGST7 PFxz7T09FNLgzSioQEUeHr5N8YLDJwRiFuStc7HfNeHF6jrRPOiihfjeZOSkJ+FTW7Hg FEu2G9xVorf+JVhRCapL8Kd3qVd82MWFffKT3vpAnepplPX6yB6N1peKVmZfZw1edCiO vuMA== X-Gm-Message-State: APjAAAXdDgP0czlklvsJnOezl5L3OSf8kVlSFIntbUIchVI3YfeCfxgH 7rW72qgjGeKqLq2o+CS0ja7XrbE/4LAhelb/6yz3T/26+hig+w== X-Google-Smtp-Source: APXvYqxFrHV6BwM5Wa+/fm6wDm3D17qblkriUzCY20Uxh3EVlMkGsmYWJTiw1GYd0SEdUgbbBtetQPkQotzfjBr8kOg= X-Received: by 2002:a25:eb0f:: with SMTP id d15mr488480ybs.247.1579829065628; Thu, 23 Jan 2020 17:24:25 -0800 (PST) MIME-Version: 1.0 From: Kyle Rose Date: Thu, 23 Jan 2020 20:24:24 -0500 Message-ID: To: taps WG Content-Type: multipart/alternative; boundary="0000000000004365be059cd89e91" Archived-At: Subject: [Taps] draft-ietf-taps-interface-05 review X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 01:24:34 -0000 --0000000000004365be059cd89e91 Content-Type: text/plain; charset="UTF-8" I've completed my review of draft-05, inline below. I will also submit a PR with minor changes that I recommend be addressed via cherry-picking agreed-upon hunks from the diff. 2. Terminology and Notation * "The method for dispatching and handling Events is an implementation detail, with the caveat that the interface for receiving Messages must require the application to invoke the Connection.Receive() Action once per Message to be received (see Section 8)." This isn't true if ReceivedPartial events are triggered, right? Also, it's not really clear that any of this discussion belongs in a section titled "Terminology and Notation". This issue is alluded to later in the doc, and probably mostly belongs in the implementation doc. * The notation "Sender -> Event" says nothing about who receives the event. Is it just assumed to be the application in the context of the particular event (e.g., a thread processing a particular connection)? 3. Interface Design Principles * What does "long-term caching of cryptographic identities" mean? The implication seems to be that credentials and transport security parameters can be configured once and used repeatedly. I'm not sure time interval ("long-term") is the right modifier here, and the word "caching" might be misunderstood as it means something subtly different in the realm of computer hardware and software than the dictionary definition implies. Maybe something like: "...and for configuration of cryptographic identities and transport security parameters persistent across multiple Connections" * "An application primarily interacts with this interface..." This seems awkward. An interface is the means by which an application interacts with the underlying transports. 4.2.1. Transport Property Names * The use of dashes in property names means they will necessarily look different in almost every widely-used language, in which dash is an operator. * If we're not currently asking IANA to create a registry of property names or namespaces, should we provide a recommendation that such symbols not listed explcitly in this document be prefixed with some experimental identifier? 4.3. Scope of the Interface Definition * "Implementations of this interface SHOULD implement each Selection Property, Connection Property, and Message Context Property specified in this document, exclusive of appendices. Each interface SHOULD be implemented even when this will always result in no operation, e.g. there is no action when the API specifies a Property that is not available in a transport protocol implemented on a specific platform." This seems like it implies that a property that is unavailable should silently fail to be activated, which conflicts with the "Require" preference referenced later. There may be some way to reword this to be clear that it's referring to implementing all of the properties in the API so that compile-time or runtime errors don't spuriously occur when some symbol hasn't been defined. Also: why "exclusive of appendices"? 5.2. Specifying Transport Properties * There are a lot of choices being made about how users will want to prioritize transport protocol selection. How confident are we that, for instance, path selection should take priority over protocol selection? I think that's right, but I wonder if it might not make more sense to have two interfaces: one that provides a purely numeric priority ordering of preferences, and one (based on the existing 5-level preferences) that maps into it. * "As preference typed selection properties..." I can't parse this. * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output of selected properties seems like a shortcut that will lead to some confusion. 5.2.5. Use 0-RTT Session Establishment with an Idempotent Message * I'll repeat the same statement I made at the mic a few years ago: idempotency != replay-safe. DELETE is idempotent, but not safe for replay because someone might have done a PUT or POST in the meantime. 5.2.10. Interface Instance or Type * These type symbols really deserve an actual registry, or at least the start of one. Otherwise, we are likely to end up with a mess. 5.2.11. Provisioning Domain Instance or Type * What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi. 5.3.2. Connection Establishment Callbacks * What constitutes trust verification prior to the handshake? 6.4. Connection Groups * "An ideal transport system" for whom? The capacity partitioning recommended here seems purely subjective. I'd just remove it. 7.3.1. Sent * It seems like an abstract API would be helpful for the reference to the Message to which a Sent event applies: this seems like something many, many applications would need to do. With callbacks, the application can always curry in a reference to the original message (that's what my event system from ~2001 did), so maybe that should be the recommendation and the message reference removed...? I don't have a strong feeling here other than that if something is included then its use should be more well-defined. 7.3.3. SendError * Is there a reason why a single messageContext object is used for both sends and receives? I probably missed the original discussion about this, but I'd like to understand the reasoning. 7.4.7. Reliable Data Transfer (Message) * The default isn't "true", it's whatever the underlying connection had, right? 7.4.9. Singular Transmission * Might be worth pointing out there's no guarantee here, either, considering resegmenting TCP middleboxes. 8. Receiving Data * A connection can be used to receive data if it is not configured as unidirectional transmit. 8.2. Receive Events * "A call to Receive will be paired with a single Receive Event" or possibly multiple ReceivedPartial Events? * Also, can the draft be consistent about Receive vs. Received, et al.? 9. Message Contexts * "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." I can't parse this. 11. General comments * There's a lot of UNIXisms here that should probably be excised in favor of a more abstract presentation. The most obvious is the use of -1 to mean something other than the integer -1. In Python, for instance, you might want to use None for this purpose. I would specify non-numeric values symbolically, and maybe indicate in the appendix that a UNIX C implementation might want to use -1 to represent such values. 11.1.3. Priority (Connection) * I'm not sure what "relative inverse priority" means. Is P1 higher priority than P5, and therefore lower inverse priority than P5? Or the other way around? 11.1.10. Capacity Profile * Very little of this section is about capacity. Traffic Profile? * "High Throughput Data" might be better phrased as "Capacity-Seeking". 11.2. Soft Errors * Should the SoftError Event carry some information about e.g. the ICMP message received? --0000000000004365be059cd89e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I've completed my review of draft-05, inline belo= w. I will also submit a PR with minor changes that I recommend be addressed= via cherry-picking agreed-upon hunks from the diff.

2. Terminology and Notation

=C2=A0* "The m= ethod for
=C2=A0 =C2=A0dispatching and handling Events is an implementat= ion detail, with the
=C2=A0 =C2=A0caveat that the interface for receivin= g Messages must require the
=C2=A0 =C2=A0application to invoke the Conne= ction.Receive() Action once per
=C2=A0 =C2=A0Message to be received (see= Section 8)."

This isn't true if Received= Partial events are triggered, right? Also, it's not really clear that a= ny of this discussion belongs in a section titled "Terminology and Not= ation". This issue is alluded to later in the doc, and probably mostly= belongs in the implementation doc.

=C2=A0* The no= tation "Sender -> Event" says nothing about who receives the e= vent. Is it just assumed to be the application in the context of the partic= ular event (e.g., a thread processing a particular connection)?

<= br>

3. Interface Design Principles

=C2= =A0* What does "long-term caching of cryptographic identities" me= an? The implication seems to be that credentials and transport security par= ameters can be configured once and used repeatedly. I'm not sure time i= nterval ("long-term") is the right modifier here, and the word &q= uot;caching" might be misunderstood as it means something subtly diffe= rent in the realm of computer hardware and software than the dictionary def= inition implies. Maybe something like:

=C2=A0=C2= =A0 "...and for configuration of cryptographic identities and transpor= t security parameters persistent across multiple Connections"

=C2=A0* "An application primarily interacts with this= interface..." This seems awkward. An interface is the means by which = an application interacts with the underlying transports.

4.2.1. Transport Property Names

=C2=A0*= The use of dashes in property names means they will necessarily look diffe= rent in almost every widely-used language, in which dash is an operator.

=C2=A0* If we're not currently asking IANA t= o create a registry of property names or namespaces, should we provide a re= commendation that such symbols not listed explcitly in this document be pre= fixed with some experimental identifier?

4.3. Scop= e of the Interface Definition

=C2=A0* "Implem= entations of this interface SHOULD implement each Selection
=C2=A0 =C2= =A0 =C2=A0 Property, Connection Property, and Message Context Property
= =C2=A0 =C2=A0 =C2=A0 specified in this document, exclusive of appendices.= =C2=A0 Each
=C2=A0 =C2=A0 =C2=A0 interface SHOULD be implemented even wh= en this will always result
=C2=A0 =C2=A0 =C2=A0 in no operation, e.g. th= ere is no action when the API specifies a
=C2=A0 =C2=A0 =C2=A0 Property = that is not available in a transport protocol implemented
=C2=A0 =C2=A0 = =C2=A0 on a specific platform."

This seems li= ke it implies that a property that is unavailable should silently fail to b= e activated, which conflicts with the "Require" preference refere= nced later. There may be some way to reword this to be clear that it's = referring to implementing all of the properties in the API so that compile-= time or runtime errors don't spuriously occur when some symbol hasn'= ;t been defined.

Also: why "exclusive of = appendices"?

5.2. Specifying Transport Proper= ties

=C2=A0* There are a lot of choices being made= about how users will want to prioritize transport protocol selection. How = confident are we that, for instance, path selection should take priority ov= er protocol selection? I think that's right, but I wonder if it might n= ot make more sense to have two interfaces: one that provides a purely numer= ic priority ordering of preferences, and one (based on the existing 5-level= preferences) that maps into it.

=C2=A0* "As = preference typed selection properties..." I can't parse this.

=C2=A0* Using the same enum (Require(d[sic])/Avoid/Ign= ore) for the queried output of selected properties seems like a shortcut th= at will lead to some confusion.

5.2.5. Use 0-RTT S= ession Establishment with an Idempotent Message

= =C2=A0* I'll repeat the same statement I made at the mic a few years ag= o: idempotency !=3D replay-safe. DELETE is idempotent, but not safe for rep= lay because someone might have done a PUT or POST in the meantime.

5.2.10. Interface Instance or Type

=C2=A0* These type symbols really deserve an actual registry, or at l= east the start of one. Otherwise, we are likely to end up with a mess.

5.2.11. Provisioning Domain Instance or Type

=C2=A0* What about ordering of similar interfaces? I have a= 2-SIM cellphone with wifi.

5.3.2. Connection = Establishment Callbacks

=C2=A0* What constitutes t= rust verification prior to the handshake?

6.4. Con= nection Groups

=C2=A0* "An ideal transport sy= stem" for whom? The capacity partitioning recommended here seems purel= y subjective. I'd just remove it.

7.3.1. Sent<= /div>

=C2=A0* It seems like an abstract API would be hel= pful for the reference to the Message to which a Sent event applies: this s= eems like something many, many applications would need to do. With callback= s, the application can always curry in a reference to the original message = (that's what my event system from ~2001 did), so maybe that should be t= he recommendation and the message reference removed...? I don't have a = strong feeling here other than that if something is included then its use s= hould be more well-defined.

7.3.3. SendError

=C2=A0* Is there a reason why a single messageContext o= bject is used for both sends and receives? I probably missed the original d= iscussion about this, but I'd like to understand the reasoning.

7.4.7. Reliable Data Transfer (Message)

=C2=A0* The default isn't "true", it's whatever t= he underlying connection had, right?

7.4.9. Singul= ar Transmission

=C2=A0* Might be worth pointing ou= t there's no guarantee here, either, considering resegmenting TCP middl= eboxes.

8. Receiving Data

=C2=A0* A connection can be used to receive data if it is not configured a= s unidirectional transmit.

8.2. Receive Events

=C2=A0* "A call to Receive will be paired with a= single Receive Event" or possibly multiple ReceivedPartial Events?

=C2=A0* Also, can the draft be consistent about Rece= ive vs. Received, et al.?

9. Message Contexts

=C2=A0* "To get or set Message Properties, the op= tional scope parameter is
=C2=A0 =C2=A0left empty, for framing meta-data= , the framer is passed." I can't parse this.

<= div>11. General comments

=C2=A0* There's a lot= of UNIXisms here that should probably be excised in favor of a more abstra= ct presentation. The most obvious is the use of -1 to mean something other = than the integer -1. In Python, for instance, you might want to use None fo= r this purpose. I would specify non-numeric values symbolically, and maybe = indicate in the appendix that a UNIX C implementation might want to use -1 = to represent such values.

11.1.3. Priority (Co= nnection)

=C2=A0* I'm not sure what "rela= tive inverse priority" means. Is P1 higher priority than P5, and there= fore lower inverse priority than P5? Or the other way around?

11.1.10. Capacity Profile

=C2=A0* Very= little of this section is about capacity. Traffic Profile?

<= /div>

=C2=A0* "High Throughput Data" might be better phrased = as "Capacity-Seeking".

11.2. Soft Errors=

=C2=A0* Should the SoftError Event carry some inf= ormation about e.g. the ICMP message received?

--0000000000004365be059cd89e91-- From nobody Fri Jan 24 00:02:28 2020 Return-Path: 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 D3F3812007A for ; Fri, 24 Jan 2020 00:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 MQ5ntESWws47 for ; Fri, 24 Jan 2020 00:02:22 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 AF630120019 for ; Fri, 24 Jan 2020 00:02:20 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iutsv-0002sM-AF for taps@ietf.org; Fri, 24 Jan 2020 08:00:09 +0000 Content-Type: multipart/alternative; boundary="===============5739096540536531943==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 24 Jan 2020 08:00:09 +0000 Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 08:02:25 -0000 --===============5739096540536531943== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+11/-8/=F0=9F=92=AC68) 11 issues created: - Appendix A.1. / Adding preference properties (by theagilepadawan) https://github.com/ietf-tapswg/api-drafts/issues/486 = - Is format of message an implementation detail? (by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/477 [API] = - Arch: service class influences protocol selection? (by theri) https://github.com/ietf-tapswg/api-drafts/issues/476 = - Arch: UDP checksums as protocol-specific property? (by theri) https://github.com/ietf-tapswg/api-drafts/issues/475 = - Arch: 4.2.3 could be misinterpreted as connection migration (by theri) https://github.com/ietf-tapswg/api-drafts/issues/472 = - Arch: Consistency of "Transport Services system" and "Transport System"= (by theri) https://github.com/ietf-tapswg/api-drafts/issues/471 = - Arch: "the ability to easily adopt different transport protocols"? (by = theri) https://github.com/ietf-tapswg/api-drafts/issues/470 = - Do we want to keep appendix about Go sample implementation in API doc? = (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/469 [API] = - Clean up appendix of API (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/468 = - own subsection for read-only properties? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/467 [API] = - Add state diagram to section "Connection State and Ordering of Operatio= ns and Events" (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/466 [API] = 25 issues received 68 new comments: - #454 Receive semantics (9 by mwelzl, theri, abrunstrom, mirjak, tfpauly= , MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/454 [API] = - #476 Arch: service class influences protocol selection? (7 by britram, = gorryfair, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/476 [Architecture] [di= scuss] = - #471 Arch: Consistency of "Transport Services system" and "Transport Sy= stem" (4 by britram, mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/471 [Architecture] [ed= itorial] [ready for text] = - #443 Message size (3 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/443 [API] = - #451 ECN property? (3 by mirjak, mwelzl, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/451 [API] = - #455 Message context (3 by mirjak, mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/455 [API] = - #457 Framers again... (3 by mirjak, tfpauly, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/457 [API] [Implementat= ion] [discuss] = - #468 Clean up appendix of API (3 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/468 = - #469 Do we want to keep appendix about Go sample implementation in API = doc? (3 by britram, gorryfair, theri) https://github.com/ietf-tapswg/api-drafts/issues/469 [API] = - #470 Arch: "the ability to easily adopt different transport protocols"?= (3 by mirjak, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/470 [Architecture] [ed= itorial] = - #472 Arch: 4.2.3 could be misinterpreted as connection migration (3 by = mirjak, britram, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/472 [Architecture] [re= ady for text] = - #477 Is format of message an implementation detail? (3 by britram, tfpa= uly, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/477 [API] = - #418 Use of normative language in Arch (2 by gorryfair, theri) https://github.com/ietf-tapswg/api-drafts/issues/418 [Architecture] = - #419 Acknowledgements in Arch (2 by mirjak, britram) https://github.com/ietf-tapswg/api-drafts/issues/419 [Architecture] = - #435 Default values for Interface Instance and PvD (2 by mirjak, theri) https://github.com/ietf-tapswg/api-drafts/issues/435 [API] = - #436 Local Address Preference always only preferred? (2 by mirjak, mwel= zl) https://github.com/ietf-tapswg/api-drafts/issues/436 [API] = - #441 Questions on Connection Groups (2 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/441 [API] = - #458 New proposed structure for API doc (2 by mirjak, theri) https://github.com/ietf-tapswg/api-drafts/issues/458 [API] = - #461 Connection Groups, Priority, and Cloning (2 by mirjak, theri) https://github.com/ietf-tapswg/api-drafts/issues/461 [API] = - #466 Add state diagram to section "Connection State and Ordering of Ope= rations and Events" (2 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/466 [API] [Architectur= e] = - #414 Is the Local Endpoint "optional"? (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/414 [Architecture] = - #437 Configuring MP use (1 by abrunstrom) https://github.com/ietf-tapswg/api-drafts/issues/437 [API] = - #448 Right design for Partial Send (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/448 [API] = - #462 Timeout for Aborting Connection (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/462 [API] = - #475 Arch: UDP checksums as protocol-specific property? (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/475 [Architecture] [re= ady for text] = 8 issues closed: - Explain that Close isn't Half-Close https://github.com/ietf-tapswg/api-= drafts/issues/397 [Architecture] = - Arch: UDP checksums as protocol-specific property? https://github.com/i= etf-tapswg/api-drafts/issues/475 [Architecture] [ready for text] = - Arch: Consistency of "Transport Services system" and "Transport System"= https://github.com/ietf-tapswg/api-drafts/issues/471 [Architecture] [edito= rial] [ready for text] = - API: Specifying local interfaces as Local Endpoint VS. as a Selection P= roperty https://github.com/ietf-tapswg/api-drafts/issues/410 [API] = - Reusing Preconnections? https://github.com/ietf-tapswg/api-drafts/issue= s/222 [API] [ready for text] = - Connection Groups, Priority, and Cloning https://github.com/ietf-tapswg= /api-drafts/issues/461 [API] = - Arch: "the ability to easily adopt different transport protocols"? http= s://github.com/ietf-tapswg/api-drafts/issues/470 [Architecture] [editorial] = - Clean up appendix of API https://github.com/ietf-tapswg/api-drafts/issu= es/468 = Pull requests ------------- * ietf-tapswg/api-drafts (+11/-17/=F0=9F=92=AC17) 11 pull requests submitted: - Update specific-protocol option example from UDP checksum to TCP UTO (b= y tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/485 = - Move text removed by #421 to the arch document (by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/484 [Architecture] = - Minor API nits (by MaxF12) https://github.com/ietf-tapswg/api-drafts/pull/483 = - Be more consistent in naming Transport Services (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/482 = - Clarify Clone and Priority, closes #461 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/481 = - Local Endpoint vs. Selection Property, closes #410 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/480 = - Allow reusing Preconnections, fixes #222 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/479 = - Clarify "adopt", summarize sec 2.3 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/478 = - Arch: Adjust Security Considerations to new Section 4.2.3 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/474 = - Arch: Some consistency and clarity fixes (by theri) https://github.com/ietf-tapswg/api-drafts/pull/473 = - New upper section for connection events (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/465 = 8 pull requests received 17 new comments: - #432 "must provide sensible defaults" (4 by mirjak, abrunstrom) https://github.com/ietf-tapswg/api-drafts/pull/432 [API] = - #464 Restructure TCP UTO section (4 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/464 [API] = - #484 Move text removed by #421 to the arch document (4 by philsbln, abr= unstrom, gorryfair) https://github.com/ietf-tapswg/api-drafts/pull/484 [Architecture] = - #403 Some small proposed fixes (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/403 [API] = - #421 Proposed alternative intro text for API doc (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/421 [API] = - #442 Add one more pointer to Framers (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/442 [API] = - #444 Indicate use of streams for unordered messages as example (1 by ab= runstrom) https://github.com/ietf-tapswg/api-drafts/pull/444 [API] = - #465 New upper section for connection events (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/465 [API] = 17 pull requests merged: - Update specific-protocol option example from UDP checksum to TCP UTO https://github.com/ietf-tapswg/api-drafts/pull/485 [Architecture] = - editorial fix https://github.com/ietf-tapswg/api-drafts/pull/460 [API] = - Local Endpoint vs. Selection Property, closes #410 https://github.com/ietf-tapswg/api-drafts/pull/480 [API] = - Allow reusing Preconnections, fixes #222 https://github.com/ietf-tapswg/api-drafts/pull/479 [API] = - Moving section on Message Contexts https://github.com/ietf-tapswg/api-drafts/pull/456 [API] = - More MAYs? https://github.com/ietf-tapswg/api-drafts/pull/431 [API] = - Proposed alternative intro text for API doc https://github.com/ietf-tapswg/api-drafts/pull/421 [API] = - Add one sentence about fallback in sec 2.3 https://github.com/ietf-tapswg/api-drafts/pull/412 [Architecture] = - Clarify Clone and Priority, closes #461 https://github.com/ietf-tapswg/api-drafts/pull/481 [API] = - Local/Remote Endpoint type or Object? https://github.com/ietf-tapswg/api-drafts/pull/428 [API] = - Normative language for property namespace https://github.com/ietf-tapswg/api-drafts/pull/425 [API] = - Some small proposed fixes https://github.com/ietf-tapswg/api-drafts/pull/403 [API] = - Be more consistent in naming Transport Services https://github.com/ietf-tapswg/api-drafts/pull/482 = - Arch: Adjust Security Considerations to new Section 4.2.3 https://github.com/ietf-tapswg/api-drafts/pull/474 = - Arch: Some consistency and clarity fixes https://github.com/ietf-tapswg/api-drafts/pull/473 = - Clarify "adopt", summarize sec 2.3 https://github.com/ietf-tapswg/api-drafts/pull/478 = - Indicate use of streams for unordered messages as example https://github.com/ietf-tapswg/api-drafts/pull/444 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============5739096540536531943== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday January 24, 2020

Issues

ietf-tapswg/api-drafts (+11/-8/=F0=9F=92=AC68)

11 issues created:

#486 Appendix A.1. / Adding preference properties (by theagilepadawan)
#477 Is format of message an implementation detail? (by MaxF12) API <= /li> =
#476 Arch: service class influences protocol selection? (by theri)
#475 Arch: UDP checksums as protocol-specific property? (by theri)
#472 Arch: 4.2.3 could be misinterpreted as connection migration (by theri)=
#471 Arch: Consistency of "Transport Services system" and "Trans= port System" (by theri)
#470 Arch: "the ability to easily adopt different transport protocols"= ;? (by theri)
#469 Do we want to keep appendix about Go sample implementation in API doc?= (by mirjak) API
#468 Clean up appendix of API (by mirjak)
#467 own subsection for read-only properties? (by mirjak) API
#466 Add state diagram to section "Connection State and Ordering of Operat= ions and Events" (by mirjak) API

25 issues received 68 new comments:

#454 Receive semantics (9 by mwelzl, theri, abrunstrom, mirjak, tfpauly, Ma= xF12) API
#476 Arch: service class influences protocol selection? (7 by britram, gorr= yfair, tfpauly) Architecture discuss
#471 Arch: Consistency of "Transport Services system" and "Trans= port System" (4 by britram, mwelzl, tfpauly) Architecture edi= torial ready for text
#443 Message size (3 by mirjak, mwelzl) API
#451 ECN property? (3 by mirjak, mwelzl, gorryfair) API
#455 Message context (3 by mirjak, mwelzl, tfpauly) API
#457 Framers again... (3 by mirjak, tfpauly, MaxF12) API Implementati= on discuss
#468 Clean up appendix of API (3 by mirjak, mwelzl)
#469 Do we want to keep appendix about Go sample implementation in API doc?= (3 by britram, gorryfair, theri) API
#470 Arch: "the ability to easily adopt different transport protocols"= ;? (3 by mirjak, tfpauly) Architecture editorial
#472 Arch: 4.2.3 could be misinterpreted as connection migration (3 by mirj= ak, britram, tfpauly) Architecture ready for text
#477 Is format of message an implementation detail? (3 by britram, tfpauly,= MaxF12) API
#418 Use of normative language in Arch (2 by gorryfair, theri) Architecture=
#419 Acknowledgements in Arch (2 by mirjak, britram) Architecture =
#435 Default values for Interface Instance and PvD (2 by mirjak, theri) API<= /span>
#436 Local Address Preference always only preferred? (2 by mirjak, mwelzl) = A= PI
#441 Questions on Connection Groups (2 by mirjak, mwelzl) API
#458 New proposed structure for API doc (2 by mirjak, theri) API
#461 Connection Groups, Priority, and Cloning (2 by mirjak, theri) API
#466 Add state diagram to section "Connection State and Ordering of Operat= ions and Events" (2 by mirjak, mwelzl) API Architecture
#414 Is the Local Endpoint "optional"? (1 by britram) Architecture=
#437 Configuring MP use (1 by abrunstrom) API
#448 Right design for Partial Send (1 by tfpauly) API
#462 Timeout for Aborting Connection (1 by mwelzl) API
#475 Arch: UDP checksums as protocol-specific property? (1 by tfpauly) Archi= tecture ready for text

8 issues closed:

#397 Explain that Close isn't Half-Close Architecture
#475 Arch: UDP checksums as protocol-specific property? Architecture = r= eady for text
#471 Arch: Consistency of "Transport Services system" and "Trans= port System" Architecture editorial ready for text
#410 API: Specifying local interfaces as Local Endpoint VS. as a Selection Prop= erty API
#222 Reusing Preconnections? API ready for text
#461 Connection Groups, Priority, and Cloning API
#470 Arch: "the ability to easily adopt different transport protocols"= ;? Architecture editorial
#468 Clean up appendix of API

Pull requests

ietf-tapswg/api-drafts (+11/-17/=F0=9F=92=AC17)

11 pull requests submitted:

#485 U= pdate specific-protocol option example from UDP checksum to TCP UTO (by= tfpauly)
#484 M= ove text removed by #421 to the arch document (by philsbln) Architecture
#483 M= inor API nits (by MaxF12)
#482 B= e more consistent in naming Transport Services (by tfpauly)
#481 C= larify Clone and Priority, closes #461 (by theri)
#480 L= ocal Endpoint vs. Selection Property, closes #410 (by theri)
#479 A= llow reusing Preconnections, fixes #222 (by theri)
#478 C= larify "adopt", summarize sec 2.3 (by theri)
#474 A= rch: Adjust Security Considerations to new Section 4.2.3 (by theri) =
#473 A= rch: Some consistency and clarity fixes (by theri)
#465 N= ew upper section for connection events (by mirjak)

8 pull requests received 17 new comments:

#432 &= quot;must provide sensible defaults" (4 by mirjak, abrunstrom) API<= /span>
#464 R= estructure TCP UTO section (4 by mirjak, mwelzl) API
#484 M= ove text removed by #421 to the arch document (4 by philsbln, abrunstro= m, gorryfair) Architecture
#403 S= ome small proposed fixes (1 by mwelzl) API
#421 P= roposed alternative intro text for API doc (1 by mirjak) API
#442 A= dd one more pointer to Framers (1 by mirjak) API
#444 I= ndicate use of streams for unordered messages as example (1 by abrunstr= om) API
#465 N= ew upper section for connection events (1 by mwelzl) API

17 pull requests merged:

#485 U= pdate specific-protocol option example from UDP checksum to TCP UTO Architectu= re
#460 e= ditorial fix API
#480 L= ocal Endpoint vs. Selection Property, closes #410 API
#479 A= llow reusing Preconnections, fixes #222 API
#456 M= oving section on Message Contexts API
#431 M= ore MAYs? API
#421 P= roposed alternative intro text for API doc API
#412 A= dd one sentence about fallback in sec 2.3 Architecture
#481 C= larify Clone and Priority, closes #461 API
#428 L= ocal/Remote Endpoint type or Object? API
#425 N= ormative language for property namespace API
#403 S= ome small proposed fixes API
#482 B= e more consistent in naming Transport Services
#474 A= rch: Adjust Security Considerations to new Section 4.2.3
#473 A= rch: Some consistency and clarity fixes
#478 C= larify "adopt", summarize sec 2.3
#444 I= ndicate use of streams for unordered messages as example API

Repositories tracked by this digest:

https://github.= com/ietf-tapswg/api-drafts

--===============5739096540536531943==-- From nobody Fri Jan 24 08:02:04 2020 Return-Path: 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 3B601120170 for ; Fri, 24 Jan 2020 08:02:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 bC6OLbs67Yqr for ; Fri, 24 Jan 2020 08:02:00 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 3114D12011F for ; Fri, 24 Jan 2020 08:02:00 -0800 (PST) Received: from smtp-3-0000.mail.infomaniak.ch ([10.4.36.107]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id 00OG1vD6016094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jan 2020 17:01:57 +0100 Received: from [IPv6:2a00:79e0:42:206:1cc2:e52c:22e1:70a7] (unknown [IPV6:2a00:79e0:42:206:1cc2:e52c:22e1:70a7]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id EAB6C1003928D; Fri, 24 Jan 2020 17:01:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1579881717; bh=cT4UdFFcpi4ncp0w6ievIPZNqVckznf0u/Chm7GSFi0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=H3U/8P3DyCv6Zqb6ujZri2ezNJZWNmvmpEYWwZL4BIQwlM4pmU9ovIrXqGOXok1/0 AjBQcP2tvLoNBUQL7eu0tow8C1S9Nh/aVAUVqTNmJLWBYHpdCN9Tjsh1PvKyzIJ01Z 9uOwLojCiraUqZvogZ2+7sGV46yEEV7nZoA3wt4E= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: <02F29C03-4727-42FF-AE4D-EA7CDC5EDB12@gmail.com> Date: Fri, 24 Jan 2020 17:01:56 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <7D92FFE8-9110-49A2-A02E-BF80CD4B8446@trammell.ch> References: <02F29C03-4727-42FF-AE4D-EA7CDC5EDB12@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Reminder: TAPS interim tomorrow (Jan 24) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 16:02:03 -0000 greetings, all, apologies for late notice, had a call scheduled over this, will be there = in 30... cheers B > On 23 Jan 2020, at 22:24, Aaron Falk wrote: >=20 > We=E2=80=99re meeting tomorrow at 1100 EST (1600 GMT). >=20 > Agenda: >=20 > =E2=80=A2 Pending -arch changes following wglc > =E2=80=A2 Open issues for -interface > =E2=80=A2 AOB > Join: https://ietf.webex.com/meet/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jan 24 08:06:58 2020 Return-Path: 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 B0597120858 for ; Fri, 24 Jan 2020 08:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 C_COK4-I6ZZv for ; Fri, 24 Jan 2020 08:06:55 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9BC120170 for ; Fri, 24 Jan 2020 08:06:55 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id j5so1876536qtq.9 for ; Fri, 24 Jan 2020 08:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=gXsypoiP8xGctogSP3CCZCf/QN4bTeyWur6WFCI9YRE=; b=PZbljnYyxAXEpAdODNJ9fy4nXv1II7tylUc2JGvpc9aklyeaDdmUzZo1lbORxPsUgf 8c33YJSFxYJnstxlyBVs154PFGZzdvOzCGIzBn8blVtrgGO3VRy9iPNghycp1ETxwYWg aHTWfd1iR85qu7xvSCMKGcPB8A1iI5PbrUifuJVG1vRpNCGAsqwJoH5oc0dhRDAmYJfX q28Qc+vIiSZ/txgPeLkDocP3ZFutTWoBnSRrKg/7HiMVDBc1HF/SuDTSyJ8zMVsm8VGx J/TcNARPf30UTyzTRGqPSEXPbW5KaQ3UGr/B9aOjFO/yc+kbqwBG3U+MgT38RYLkDfKD d9fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gXsypoiP8xGctogSP3CCZCf/QN4bTeyWur6WFCI9YRE=; b=koUCKBlQH/LVK5dEns6EGanXNF3yEJCxMgsZRMD4j89zJkCYdxm4jp12Rc5ZeNTW+t RM077kYYsIYFthjeJZ9ti8PQW9LFf8QbTzK7iDYF/QOH3V/Srbpnh25O63HEIzrjrIO2 TR/pRVwEa60RnOxbjTCEZ6nUbU0+R+SCktj279q2M3dadFBbuVf1iycMO9aWC8HiORfL ypcLQGvbeK/hPEFnpBPsysDVL6nlBzhIAUL9QkxXxQiTapQr0wYAxBeI3ix3w4MTJyQ5 CH7WBFqHqIsFFfIlMv9bHaU3WziDYk00QRpRaoXAHZrmkxnFi7xn51x1HrCR5FowuBwE 0swA== X-Gm-Message-State: APjAAAV95MVXtD1wv6WL2c/6T39QhurR4BDs9Ux4a4uwowfgdalY1RM9 5oQrs3m2P4YhBoksjPeG8At3RSW5ThI= X-Google-Smtp-Source: APXvYqyrRPDm1COoSuP4MRZ1DT08j18rfoWTTFkVzHZaZUJqdUFgDe1ddEbzldtNbFsuXb4BHBgmUQ== X-Received: by 2002:ac8:5548:: with SMTP id o8mr2958773qtr.338.1579882014426; Fri, 24 Jan 2020 08:06:54 -0800 (PST) Received: from [172.19.113.235] ([2001:4878:a048:3000:34e2:1992:83bb:9d4c]) by smtp.gmail.com with ESMTPSA id 65sm1073461qtc.4.2020.01.24.08.06.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 08:06:53 -0800 (PST) From: "Aaron Falk" To: "Brian Trammell" Cc: "taps WG" Date: Fri, 24 Jan 2020 11:06:50 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <7D92FFE8-9110-49A2-A02E-BF80CD4B8446@trammell.ch> References: <02F29C03-4727-42FF-AE4D-EA7CDC5EDB12@gmail.com> <7D92FFE8-9110-49A2-A02E-BF80CD4B8446@trammell.ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5168D7C9-835E-46AA-96F1-A6D88AE4F35C_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Reminder: TAPS interim tomorrow (Jan 24) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 16:06:58 -0000 --=_MailMate_5168D7C9-835E-46AA-96F1-A6D88AE4F35C_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 30 seconds or minutes? On 24 Jan 2020, at 11:01, Brian Trammell (IETF) wrote: > greetings, all, > > apologies for late notice, had a call scheduled over this, will be > there in 30... > > cheers B > > >> On 23 Jan 2020, at 22:24, Aaron Falk wrote: >> >> We’re meeting tomorrow at 1100 EST (1600 GMT). >> >> Agenda: >> >> • Pending -arch changes following wglc >> • Open issues for -interface >> • AOB >> Join: https://ietf.webex.com/meet/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_5168D7C9-835E-46AA-96F1-A6D88AE4F35C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= p dir=3D"auto">30 seconds or minutes?

On 24 Jan 2020, at 11:01, Brian Trammell (IETF) wrote:

greetings, all,

apologies for late notice, had a call scheduled over this, will be there = in 30...

cheers B

On 23 Jan 2= 020, at 22:24, Aaron Falk <aaron.falk@gmail.com> wrote:

We=E2=80=99re meeting tomorrow at 1100 EST (1600 GMT).

Agenda:

=E2=80=A2 Pending -arch changes following wglc
=E2=80=A2 Open issues for -interface
=E2=80=A2 AOB
Join: h= ttps://ietf.webex.com/meet/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_5168D7C9-835E-46AA-96F1-A6D88AE4F35C_=-- From nobody Fri Jan 24 08:10:53 2020 Return-Path: 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 27DCE120923 for ; Fri, 24 Jan 2020 08:10:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 ixMyMig8Cr4R for ; Fri, 24 Jan 2020 08:10:48 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 6F20412091D for ; Fri, 24 Jan 2020 08:10:48 -0800 (PST) Received: from smtp-3-0001.mail.infomaniak.ch ([10.4.36.108]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id 00OGAk3n030385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jan 2020 17:10:46 +0100 Received: from [IPv6:2a00:79e0:42:206:1cc2:e52c:22e1:70a7] (unknown [IPV6:2a00:79e0:42:206:1cc2:e52c:22e1:70a7]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id C3235100644BD; Fri, 24 Jan 2020 17:10:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1579882246; bh=mbiutNMuIerDhfRZl0JrjJZ5JaMhhYPMs+4aONilNDk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fqiMBCVAxN6O+RRgSV3Pr7BaAe5Ui54effSczsdkbiXmJXuycNLTVPJ4sCyhwNbp4 J8WdwYLBvNWT4uCSlw9q/4JAd2cth2qraH2Vegj7pkJVk8MuGq42bzi+iW4zK/uWmr QwvOBQVAvlseWKngSVqaAw24KbxffvcwzzZHpQHA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: Date: Fri, 24 Jan 2020 17:10:45 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <791A7D80-59FF-4A31-8A59-9012D12FE0BE@trammell.ch> References: <02F29C03-4727-42FF-AE4D-EA7CDC5EDB12@gmail.com> <7D92FFE8-9110-49A2-A02E-BF80CD4B8446@trammell.ch> To: Aaron Falk X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Reminder: TAPS interim tomorrow (Jan 24) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 16:10:51 -0000 minutes. :( > On 24 Jan 2020, at 17:06, Aaron Falk wrote: >=20 > 30 seconds or minutes? >=20 > On 24 Jan 2020, at 11:01, Brian Trammell (IETF) wrote: >=20 > greetings, all, >=20 > apologies for late notice, had a call scheduled over this, will be = there in 30... >=20 > cheers B >=20 >=20 > On 23 Jan 2020, at 22:24, Aaron Falk wrote: >=20 > We=E2=80=99re meeting tomorrow at 1100 EST (1600 GMT). >=20 > Agenda: >=20 > =E2=80=A2 Pending -arch changes following wglc > =E2=80=A2 Open issues for -interface > =E2=80=A2 AOB > Join: https://ietf.webex.com/meet/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Fri Jan 24 10:05:59 2020 Return-Path: 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 105541209A6 for ; Fri, 24 Jan 2020 10:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 cVH-mkxtMG-8 for ; Fri, 24 Jan 2020 10:05:57 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19159120841 for ; Fri, 24 Jan 2020 10:05:57 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id h12so2222481qtu.1 for ; Fri, 24 Jan 2020 10:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=o+w9lFbYwDFtHfn4Qe+n4/DTA/8WDp3cmHTkak51gqk=; b=Vcx0cmQBc6C77pvdc/0CyhQdTZZG6wxxeav6OBBmSkCd5iv1wCThfaQ68IVa3pk21d QpWl60+8idDhUkLIOcLHNdXe26hoL457QBHi9DI9/JAHhmI+2O9ePGn2Lj5USZr19Xys TlSwgTFtVDkOCbrd4ATLPqYHkhtFWmuH0BpJ5tF1e6l+MwZvV2WPTeRwkAnaXlDxPFwv 2ZYYwHyIaasM5NHh/ccbuT4R8LhAqvzD5ibJBPX0cKY6QMmZvxIW/Hg4IAOGfjlLBncR /NcQ2zF24hTYurKt4sNhVB3bAP7v175YL1vYPayqXNzd0Jvi/ThVBEUpmEVPvoxPZHPM e3kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=o+w9lFbYwDFtHfn4Qe+n4/DTA/8WDp3cmHTkak51gqk=; b=VGe3uVK8F9NACu0cJHPasE5DyUQUZVW1eLog6sULG/uMoiRExL3pjrQ2saI/8cTNdZ hD1BAcccIoJXmICerfns7qhK6SdMRIVgrewRPzLUILDxcApBYDFGNCs1etg0adwqlHx0 m1K7KAnmqnOgvCbwGI1UGhTBcuxNpyYIhasi/fxvdC7EnEw7HC/OJMXexmEzRzLvDCOz cWfJ6AuTQDooPlwmtQqcmNBS7GV5veSu569JcMdCex+yjeqek/nLFdNRJduF63tJjFWr c6dDFsprP5hzgC+bvPRobanuvnDfmivVeWwLquZPCj8rd+WEj2SwU/wZNmrmAfe2FxyB tGTA== X-Gm-Message-State: APjAAAXnib1D3x58/KAVaYhnoSHCAwAsMqiFgCqGmdzR58qPkjKLayav OJgGkQcX88lzmOLzL9grARBynXENUT0= X-Google-Smtp-Source: APXvYqzYfu5Ns6P1Zxy+1ihWj4dTZHSV/rBcQLW2bYVYdMdCYefzI5dL3XhQ48IsnrfsU9XFoJKrlQ== X-Received: by 2002:ac8:1415:: with SMTP id k21mr3541911qtj.300.1579889155646; Fri, 24 Jan 2020 10:05:55 -0800 (PST) Received: from [172.19.113.235] ([2001:4878:a048:3000:34e2:1992:83bb:9d4c]) by smtp.gmail.com with ESMTPSA id x8sm3532494qki.60.2020.01.24.10.05.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 10:05:53 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Fri, 24 Jan 2020 13:05:51 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: <62897EE9-2482-4951-BA19-F11EDC55DF7A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8420A668-4B18-4C83-A660-12E5E1EFAA53_=" Archived-At: Subject: [Taps] notes from TAPS Jan 24 interim X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 18:05:59 -0000 --=_MailMate_8420A668-4B18-4C83-A660-12E5E1EFAA53_= Content-Type: text/plain; format=flowed; markup=markdown Architecture doc * Resolved most open issues with writing assignments; resolved all open PRs; revised draft needed * Open issue about use of normative language ([issue](https://github.com/ietf-tapswg/api-drafts/issues/418)); * Agreed to hold publication request until API and implementation docs are ready Implementation doc * Reviewed & resolved some open issues; reviewed some PRs; more work to do Next TAPS interim: * Feb 21 1100 EST (1600 GST) * 2 hours * https://ietf.webex.com/meet/taps * Agenda: * Resolve arch normative language issue (if still open) * Work through API issues & PRs --=_MailMate_8420A668-4B18-4C83-A660-12E5E1EFAA53_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Architecture doc

Resolved most open issues with writing assignments; resolved all open= PRs; revised draft needed
Open issue about use of normative language (issue);

Agreed to hold publication request until API and implementation docs = are ready

Implementation doc

Reviewed & resolved some open issues; reviewed some PRs; more wor= k to do

Next TAPS interim:

Feb 21 1100 EST (1600 GST)

2 hours

= https://ietf.webex.com/meet/taps
Agenda:
- Resolve arch normative language issue (if still open)
- Work through API issues & PRs

--=_MailMate_8420A668-4B18-4C83-A660-12E5E1EFAA53_=-- From nobody Fri Jan 31 00:02:22 2020 Return-Path: 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 7F1251200A4 for ; Fri, 31 Jan 2020 00:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 fKzaGxdny531 for ; Fri, 31 Jan 2020 00:02:18 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 21F1C12009E for ; Fri, 31 Jan 2020 00:02:18 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1ixRDh-0004em-CL for taps@ietf.org; Fri, 31 Jan 2020 08:00:05 +0000 Content-Type: multipart/alternative; boundary="===============4229291873097770827==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 31 Jan 2020 08:00:05 +0000 Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 08:02:21 -0000 --===============4229291873097770827== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+2/-6/=F0=9F=92=AC38) 2 issues created: - Comments on DSCP text (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/494 [API] = - Fig. 4: fix terminology mismatch with API sec. 12 (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/489 [Architecture] = 16 issues received 38 new comments: - #441 Questions on Connection Groups (12 by abrunstrom, mirjak, mwelzl, = MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/441 [API] = - #429 section algorithm (text in API doc) (5 by philsbln, mwelzl, theri) https://github.com/ietf-tapswg/api-drafts/issues/429 [API] = - #413 Do we need to say more about authentication and encryption? (3 by = tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/413 [Architecture] [re= ady for text] = - #416 add example for "information about the received Message"? (2 by tf= pauly) https://github.com/ietf-tapswg/api-drafts/issues/416 [Architecture] [ed= itorial] [ready for text] = - #417 Add Framer to Figure 3 (2 by mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/417 [Architecture] = - #489 Fig. 4: fix terminology mismatch with API sec. 12 (2 by britram, m= welzl) https://github.com/ietf-tapswg/api-drafts/issues/489 [Architecture] [re= ady for text] = - #177 Privacy considerations section (2 by tfpauly, csperkins) https://github.com/ietf-tapswg/api-drafts/issues/177 [API] [Implementat= ion] [ready for text] = - #476 Arch: service class influences protocol selection? (2 by gorryfair= , tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/476 [Architecture] [re= ady for text] = - #418 Use of normative language in Arch (1 by theri) https://github.com/ietf-tapswg/api-drafts/issues/418 [Architecture] [di= scuss] = - #420 Where to define Connection Group? (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/420 [Architecture] [ed= itorial] = - #427 API, sec 5: SHOULD add Framers (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/427 [API] = - #466 Add state diagram to section "Connection State and Ordering of Ope= rations and Events" (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/466 [API] [Architectur= e] = - #409 Security: Connection and Post-Connection Interfaces (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/409 [API] [discuss] = - #440 Why do we use functions to set security parameters... (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/440 [API] = - #446 Do we need msg-reliable and lifetime? (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/446 [API] = - #447 Is "Singular Transmission" the right term (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/447 [API] = 6 issues closed: - Where to define Connection Group? https://github.com/ietf-tapswg/api-dr= afts/issues/420 [Architecture] [editorial] = - Acknowledgements in Arch https://github.com/ietf-tapswg/api-drafts/issu= es/419 [Architecture] = - Fig. 4: fix terminology mismatch with API sec. 12 https://github.com/ie= tf-tapswg/api-drafts/issues/489 [Architecture] [ready for text] = - Do we want to keep appendix about Go sample implementation in API doc? = https://github.com/ietf-tapswg/api-drafts/issues/469 [API] = - Is the Local Endpoint "optional"? https://github.com/ietf-tapswg/api-dr= afts/issues/414 [API] = - Security: Connection and Post-Connection Interfaces https://github.com/= ietf-tapswg/api-drafts/issues/409 [API] [discuss] = Pull requests ------------- * ietf-tapswg/api-drafts (+11/-6/=F0=9F=92=AC11) 11 pull requests submitted: - Justify why TCP UTO is included (by theri) https://github.com/ietf-tapswg/api-drafts/pull/499 = - Default for interface and PvD is no preference, fixes #435 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/498 = - Refactor Local Address Preference, fixes #436 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/497 = - Add justification and normative language, fixes #429 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/496 = - Minor fixes with messageContexts, fixes #408 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/495 = - figure 4 tweaks, fix #489 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/493 = - Remove Go API illustration, fix #469 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/492 = - Connection Groups are objects, fix #420 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/491 = - acknowledge all contributors to architecture discussions (by britram) https://github.com/ietf-tapswg/api-drafts/pull/490 = - add framer, fix #417 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/488 = - Make the singular transmission text clearer (by adventureloop) https://github.com/ietf-tapswg/api-drafts/pull/487 = 5 pull requests received 11 new comments: - #432 "must provide sensible defaults" (4 by mirjak, abrunstrom, tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/432 [API] = - #487 Make the singular transmission text clearer (2 by adventureloop, g= orryfair) https://github.com/ietf-tapswg/api-drafts/pull/487 [Implementation] = - #490 acknowledge all contributors to architecture discussions (2 by bri= tram) https://github.com/ietf-tapswg/api-drafts/pull/490 [Architecture] = - #465 New upper section for connection events (2 by mirjak, britram) https://github.com/ietf-tapswg/api-drafts/pull/465 [API] = - #463 Mostly Editorial changes on Capacity Profile (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/463 [API] = 6 pull requests merged: - Connection Groups are objects, fix #420 https://github.com/ietf-tapswg/api-drafts/pull/491 [Architecture] = - acknowledge all contributors to architecture discussions https://github.com/ietf-tapswg/api-drafts/pull/490 [Architecture] = - figure 4 tweaks, fix #489 https://github.com/ietf-tapswg/api-drafts/pull/493 = - Remove Go API illustration, fix #469 https://github.com/ietf-tapswg/api-drafts/pull/492 = - Move text removed by #421 to the arch document https://github.com/ietf-tapswg/api-drafts/pull/484 [Architecture] = - Restructure TCP UTO section https://github.com/ietf-tapswg/api-drafts/pull/464 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============4229291873097770827== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday January 31, 2020

Issues

ietf-tapswg/api-drafts (+2/-6/=F0=9F=92=AC38)

2 issues created:

#494 Comments on DSCP text (by gorryfair) API
#489 Fig. 4: fix terminology mismatch with API sec. 12 (by mwelzl) Architect= ure

16 issues received 38 new comments:

#441 Questions on Connection Groups (12 by abrunstrom, mirjak, mwelzl, MaxF= 12) API
#429 section algorithm (text in API doc) (5 by philsbln, mwelzl, theri) API<= /span>
#413 Do we need to say more about authentication and encryption? (3 by tfpa= uly) Architecture ready for text
#416 add example for "information about the received Message"? (2= by tfpauly) Architecture editorial ready for text
#417 Add Framer to Figure 3 (2 by mwelzl, tfpauly) Architecture
#489 Fig. 4: fix terminology mismatch with API sec. 12 (2 by britram, mwelz= l) ready for text
#177 Privacy considerations section (2 by tfpauly, csperkins) API <= span class=3D"label" style=3D"background-color: #fbca04; color: #000000">Im= plementation ready for text
#476 Arch: service class influences protocol selection? (2 by gorryfair, tf= pauly) Architecture ready for text
#418 Use of normative language in Arch (1 by theri) Architecture discu= ss
#420 Where to define Connection Group? (1 by tfpauly) Architecture edi= torial
#427 API, sec 5: SHOULD add Framers (1 by tfpauly) API
#466 Add state diagram to section "Connection State and Ordering of Operat= ions and Events" (1 by britram) API Architecture
#409 Security: Connection and Post-Connection Interfaces (1 by tfpauly) API<= /span> discuss
#440 Why do we use functions to set security parameters... (1 by mwelzl) API=
#446 Do we need msg-reliable and lifetime? (1 by mwelzl) API
#447 Is "Singular Transmission" the right term (1 by gorryfair) <= span class=3D"label" style=3D"background-color: #fbca04; color: #000000">AP= I

6 issues closed:

#420 Where to define Connection Group? Architecture editorial <= /li> =
#419 Acknowledgements in Arch Architecture
#489 Fig. 4: fix terminology mismatch with API sec. 12 Architecture <= span class=3D"label" style=3D"background-color: #4ae0d1; color: #000000">re= ady for text
#469 Do we want to keep appendix about Go sample implementation in API doc?= = API
#414 Is the Local Endpoint "optional"? API
#409 Security: Connection and Post-Connection Interfaces API discuss

Pull requests

ietf-tapswg/api-drafts (+11/-6/=F0=9F=92=AC11)

11 pull requests submitted:

#499 J= ustify why TCP UTO is included (by theri)
#498 D= efault for interface and PvD is no preference, fixes #435 (by theri) =
#497 R= efactor Local Address Preference, fixes #436 (by theri)
#496 A= dd justification and normative language, fixes #429 (by theri)
#495 M= inor fixes with messageContexts, fixes #408 (by theri)
#493 f= igure 4 tweaks, fix #489 (by britram)
#492 R= emove Go API illustration, fix #469 (by britram)
#491 C= onnection Groups are objects, fix #420 (by britram)
#490 a= cknowledge all contributors to architecture discussions (by britram) =
#488 a= dd framer, fix #417 (by britram)
#487 M= ake the singular transmission text clearer (by adventureloop)

5 pull requests received 11 new comments:

#432 &= quot;must provide sensible defaults" (4 by mirjak, abrunstrom, tfp= auly) API
#487 M= ake the singular transmission text clearer (2 by adventureloop, gorryfa= ir) Implementation
#490 a= cknowledge all contributors to architecture discussions (2 by britram) = A= rchitecture
#465 N= ew upper section for connection events (2 by mirjak, britram) API=
#463 M= ostly Editorial changes on Capacity Profile (1 by mirjak) API <= /li>

6 pull requests merged:

#491 C= onnection Groups are objects, fix #420 Architecture
#490 a= cknowledge all contributors to architecture discussions Architecture =
#493 f= igure 4 tweaks, fix #489
#492 R= emove Go API illustration, fix #469
#484 M= ove text removed by #421 to the arch document Architecture
#464 R= estructure TCP UTO section API

Repositories tracked by this digest:

https://github.= com/ietf-tapswg/api-drafts

--===============4229291873097770827==--

Friday January 03, 2020

Issues

ietf-tapswg/api-drafts (+0/-1/=F0=9F=92=AC0)

Pull requests

ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC0)

Repositories tracked by this digest:

Friday January 17, 2020

Issues

ietf-tapswg/api-drafts (+22/-0/=F0=9F=92=AC23)

Pull requests

ietf-tapswg/api-drafts (+19/-9/=F0=9F=92=AC6)

Repositories tracked by this digest:

Friday January 24, 2020

Issues

ietf-tapswg/api-drafts (+11/-8/=F0=9F=92=AC68)

Pull requests

ietf-tapswg/api-drafts (+11/-17/=F0=9F=92=AC17)

Repositories tracked by this digest:

Friday January 31, 2020

Issues

ietf-tapswg/api-drafts (+2/-6/=F0=9F=92=AC38)

Pull requests

ietf-tapswg/api-drafts (+11/-6/=F0=9F=92=AC11)

Repositories tracked by this digest: