From tpauly@apple.com Mon Dec 11 12:58:14 2023 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 D84E8C14CE51 for ; Mon, 11 Dec 2023 12:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.103 X-Spam-Level: X-Spam-Status: No, score=-7.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6dXH3tQWyh2 for ; Mon, 11 Dec 2023 12:58:12 -0800 (PST) Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB15DC15108C for ; Mon, 11 Dec 2023 12:58:12 -0800 (PST) Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5I00OL1SWR0700@ma-mailsvcp-mx-lapp02.apple.com> for taps@ietf.org; Mon, 11 Dec 2023 12:58:11 -0800 (PST) X-Proofpoint-ORIG-GUID: dRYqCUn0GOwhvNQeorzwZElGbT26uyR9 X-Proofpoint-GUID: dRYqCUn0GOwhvNQeorzwZElGbT26uyR9 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-11_09:2023-12-07, 2023-12-11 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 bulkscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 suspectscore=0 malwarescore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312110173 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=cEikpv89D1a8gHtHDhAVnIXbqQVr2Hi7wwDBuSIOJQw=; b=HKzbAmzNr8fDtkIsdpjh/vuBUeEBglLC1aaYPr97sqGIIBz7+vH35T6ZkB1npsYAKpj7 LS4d689fBFqmdJZ4MS8gUpjIdu6N1g/MW7Z2V8rLyclby/nwassUfbOi5C4yjF5M1pmg 92N/6jfvaa/qO2I1IpihM0TD3pNbAablRSbh5WZoPbbO/EjpWt9XIfu6X3Dg32NWsMOr ZZrhZxsSxiu5gDHhO7Dp1zlVgqPYDlo2DDUalkOsG+wWDanLCZkqupsQR4US8GHJToXs V7tU/vtUOCuM38IFs46/MguM5t4Zw0ATwfXXrMXhRG+Is3QZcm3EAM0mB0g+kRzrEkmM sw== Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5I00WJ1SWQF5Z0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 11 Dec 2023 12:58:03 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S5I00300STSD000@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 11 Dec 2023 12:58:02 -0800 (PST) X-Va-A: X-Va-T-CD: e52bc99798a6b8983ba7b5634300aea3 X-Va-E-CD: 131c43a3a6412cc28a5b861b2a311273 X-Va-R-CD: c06fad883c61093726cf88396f321272 X-Va-ID: fa6d95cb-d17d-4269-9fb0-b40c3591be88 X-Va-CD: 0 X-V-A: X-V-T-CD: e52bc99798a6b8983ba7b5634300aea3 X-V-E-CD: 131c43a3a6412cc28a5b861b2a311273 X-V-R-CD: c06fad883c61093726cf88396f321272 X-V-ID: c841be02-0dff-40f1-be7c-31328aeab596 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-11_09:2023-12-07, 2023-12-11 signatures=0 Received: from smtpclient.apple ([17.11.230.175]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S5I00UBRSVMX100@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 11 Dec 2023 12:58:02 -0800 (PST) From: Tommy Pauly Message-id: <4A7A0573-E1B6-42D8-955B-AB5DA7098F07@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_275C0D5B-8851-4EC3-809B-257548EE11C1" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Date: Mon, 11 Dec 2023 12:57:52 -0800 In-reply-to: Cc: The IESG , draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, =?utf-8?Q?Anna_Brunstr=C3=B6m?= To: Lars Eggert References: <169408439315.13814.3746604129872399062@ietfa.amsl.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) Archived-At: Subject: Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.39 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, 11 Dec 2023 20:58:14 -0000 --Apple-Mail=_275C0D5B-8851-4EC3-809B-257548EE11C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Lars, Thanks again for your review =E2=80=94 just a quick reminder to please = take a look at the updates, and let us know if there=E2=80=99s anything = else that needs to be addressed to clear your DISCUSS. Best, Tommy > On Nov 14, 2023, at 9:17=E2=80=AFAM, Tommy Pauly = wrote: >=20 > Hi Lars, >=20 > Thanks for your detailed review! The authors appreciate the helpful = comments. >=20 > The authors have just posted a -23 version that addresses the IESG = comments, including your DISCUSS. = https://www.ietf.org/archive/id/draft-ietf-taps-interface-23.html >=20 > Below, I=E2=80=99ve added inline responses to each DISCUSS point. >=20 > Best, > Tommy (on behalf of the authors) >=20 >> On Sep 7, 2023, at 3:59=E2=80=AFAM, Lars Eggert via Datatracker = wrote: >>=20 >> Lars Eggert has entered the following ballot position for >> draft-ietf-taps-interface-22: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position= s/=20 >> for more information about how to handle DISCUSS and COMMENT = positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> # GEN AD review of draft-ietf-taps-interface-22 >>=20 >> CC @larseggert >>=20 >> Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) = review >> = (https://mailarchive.ietf.org/arch/msg/gen-art/Uohwi2MvOOwswMfkE5w4mt9IZKE= ). >>=20 >> ## Discuss >>=20 >> ### Section 4.1, paragraph 8 >> ``` >> * For IETF protocols, the name of a Protocol-specific Property >> SHOULD be specified in an IETF document published in the RFC >> Series. >> ``` >> For IETF protocols, i.e., protocols published on the IETF RFC stream, >> those names must IMO be also specified in IETF-stream RFCs. I see no >> reason to let other RFC streams make definitions for IETF protocols. >=20 > This now reads: "For IETF protocols, the name of a Protocol-specific = Property SHOULD be specified in an IETF document published in the RFC = Series after IETF review.=E2=80=9D >=20 >>=20 >> ### Section 6.1, paragraph 13 >> ``` >> * Interface name (string), e.g., to qualify link-local or = multicast >> addresses (see Section 6.1.2 for details): >>=20 >> LocalSpecifier.WithInterface("en0") >> ``` >> How does an application learn which interface name strings are >> allowed/available on the system? The API doesn't seem to provide this >> information. Also, based on the examples, there seem to be special >> names such as "any" - where are those defined and how are conflicts >> with names used on the system avoided? >=20 > This is addressed with = https://github.com/ietf-tapswg/api-drafts/pull/1456 >=20 > This updates the text to allow the =E2=80=9CResolve=E2=80=9D = functionality for Rendezvous to be used generically to enumerate = interfaces/addresses. >=20 >>=20 >> ### Section 6.1.3, paragraph 6 >> ``` >> In order to scope an alias to a specific transport protocol, an >> Endpoint can specify a protocol identifier. >>=20 >> AlternateRemoteSpecifier.WithProtocol(QUIC) >> ``` >> This is the first and only time protocol identifiers are used. What >> are they defined to be? >=20 >>=20 >> ### Section 6.1.3, paragraph 9 >> ``` >> The following example shows a case where example.com has a server >> running on port 443, with an alternate port of 8443 for QUIC. >>=20 >> RemoteSpecifier :=3D NewRemoteEndpoint() >> RemoteSpecifier.WithHostname("example.com") >> RemoteSpecifier.WithPort(443) >>=20 >> QUICRemoteSpecifier :=3D NewRemoteEndpoint() >> QUICRemoteSpecifier.WithHostname("example.com") >> QUICRemoteSpecifier.WithPort(8443) >> QUICRemoteSpecifier.WithProtocol(QUIC) >>=20 >> RemoteSpecifier.AddAlias(QUICRemoteSpecifier) >> ``` >> Why does the `RemoteSpecifier` definition not contain a = `WithProtocol` >> clause for TCP/TLS? And what would that look like, given that TCP/TLS >> is a protocol combination? >=20 > These comments around protocol-specific endpoints are addressed with = https://github.com/ietf-tapswg/api-drafts/pull/1408 and = https://github.com/ietf-tapswg/api-drafts/pull/1451 >=20 > The text now clarifies that the values for the protocol scoping here = are implementation-provided enumerations. >=20 > "To scope an Endpoint to apply conditionally to a specific transport > protocol (such as defining an alternate port to use when QUIC > is selected, as opposed to TCP), an Endpoint can be > associated with a protocol identifier. Protocol identifiers are > objects or enumeration values provided by the Transport > Services API, which will vary based on which protocols are > implemented in a particular system." >=20 > The reason to show one protocol being specified with an override is to = show how there=E2=80=99s a default endpoint that the connection should = use, and it should conditionally load an alternate when using a = particular protocol. This then doesn=E2=80=99t constrain the protocol = stacks being used, but only customizes the endpoint in case a particular = protocol is loaded. >=20 >>=20 >> ### Section 6.2, paragraph 0 >> ``` >> 6.2. Specifying Transport Properties >> ``` >> This section defines a boatload of different properties, many of = which >> are interacting with each other due to how our current transport >> protocols are implemented. Future interactions, due to future >> transport protocols potentially becoming available, are undefined. I >> question how a potential programmer is supposed to make informed >> choices here without needing to be aware of all of this >> background/baggage? >=20 > Please see comments on = https://github.com/ietf-tapswg/api-drafts/issues/1334 >=20 > "Complex interactions may exist between socket options in the existing = BSD sockets API. > There are also implementations of TAPS systems available, at least one = of which is fairly comprehensive. > Future interactions of properties of future protocols are also unclear = in the BSD sockets API. >=20 > In a sense, we offer a safer set of options than BSD sockets, as we = have constrained the generic ones to the set of properties that do not = constrain selection amongst existing protocols. Everything that is = protocol-specific goes in its own protocol namespace and only applies = when this protocol is selected. The intent is for future = protocol-specific options to also be categorized that way. We cannot = guarantee that no future transport protocol will somehow be constrained = by our generic properties, but the analysis in our prior RFCs = (specifically the minset RFC) leads us to believe that we have chosen a = workable subset." >=20 >>=20 >> ### Section 8.1.5, paragraph 4 >> ``` >> Default: Weighted Fair Queueing (see Section 3.6 in [RFC8260]) >>=20 >> This property specifies which scheduler should be used among >> Connections within a Connection Group, see Section 7.4. A set of >> schedulers is described in [RFC8260]. >> ``` >> What is this scheduler scheduling? 7.4 is silent on this. I'm = guessing >> this is related to `connPriority`? >=20 > Yes, thank you; we clarified this in the text by adding a reference to = the conn priority with = https://github.com/ietf-tapswg/api-drafts/pull/1393 >=20 >>=20 >> ### Section 9.1.3, paragraph 9 >> ``` >> If a Message Property contradicts a Connection Property, and if = this >> per-Message behavior can be supported, it overrides the = Connection >> Property for the specific Message. For example, if reliability = is >> set to Require and a protocol with configurable per-Message >> reliability is used, setting msgReliable to false for a = particular >> Message will allow this Message to be sent without any = reliability >> guarantees. Changing the msgReliable Message Property is only >> possible for Connections that were established enabling the = Selection >> Property perMsgReliability. >> ``` >> How is this going to work in the opposite case, i.e., if an = unreliable >> connection was set up and then some messages are passed in which >> require reliable transmission? At connection open, the stack may have >> chosen a transport protocol that cannot support reliable >> transmission? (Also, I think this general principle of message > >> connection has other issues for other properties.) >=20 > This is addressed with = https://github.com/ietf-tapswg/api-drafts/pull/1397, which clarifies: >=20 > "If the contradicting Message Property > cannot be supported by the Connection (such as requiring reliability > on a Connection that uses an unreliable protocol), the `Send` action > will result in a `SendError` event." >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_275C0D5B-8851-4EC3-809B-257548EE11C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Lars,

Thanks again for your review =E2=80=94 = just a quick reminder to please take a look at the updates, and let us = know if there=E2=80=99s anything else that needs to be addressed to = clear your = DISCUSS.

Best,
Tommy

On Nov 14, 2023, at 9:17=E2=80=AFAM, Tommy = Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Hi Lars,

Thanks for your detailed review! The authors = appreciate the helpful comments.

The authors have just posted a -23 version that = addresses the IESG comments, including your DISCUSS. https://www.ietf.org/archive/id/draft-ietf-taps-interface-23.html

Below, I=E2=80=99ve added inline responses to each DISCUSS = point.

Best,
Tommy (on behalf of the authors)

On Sep 7, = 2023, at 3:59=E2=80=AFAM, Lars Eggert via Datatracker = <noreply@ietf.org> wrote:

Lars Eggert has entered = the following ballot position for
draft-ietf-taps-interface-22: = Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. (Feel = free to cut this
introductory paragraph, however.)


Please = refer to = https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position= s/ 
for more = information about how to handle DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found = here:
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/


----------------------------------------------------------------= ------
DISCUSS:
----------------------------------------------------= ------------------

# GEN AD review of = draft-ietf-taps-interface-22

CC @larseggert

Thanks to = Thomas Fossati for the General Area Review Team (Gen-ART) = review
(https://mailarchive.ietf.org/arch/msg/gen-art/Uohwi2MvOOwswMfkE= 5w4mt9IZKE).

## Discuss

### Section 4.1, paragraph = 8
```
    *  For IETF protocols, the name = of a Protocol-specific = Property
       SHOULD be = specified in an IETF document published in the = RFC
       Series.
```
For = IETF protocols, i.e., protocols published on the IETF RFC = stream,
those names must IMO be also specified in IETF-stream RFCs. I = see no
reason to let other RFC streams make definitions for IETF = protocols.

This now reads: = "For IETF protocols, the name of a Protocol-specific Property SHOULD be = specified in an IETF document published in the RFC Series after IETF = review.=E2=80=9D


### = Section 6.1, paragraph 13
```
    * =  Interface name (string), e.g., to qualify link-local or = multicast
       addresses (see = Section 6.1.2 for = details):

    LocalSpecifier.WithInterface("en0= ")
```
How does an application learn which interface name strings = are
allowed/available on the system? The API doesn't seem to provide = this
information. Also, based on the examples, there seem to be = special
names such as "any" - where are those defined and how are = conflicts
with names used on the system = avoided?


This = updates the text to allow the =E2=80=9CResolve=E2=80=9D functionality = for Rendezvous to be used generically to enumerate = interfaces/addresses.


###= Section 6.1.3, paragraph 6
```
    In order = to scope an alias to a specific transport protocol, = an
    Endpoint can specify a protocol = identifier.

    AlternateRemoteSpecifier.WithPr= otocol(QUIC)
```
This is the first and only time protocol = identifiers are used. What
are they defined to = be?

### = Section 6.1.3, paragraph 9
```
    The = following example shows a case where example.com has a = server
    running on port 443, with an alternate = port of 8443 for QUIC.

    RemoteSpecifier :=3D= = NewRemoteEndpoint()
    RemoteSpecifier.WithHostnam= e("example.com")
    RemoteSpecifier.WithPort(443)<= br>
    QUICRemoteSpecifier :=3D = NewRemoteEndpoint()
    QUICRemoteSpecifier.WithHos= tname("example.com")
    QUICRemoteSpecifier.WithPo= rt(8443)
    QUICRemoteSpecifier.WithProtocol(QUIC)=

    RemoteSpecifier.AddAlias(QUICRemoteSpecifi= er)
```
Why does the `RemoteSpecifier` definition not contain a = `WithProtocol`
clause for TCP/TLS? And what would that look like, = given that TCP/TLS
is a protocol = combination?

These = comments around protocol-specific endpoints are addressed with https://githu= b.com/ietf-tapswg/api-drafts/pull/1408 and https://githu= b.com/ietf-tapswg/api-drafts/pull/1451

T= he text now clarifies that the values for the protocol scoping here are = implementation-provided enumerations.

"To scope = an Endpoint to apply conditionally to a specific = transport
 protocol (such as defining an alternate port = to use when QUIC
 is selected, as opposed to TCP), an = Endpoint can be
 associated with a protocol identifier. = Protocol identifiers are
 objects or enumeration values = provided by the Transport
 Services API, which will vary = based on which protocols are
implemented in a particular = system."

The reason to show one protocol being = specified with an override is to show how there=E2=80=99s a default = endpoint that the connection should use, and it should conditionally = load an alternate when using a particular protocol. This then doesn=E2=80=99= t constrain the protocol stacks being used, but only customizes the = endpoint in case a particular protocol is = loaded.


### = Section 6.2, paragraph 0
```
 6.2.  Specifying Transport = Properties
```
This section defines a boatload of different = properties, many of which
are interacting with each other due to how = our current transport
protocols are implemented. Future interactions, = due to future
transport protocols potentially becoming available, are = undefined. I
question how a potential programmer is supposed to make = informed
choices here without needing to be aware of all of = this
background/baggage?

Ple= ase see comments on https://git= hub.com/ietf-tapswg/api-drafts/issues/1334

"Complex = interactions may exist between socket options in the existing BSD = sockets API.
There are also implementations of TAPS systems available, at = least one of which is fairly comprehensive.
Future = interactions of properties of future protocols are also unclear in the = BSD sockets API.

In a sense, we offer a safer set of options than = BSD sockets, as we have constrained the generic ones to the set of = properties that do not constrain selection amongst existing protocols. = Everything that is protocol-specific goes in its own protocol namespace = and only applies when this protocol is selected. The intent is for = future protocol-specific options to also be categorized that way. We = cannot guarantee that no future transport protocol will somehow be = constrained by our generic properties, but the analysis in our prior = RFCs (specifically the minset RFC) leads us to believe that we have = chosen a workable subset."


### = Section 8.1.5, paragraph 4
```
    Default: =  Weighted Fair Queueing (see Section 3.6 in = [RFC8260])

    This property specifies which = scheduler should be used among
    Connections = within a Connection Group, see Section 7.4.  A set = of
    schedulers is described in = [RFC8260].
```
What is this scheduler scheduling? 7.4 is silent on = this. I'm guessing
this is related to = `connPriority`?

Yes, thank = you; we clarified this in the text by adding a reference to the conn = priority with https://githu= b.com/ietf-tapswg/api-drafts/pull/1393


### = Section 9.1.3, paragraph 9
```
    If a = Message Property contradicts a Connection Property, and if = this
    per-Message behavior can be supported, = it overrides the Connection
    Property for the = specific Message.  For example, if reliability = is
    set to Require and a protocol with = configurable per-Message
    reliability is used, = setting msgReliable to false for a = particular
    Message will allow this Message to = be sent without any reliability
    guarantees. =  Changing the msgReliable Message Property is = only
    possible for Connections that were = established enabling the Selection
    Property = perMsgReliability.
```
How is this going to work in the opposite = case, i.e., if an unreliable
connection was set up and then some = messages are passed in which
require reliable transmission? At = connection open, the stack may have
chosen a transport protocol that = cannot support reliable
transmission? (Also, I think this general = principle of message >
connection has other issues for other = properties.)

This is = addressed with https://githu= b.com/ietf-tapswg/api-drafts/pull/1397, which clarifies:

"If the = contradicting Message Property
 cannot be supported by the = Connection (such as requiring reliability
 on a = Connection that uses an unreliable protocol), the `Send` = action
 will result in a `SendError` = event."


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

= --Apple-Mail=_275C0D5B-8851-4EC3-809B-257548EE11C1--