From nobody Fri Mar 1 13:18:14 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 849E5131222; Fri, 1 Mar 2019 13:10:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147461553.6101.1387966729599907769.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:15 -0800 Archived-At: Subject: [Taps] taps - Requested session has been scheduled for IETF 104 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:31 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:00 requested) Friday, 29 March 2019, Morning Session II 1050-1250 Room Name: Karlin 1/2 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/taps.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpbis ipsecme rtcweb avtcore capport tls panrg quic tsvarea rmcat ippm tsvwg iccrg tcpm dispatch maprg cfrg intarea Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Colin Perkins Aaron Falk Michael Welzl Gorry Fairhurst Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Anna Brunstrom Tommy Pauly Kyle Rose Christopher A. Wood Philipp S. Tiesel Theresa Enghardt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Mar 4 10:53:09 2019 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 96059130F07 for ; Mon, 4 Mar 2019 10:53:07 -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_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 VHMlBPiwqUMK for ; Mon, 4 Mar 2019 10:53:05 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 717BB130F32 for ; Mon, 4 Mar 2019 10:53:05 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id z39so6286104qtz.0 for ; Mon, 04 Mar 2019 10:53:05 -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; bh=K7edtg3KMLk2ZG+yb+q9vPPwHumhDV5CYFogneIKhTk=; b=S3FNQ6fW9yolYaXhfwuhdzvBVvSniemEZ5jHFtzIg2atTD+zho+dncQV+mmtUWQWPm qiCJ6FeemIc5ECwp1FPEXt3TYhxWthmWAFZ869uGOL66itQg5q7OCWsJ2JSEb692scz5 Rm9/Z6F/PaZiTSp4Xe5v4/sw7ToYD2kxJDhTPbORuHhTUf10aUfR+Wd2QXheINZ8WKqj rvYTA3vQas2diRQ1u2l7l6LCbIEDh36ZWynGulFeikTU9NNNciFfbQZwv/YrbcUg0bWN rn1PUfLu/shG+5wR4m6APQ8OC7Fk7EyBCWf0wyXlqHbx94E0DDcwyy9bEwQZFYAKcSoJ /g7g== 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; bh=K7edtg3KMLk2ZG+yb+q9vPPwHumhDV5CYFogneIKhTk=; b=VBZt8Vl8rzsEnHzK3NkTZ2oB13I8uyws2bFiPZ9jO4M9QEUhb6ZYt9I8GN9sAj0qqJ tO3shqiRkRD9kN+dSMivfgazZK2dqPFL/lTfqMPRYqi64W2Nthnti+LILcFJ6GDh33mF WamVdPrmu6CG4w3VPnY8wVt5oiPthQLf6A/k9J+klU9LXoEBU5WNtcj3vFGEzti2h8Ae VkLt6tKBpBCRSNBdDjhnm/jV9hjbS4Lv3P/zSZgjPb7+2oFx86IhfG/5JxEdzLxzGzz1 4wbpKZ9pgL5S4ZVfk3B1PdsO1GxWl+8cvwEe+SVAJ3EBPYf/rDZCKKj+fdxismyJBhEq 9XKw== X-Gm-Message-State: APjAAAW7gE+NU2lfP4RloaenmdJ8qMVlZV6iek8OrwfRmTE1TThXBZsY 8M4scWKWcdo0BPY0VIqylpV3Pjcf X-Google-Smtp-Source: APXvYqzhXYCmaHXxQmgTXj6c7HppRkLRrGeO4HDakT+oOlMO6/uoccjtYoIl0Sycq0vyQo5pJx/05Q== X-Received: by 2002:aed:23c6:: with SMTP id k6mr15492562qtc.244.1551725584003; Mon, 04 Mar 2019 10:53:04 -0800 (PST) Received: from [172.19.38.78] ([2601:184:497f:bb25:5414:65ea:35bd:a799]) by smtp.gmail.com with ESMTPSA id a68sm4228902qkj.82.2019.03.04.10.53.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 10:53:03 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" Date: Mon, 04 Mar 2019 13:53:01 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0999F2B9-4165-4457-9CC4-F504962F2FA4_=" Archived-At: Subject: [Taps] call for agenda items at TAPS IETF-104 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, 04 Mar 2019 18:53:08 -0000 --=_MailMate_0999F2B9-4165-4457-9CC4-F504962F2FA4_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi All- What should we use our time to discuss? Let=E2=80=99s focus on things th= at = would benefit from f2f discussion, consensus building, or just argument. = :) * TAPS docs: are there open topics that need group attention? Seems = like we settled most of the remainder at the interim. * TAPS security: this seems nearly done. Anything to discuss? * Implementations: a good topic for information sharing but less = important than anything needing agreement * Mobility: [non-TAPS draft on API & = mobility](https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-17= ) = and [incoming TSV AD suggestion to = collaborate](https://datatracker.ietf.org/doc/review-ietf-dmm-ondemand-mo= bility-15-tsvart-lc-westerlund-2019-01-08/) --aaron --=_MailMate_0999F2B9-4165-4457-9CC4-F504962F2FA4_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi All-

What should we use our time to discuss? Let=E2=80=99s fo= cus on things that would benefit from f2f discussion, consensus building,= or just argument. :)

  • TAPS docs: are there open topics that need group attention? Seems li= ke we settled most of the remainder at the interim.
  • TAPS security: this seems nearly done. Anything to discuss?
  • Implementations: a good topic for information sharing but less import= ant than anything needing agreement
  • Mobility: non-TAPS draft on API & mobi= lity and incoming TSV AD suggestion to collaborate

--aaron

--=_MailMate_0999F2B9-4165-4457-9CC4-F504962F2FA4_=-- From nobody Mon Mar 4 12:21:04 2019 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 31DAF12E04D for ; Mon, 4 Mar 2019 12:21:02 -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 eY71WIc1m4yt for ; Mon, 4 Mar 2019 12:21:00 -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 3441B128D0B for ; Mon, 4 Mar 2019 12:21:00 -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 x24KGuD3011545; Mon, 4 Mar 2019 12:20:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=YSbe+2kBZiw/Jds8SrulDtLpJV+kzWI/Hpzu36gP21g=; b=CqqjgByeUCyQ8fWX4DVwd0qmxProI9uXniwqTtS4pK5som6gb5eN3oEz818Nz3j1gSmE WVHCPb2vyo/Y3RVnrory/XOpqvmeqxZhnxAAWthWrcstKdWVkSxndWwVXZ6fWtU3tdcf yxUYJGBlIGxNTtvBHhtyngspIFUEccu5O2Li4q/kKoZxHumyGVSfLFLp7hoOExnD4Az2 mCcjjZmVtnPQGyKIfmvyyXHo6drnmgJSrbnHanimD0/MV3SZ3AWgN6gL+9oMaa5lYMnG 1tFp9COOMwY3MKJF6euQQQyZnhKFxWpUARXEwYqhib0rTmdiEKD2xUigGWOkzLQ68CF+ yw== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2qyqd21xuv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 04 Mar 2019 12:20:56 -0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_U7EGUUvupIcgPWYlfZ0esQ)" Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PNU00E5QZ6VMB00@ma1-mtap-s03.corp.apple.com>; Mon, 04 Mar 2019 12:20:56 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PNU00E00WTVZ000@nwk-mmpp-sz13.apple.com>; Mon, 04 Mar 2019 12:20:55 -0800 (PST) X-Va-A: X-Va-T-CD: 9ea90e61654dad0c8920388428deae70 X-Va-E-CD: b7992a9d747c7fc2a60ee66a4ee9c0cd X-Va-R-CD: 751ae8d9674db45f87333cb50b20978c X-Va-CD: 0 X-Va-ID: 04d0d097-b09d-4574-ac27-63444e814734 X-V-A: X-V-T-CD: 9ea90e61654dad0c8920388428deae70 X-V-E-CD: b7992a9d747c7fc2a60ee66a4ee9c0cd X-V-R-CD: 751ae8d9674db45f87333cb50b20978c X-V-CD: 0 X-V-ID: cbdab125-277b-4c27-b0c8-2151b5440e5c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-04_11:,, signatures=0 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PNU00L1EZ6M9Y80@nwk-mmpp-sz13.apple.com>; Mon, 04 Mar 2019 12:20:47 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 04 Mar 2019 12:20:46 -0800 In-reply-to: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> Cc: taps WG , Zaheduzzaman Sarker To: Aaron Falk References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> X-Mailer: Apple Mail (2.3526.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-04_11:, , signatures=0 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 04 Mar 2019 20:21:02 -0000 --Boundary_(ID_U7EGUUvupIcgPWYlfZ0esQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable One topic that I=E2=80=99d like to discuss on the core documents, = that=E2=80=99s been raised previously as a vague area, is how to = actually implement framing protocols. The API document references = framing and deframing, but we need more specificity into how that is = implemented. This is an area that I've been working on recently, and = I=E2=80=99d be happy to share my initial findings and get feedback from = the group. Thanks, Tommy > On Mar 4, 2019, at 10:53 AM, Aaron Falk wrote: >=20 > Hi All- >=20 > What should we use our time to discuss? Let=E2=80=99s focus on things = that would benefit from f2f discussion, consensus building, or just = argument. :) >=20 > TAPS docs: are there open topics that need group attention? Seems like = we settled most of the remainder at the interim. > TAPS security: this seems nearly done. Anything to discuss? > Implementations: a good topic for information sharing but less = important than anything needing agreement > Mobility: non-TAPS draft on API & mobility = and = incoming TSV AD suggestion to collaborate = > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_U7EGUUvupIcgPWYlfZ0esQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable One = topic that I=E2=80=99d like to discuss on the core documents, that=E2=80=99= s been raised previously as a vague area, is how to actually implement = framing protocols. The API document references framing and deframing, = but we need more specificity into how that is implemented. This is an = area that I've been working on recently, and I=E2=80=99d be happy to = share my initial findings and get feedback from the group.

Thanks,
Tommy

On Mar = 4, 2019, at 10:53 AM, Aaron Falk <aaron.falk@gmail.com> wrote:

Hi = All-

What should we use our time to = discuss? Let=E2=80=99s focus on things that would benefit from f2f = discussion, consensus building, or just argument. :)

  • TAPS docs: are there open topics that need group = attention? Seems like we settled most of the remainder at the = interim.
  • TAPS security: this seems nearly done. Anything to = discuss?
  • Implementations: a good topic for information sharing but = less important than anything needing agreement
  • Mobility: non-TAPS draft on API & = mobility and incoming TSV AD suggestion to collaborate

--aaron

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

= --Boundary_(ID_U7EGUUvupIcgPWYlfZ0esQ)-- From nobody Mon Mar 4 17:19:28 2019 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 9C9AE128B33 for ; Mon, 4 Mar 2019 17:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 jXVwIOlH4lWl for ; Mon, 4 Mar 2019 17:19:23 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 71DDF12894E for ; Mon, 4 Mar 2019 17:19:23 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x251HgJl030966 for ; Tue, 5 Mar 2019 01:19:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=C4xKrMiuUdcOtcLdlfivVG1RG3Zmt663tFsA20qj6EA=; b=KUPUh84OsF9u0uZX1z9Hq+sVr9G8SBnUb6fWoees57r4QcGuQmAsamSWFwxd2SBve5Rd dUNLJf/HGbDXdOXkCgsLJOwt+MgEDqvybVRbyHkA5fQ/1WAQSaHFtSW4TtXKwqQxRpF+ uSOgjBbDx+MYgEHv8Vdwiz6wwlXHWuf10iGI+iz7kC/SjDKRMvdolOFMt1/W0sBLIBkC N0+uPTflkN4yDOfLl/tg6Oy7rkjTDURQxYOeB4VFcmpg0wUsOhJFUmr3+9WgjrbvE/I6 bcCLiGh39ufiUobke6UhK77mvhs5UP7S8ZtWL8Nf62cBNQaDjmkHwa8yBcz9RvuSQ89B 7g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2r1f1e81eh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 05 Mar 2019 01:19:21 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2515eBX000632 for ; Mon, 4 Mar 2019 20:19:20 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2qyp1yttht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 04 Mar 2019 20:19:20 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 Mar 2019 19:19:18 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1395.000; Mon, 4 Mar 2019 19:19:18 -0600 From: "Holland, Jake" To: taps WG Thread-Topic: [Taps] call for agenda items at TAPS IETF-104 Thread-Index: AQHU0ruJg/BpMSiZnkS1XjtUnIdzOKX8G+mA Date: Tue, 5 Mar 2019 01:19:18 +0000 Message-ID: <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> In-Reply-To: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.83] Content-Type: text/plain; charset="utf-8" Content-ID: <18FFE9EE0FE37D42B8046F3E7EB73B12@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-04_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903050005 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-04_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903050007 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 05 Mar 2019 01:19:27 -0000 SGkgdGFwcyBmb2xrcywNCg0KVEw7RFI6IEkgdGhpbmsgdGhlIHNwZWMgc2hvdWxkIGhhdmUgYSBZ QU5HIG1vZGVsIGFuZCBJIHdhbnQgdG8gdXNlIGl0DQp0byBnZXQgbXVsdGljYXN0IHN1cHBvcnQg aW4gYW4gaW1wbGVtZW50YXRpb24uDQoNCg0KSSByZWNlbnRseSBzdGFydGVkIGRpZ2dpbmcgaW50 byB0aGUgdGFwcyBBUEkgd2l0aCB0aGUgaW50ZW50IG9mIGFkZGluZw0KbXVsdGljYXN0IHN1cHBv cnQsIGJ1dCBpdCBsb29rcyBsaWtlIGl0J3MgYmFzaWNhbGx5IGFscmVhZHkgdGhlcmUsIGFzDQpm YXIgYXMgaXQgZ29lc1sqXS4NCg0KQnV0IEkgZW5kZWQgdXAgd2l0aCBhIGhpZ2hlci1sZXZlbCBj b21tZW50LCBzbyBJIHRob3VnaHQgSSdkIHJhaXNlIGl0DQp0byB0aGUgd2cgYW5kIGFzayB3aGF0 IHlvdSBhbGwgdGhpbmsuDQoNCkkgZm91bmQgdGhlIHdob2xlICJhYnN0cmFjdCBpbnRlcmZhY2Ui IGFwcHJvYWNoIGEgbGl0dGxlIHRvbw0KbG9vc2V5LWdvb3NleSwgc28gSSB0aG91Z2h0IEknZCB0 cnkgdG8gc3VnZ2VzdCBhIHdheSB0byB0aWdodGVuIGl0IHVwLg0KDQpNeSBnb2FsIHdpdGggdGhp cyBpcyB0byBtYWtlIGl0IG11Y2ggbW9yZSBjbGVhciAodG8gdGhlIHBvaW50IG9mIGJlaW5nDQpt ZWNoYW5pY2FsbHkgY2hlY2thYmxlKSBwcmVjaXNlbHkgd2hhdCBhIGNvbXBsaWFudCBBUEkgcHJv dmlkZXMuDQoNCkknbSBub3QgYXR0YWNoZWQgdG8gdGhlIHN0cnVjdHVyZSBJJ20gcHJvcG9zaW5n IG9yIHRvIGFueSBvZiB0aGUNCnBhcnRpY3VsYXJzIGluIHRoZSBzdHJhdy1tYW4gSSd2ZSBwb3N0 ZWQsIGJ1dCBpZiBpdCdzIG5vdCB0aWdodGVuZWQgdXANCndpdGggc29tZXRoaW5nIGF0IGEgc2lt aWxhciBsZXZlbCBvZiBjb25jcmV0ZW5lc3MsIEknbSBjb25jZXJuZWQgdGhhdA0KZGlmZmVyZW50 IGltcGxlbWVudGF0aW9ucyB3aWxsIGJlIG5vdCBvbmx5IGluY29tcGF0aWJsZSBpbiByYW5kb20N CnVuZGVyc3BlY2lmaWVkIGNvcm5lciBjYXNlcyAobGlrZSBCU0Qgc29ja2V0cyB0b2RheSB3aGVu IHlvdSB0cnkgdG8gbWFrZQ0KY3Jvc3MtcGxhdGZvcm0gQyBjb2RlKSwgYnV0IGFsc28gYXJlIGxp a2VseSB0byBlbmQgdXAgd2l0aCB2ZXJ5IG1hbnkNCmltcG9ydGFudCBkaWZmZXJlbmNlcyB0aGF0 IHdvdWxkIG1ha2UgdGhlIHdob2xlIHRhcHMgZWZmb3J0IG1vcmUgb3IgbGVzcw0KbW9vdC4NCg0K SW4gYSB3b3JsZCB3aGVyZSB3ZSBlbmQgdXAgd2l0aCBhIGRvYyBhdCB0aGUgbGV2ZWwgb2YgYWJz dHJhY3Rpb24gSSdtDQpjdXJyZW50bHkgc2VlaW5nIGluIGRyYWZ0LXRhcHMtaW50ZXJmYWNlLCBp dCBzZWVtcyB0byBtZSB0aGF0IGlmIDINCmRpZmZlcmVudCBBUEkgaW1wbGVtZW50YXRpb25zIHdl cmUgd3JpdHRlbiBpbiB0aGUgc2FtZSBsYW5ndWFnZSwgaXQnbGwNCmJlIHByb2hpYml0aXZlbHkg ZGlmZmljdWx0IGZvciBhbiBhcHAgdG8gbWlncmF0ZSBmcm9tIHVzaW5nIG9uZSB0byB1c2luZw0K dGhlIG90aGVyLCBqdXN0IGJlY2F1c2Ugc28gbWFueSBhc3BlY3RzIG9mIGl0IGFyZSBsZWZ0IG9w ZW4gdG8gdGhlDQppbXBsZW1lbnRvcnMuDQoNCkluIHRoYXQgY29udGV4dCwgSSB0aG91Z2h0IGEg WUFORyBtb2RlbCB3b3VsZCBiZSB1c2VmdWwgaGVyZSB0bw0KcHJvdmlkZSBhIGNyb3NzLXBsYXRm b3JtIHdheSB0byBzcGVjaWZ5IHdoYXQgZXhhY3QgcHJvcGVydGllcyBhbmQNCm9iamVjdHMgZXhp c3QsIGFuIGV4YWN0IGZvcm1hdCBpbiB3aGljaCB0aGUgdmFsdWVzIGNhbiBiZSBzcGVjaWZpZWQs IGFuZA0Kd2hhdCBleGFjdCBzZW1hbnRpY3MgdGhleSBoYXZlLCB3aGlsZSBzdGlsbCBhbGxvd2lu ZyBmb3IgYSBzYW5lDQpleHRlbnNpb24gcGF0aCBhbmQgbGFuZ3VhZ2Utc3BlY2lmaWMgaW1wbGVt ZW50YXRpb24gZGV0YWlscy4NCg0KSSdtIHRoaW5raW5nIHNvbWUgbGFuZ3VhZ2UgYSBiaXQgbGlr ZSB0aGUgZmlyc3QgYnVsbGV0IGluIFNlY3Rpb24gNC4yIG9mDQp0YXBzLWludGVyZmFjZToNCg0K ICBBIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgcHJvdmlkZSBhIGxhbmd1YWdlLWFw cHJvcHJpYXRlIHdheSB0bw0KICBjb25maWd1cmUgYSBQcmVDb25uZWN0aW9uIHVzaW5nIFlBTkcg aW5zdGFuY2UgZGF0YSBmb3IgdGhpcyBtb2RlbCwgYW5kDQogIFNIT1VMRCBwcm92aWRlIGFuIEFQ SSB0aGF0IG91dHB1dHMgdGhlIFlBTkcgaW5zdGFuY2UgZGF0YSBmb3IgYW4NCiAgZXN0YWJsaXNo ZWQgQ29ubmVjdGlvbi4NCg0KICBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgYWxzbyBwcm92aWRlIGFw cHJvcHJpYXRlIEFQSXMgZm9yIGRpcmVjdGx5IGVkaXRpbmcNCiAgdGhlIG9iamVjdHMgd2l0aG91 dCB1c2luZyBZQU5HLiAgSXQncyBSRUNPTU1FTkRFRCB3aGVyZSBwb3NzaWJsZSB0byB1c2UNCiAg bmFtZXMgdGhhdCBtZWNoYW5pY2FsbHkgdHJhbnNsYXRlIHRvIHRoZSBuYW1lcyBpbiB0aGUgWUFO RyBkYXRhIG1vZGVsLA0KICB1c2luZyBjYXBpdGFsaXphdGlvbiBhbmQgcHVuY3R1YXRpb24gY29u dmVudGlvbnMgYXMgZXhwZWN0ZWQgZm9yIHRoZQ0KICBsYW5ndWFnZSBvZiB0aGUgaW1wbGVtZW50 YXRpb24uDQoNCkFuZCB0aGVuIG9mIGNvdXJzZSBhIFlBTkcgbW9kZWw6DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaG9sbGFuZC10YXBzLWFwaS15YW5nLw0KKGRyYWZ0 LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcpDQoNCklmIHRoaXMgc2VlbXMgdXNlZnVsLCBpdCB3aWxs IG5lZWQgbG90cyBvZiByZWZpbmluZy4gIEknbGwgYmUgc3VycHJpc2VkDQppZiBhbnkgcGFydCBv ZiBpdCBzdXJ2aXZlcyBleGFjdGx5IGFzIHdyaXR0ZW4uICBJdCdzIGEgcXVpY2sgYW5kDQpkaXJ0 eSBhdHRlbXB0IHRvIGNvbmNyZXRpemUgYSBmZXcgb2YgdGhlIHRoaW5ncyBJIHNhdyBsaXN0ZWQg aW4NCmRyYWZ0LWlldGYtdGFwcy1pbnRlcmZhY2UsIGFzIGEgc3RhcnRpbmcgcG9pbnQgdG8gZmls bCBvdXQgaWYgaXQgc2VlbXMNCnVzZWZ1bC4NCg0KQnV0IHRoZSBtb2RlbCBwYXJzZXMsIGFuZCB0 aGUgZXhhbXBsZSBkYXRhIGluc3RhbmNlcyBpbiB0aGUgZHJhZnQNCnBhcnNlIGFnYWluc3QgdGhl IG1vZGVsIChhbGwgd2l0aCBsaWJ5YW5nKS4NCg0KT25lIG9mIHRoZSBtYWluIHJlYXNvbnMgSSdt IGRvaW5nIHRoaXMgaXMgYmVjYXVzZSBpdCBzZWVtcyB0byBtZSB3aGF0J3MNCnNwZWNpZmllZCBp biB0YXBzLWludGVyZmFjZS0wMiB0b2RheSBpcyBtaXNzaW5nIHNvbWUga2V5IGZlYXR1cmVzLCBs aWtlDQphbiBlbnVtZXJhdGlvbiBvZiB0aGUgcHJvcGVydGllcyBpbiB0aGUgTG9jYWwvUmVtb3Rl RW5kcG9pbnQgZXhhbXBsZXMgaW4NCnNlY3Rpb24gNS4xLiAgQW5kIEkgZG9uJ3Qgc2VlIHRoYXQg bGlzdGVkIGFzIGFuIG9wZW4gaXNzdWUgaW4gZ2l0aHViLA0Kd2hpY2ggc3VycHJpc2VkIG1lIGEg Yml0Lg0KDQpJIHRoaW5rIG92ZXJzaWdodHMgbGlrZSB0aGlzIHdpbGwgYmVjb21lIGltbWVkaWF0 ZWx5IGFuZCBwYWluZnVsbHkNCm9idmlvdXMgd2hlbiB0aGVyZSdzIGEgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIHRoYXQgaW5jbHVkZXMgYSBZQU5HDQpwYXJzZXIgYW5kIGFuIGV4cGxpY2l0IGRh dGEgbW9kZWwsIGFzIG9wcG9zZWQgdG8gdGhlIGNvbWJpbmcgb2YgdGhlDQpkb2N1bWVudCBhbmQg YSBzb3J0IG9mIGV5ZWJhbGxlZCBjb21wYXJpc29uIHRvIE5FQVQgdGhhdCBJIHRyaWVkDQp0aGlz IHdlZWsgdG8gcmVhY2ggdGhhdCBjb25jbHVzaW9uICh3aGljaCBJIGZvdW5kIGNoYWxsZW5naW5n IGV2ZW4NCnRob3VnaCBJIHRob3VnaHQgYm90aCB0aGUgZG9jdW1lbnQgYW5kIHRoZSBsaWJyYXJ5 IHdlcmUgbW9zdGx5IHByZXR0eQ0Kd2VsbCB3cml0dGVuKS4NCg0KVGhlIHdob2xlIHRoaW5nIGF0 IHRoaXMgcG9pbnQganVzdCBzbWVsbHMgdG8gbWUgbXVjaCBtb3JlIGFic3RyYWN0IHRoYW4NCml0 IHJlYWxseSBoYXMgdG8gYmUgb3IgdGhhbiBpdCdzIHJlYWxseSB1c2VmdWwgdG8gYmUsIHdoaWNo IGJvdGhlcnMgbWUNCmJlY2F1c2UgdGhlIGlkZWEgb2YgcmVwbGFjaW5nIEJTRCBzb2NrZXRzIHdp dGggc29tZXRoaW5nIHVzYWJsZSBzZWVtcw0KbGlrZSBzdWNoIGEgZ3JlYXQgaWRlYS4gIEknZCBs aWtlIHRoaXMgdG8gYmUgc29tZXRoaW5nIEkgY2FuIGFjdHVhbGx5DQp1c2UgaW4gYSB3YXkgdGhh dCBtYWtlcyBteSBsaWZlIGVhc2llciBzb21lZGF5IHNvb24uDQoNCkJ1dCBJIHRoaW5rIEknbSBh dCB0aGUgcG9pbnQgd2hlcmUgSSBuZWVkIGEgc2FuaXR5IGNoZWNrIHRvIHNlZSBpZiBJJ20NCmp1 c3QgbWlzc2luZyBzb21ldGhpbmcsIG9yIGlmIHRoaXMgc2VlbXMgbGlrZSBhIHVzZWZ1bCBkaXJl Y3Rpb24uDQoNClRob3VnaHRzPyAgU3VnZ2VzdGlvbnM/ICAgV29ydGggZGlzY3Vzc2luZyBpbiBQ cmFndWU/ICAoSWYgc28sIGNhbiBJDQpnZXQgYSBzbG90PykNCg0KQ2hlZXJzLA0KSmFrZQ0KDQoq Og0KSSBjb25jbHVkZWQgdGhhdCB0aGVyZSdzIG5vIHJlYXNvbiBtdWx0aWNhc3QgY291bGRuJ3Qg YmUgc3VwcG9ydGVkDQp0b2RheSwgaWYgdGhlcmUgd2VyZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0 IGNvdWxkIHJlYXNvbmFibHkgY2xhaW0gdG8gYmUNCmNvbXBsaWFudCwgYnkganVzdCBhZGFwdGlu ZyBzb21lIG9mIHRoZSBleGFtcGxlcyBpbg0KZHJhZnQtaWV0Zi10YXBzLWludGVyZmFjZS0wMiBh bmQgdW5kZXJzdGFuZGluZyB0aGUgc2VtYW50aWMgbWVhbmluZyBvZg0KbXVsdGljYXN0IGFkZHJl c3Mgc3BhY2VzIGluc2lkZSB0aGUgQVBJLg0KDQpGb3IgZXhhbXBsZSwgSSBjb3VsZG4ndCBmaW5k IGFueSByZWFzb24gdGhpcyBjYW4ndCBiZSBleHBlY3RlZCB0byBzZXQNCnVwIGFuIFNTTSBjaGFu bmVsIHN1YnNjcmlwdGlvbiB3aXRob3V0IGFueSBmdXJ0aGVyIGFkbywgZ2l2ZW4gYSBzYW5lDQpp bXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIGl0Og0KDQogIFJlbW90ZVNwZWNpZmllciA6PSBO ZXdSZW1vdGVFbmRwb2ludCgpDQogIFJlbW90ZVNwZWNpZmllci5XaXRoSVB2NEFkZHJlc3MoMTky LjAuMi4yMSkNCg0KICBMb2NhbFNwZWNpZmllciA6PSBOZXdMb2NhbEVuZHBvaW50KCkNCiAgTG9j YWxTcGVjaWZpZXIuV2l0aFBvcnQoMzAwMDApDQogIExvY2FsU3BlY2lmaWVyLldpdGhJUHY0QWRk cmVzcygyMzIuMjUyLjAuMikNCg0KICBOZXdQcmVjb25uZWN0aW9uKFJlbW90ZVNwZWNpZmllciwg TG9jYWxTcGVjaWZpZXIpLkxpc3RlbiguLi4pDQoNCk1heWJlIHRoZXJlJ3Mgc29tZSB2YWx1ZSBp biBzcGVjaWZ5aW5nIGEgIkpvaW5TU00oKSIgdG8gb3ZlcnJpZGUgZGVmYXVsdHMNCmluIHRoZSBQ cmVDb25uZWN0aW9uLCBqdXN0IHRvIG1ha2Ugc3VyZSB5b3UncmUgc3BlY2lmaWNhbGx5IGFza2lu ZyBmb3INCm11bHRpY2FzdC4gIEkgdGhpbmsgdGhhdCB3b3VsZCBiZSBmaW5lIGZvciBuYXRpdmUg bXVsdGljYXN0LCBidXQgbGlrZSBJDQpzYWlkLCBhIG11Y2ggc21hbGxlciBwb2ludCB0aGFuIHRo ZSBsb29zZW5lc3Mgb2YgdGhlIEFQSS4NCg0KV2hlcmUgaXQgZ2V0cyBhIGJpdCBtb3JlIGNvbXBs aWNhdGVkIGlzIHRyeWluZyB0byBoYW5kbGUgbXVsdGlwbGUgb3B0aW9ucw0KZm9yIGRpc2NvdmVy aW5nIGEgdXNhYmxlIHVuaWNhc3QgdHVubmVsIGZvciBtdWx0aWNhc3QgdHJhZmZpYywgYXMNCmRl c2NyaWJlZCBpbiBTZWN0aW9uIDIuNC4xIG9mIGRyYWZ0LWlldGYtbWJvbmVkLWRyaWFkLWFtdC1k aXNjb3ZlcnktMDEuDQoNCkknZCBsaWtlIHRvIGhhdmUgYSBkZWNlbnQgcGxhY2UgdG8gdGFjayBv biBhbiBleHRlbnNpb24gdG8gdGhpcyBBUEkgdGhhdA0KY2FuIHRyYW5zcGFyZW50bHksIHdpdGhp biB0aGUgY29ubmVjdGlvbiBBUEksIGRpc2NvdmVyIHRoZSBiZXN0IGF2YWlsYWJsZQ0KQU1UIHJl bGF5IGFuZCBzdGFydCB1c2luZyBpdCB3aGVuIG5hdGl2ZSBqb2luaW5nIGlzIHVuYXZhaWxhYmxl IChhbmQgYWxzbw0KdG8gcHJvdmlkZSBub3JtYXRpdmUgY29udHJvbHMgZm9yIGNvbmZpZ3VyaW5n IGl0IHdoZW4gdGhlcmUncw0KYWRtaW5pc3RyYXRpdmUgY29uZmlndXJhdGlvbiB0byBiZSBhZGRl ZCkuDQoNCkJ1dCB0aGF0J3MgYSAybmQgb3JkZXIgcXVlc3Rpb24gZm9yIG1lIGF0IHRoaXMgcG9p bnQsIGJlY2F1c2UgaW4gdGhlDQpjdXJyZW50IFRBUFMgQVBJIEkgZG9uJ3Qgc2VlIGFueSBvYnZp b3VzbHkgZ29vZCBzcG90IHRvIHB1dCBzZWxlY3Rpb24NCmNvbnRyb2xzIGZvciB0aGF0IGtpbmQg b2YgdHVubmVsIGRpc2NvdmVyeSBzZWxlY3Rpb24sIG9yIHJlYWxseSBhIGdvb2QNCndheSB0byBl eHBsYWluIHdoYXQgaXQncyBzdXBwb3NlZCB0byBkbywgaWYgSSB0cmllZCB0byBhZGQgY29udHJv bHMgdG8NCnNvbWV0aGluZyB0aGF0J3MgdGhlcmUuDQoNClNvbHZpbmcgdGhhdCBpcyBteSBtYWlu IG1vdGl2YXRpb24gZm9yIGJlaW5nIGhlcmUuICAoV2VsbCwgYW5kIHRoYXQNCnRoZSBCU0Qgc29j a2V0IEFQSSBmb3IgbXVsdGljYXN0IGlzIGtpbmQgb2YgYSBkaXNhc3RlciB0b2RheS4pDQoNCkFu eXdheSwgaWYgdGFwcyBmaW5kcyB0aGUgd2hvbGUgWUFORyBzdWdnZXN0aW9uIHVzZWZ1bCwgSSds bCBwcm9iYWJseQ0Kc3VnZ2VzdCBzb21lIG5ldyBleHRlbnNpb25zIGFib3V0IHRoaXMsIGFuZCBt YXliZSBhIGZldyBvdGhlciBwb2ludHMsDQplc3BlY2lhbGx5IG1heWJlIGFyb3VuZCB0cnlpbmcg dG8gcHV0IGluIGEgc3RydWN0dXJlIHRoYXQgY2FuIHN1cHBvcnQNCnNvbWUga2luZCBvZiBzYW5l IGV4cGxpY2l0IGxheWVyaW5nLg0KDQpCdXQgSSdtIG5vdCBzdXJlIEkgY2FuIGFydGljdWxhdGUg dGhvc2Ugc3VnZ2VzdGlvbnMgaW4gYSB3YXkgSSdtIHN1cmUgaXMNCm1lYW5pbmdmdWwgd2l0aG91 dCBmaXJzdCBnZXR0aW5nIGEgbW9yZSBjbGVhciBzcGVjaWZpY2F0aW9uIG5haWxlZCBkb3duDQph Ym91dCB3aGF0J3MgYWN0dWFsbHkgaW4gdGhlIHRhcHMgc3BlYy4gQmVjYXVzZSByaWdodCBub3cg SSdtIG1vc3RseQ0KanVzdCBjb25mdXNlZCBhYm91dCB3aGF0IGFuIEFQSSBpbXBsZW1lbnRhdGlv biB3b3VsZCByZWFsbHkgbG9vayBsaWtlLA0KYW5kIGhvdyB5b3UgY291bGQgdGVsbCB3aGV0aGVy IGl0IG1hdGNoZXMgdGhlIHRhcHMtaW50ZXJmYWNlIHNwZWMuDQoNCg0KDQpGcm9tOiBBYXJvbiBG YWxrIDxhYXJvbi5mYWxrQGdtYWlsLmNvbT4NCkRhdGU6IDIwMTktMDMtMDQgYXQgMTA6NTMNClRv OiB0YXBzIFdHIDx0YXBzQGlldGYub3JnPg0KQ2M6IFphaGVkdXp6YW1hbiBTYXJrZXIgPHphaGVk dXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPg0KU3ViamVjdDogW1RhcHNdIGNhbGwgZm9yIGFn ZW5kYSBpdGVtcyBhdCBUQVBTIElFVEYtMTA0DQoNCkhpIEFsbC0NCldoYXQgc2hvdWxkIHdlIHVz ZSBvdXIgdGltZSB0byBkaXNjdXNzPyBMZXTigJlzIGZvY3VzIG9uIHRoaW5ncyB0aGF0IHdvdWxk IGJlbmVmaXQgZnJvbSBmMmYgZGlzY3Vzc2lvbiwgY29uc2Vuc3VzIGJ1aWxkaW5nLCBvciBqdXN0 IGFyZ3VtZW50LiA6KQ0K4oCiIFRBUFMgZG9jczogYXJlIHRoZXJlIG9wZW4gdG9waWNzIHRoYXQg bmVlZCBncm91cCBhdHRlbnRpb24/IFNlZW1zIGxpa2Ugd2Ugc2V0dGxlZCBtb3N0IG9mIHRoZSBy ZW1haW5kZXIgYXQgdGhlIGludGVyaW0uIA0K4oCiIFRBUFMgc2VjdXJpdHk6IHRoaXMgc2VlbXMg bmVhcmx5IGRvbmUuIEFueXRoaW5nIHRvIGRpc2N1c3M/IA0K4oCiIEltcGxlbWVudGF0aW9uczog YSBnb29kIHRvcGljIGZvciBpbmZvcm1hdGlvbiBzaGFyaW5nIGJ1dCBsZXNzIGltcG9ydGFudCB0 aGFuIGFueXRoaW5nIG5lZWRpbmcgYWdyZWVtZW50IA0K4oCiIE1vYmlsaXR5OiBodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3Jn X2h0bWxfZHJhZnQtMkRpZXRmLTJEZG1tLTJEb25kZW1hbmQtMkRtb2JpbGl0eS0yRDE3JmQ9RHdN RmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWJxbkZST2l2RG9fNGlGOFozUjREeU5XS2Ji TWVYcjBMT2dMbkVsVDFPb2smbT1wTFc1Z1N5ZXRmVmVfaXhHNF91N3FLWF9WY2pJcXpON0p1MkJn TTJycFFvJnM9SFVzQlZCRl9HaE5pT2szZ3FZX201cVpNRC1zUG1CSjkzR0U1d2QzRDVfcyZlPSBh bmQgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19k YXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfcmV2aWV3LTJEaWV0Zi0yRGRtbS0yRG9uZGVtYW5kLTJE bW9iaWxpdHktMkQxNS0yRHRzdmFydC0yRGxjLTJEd2VzdGVybHVuZC0yRDIwMTktMkQwMS0yRDA4 XyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1icW5GUk9pdkRvXzRpRjhaM1I0 RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJm09cExXNWdTeWV0ZlZlX2l4RzRfdTdxS1hfVmNqSXF6 TjdKdTJCZ00ycnBRbyZzPTBZbUNfWENBdTRfR1ZZZEZpMEh4aUthS0JwYW4yQ09ZcUJMMW1CNmJY clkmZT0gDQotLWFhcm9uDQoNCg== From nobody Tue Mar 5 14:07:01 2019 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 C2A7D1310C2 for ; Tue, 5 Mar 2019 14:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 4hBzEkWYCav4 for ; Tue, 5 Mar 2019 14:06:56 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 261501310AE for ; Tue, 5 Mar 2019 14:06:55 -0800 (PST) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x25M6rGK021695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 5 Mar 2019 23:06:54 +0100 Received: from [10.11.33.83] (dynamic-145-014-214-039.glattnet.ch [145.14.214.39]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x25M6rnK155318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Mar 2019 23:06:53 +0100 From: "Brian Trammell (IETF)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> Date: Tue, 5 Mar 2019 23:06:52 +0100 To: taps WG X-Mailer: Apple Mail (2.3445.9.1) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Taps] API drafts repository has been migrated 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, 05 Mar 2019 22:06:59 -0000 Greetings, all, The API drafts repository is now at: https://github.com/ietf-tapswg/api-drafts To update your working directories to point to the new repo: git remote set-url origin git@github.com:ietf-tapswg/api-drafts (Or, as with all things git, just re-clone if you want to be sure :) ) CircleCI support for autobuilding drafts should be up sometime tomorrow = (it's late here); please let me know if you notice any problems with the = migration. Thanks, cheers, Brian= From nobody Tue Mar 5 14:09:46 2019 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 D1FBD130EA8 for ; Tue, 5 Mar 2019 14:09:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wNTUAI1mdzgn for ; Tue, 5 Mar 2019 14:09:40 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 65661124B0C for ; Tue, 5 Mar 2019 14:09:40 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x25M7Hgl047656; Tue, 5 Mar 2019 14:09:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=75HZaooEDWQFhWOo1S6nBftvhUiusvy+/DX1wrkWxe0=; b=hdvyA2AKjd6t657ppXtShajEmCPdHZYV8MBRkXRkD2tY2XG2oubvLWBK3eZIRxe2pPID VLVHuwg5jAe+CcYZZq9oLV9l28XvyAGXFO9SPCMxQBOf909gUBoxffJvwg3t+CZC4ZMV FEqaTgDOwV1T8j664xxWobU6Sv/kgXt+V/sKTmBr6ZJXHhcakfs+YT9EA+g7hWNALXTd j2GuIuY+1AGKh0smvKV5BmhRj2XrXBVsTVfUebWtT1GHbc9n50I0YLwIQxXtG8tTpwGd Egs5K/YtHws8f9bQj48xnkUa8gEIsvPqG0shZDeN+6JYaeqKwAFO8qPp02ATkqBv/Myj hQ== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2qysq47t0e-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 05 Mar 2019 14:09:39 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PNW009H7YW1ZBR0@mr2-mtap-s03.rno.apple.com>; Tue, 05 Mar 2019 14:09:37 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PNW00500YIJ1C00@nwk-mmpp-sz10.apple.com>; Tue, 05 Mar 2019 14:09:37 -0800 (PST) X-Va-A: X-Va-T-CD: 9c97c4ee6b86f0613f4a782fc1fa69f6 X-Va-E-CD: 61ab767b6cd52248ad41705079920c51 X-Va-R-CD: 0ec22fe16ceba1a24f0a89e3150b3211 X-Va-CD: 0 X-Va-ID: 04ff2fe4-b001-415e-9fc0-0f041cfb6f31 X-V-A: X-V-T-CD: 9c97c4ee6b86f0613f4a782fc1fa69f6 X-V-E-CD: 61ab767b6cd52248ad41705079920c51 X-V-R-CD: 0ec22fe16ceba1a24f0a89e3150b3211 X-V-CD: 0 X-V-ID: 4787e27e-13b9-43bd-ad95-24614d91d5cd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-05_11:,, signatures=0 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PNW009ZRYW19D50@nwk-mmpp-sz10.apple.com>; Tue, 05 Mar 2019 14:09:37 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> Date: Tue, 05 Mar 2019 14:09:37 -0800 Cc: taps WG Message-id: References: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> To: "Brian Trammell (IETF)" X-Mailer: Apple Mail (2.3526.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-05_11:, , signatures=0 Archived-At: Subject: Re: [Taps] API drafts repository has been migrated 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, 05 Mar 2019 22:09:44 -0000 Fantastic, thanks for getting this done! Now, to make some PRs before the Prague submission deadlines =) Best, Tommy > On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) wrote: > > Greetings, all, > > > The API drafts repository is now at: > > https://github.com/ietf-tapswg/api-drafts > > To update your working directories to point to the new repo: > > git remote set-url origin git@github.com:ietf-tapswg/api-drafts > > (Or, as with all things git, just re-clone if you want to be sure :) ) > > > CircleCI support for autobuilding drafts should be up sometime tomorrow (it's late here); please let me know if you notice any problems with the migration. > > Thanks, cheers, > > Brian > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Mar 5 14:16:06 2019 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 1A71212F1AC for ; Tue, 5 Mar 2019 14:16:05 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zRVvHghK6K7Y for ; Tue, 5 Mar 2019 14:16:03 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 14DBB130DE4 for ; Tue, 5 Mar 2019 14:16:01 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id h28so5672890qkk.7 for ; Tue, 05 Mar 2019 14:16:01 -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; bh=8vOFWJLT/IRLQtdVdmkJeEwCzBlMmrJJ87QgyV2zgJk=; b=o3sNWASfNsGpKhIcc/VoI7taqbgguuF20gi3eVYRrcUPRkLAvb10JKgLBuJC8qCwz+ 2BcccmI9Ya3GFsWzsOOZmclH5UiM1saUcd0m9YqMT/9FWp63HoObXAMfSBjVixSDwnPO J7CToHCPCuOx0fdYoviUOrhTLje66wIzXQqXB2oxr3YeyuSCalFw+I8YBNmgvfx26rw9 EqTo0fyXs8Iak71dT2pK8S5PAx84934wg1AneGjlOIpGKZBsebIKVP2TwOCHkL1iZ5LO ROoRSOPbuL5xM2H4uWbGasDwen8p/NY0z39A0diZ3D1Pe/SCx7br+IBoZMf8VsYEyHUo Q7pA== 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; bh=8vOFWJLT/IRLQtdVdmkJeEwCzBlMmrJJ87QgyV2zgJk=; b=sIugbDyYFaTTJdgo0jAK7hi8pYzXK+5FwmugVcbZbcxS9tZ+q3rNFkna8msaUpKsW9 OuIaFPjUazZFjYWhPVR99C8uyUmbfXNWZteF/bL1GHd71nHQqvBqyUdO0+uGeG/tlSyq 2cpcNkcCVkKIFTa0vpsAG/lyqno8b1YkxBDm6uVBQjZG5MNsJlzg1F7O/+m457VEvlMF opPqwFowkXi8APKdxkQ4YXBMIu8Yuo+v4j/m7Un05p5vsB/CaekEr6gAgizoClg31buL vM81OWm8AwJhEsHTNe3VImEbzZRZ/CyawqGD6GmRFG9Fv7e+SUh0X+MVEHT+3whObDjl +kmw== X-Gm-Message-State: APjAAAWbHPuNX2PeFaMhr3MYMPVQgXi4Ki6v84FEk1hmTM24BR2C5IL2 TKmNK7jMJHo+Alzd0hlO4mEKjGqT X-Google-Smtp-Source: APXvYqx6HXEClOBUb2Lw+FaVfhydNDNKnNjdZg8lm3EIqlQUdAz/95agBLFaj89NxMN9nm19O8cN4w== X-Received: by 2002:a37:9a13:: with SMTP id c19mr3472506qke.48.1551824159829; Tue, 05 Mar 2019 14:15:59 -0800 (PST) Received: from [172.19.35.233] ([2001:4878:a000:3000:8422:7868:6be9:a84b]) by smtp.gmail.com with ESMTPSA id h58sm7160761qtb.89.2019.03.05.14.15.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 14:15:59 -0800 (PST) From: "Aaron Falk" To: "Tommy Pauly" Cc: "Brian Trammell" , "taps WG" Date: Tue, 05 Mar 2019 17:15:58 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_460EF58E-ED6B-48CC-AEFD-0B04AEF64DF7_=" Archived-At: Subject: Re: [Taps] API drafts repository has been migrated 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, 05 Mar 2019 22:16:05 -0000 --=_MailMate_460EF58E-ED6B-48CC-AEFD-0B04AEF64DF7_= Content-Type: text/plain; format=flowed Many thanks to Brian & Zahed! On 5 Mar 2019, at 17:09, Tommy Pauly wrote: > Fantastic, thanks for getting this done! > > Now, to make some PRs before the Prague submission deadlines =) > > Best, > Tommy > >> On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) >> wrote: >> >> Greetings, all, >> >> >> The API drafts repository is now at: >> >> https://github.com/ietf-tapswg/api-drafts >> >> To update your working directories to point to the new repo: >> >> git remote set-url origin git@github.com:ietf-tapswg/api-drafts >> >> (Or, as with all things git, just re-clone if you want to be sure :) >> ) >> >> >> CircleCI support for autobuilding drafts should be up sometime >> tomorrow (it's late here); please let me know if you notice any >> problems with the migration. >> >> Thanks, cheers, >> >> Brian >> _______________________________________________ >> 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 --=_MailMate_460EF58E-ED6B-48CC-AEFD-0B04AEF64DF7_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Many thanks to Brian & Zahed!



On 5 Mar 2019, at 17:09, Tommy Pauly wrote:

Fantastic, thanks for getting this = done!

Now, to make some PRs before the Prague submission deadlines =3D)

Best,
Tommy

On Mar 5, 2= 019, at 2:06 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
Greetings, all,


The API drafts repository is now at:

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

To update your working directories to point to the new repo:

git remote set-url origin git@github.com:ietf-tapswg/api-drafts

(Or, as with all things git, just re-clone if you want to be sure :) )

CircleCI support for autobuilding drafts should be up sometime tomorrow (= it's late here); please let me know if you notice any problems with the m= igration.

Thanks, cheers,

Brian
_______________________________________________
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

--=_MailMate_460EF58E-ED6B-48CC-AEFD-0B04AEF64DF7_=-- From nobody Tue Mar 5 15:51:49 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E667A13105F; Tue, 5 Mar 2019 15:51:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155182989393.27720.10093596560747220553.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2019 15:51:33 -0800 Archived-At: Subject: [Taps] taps - Requested session has been scheduled for IETF 104 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 23:51:34 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:00 requested) Friday, 29 March 2019, Morning Session II 1050-1250 Room Name: Athens/Barcelona size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/taps.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpbis ipsecme rtcweb avtcore capport tls panrg quic tsvarea rmcat ippm tsvwg iccrg tcpm dispatch maprg cfrg intarea Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Colin Perkins Aaron Falk Michael Welzl Gorry Fairhurst Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Anna Brunstrom Tommy Pauly Kyle Rose Christopher A. Wood Philipp S. Tiesel Theresa Enghardt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Mar 6 04:29:06 2019 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 2FBCA12DDA3 for ; Wed, 6 Mar 2019 04:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ys8xKNCOyHE8 for ; Wed, 6 Mar 2019 04:29:02 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 554991286D8 for ; Wed, 6 Mar 2019 04:29:01 -0800 (PST) Received: from [130.149.220.45] (esmeralda.net.t-labs.tu-berlin.de [130.149.220.45]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 0AE74590; Wed, 6 Mar 2019 13:28:59 +0100 (CET) To: taps@ietf.org, "Brian Trammell (IETF)" References: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== Message-ID: <00fc4830-b1cd-85a7-b3fd-f603119da521@inet.tu-berlin.de> Date: Wed, 6 Mar 2019 13:28:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E64D213D27580C541E8360A6" Content-Language: en-US Archived-At: Subject: Re: [Taps] API drafts repository has been migrated 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, 06 Mar 2019 12:29:05 -0000 This is a multi-part message in MIME format. --------------E64D213D27580C541E8360A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks for migrating the repo! > On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) > wrote: > > CircleCI support for autobuilding drafts should be up sometime > tomorrow (it's late here); please let me know if you notice > any problems with the migration. > Not sure if problem or intended, but: As a member of the organization, I used to be allowed to create and push branches directly to the api-drafts repository. However, on the new organization, this did not work just now, see below. Is this intentional, in which case I will just fork the repo and push the branch there? Or is this a bug in the configuration of the new organization? --- $ git push -u origin theri-api-usage-example ERROR: Permission to ietf-tapswg/api-drafts.git denied to theri. fatal: Konnte nicht vom Remote-Repository lesen. Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen und das Repository existiert. $ git remote -v origin    git@github.com:ietf-tapswg/api-drafts (fetch) origin    git@github.com:ietf-tapswg/api-drafts (push) -- (It says that it could not read from the remote repository and that I should check if I have the correct permissions and that the repository exists.) Cloning the entire repository again in a different directory did not help. "git pull" works as usual. Best, Theresa --------------E64D213D27580C541E8360A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks for migrating the repo!

On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

CircleCI support for autobuilding drafts should be up sometime tomorrow (it's late here); please let me know if you notice any problems with the migration.

Not sure if problem or intended, but:

As a member of the organization, I used to be allowed to create and push branches directly to the api-drafts repository.
However, on the new organization, this did not work just now, see below.

Is this intentional, in which case I will just fork the repo and push the branch there?
Or is this a bug in the configuration of the new organization?

---

$ git push -u origin theri-api-usage-example
ERROR: Permission to ietf-tapswg/api-drafts.git denied to theri.
fatal: Konnte nicht vom Remote-Repository lesen.

Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.

$ git remote -v
origin    git@github.com:ietf-tapswg/api-drafts (fetch)
origin    git@github.com:ietf-tapswg/api-drafts (push)

--

(It says that it could not read from the remote repository and that I should check if I have the correct permissions and that the repository exists.)

Cloning the entire repository again in a different directory did not help.

"git pull" works as usual.

Best,
Theresa
--------------E64D213D27580C541E8360A6-- From nobody Wed Mar 6 05:50:55 2019 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 0B42F12423B for ; Wed, 6 Mar 2019 05:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=DHq7tC7f; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PMpK2Q6Z 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 DjCkgEGi0iFt for ; Wed, 6 Mar 2019 05:50:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 EAC161224E8 for ; Wed, 6 Mar 2019 05:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551880246; x=1554472246; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c7nOcqladuK0hO4ksbfUUXS+YQ4u5Ue2ybgXEt288ag=; b=DHq7tC7fEZuOEI05USPaSB7rkj+cj1jyV+1jBEUm+YgPCpiqEMdgqKw5MStTgH/f /Ty9xKdomDVUh61YHA34aBFIB4hnONWfs1cGAbK+Vn2AGq3y1JLLTYFhA31YhDqD ectI/vbcdIlZEfGH31txaZ6P6FyQLKXMyGqu8S6Z1Sc=; X-AuditID: c1b4fb25-d89ff70000005ff7-54-5c7fd03633dd Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.D2.24567.630DF7C5; Wed, 6 Mar 2019 14:50:46 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 14:50:45 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 14:50:46 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 14:50:46 +0100 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=c7nOcqladuK0hO4ksbfUUXS+YQ4u5Ue2ybgXEt288ag=; b=PMpK2Q6ZSlnjJB4b1ImGni2jyRb1UtGzZw1C4O8qgiz/AZG+Hdd2+YvsjFfUX6FGkgQWiBg5TUP8rrTHfczoUXbKhyoHioxovrhWTw+ehfDoiRkpZqe8uRmP2scL4kS0m924K5/8WMLO9Xk69F6KKWeOPU7zdbhUDg25TmL+KAo= Received: from HE1PR0701MB3020.eurprd07.prod.outlook.com (10.168.93.142) by HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.6; Wed, 6 Mar 2019 13:50:45 +0000 Received: from HE1PR0701MB3020.eurprd07.prod.outlook.com ([fe80::20ab:1417:b887:a821]) by HE1PR0701MB3020.eurprd07.prod.outlook.com ([fe80::20ab:1417:b887:a821%6]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 13:50:45 +0000 From: Zaheduzzaman Sarker To: Theresa Enghardt , "taps@ietf.org" , "Brian Trammell (IETF)" Thread-Topic: [Taps] API drafts repository has been migrated Thread-Index: AQHU05/NTeIIovHrxEuP7szzikui3aX9mP6AgAABxgCAAO5VgIAAJ5mA Date: Wed, 6 Mar 2019 13:50:44 +0000 Message-ID: <4B9419DD-D00A-497E-B895-138981D36A33@ericsson.com> References: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> <00fc4830-b1cd-85a7-b3fd-f603119da521@inet.tu-berlin.de> In-Reply-To: <00fc4830-b1cd-85a7-b3fd-f603119da521@inet.tu-berlin.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f97f00a-6fb0-4cf7-3032-08d6a23abb15 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2746; x-ms-traffictypediagnostic: HE1PR0701MB2746: x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(136003)(366004)(199004)(189003)(14454004)(8936002)(81166006)(81156014)(33656002)(478600001)(8676002)(2501003)(97736004)(7736002)(82746002)(6246003)(25786009)(105586002)(106356001)(36756003)(110136005)(58126008)(2906002)(71200400001)(66066001)(71190400001)(316002)(68736007)(26005)(53936002)(83716004)(76176011)(6436002)(6486002)(86362001)(99286004)(186003)(229853002)(6116002)(3846002)(236005)(6306002)(54896002)(6512007)(6506007)(53546011)(5660300002)(102836004)(256004)(446003)(14444005)(93886005)(486006)(11346002)(2616005)(476003)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2746; H:HE1PR0701MB3020.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5Sg74L4C8faM6WirI/5y81TdBs+hx+FxDMsxJCoH8eMaHnq8+9ONOYOk3FRNqrREf7I081ZNZCpjcTOczT2pK9SGjy5Z/pPbIE7N/9p3clZ8fweDSFwMPHlUCxzHTV5nGGtxF8/Jx1c6rPiWWt1QHKyiKj3tzo6VbgjpKGx1ZZGLHUSQCnr7ti9ecrfvtYkV8XLY1l58nz+bGb/Y3O+jN6RKo+FwBVDFRkLR3ar2DoRjLFpCI9//KURAaha00MZ1JFPmErHdA3NrNmYWjA8hGwur9+jZNRlAUY4RzU2e/LwYuCPqWmgB5XPMrpYdsBmRnqQ6mavY8Eei4CvgIHqFUfx1tGu4FbSuVoeKUO0e8Mnp655itWDjMAmBenbaxM4FqLOvFOVEh+OIJBx3N71yrO7zX2R86c89d0sZKxGi+LI= Content-Type: multipart/alternative; boundary="_000_4B9419DDD00A497EB895138981D36A33ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f97f00a-6fb0-4cf7-3032-08d6a23abb15 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 13:50:44.8853 (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-Transport-CrossTenantHeadersStamped: HE1PR0701MB2746 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyzUYRzHPfd8na/Lrcc5fJI2XayYqFRTma6aXG1av/5oxrj4DvPjdCc7 /YO4MtcKUShjfnRLzDLbCcv8yo9Eo2HYCsfJr7XJWqHyve/V/Pf6vN/v57P38+yhsajR0omO SUhilAnyOAlfQBXd0CcdPP4xNeRQZ7GH7+vMFb7vZIhvxnSAFMsqK3/yZPef9FEyQ2sRdRkH C/wimbiYZEbp7R8uiB55qk7sDFV3zK7jNLQenI2saSBHQfd43iobCWgR6URgnKsxD2sI3nXk Uf+H7q42zA0VPFjoqjI5FMnBsJjXZckuE5ECHoy+lXCpWQSb+YNby2iaT/xgpuISmxGTVBh6 1IpZ2Y6cAv2f/ZzsB8axXj7H56H7fSnFMkVc4dW8EbEsJKehb3TWXOIzgk8lczzWsCYB0KJ5 g1lGxAF+9NWYdEwcYdxQyuMuSqCyZRBzbA9fZ36bOtsTb2h4+IXizkZAwZqGz2VcYEGbZuY9 MFSqRWxnIEGgbwhlOwCZQFCe3sXjdE94ee8sF1dAYU8V5mRnqL17gotn8kGTUYa5p2JAV6tB OcizeFtTjiNgZdloYiGxhd4iA1W8tQoTd6hr8uYieyFfO2XF8QHQPC8xswzqxmustmfKEF2N 7FWM6mZ81BEfL0YZE6FSKRK8EpikerT1n9oa1t0a0fDSmXZEaCSxEcY2p4aILOXJqpT4dgQ0 loiFgTVbkjBSnnKHUSrClLfjGFU72k1TEkfhhsg2RESi5ElMLMMkMsp/Lo+2dkpDomvOPpVB 9sv+/leOhZV3a8VZzS+qLricyxLWSqVq7Ldr51TPxV8nwxWFS4GZq2N4X/2D2sD+ibbr0/li hfvmre82q8NDdt9Idm6vm+PGpGX5RoGuzlZtDBrwlDq46kYsqpd2JG/2D39AmRVNWG+dPiB5 xl+0WDDMXs2Ni4z1l1CqaPlhD6xUyf8CTzcVrEsDAAA= Archived-At: Subject: Re: [Taps] API drafts repository has been migrated 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, 06 Mar 2019 13:50:53 -0000 --_000_4B9419DDD00A497EB895138981D36A33ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KSnVzdCBjaGFuZ2VkIHRoZSBiYXNlIG1lbWJlciBwZXJtaXNzaW9uIHRvIHdyaXRl LCB0aGF0IHNob3VsZCBzb2x2ZSB5b3VyIHByb2JsZW0uIENhbiB5b3UgY29uZmlybSB0aGF0Pw0K DQpCUg0KWmFoZWQNCg0KT24gMjAxOS0wMy0wNiwgMTM6MjksICJUYXBzIG9uIGJlaGFsZiBvZiBU aGVyZXNhIEVuZ2hhcmR0IiA8dGFwcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0YXBzLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB0aGVyZXNhQGluZXQudHUtYmVybGluLmRlPG1haWx0 bzp0aGVyZXNhQGluZXQudHUtYmVybGluLmRlPj4gd3JvdGU6DQoNClRoYW5rcyBmb3IgbWlncmF0 aW5nIHRoZSByZXBvIQ0KDQoNCk9uIE1hciA1LCAyMDE5LCBhdCAyOjA2IFBNLCBCcmlhbiBUcmFt bWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+PG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPiB3 cm90ZToNCg0KQ2lyY2xlQ0kgc3VwcG9ydCBmb3IgYXV0b2J1aWxkaW5nIGRyYWZ0cyBzaG91bGQg YmUgdXAgc29tZXRpbWUgdG9tb3Jyb3cgKGl0J3MgbGF0ZSBoZXJlKTsgcGxlYXNlIGxldCBtZSBr bm93IGlmIHlvdSBub3RpY2UgYW55IHByb2JsZW1zIHdpdGggdGhlIG1pZ3JhdGlvbi4NCg0KTm90 IHN1cmUgaWYgcHJvYmxlbSBvciBpbnRlbmRlZCwgYnV0Og0KQXMgYSBtZW1iZXIgb2YgdGhlIG9y Z2FuaXphdGlvbiwgSSB1c2VkIHRvIGJlIGFsbG93ZWQgdG8gY3JlYXRlIGFuZCBwdXNoIGJyYW5j aGVzIGRpcmVjdGx5IHRvIHRoZSBhcGktZHJhZnRzIHJlcG9zaXRvcnkuDQpIb3dldmVyLCBvbiB0 aGUgbmV3IG9yZ2FuaXphdGlvbiwgdGhpcyBkaWQgbm90IHdvcmsganVzdCBub3csIHNlZSBiZWxv dy4NCg0KSXMgdGhpcyBpbnRlbnRpb25hbCwgaW4gd2hpY2ggY2FzZSBJIHdpbGwganVzdCBmb3Jr IHRoZSByZXBvIGFuZCBwdXNoIHRoZSBicmFuY2ggdGhlcmU/DQpPciBpcyB0aGlzIGEgYnVnIGlu IHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBuZXcgb3JnYW5pemF0aW9uPw0KDQotLS0NCg0KJCBn aXQgcHVzaCAtdSBvcmlnaW4gdGhlcmktYXBpLXVzYWdlLWV4YW1wbGUNCkVSUk9SOiBQZXJtaXNz aW9uIHRvIGlldGYtdGFwc3dnL2FwaS1kcmFmdHMuZ2l0IGRlbmllZCB0byB0aGVyaS4NCmZhdGFs OiBLb25udGUgbmljaHQgdm9tIFJlbW90ZS1SZXBvc2l0b3J5IGxlc2VuLg0KDQpCaXR0ZSBzdGVs bGVuIFNpZSBzaWNoZXIsIGRhc3MgZGllIGtvcnJla3RlbiBadWdyaWZmc2JlcmVjaHRpZ3VuZ2Vu IGJlc3RlaGVuDQp1bmQgZGFzIFJlcG9zaXRvcnkgZXhpc3RpZXJ0Lg0KDQokIGdpdCByZW1vdGUg LXYNCm9yaWdpbiAgICBnaXRAZ2l0aHViLmNvbTppZXRmLXRhcHN3Zy9hcGktZHJhZnRzPG1haWx0 bzpnaXRAZ2l0aHViLmNvbTppZXRmLXRhcHN3Zy9hcGktZHJhZnRzPiAoZmV0Y2gpDQpvcmlnaW4g ICAgZ2l0QGdpdGh1Yi5jb206aWV0Zi10YXBzd2cvYXBpLWRyYWZ0czxtYWlsdG86Z2l0QGdpdGh1 Yi5jb206aWV0Zi10YXBzd2cvYXBpLWRyYWZ0cz4gKHB1c2gpDQotLQ0KDQooSXQgc2F5cyB0aGF0 IGl0IGNvdWxkIG5vdCByZWFkIGZyb20gdGhlIHJlbW90ZSByZXBvc2l0b3J5IGFuZCB0aGF0IEkg c2hvdWxkIGNoZWNrIGlmIEkgaGF2ZSB0aGUgY29ycmVjdCBwZXJtaXNzaW9ucyBhbmQgdGhhdCB0 aGUgcmVwb3NpdG9yeSBleGlzdHMuKQ0KDQpDbG9uaW5nIHRoZSBlbnRpcmUgcmVwb3NpdG9yeSBh Z2FpbiBpbiBhIGRpZmZlcmVudCBkaXJlY3RvcnkgZGlkIG5vdCBoZWxwLg0KDQoiZ2l0IHB1bGwi IHdvcmtzIGFzIHVzdWFsLg0KDQpCZXN0LA0KVGhlcmVzYQ0K --_000_4B9419DDD00A497EB895138981D36A33ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPkp1c3QgY2hhbmdlZCB0aGUgYmFzZSBtZW1iZXIgcGVybWlzc2lvbiB0 byB3cml0ZSwgdGhhdCBzaG91bGQgc29sdmUgeW91ciBwcm9ibGVtLiBDYW4geW91IGNvbmZpcm0g dGhhdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkJSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlphaGVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjAxOS0wMy0wNiwgMTM6MjksICZxdW90O1RhcHMg b24gYmVoYWxmIG9mIFRoZXJlc2EgRW5naGFyZHQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0 YXBzLWJvdW5jZXNAaWV0Zi5vcmciPnRhcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm IG9mDQo8YSBocmVmPSJtYWlsdG86dGhlcmVzYUBpbmV0LnR1LWJlcmxpbi5kZSI+dGhlcmVzYUBp bmV0LnR1LWJlcmxpbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyBmb3IgbWlncmF0aW5nIHRo ZSByZXBvITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdp bi1sZWZ0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjOTk5OTk5IDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izk5OTk5OSI+T24gTWFyIDUsIDIwMTksIGF0IDI6MDYgUE0sIEJyaWFuIFRyYW1tZWxsIChJ RVRGKQ0KPGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giPiZsdDtpZXRmQHRyYW1tZWxs LmNoJmd0OzwvYT4gd3JvdGU6PGJyPg0KPGJyPg0KQ2lyY2xlQ0kgc3VwcG9ydCBmb3IgYXV0b2J1 aWxkaW5nIGRyYWZ0cyBzaG91bGQgYmUgdXAgc29tZXRpbWUgdG9tb3Jyb3cgKGl0J3MgbGF0ZSBo ZXJlKTsgcGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBub3RpY2UgYW55IHByb2JsZW1zIHdpdGgg dGhlIG1pZ3JhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Tm90IHN1cmUgaWYgcHJvYmxlbSBvciBpbnRlbmRlZCwgYnV0OjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkFzIGEgbWVtYmVyIG9mIHRoZSBvcmdhbml6YXRpb24sIEkgdXNlZCB0byBiZSBh bGxvd2VkIHRvIGNyZWF0ZSBhbmQgcHVzaCBicmFuY2hlcyBkaXJlY3RseSB0byB0aGUgYXBpLWRy YWZ0cyByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SG93ZXZlciwgb24gdGhlIG5l dyBvcmdhbml6YXRpb24sIHRoaXMgZGlkIG5vdCB3b3JrIGp1c3Qgbm93LCBzZWUgYmVsb3cuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklzIHRoaXMg aW50ZW50aW9uYWwsIGluIHdoaWNoIGNhc2UgSSB3aWxsIGp1c3QgZm9yayB0aGUgcmVwbyBhbmQg cHVzaCB0aGUgYnJhbmNoIHRoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T3IgaXMgdGhpcyBh IGJ1ZyBpbiB0aGUgY29uZmlndXJhdGlvbiBvZiB0aGUgbmV3IG9yZ2FuaXphdGlvbj88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0tPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiQgZ2l0IHB1c2ggLXUg b3JpZ2luIHRoZXJpLWFwaS11c2FnZS1leGFtcGxlDQo8YnI+DQpFUlJPUjogUGVybWlzc2lvbiB0 byBpZXRmLXRhcHN3Zy9hcGktZHJhZnRzLmdpdCBkZW5pZWQgdG8gdGhlcmkuPGJyPg0KZmF0YWw6 IEtvbm50ZSBuaWNodCB2b20gUmVtb3RlLVJlcG9zaXRvcnkgbGVzZW4uPGJyPg0KPGJyPg0KQml0 dGUgc3RlbGxlbiBTaWUgc2ljaGVyLCBkYXNzIGRpZSBrb3JyZWt0ZW4gWnVncmlmZnNiZXJlY2h0 aWd1bmdlbiBiZXN0ZWhlbjxicj4NCnVuZCBkYXMgUmVwb3NpdG9yeSBleGlzdGllcnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiQgZ2l0 IHJlbW90ZSAtdjxicj4NCm9yaWdpbiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86 Z2l0QGdpdGh1Yi5jb206aWV0Zi10YXBzd2cvYXBpLWRyYWZ0cyI+Z2l0QGdpdGh1Yi5jb206aWV0 Zi10YXBzd2cvYXBpLWRyYWZ0czwvYT4gKGZldGNoKTxicj4NCm9yaWdpbiZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJtYWlsdG86Z2l0QGdpdGh1Yi5jb206aWV0Zi10YXBzd2cvYXBpLWRyYWZ0 cyI+Z2l0QGdpdGh1Yi5jb206aWV0Zi10YXBzd2cvYXBpLWRyYWZ0czwvYT4gKHB1c2gpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4oSXQgc2F5cyB0aGF0IGl0IGNvdWxkIG5vdCByZWFkIGZyb20gdGhlIHJl bW90ZSByZXBvc2l0b3J5IGFuZCB0aGF0IEkgc2hvdWxkIGNoZWNrIGlmIEkgaGF2ZSB0aGUgY29y cmVjdCBwZXJtaXNzaW9ucyBhbmQgdGhhdCB0aGUgcmVwb3NpdG9yeSBleGlzdHMuKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5DbG9uaW5nIHRoZSBl bnRpcmUgcmVwb3NpdG9yeSBhZ2FpbiBpbiBhIGRpZmZlcmVudCBkaXJlY3RvcnkgZGlkIG5vdCBo ZWxwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m cXVvdDtnaXQgcHVsbCZxdW90OyB3b3JrcyBhcyB1c3VhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QmVzdCw8YnI+DQpUaGVyZXNhPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4B9419DDD00A497EB895138981D36A33ericssoncom_-- From nobody Wed Mar 6 06:07:06 2019 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 0AE0E126C87 for ; Wed, 6 Mar 2019 06:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ll7pCa-myJcT for ; Wed, 6 Mar 2019 06:07:03 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail1.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC4124B19 for ; Wed, 6 Mar 2019 06:07:02 -0800 (PST) Received: from [130.149.220.45] (esmeralda.net.t-labs.tu-berlin.de [130.149.220.45]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id C9F70593; Wed, 6 Mar 2019 15:07:00 +0100 (CET) To: Zaheduzzaman Sarker , "taps@ietf.org" , "Brian Trammell (IETF)" References: <601B8FF6-2010-489C-8FF5-C26CB06874DD@trammell.ch> <00fc4830-b1cd-85a7-b3fd-f603119da521@inet.tu-berlin.de> <4B9419DD-D00A-497E-B895-138981D36A33@ericsson.com> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== Message-ID: Date: Wed, 6 Mar 2019 15:07:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <4B9419DD-D00A-497E-B895-138981D36A33@ericsson.com> Content-Type: multipart/alternative; boundary="------------56ACD6DDC6F4F120000BECBB" Content-Language: en-US Archived-At: Subject: Re: [Taps] API drafts repository has been migrated 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, 06 Mar 2019 14:07:05 -0000 This is a multi-part message in MIME format. --------------56ACD6DDC6F4F120000BECBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Zahed, On 06.03.19 14:50, Zaheduzzaman Sarker wrote: > >  Just changed the base member permission to write, that should solve > your problem. Can you confirm that? > Yes, it works now. Thanks! Best, Theresa >   > > On 2019-03-06, 13:29, "Taps on behalf of Theresa Enghardt" > on behalf of > theresa@inet.tu-berlin.de > wrote: > >   > > Thanks for migrating the repo! > >   > > On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) > wrote: > > CircleCI support for autobuilding drafts should be up > sometime tomorrow (it's late here); please let me know if > you notice any problems with the migration. > > Not sure if problem or intended, but: > > As a member of the organization, I used to be allowed to create and > push branches directly to the api-drafts repository. > > However, on the new organization, this did not work just now, see below. > >   > > Is this intentional, in which case I will just fork the repo and push > the branch there? > > Or is this a bug in the configuration of the new organization? > >   > > --- > >   > > $ git push -u origin theri-api-usage-example > ERROR: Permission to ietf-tapswg/api-drafts.git denied to theri. > fatal: Konnte nicht vom Remote-Repository lesen. > > Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen > bestehen > und das Repository existiert. > >   > > $ git remote -v > origin    git@github.com:ietf-tapswg/api-drafts > (fetch) > origin    git@github.com:ietf-tapswg/api-drafts > (push) > > -- > >   > > (It says that it could not read from the remote repository and that I > should check if I have the correct permissions and that the repository > exists.) > >   > > Cloning the entire repository again in a different directory did not help. > >   > > "git pull" works as usual. > >   > > Best, > Theresa > -- Theresa Enghardt Wissenschaftliche Mitarbeiterin / Research Assistant Phone: +49 30 314 78628 Office: MAR 4.032 FG / Group "Internet Network Architectures" (INET) Technische Universität Berlin Sekr. MAR 4-4, Marchstraße 23, 10587 Berlin --------------56ACD6DDC6F4F120000BECBB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Zahed,

On 06.03.19 14:50, Zaheduzzaman Sarker wrote:

 Just changed the base member permission to write, that should solve your problem. Can you confirm that?

Yes, it works now. Thanks!

Best,
Theresa


 

On 2019-03-06, 13:29, "Taps on behalf of Theresa Enghardt" <taps-bounces@ietf.org on behalf of theresa@inet.tu-berlin.de> wrote:

 

Thanks for migrating the repo!

 

On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

CircleCI support for autobuilding drafts should be up sometime tomorrow (it's late here); please let me know if you notice any problems with the migration.

Not sure if problem or intended, but:

As a member of the organization, I used to be allowed to create and push branches directly to the api-drafts repository.

However, on the new organization, this did not work just now, see below.

 

Is this intentional, in which case I will just fork the repo and push the branch there?

Or is this a bug in the configuration of the new organization?

 

---

 

$ git push -u origin theri-api-usage-example
ERROR: Permission to ietf-tapswg/api-drafts.git denied to theri.
fatal: Konnte nicht vom Remote-Repository lesen.

Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.

 

$ git remote -v
origin    git@github.com:ietf-tapswg/api-drafts (fetch)
origin    git@github.com:ietf-tapswg/api-drafts (push)

--

 

(It says that it could not read from the remote repository and that I should check if I have the correct permissions and that the repository exists.)

 

Cloning the entire repository again in a different directory did not help.

 

"git pull" works as usual.

 

Best,
Theresa


-- 
Theresa Enghardt
Wissenschaftliche Mitarbeiterin / Research Assistant
Phone: +49 30 314 78628
Office: MAR 4.032

FG / Group "Internet Network Architectures" (INET)
Technische Universität Berlin
Sekr. MAR 4-4, Marchstraße 23, 10587 Berlin
--------------56ACD6DDC6F4F120000BECBB-- From nobody Wed Mar 6 10:05:50 2019 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 4755413104B; Wed, 6 Mar 2019 10:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 GVsg4IxU3bOd; Wed, 6 Mar 2019 10:05:46 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 29377127970; Wed, 6 Mar 2019 10:05:46 -0800 (PST) Received: from [130.149.220.45] (esmeralda.net.t-labs.tu-berlin.de [130.149.220.45]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 745DD590; Wed, 6 Mar 2019 19:05:44 +0100 (CET) From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== To: hackathon@ietf.org, "taps@ietf.org" Message-ID: <8a16cd43-cdc8-eec9-e460-19da0908fc62@inet.tu-berlin.de> Date: Wed, 6 Mar 2019 19:05:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Taps] Transport Services (TAPS) implementation at IETF 104 hackathon 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, 06 Mar 2019 18:05:49 -0000 Hi everyone, At the IETF 104 hackathon in Prague, my colleagues and I will be working on a Transport Services (TAPS) implementation. For those who are not familiar with TAPS, here's a quick summary: TAPS describes an abstract interface on top of different transport protocols. TAPS implementations provide a transport protocol-independent API to applications. Through this API, instead of explicitly choosing a transport protocol, an application specifies more abstract requirements and preferences. These can be Transport Services such as reliable data transfer, in-order delivery, optimizing for low latency, and others. The TAPS implementation will then determine what transport protocols are available and select one of them. It may also select between multiple available local interfaces or remote endpoints. For more information, see our drafts: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ (TAPS architecture) https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ (abstract interface) https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ (implementation considerations) Specifically, we will be working on a new TAPS implementation based on Python asyncio: https://github.com/fg-inet/python-asyncio-taps. Current ideas for the hackathon include: Incorporate more transport protocols (SCTP? QUIC?), implement (non-trivial) transport protocol selection, and incorporate security protocols, e.g., TLS. Anyone who wants to join our table is very welcome to do so. Best regards, Theresa From nobody Wed Mar 6 19:55:28 2019 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 2FEED1277CC for ; Wed, 6 Mar 2019 19:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 rq8EjJ-B7plb for ; Wed, 6 Mar 2019 19:55:25 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6F6BA1200ED for ; Wed, 6 Mar 2019 19:55:25 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x273l3T1031137 for ; Thu, 7 Mar 2019 03:55:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=qN+TQCtjtb9Rrg8KcujZhgnUB5bx3nH5Zor0/OHTEOs=; b=G8BqAwScbcMA058MY41V32piP7S15hMLKa8RuZfnglVSCEYqlFqta+MWwkW/X3BeAFnS 2QqQ1UkJ7xeYR2vfJ4sf5xTXrrffWzqWILQgMfIP8PIxwZYnkt9B/qu38GFpN3eLDwFQ YFxSeHFl+dmRpYYKdYB5dmS38UV9UGm4/rzJgssmyEQToHUrCGhxwMJ/q+mHp80GyBas OhGspYgsh+SOygvvC6YYkVYAQbdFBlka6ONQle0DBzUeu7K2RPdfbSeS+u7M42UBXxb0 7WnWS1ow2xf9n57UT3kCCB+RKFohS6DF2cPKBacPtkrtgSAKXxt8T/Vijdc5jJgNwD/i dA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2r2fm8ad64-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 07 Mar 2019 03:55:25 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x273ki7m002804 for ; Wed, 6 Mar 2019 22:55:24 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2qyp1yr53w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 06 Mar 2019 22:55:23 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Mar 2019 22:55:22 -0500 Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1473.003; Wed, 6 Mar 2019 22:55:21 -0500 From: "Holland, Jake" To: taps WG Thread-Topic: [Taps] call for agenda items at TAPS IETF-104 Thread-Index: AQHU0ruJg/BpMSiZnkS1XjtUnIdzOKX8G+mAgAM/gYA= Date: Thu, 7 Mar 2019 03:55:21 +0000 Message-ID: <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> In-Reply-To: <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.22] Content-Type: text/plain; charset="utf-8" Content-ID: <4CB25495145A184FB04E7138D4E4385C@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070025 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070025 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 03:55:27 -0000 SGkgdGFwcywNCg0KKFRyeWluZyBhZ2FpbiwgYnV0IHNpbXBsZXIuKQ0KDQpJJ20gbG9va2luZyBm b3IgYSBjb25zZW5zdXMgeWVzIG9yIG5vIGFuc3dlcjoNCg0KSXMgYSBub3JtYXRpdmUgY29uZmln IGlucHV0IGZvcm1hdCBhbiBpbnRlcmVzdGluZyBhbmQgdXNlZnVsDQpkaXJlY3Rpb24/DQoNCg0K VGhlIGlkZWEgaXMgdG8gYWRkIGZ1bmN0aW9uYWxpdHkgbGlrZSB0aGlzLCBpbiB0YXBzLWludGVy ZmFjZToNCg0KICBuZXdQcmUgPSBQcmVDb25uZWN0aW9uLk5ld0Zyb21Kc29uKCcnJ3sNCiAgICAi cmVtb3RlLWVuZHBvaW50Ijp7DQogICAgICAiaG9zdHMiOlsNCiAgICAgICAgeyAiaG9zdCI6ImV4 YW1wbGUuY29tIiB9DQogICAgICBdDQogICAgfQ0KICB9JycnKQ0KDQpXaXRoIGEgZnVsbHkgc3Bl Y2lmaWVkIGpzb24gaW5wdXQgZm9ybWF0IHRoYXQgY2FuIHByb3ZpZGUgYWxsIHRoZQ0KY29uZmln dXJhYmxlIHZhbHVlcy4NCg0KDQpJZiBubywgSSdsbCBtb3ZlIG9uIGFuZCBhc3N1bWUgSSBqdXN0 IGRvbid0IHVuZGVyc3RhbmQgdGFwcyBnb2Fscy4NCg0KSWYgeWVzLCBJJ2QgbGlrZSAxNSBtaW51 dGVzIHRvIGRpc2N1c3MgaW4gUHJhZ3VlLCBhbmQga2VlcCByZWFkaW5nOg0KDQpJIHRoaW5rIGEg ZnVsbCBkZWZpbml0aW9uIG9mIGFuIGlucHV0IGpzb24gZm9ybWF0IGNhbiBiZSBleGFjdGx5DQpz cGVjaWZpZWQgYnkgYSBZQU5HIG1vZGVsLiAoV2l0aCB4bWwgZm9yIGZyZWUsIGlmIHlvdSB3YW50 IGl0LikNCg0KSSB0cmllZCB0byBza2V0Y2ggYSBzdGFydCBhdCB3aGF0IGEgWUFORyBtb2RlbCBm b3IgdGhpcyBtaWdodCBsb29rIGxpa2U6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtamhvbGxhbmQtdGFwcy1hcGkteWFuZy0wMCNzZWN0aW9uLTMNCg0KSSdtIG5vdCBhIFlBTkcg ZXhwZXJ0IHlldCwgYW5kIGl0J3Mgbm90IG11Y2ggb2YgYSBtb2RlbC4gIEFuZCBpdCdzIHZlcnkN CmZhciBmcm9tIGNvbXBsZXRlLiAgQnV0IGl0IGNvbXBpbGVzLCBhbmQgYWxsIHRoZSBleGFtcGxl cyBpbiB0aGUgZHJhZnQNCnZhbGlkYXRlIGFnYWluc3QgdGhhdCBtb2RlbCB3aXRoIGxpYnlhbmcu ICBJZiBpdCdzIHdvcnRod2hpbGUsIEkgdGhpbmsNCnNvbWV0aGluZyBsaWtlIHRoaXMgY2FuIGJl IGdvb2QgKGFuZCBleHRlbnNpYmxlISksIGlmIGRvbmUgcmlnaHQuDQoNCkkgYmVsaWV2ZSBzb21l dGhpbmcgYWxvbmcgdGhlc2UgbGluZXMgd291bGQgc2hhcnBlbiB1cCB0YXBzLWludGVyZmFjZQ0K YSBsb3QuIChBZnRlciBmaWxsaW5nIGluIGFsbCB0aGUgdGFwcy1pbnRlcmZhY2UgcHJvcGVydGll cy4pDQoNCg0KVGhlIHJlYXNvbiBJJ20gYXNraW5nIGlzIGJlY2F1c2UgcmlnaHQgbm93LCB0YXBz LWludGVyZmFjZSB0byBtZQ0Kc2VlbXMgX2FsbW9zdF8gcmVhbGx5IGdvb2QsIGV4Y2VwdCB0b28g Y29uZnVzaW5nIGFuZCB2YWd1ZSB0byBhY3R1YWxseQ0KYnVpbGQgYW4gQVBJIHRoYXQgY2FuIHJl cGxhY2UgQlNEIHNvY2tldHMuICBJIHRoaW5rIHdpdGggYSBzb2xpZCBjb25maWcNCmZvcm1hdCB3 aXRoIG5vcm1hdGl2ZSBhbmQgdGVzdGFibGUgZXhhbXBsZXMsIHRoYXQgY291bGQgYmUgZml4ZWQu DQoNCklmIGNvbnNlbnN1cyBzYXlzICJpbnRlcmVzdGluZyIsIEknbGwgd2FudCAxNSBtaW51dGVz IHRvIGRpc2N1c3MgaXQsIGFuZA0KdG8gc3RhcnQgZGlnZ2luZyBpbnRvIGhvdyB0byBtYWtlIGl0 IGdvb2QuICAoQW5kIGFsc28gdG8gYWRkIG11bHRpY2FzdA0Kc3VwcG9ydCB0byB0aGUgbW9kZWwg YW5kIGF0IGxlYXN0IG9uZSBpbXBsZW1lbnRhdGlvbi4pDQoNClRoYW5rcyBmb3IgeW91ciBjb25z aWRlcmF0aW9uLg0KDQoNCkNoZWVycywNCkpha2UNCg0KDQoNCu+7v09uIDIwMTktMDMtMDQsIDE3 OjE5LCAiSG9sbGFuZCwgSmFrZSIgPGpob2xsYW5kQGFrYW1haS5jb20+IHdyb3RlOg0KDQogICAg SGkgdGFwcyBmb2xrcywNCiAgICANCiAgICBUTDtEUjogSSB0aGluayB0aGUgc3BlYyBzaG91bGQg aGF2ZSBhIFlBTkcgbW9kZWwgYW5kIEkgd2FudCB0byB1c2UgaXQNCiAgICB0byBnZXQgbXVsdGlj YXN0IHN1cHBvcnQgaW4gYW4gaW1wbGVtZW50YXRpb24uDQogICAgDQogICAgDQogICAgSSByZWNl bnRseSBzdGFydGVkIGRpZ2dpbmcgaW50byB0aGUgdGFwcyBBUEkgd2l0aCB0aGUgaW50ZW50IG9m IGFkZGluZw0KICAgIG11bHRpY2FzdCBzdXBwb3J0LCBidXQgaXQgbG9va3MgbGlrZSBpdCdzIGJh c2ljYWxseSBhbHJlYWR5IHRoZXJlLCBhcw0KICAgIGZhciBhcyBpdCBnb2VzWypdLg0KICAgIA0K ICAgIEJ1dCBJIGVuZGVkIHVwIHdpdGggYSBoaWdoZXItbGV2ZWwgY29tbWVudCwgc28gSSB0aG91 Z2h0IEknZCByYWlzZSBpdA0KICAgIHRvIHRoZSB3ZyBhbmQgYXNrIHdoYXQgeW91IGFsbCB0aGlu ay4NCiAgICANCiAgICBJIGZvdW5kIHRoZSB3aG9sZSAiYWJzdHJhY3QgaW50ZXJmYWNlIiBhcHBy b2FjaCBhIGxpdHRsZSB0b28NCiAgICBsb29zZXktZ29vc2V5LCBzbyBJIHRob3VnaHQgSSdkIHRy eSB0byBzdWdnZXN0IGEgd2F5IHRvIHRpZ2h0ZW4gaXQgdXAuDQogICAgDQogICAgTXkgZ29hbCB3 aXRoIHRoaXMgaXMgdG8gbWFrZSBpdCBtdWNoIG1vcmUgY2xlYXIgKHRvIHRoZSBwb2ludCBvZiBi ZWluZw0KICAgIG1lY2hhbmljYWxseSBjaGVja2FibGUpIHByZWNpc2VseSB3aGF0IGEgY29tcGxp YW50IEFQSSBwcm92aWRlcy4NCiAgICANCiAgICBJJ20gbm90IGF0dGFjaGVkIHRvIHRoZSBzdHJ1 Y3R1cmUgSSdtIHByb3Bvc2luZyBvciB0byBhbnkgb2YgdGhlDQogICAgcGFydGljdWxhcnMgaW4g dGhlIHN0cmF3LW1hbiBJJ3ZlIHBvc3RlZCwgYnV0IGlmIGl0J3Mgbm90IHRpZ2h0ZW5lZCB1cA0K ICAgIHdpdGggc29tZXRoaW5nIGF0IGEgc2ltaWxhciBsZXZlbCBvZiBjb25jcmV0ZW5lc3MsIEkn bSBjb25jZXJuZWQgdGhhdA0KICAgIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBiZSBu b3Qgb25seSBpbmNvbXBhdGlibGUgaW4gcmFuZG9tDQogICAgdW5kZXJzcGVjaWZpZWQgY29ybmVy IGNhc2VzIChsaWtlIEJTRCBzb2NrZXRzIHRvZGF5IHdoZW4geW91IHRyeSB0byBtYWtlDQogICAg Y3Jvc3MtcGxhdGZvcm0gQyBjb2RlKSwgYnV0IGFsc28gYXJlIGxpa2VseSB0byBlbmQgdXAgd2l0 aCB2ZXJ5IG1hbnkNCiAgICBpbXBvcnRhbnQgZGlmZmVyZW5jZXMgdGhhdCB3b3VsZCBtYWtlIHRo ZSB3aG9sZSB0YXBzIGVmZm9ydCBtb3JlIG9yIGxlc3MNCiAgICBtb290Lg0KICAgIA0KICAgIElu IGEgd29ybGQgd2hlcmUgd2UgZW5kIHVwIHdpdGggYSBkb2MgYXQgdGhlIGxldmVsIG9mIGFic3Ry YWN0aW9uIEknbQ0KICAgIGN1cnJlbnRseSBzZWVpbmcgaW4gZHJhZnQtdGFwcy1pbnRlcmZhY2Us IGl0IHNlZW1zIHRvIG1lIHRoYXQgaWYgMg0KICAgIGRpZmZlcmVudCBBUEkgaW1wbGVtZW50YXRp b25zIHdlcmUgd3JpdHRlbiBpbiB0aGUgc2FtZSBsYW5ndWFnZSwgaXQnbGwNCiAgICBiZSBwcm9o aWJpdGl2ZWx5IGRpZmZpY3VsdCBmb3IgYW4gYXBwIHRvIG1pZ3JhdGUgZnJvbSB1c2luZyBvbmUg dG8gdXNpbmcNCiAgICB0aGUgb3RoZXIsIGp1c3QgYmVjYXVzZSBzbyBtYW55IGFzcGVjdHMgb2Yg aXQgYXJlIGxlZnQgb3BlbiB0byB0aGUNCiAgICBpbXBsZW1lbnRvcnMuDQogICAgDQogICAgSW4g dGhhdCBjb250ZXh0LCBJIHRob3VnaHQgYSBZQU5HIG1vZGVsIHdvdWxkIGJlIHVzZWZ1bCBoZXJl IHRvDQogICAgcHJvdmlkZSBhIGNyb3NzLXBsYXRmb3JtIHdheSB0byBzcGVjaWZ5IHdoYXQgZXhh Y3QgcHJvcGVydGllcyBhbmQNCiAgICBvYmplY3RzIGV4aXN0LCBhbiBleGFjdCBmb3JtYXQgaW4g d2hpY2ggdGhlIHZhbHVlcyBjYW4gYmUgc3BlY2lmaWVkLCBhbmQNCiAgICB3aGF0IGV4YWN0IHNl bWFudGljcyB0aGV5IGhhdmUsIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciBhIHNhbmUNCiAgICBl eHRlbnNpb24gcGF0aCBhbmQgbGFuZ3VhZ2Utc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gZGV0YWls cy4NCiAgICANCiAgICBJJ20gdGhpbmtpbmcgc29tZSBsYW5ndWFnZSBhIGJpdCBsaWtlIHRoZSBm aXJzdCBidWxsZXQgaW4gU2VjdGlvbiA0LjIgb2YNCiAgICB0YXBzLWludGVyZmFjZToNCiAgICAN CiAgICAgIEEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIFNIT1VMRCBwcm92aWRlIGEgbGFuZ3Vh Z2UtYXBwcm9wcmlhdGUgd2F5IHRvDQogICAgICBjb25maWd1cmUgYSBQcmVDb25uZWN0aW9uIHVz aW5nIFlBTkcgaW5zdGFuY2UgZGF0YSBmb3IgdGhpcyBtb2RlbCwgYW5kDQogICAgICBTSE9VTEQg cHJvdmlkZSBhbiBBUEkgdGhhdCBvdXRwdXRzIHRoZSBZQU5HIGluc3RhbmNlIGRhdGEgZm9yIGFu DQogICAgICBlc3RhYmxpc2hlZCBDb25uZWN0aW9uLg0KICAgIA0KICAgICAgQW4gaW1wbGVtZW50 YXRpb24gTUFZIGFsc28gcHJvdmlkZSBhcHByb3ByaWF0ZSBBUElzIGZvciBkaXJlY3RseSBlZGl0 aW5nDQogICAgICB0aGUgb2JqZWN0cyB3aXRob3V0IHVzaW5nIFlBTkcuICBJdCdzIFJFQ09NTUVO REVEIHdoZXJlIHBvc3NpYmxlIHRvIHVzZQ0KICAgICAgbmFtZXMgdGhhdCBtZWNoYW5pY2FsbHkg dHJhbnNsYXRlIHRvIHRoZSBuYW1lcyBpbiB0aGUgWUFORyBkYXRhIG1vZGVsLA0KICAgICAgdXNp bmcgY2FwaXRhbGl6YXRpb24gYW5kIHB1bmN0dWF0aW9uIGNvbnZlbnRpb25zIGFzIGV4cGVjdGVk IGZvciB0aGUNCiAgICAgIGxhbmd1YWdlIG9mIHRoZSBpbXBsZW1lbnRhdGlvbi4NCiAgICANCiAg ICBBbmQgdGhlbiBvZiBjb3Vyc2UgYSBZQU5HIG1vZGVsOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcvDQogICAgKGRyYWZ0 LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcpDQogICAgDQogICAgSWYgdGhpcyBzZWVtcyB1c2VmdWws IGl0IHdpbGwgbmVlZCBsb3RzIG9mIHJlZmluaW5nLiAgSSdsbCBiZSBzdXJwcmlzZWQNCiAgICBp ZiBhbnkgcGFydCBvZiBpdCBzdXJ2aXZlcyBleGFjdGx5IGFzIHdyaXR0ZW4uICBJdCdzIGEgcXVp Y2sgYW5kDQogICAgZGlydHkgYXR0ZW1wdCB0byBjb25jcmV0aXplIGEgZmV3IG9mIHRoZSB0aGlu Z3MgSSBzYXcgbGlzdGVkIGluDQogICAgZHJhZnQtaWV0Zi10YXBzLWludGVyZmFjZSwgYXMgYSBz dGFydGluZyBwb2ludCB0byBmaWxsIG91dCBpZiBpdCBzZWVtcw0KICAgIHVzZWZ1bC4NCiAgICAN CiAgICBCdXQgdGhlIG1vZGVsIHBhcnNlcywgYW5kIHRoZSBleGFtcGxlIGRhdGEgaW5zdGFuY2Vz IGluIHRoZSBkcmFmdA0KICAgIHBhcnNlIGFnYWluc3QgdGhlIG1vZGVsIChhbGwgd2l0aCBsaWJ5 YW5nKS4NCiAgICANCiAgICBPbmUgb2YgdGhlIG1haW4gcmVhc29ucyBJJ20gZG9pbmcgdGhpcyBp cyBiZWNhdXNlIGl0IHNlZW1zIHRvIG1lIHdoYXQncw0KICAgIHNwZWNpZmllZCBpbiB0YXBzLWlu dGVyZmFjZS0wMiB0b2RheSBpcyBtaXNzaW5nIHNvbWUga2V5IGZlYXR1cmVzLCBsaWtlDQogICAg YW4gZW51bWVyYXRpb24gb2YgdGhlIHByb3BlcnRpZXMgaW4gdGhlIExvY2FsL1JlbW90ZUVuZHBv aW50IGV4YW1wbGVzIGluDQogICAgc2VjdGlvbiA1LjEuICBBbmQgSSBkb24ndCBzZWUgdGhhdCBs aXN0ZWQgYXMgYW4gb3BlbiBpc3N1ZSBpbiBnaXRodWIsDQogICAgd2hpY2ggc3VycHJpc2VkIG1l IGEgYml0Lg0KICAgIA0KICAgIEkgdGhpbmsgb3ZlcnNpZ2h0cyBsaWtlIHRoaXMgd2lsbCBiZWNv bWUgaW1tZWRpYXRlbHkgYW5kIHBhaW5mdWxseQ0KICAgIG9idmlvdXMgd2hlbiB0aGVyZSdzIGEg cmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIHRoYXQgaW5jbHVkZXMgYSBZQU5HDQogICAgcGFyc2Vy IGFuZCBhbiBleHBsaWNpdCBkYXRhIG1vZGVsLCBhcyBvcHBvc2VkIHRvIHRoZSBjb21iaW5nIG9m IHRoZQ0KICAgIGRvY3VtZW50IGFuZCBhIHNvcnQgb2YgZXllYmFsbGVkIGNvbXBhcmlzb24gdG8g TkVBVCB0aGF0IEkgdHJpZWQNCiAgICB0aGlzIHdlZWsgdG8gcmVhY2ggdGhhdCBjb25jbHVzaW9u ICh3aGljaCBJIGZvdW5kIGNoYWxsZW5naW5nIGV2ZW4NCiAgICB0aG91Z2ggSSB0aG91Z2h0IGJv dGggdGhlIGRvY3VtZW50IGFuZCB0aGUgbGlicmFyeSB3ZXJlIG1vc3RseSBwcmV0dHkNCiAgICB3 ZWxsIHdyaXR0ZW4pLg0KICAgIA0KICAgIFRoZSB3aG9sZSB0aGluZyBhdCB0aGlzIHBvaW50IGp1 c3Qgc21lbGxzIHRvIG1lIG11Y2ggbW9yZSBhYnN0cmFjdCB0aGFuDQogICAgaXQgcmVhbGx5IGhh cyB0byBiZSBvciB0aGFuIGl0J3MgcmVhbGx5IHVzZWZ1bCB0byBiZSwgd2hpY2ggYm90aGVycyBt ZQ0KICAgIGJlY2F1c2UgdGhlIGlkZWEgb2YgcmVwbGFjaW5nIEJTRCBzb2NrZXRzIHdpdGggc29t ZXRoaW5nIHVzYWJsZSBzZWVtcw0KICAgIGxpa2Ugc3VjaCBhIGdyZWF0IGlkZWEuICBJJ2QgbGlr ZSB0aGlzIHRvIGJlIHNvbWV0aGluZyBJIGNhbiBhY3R1YWxseQ0KICAgIHVzZSBpbiBhIHdheSB0 aGF0IG1ha2VzIG15IGxpZmUgZWFzaWVyIHNvbWVkYXkgc29vbi4NCiAgICANCiAgICBCdXQgSSB0 aGluayBJJ20gYXQgdGhlIHBvaW50IHdoZXJlIEkgbmVlZCBhIHNhbml0eSBjaGVjayB0byBzZWUg aWYgSSdtDQogICAganVzdCBtaXNzaW5nIHNvbWV0aGluZywgb3IgaWYgdGhpcyBzZWVtcyBsaWtl IGEgdXNlZnVsIGRpcmVjdGlvbi4NCiAgICANCiAgICBUaG91Z2h0cz8gIFN1Z2dlc3Rpb25zPyAg IFdvcnRoIGRpc2N1c3NpbmcgaW4gUHJhZ3VlPyAgKElmIHNvLCBjYW4gSQ0KICAgIGdldCBhIHNs b3Q/KQ0KICAgIA0KICAgIENoZWVycywNCiAgICBKYWtlDQogICAgDQogICAgKjoNCiAgICBJIGNv bmNsdWRlZCB0aGF0IHRoZXJlJ3Mgbm8gcmVhc29uIG11bHRpY2FzdCBjb3VsZG4ndCBiZSBzdXBw b3J0ZWQNCiAgICB0b2RheSwgaWYgdGhlcmUgd2VyZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGNv dWxkIHJlYXNvbmFibHkgY2xhaW0gdG8gYmUNCiAgICBjb21wbGlhbnQsIGJ5IGp1c3QgYWRhcHRp bmcgc29tZSBvZiB0aGUgZXhhbXBsZXMgaW4NCiAgICBkcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNl LTAyIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBzZW1hbnRpYyBtZWFuaW5nIG9mDQogICAgbXVsdGlj YXN0IGFkZHJlc3Mgc3BhY2VzIGluc2lkZSB0aGUgQVBJLg0KICAgIA0KICAgIEZvciBleGFtcGxl LCBJIGNvdWxkbid0IGZpbmQgYW55IHJlYXNvbiB0aGlzIGNhbid0IGJlIGV4cGVjdGVkIHRvIHNl dA0KICAgIHVwIGFuIFNTTSBjaGFubmVsIHN1YnNjcmlwdGlvbiB3aXRob3V0IGFueSBmdXJ0aGVy IGFkbywgZ2l2ZW4gYSBzYW5lDQogICAgaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBpdDoN CiAgICANCiAgICAgIFJlbW90ZVNwZWNpZmllciA6PSBOZXdSZW1vdGVFbmRwb2ludCgpDQogICAg ICBSZW1vdGVTcGVjaWZpZXIuV2l0aElQdjRBZGRyZXNzKDE5Mi4wLjIuMjEpDQogICAgDQogICAg ICBMb2NhbFNwZWNpZmllciA6PSBOZXdMb2NhbEVuZHBvaW50KCkNCiAgICAgIExvY2FsU3BlY2lm aWVyLldpdGhQb3J0KDMwMDAwKQ0KICAgICAgTG9jYWxTcGVjaWZpZXIuV2l0aElQdjRBZGRyZXNz KDIzMi4yNTIuMC4yKQ0KICAgIA0KICAgICAgTmV3UHJlY29ubmVjdGlvbihSZW1vdGVTcGVjaWZp ZXIsIExvY2FsU3BlY2lmaWVyKS5MaXN0ZW4oLi4uKQ0KICAgIA0KICAgIE1heWJlIHRoZXJlJ3Mg c29tZSB2YWx1ZSBpbiBzcGVjaWZ5aW5nIGEgIkpvaW5TU00oKSIgdG8gb3ZlcnJpZGUgZGVmYXVs dHMNCiAgICBpbiB0aGUgUHJlQ29ubmVjdGlvbiwganVzdCB0byBtYWtlIHN1cmUgeW91J3JlIHNw ZWNpZmljYWxseSBhc2tpbmcgZm9yDQogICAgbXVsdGljYXN0LiAgSSB0aGluayB0aGF0IHdvdWxk IGJlIGZpbmUgZm9yIG5hdGl2ZSBtdWx0aWNhc3QsIGJ1dCBsaWtlIEkNCiAgICBzYWlkLCBhIG11 Y2ggc21hbGxlciBwb2ludCB0aGFuIHRoZSBsb29zZW5lc3Mgb2YgdGhlIEFQSS4NCiAgICANCiAg ICBXaGVyZSBpdCBnZXRzIGEgYml0IG1vcmUgY29tcGxpY2F0ZWQgaXMgdHJ5aW5nIHRvIGhhbmRs ZSBtdWx0aXBsZSBvcHRpb25zDQogICAgZm9yIGRpc2NvdmVyaW5nIGEgdXNhYmxlIHVuaWNhc3Qg dHVubmVsIGZvciBtdWx0aWNhc3QgdHJhZmZpYywgYXMNCiAgICBkZXNjcmliZWQgaW4gU2VjdGlv biAyLjQuMSBvZiBkcmFmdC1pZXRmLW1ib25lZC1kcmlhZC1hbXQtZGlzY292ZXJ5LTAxLg0KICAg IA0KICAgIEknZCBsaWtlIHRvIGhhdmUgYSBkZWNlbnQgcGxhY2UgdG8gdGFjayBvbiBhbiBleHRl bnNpb24gdG8gdGhpcyBBUEkgdGhhdA0KICAgIGNhbiB0cmFuc3BhcmVudGx5LCB3aXRoaW4gdGhl IGNvbm5lY3Rpb24gQVBJLCBkaXNjb3ZlciB0aGUgYmVzdCBhdmFpbGFibGUNCiAgICBBTVQgcmVs YXkgYW5kIHN0YXJ0IHVzaW5nIGl0IHdoZW4gbmF0aXZlIGpvaW5pbmcgaXMgdW5hdmFpbGFibGUg KGFuZCBhbHNvDQogICAgdG8gcHJvdmlkZSBub3JtYXRpdmUgY29udHJvbHMgZm9yIGNvbmZpZ3Vy aW5nIGl0IHdoZW4gdGhlcmUncw0KICAgIGFkbWluaXN0cmF0aXZlIGNvbmZpZ3VyYXRpb24gdG8g YmUgYWRkZWQpLg0KICAgIA0KICAgIEJ1dCB0aGF0J3MgYSAybmQgb3JkZXIgcXVlc3Rpb24gZm9y IG1lIGF0IHRoaXMgcG9pbnQsIGJlY2F1c2UgaW4gdGhlDQogICAgY3VycmVudCBUQVBTIEFQSSBJ IGRvbid0IHNlZSBhbnkgb2J2aW91c2x5IGdvb2Qgc3BvdCB0byBwdXQgc2VsZWN0aW9uDQogICAg Y29udHJvbHMgZm9yIHRoYXQga2luZCBvZiB0dW5uZWwgZGlzY292ZXJ5IHNlbGVjdGlvbiwgb3Ig cmVhbGx5IGEgZ29vZA0KICAgIHdheSB0byBleHBsYWluIHdoYXQgaXQncyBzdXBwb3NlZCB0byBk bywgaWYgSSB0cmllZCB0byBhZGQgY29udHJvbHMgdG8NCiAgICBzb21ldGhpbmcgdGhhdCdzIHRo ZXJlLg0KICAgIA0KICAgIFNvbHZpbmcgdGhhdCBpcyBteSBtYWluIG1vdGl2YXRpb24gZm9yIGJl aW5nIGhlcmUuICAoV2VsbCwgYW5kIHRoYXQNCiAgICB0aGUgQlNEIHNvY2tldCBBUEkgZm9yIG11 bHRpY2FzdCBpcyBraW5kIG9mIGEgZGlzYXN0ZXIgdG9kYXkuKQ0KICAgIA0KICAgIEFueXdheSwg aWYgdGFwcyBmaW5kcyB0aGUgd2hvbGUgWUFORyBzdWdnZXN0aW9uIHVzZWZ1bCwgSSdsbCBwcm9i YWJseQ0KICAgIHN1Z2dlc3Qgc29tZSBuZXcgZXh0ZW5zaW9ucyBhYm91dCB0aGlzLCBhbmQgbWF5 YmUgYSBmZXcgb3RoZXIgcG9pbnRzLA0KICAgIGVzcGVjaWFsbHkgbWF5YmUgYXJvdW5kIHRyeWlu ZyB0byBwdXQgaW4gYSBzdHJ1Y3R1cmUgdGhhdCBjYW4gc3VwcG9ydA0KICAgIHNvbWUga2luZCBv ZiBzYW5lIGV4cGxpY2l0IGxheWVyaW5nLg0KICAgIA0KICAgIEJ1dCBJJ20gbm90IHN1cmUgSSBj YW4gYXJ0aWN1bGF0ZSB0aG9zZSBzdWdnZXN0aW9ucyBpbiBhIHdheSBJJ20gc3VyZSBpcw0KICAg IG1lYW5pbmdmdWwgd2l0aG91dCBmaXJzdCBnZXR0aW5nIGEgbW9yZSBjbGVhciBzcGVjaWZpY2F0 aW9uIG5haWxlZCBkb3duDQogICAgYWJvdXQgd2hhdCdzIGFjdHVhbGx5IGluIHRoZSB0YXBzIHNw ZWMuIEJlY2F1c2UgcmlnaHQgbm93IEknbSBtb3N0bHkNCiAgICBqdXN0IGNvbmZ1c2VkIGFib3V0 IHdoYXQgYW4gQVBJIGltcGxlbWVudGF0aW9uIHdvdWxkIHJlYWxseSBsb29rIGxpa2UsDQogICAg YW5kIGhvdyB5b3UgY291bGQgdGVsbCB3aGV0aGVyIGl0IG1hdGNoZXMgdGhlIHRhcHMtaW50ZXJm YWNlIHNwZWMuDQogICAgDQogICAgDQogICAgDQogICAgRnJvbTogQWFyb24gRmFsayA8YWFyb24u ZmFsa0BnbWFpbC5jb20+DQogICAgRGF0ZTogMjAxOS0wMy0wNCBhdCAxMDo1Mw0KICAgIFRvOiB0 YXBzIFdHIDx0YXBzQGlldGYub3JnPg0KICAgIENjOiBaYWhlZHV6emFtYW4gU2Fya2VyIDx6YWhl ZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbT4NCiAgICBTdWJqZWN0OiBbVGFwc10gY2FsbCBm b3IgYWdlbmRhIGl0ZW1zIGF0IFRBUFMgSUVURi0xMDQNCiAgICANCiAgICBIaSBBbGwtDQogICAg V2hhdCBzaG91bGQgd2UgdXNlIG91ciB0aW1lIHRvIGRpc2N1c3M/IExldOKAmXMgZm9jdXMgb24g dGhpbmdzIHRoYXQgd291bGQgYmVuZWZpdCBmcm9tIGYyZiBkaXNjdXNzaW9uLCBjb25zZW5zdXMg YnVpbGRpbmcsIG9yIGp1c3QgYXJndW1lbnQuIDopDQogICAg4oCiIFRBUFMgZG9jczogYXJlIHRo ZXJlIG9wZW4gdG9waWNzIHRoYXQgbmVlZCBncm91cCBhdHRlbnRpb24/IFNlZW1zIGxpa2Ugd2Ug c2V0dGxlZCBtb3N0IG9mIHRoZSByZW1haW5kZXIgYXQgdGhlIGludGVyaW0uIA0KICAgIOKAoiBU QVBTIHNlY3VyaXR5OiB0aGlzIHNlZW1zIG5lYXJseSBkb25lLiBBbnl0aGluZyB0byBkaXNjdXNz PyANCiAgICDigKIgSW1wbGVtZW50YXRpb25zOiBhIGdvb2QgdG9waWMgZm9yIGluZm9ybWF0aW9u IHNoYXJpbmcgYnV0IGxlc3MgaW1wb3J0YW50IHRoYW4gYW55dGhpbmcgbmVlZGluZyBhZ3JlZW1l bnQgDQogICAg4oCiIE1vYmlsaXR5OiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEZG1t LTJEb25kZW1hbmQtMkRtb2JpbGl0eS0yRDE3JmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZyPWJxbkZST2l2RG9fNGlGOFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1wTFc1 Z1N5ZXRmVmVfaXhHNF91N3FLWF9WY2pJcXpON0p1MkJnTTJycFFvJnM9SFVzQlZCRl9HaE5pT2sz Z3FZX201cVpNRC1zUG1CSjkzR0U1d2QzRDVfcyZlPSBhbmQgaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2Nf cmV2aWV3LTJEaWV0Zi0yRGRtbS0yRG9uZGVtYW5kLTJEbW9iaWxpdHktMkQxNS0yRHRzdmFydC0y RGxjLTJEd2VzdGVybHVuZC0yRDIwMTktMkQwMS0yRDA4XyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0 dzBGNGpwTjZMWmcmcj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29r Jm09cExXNWdTeWV0ZlZlX2l4RzRfdTdxS1hfVmNqSXF6TjdKdTJCZ00ycnBRbyZzPTBZbUNfWENB dTRfR1ZZZEZpMEh4aUthS0JwYW4yQ09ZcUJMMW1CNmJYclkmZT0gDQogICAgLS1hYXJvbg0KICAg IA0KICAgIA0KDQo= From nobody Thu Mar 7 00:32:13 2019 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 1A5D5130EBA for ; Thu, 7 Mar 2019 00:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 e3o8BeFOx9Ar for ; Thu, 7 Mar 2019 00:32:08 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 B2418128AFB for ; Thu, 7 Mar 2019 00:32:07 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h1oRg-0009RW-Ea; Thu, 07 Mar 2019 09:32:04 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1h1oRf-000GTg-1n; Thu, 07 Mar 2019 09:32:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> Date: Thu, 7 Mar 2019 09:32:01 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B677A4E4FDFE38D4EBF6640FC0C169D0F5483303 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 08:32:12 -0000 Hi, Very sorry for the silence. I can only speak for myself, but here's an = example of why this one person was silent: - When you created your issue on multicast in github, I thought of = answering (positively), but then thought that the repo is about to move, = and it would probably be better to delay things until the move is = finished. - Then, the issue was overruled by your email. I read it and found it = interesting, but hoped for someone else to answer because, frankly, I = was afraid to make a fool of myself ... because I know almost nothing = about YANG. But now I'll be brave :) I'll go ahead and ask: how exactly is this = YANG proposal more than just a syntax change? What would it give us? (I understand that YANG can be automatically parsed / checked by some = tools, but... what does THAT give us?) Also, I actually see 3 separable things being proposed here: 1) the YANG model 2) multicast support (I find your conclusion that not much needs to = change interesting! Though the example you're giving (joining an SSM = channel) is only a part of what we'd need, as you also say...) 3) applying preferences to addresses and port numbers (which you seem = to take for granted in your draft, but which I don't think is supported = by our current document). Side note: unless I'm mistaken, this wouldn't fit our structure well: = e.g. a port number would then be a Transport Property that has a certain = value, but also has a preference, but currently we say that a Transport = Property has "one of a set of data types", one of which is a Preference. = Isn't that structure too limiting? Or am I missing something? I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) as = separate... maybe there are other use cases for 3) alone ? IMO, all of these things are interesting, and would be good to discuss = on site. However, I doubt that we can deal with them all in only 15 = minutes :-) Cheers, Michael PS: Travis is down, or something. At least the "Editor's Copy" links = don't currently work. > On 7 Mar 2019, at 04:55, Holland, Jake wrote: >=20 > Hi taps, >=20 > (Trying again, but simpler.) >=20 > I'm looking for a consensus yes or no answer: >=20 > Is a normative config input format an interesting and useful > direction? >=20 >=20 > The idea is to add functionality like this, in taps-interface: >=20 > newPre =3D PreConnection.NewFromJson('''{ > "remote-endpoint":{ > "hosts":[ > { "host":"example.com" } > ] > } > }''') >=20 > With a fully specified json input format that can provide all the > configurable values. >=20 >=20 > If no, I'll move on and assume I just don't understand taps goals. >=20 > If yes, I'd like 15 minutes to discuss in Prague, and keep reading: >=20 > I think a full definition of an input json format can be exactly > specified by a YANG model. (With xml for free, if you want it.) >=20 > I tried to sketch a start at what a YANG model for this might look = like: > https://tools.ietf.org/html/draft-jholland-taps-api-yang-00#section-3 >=20 > I'm not a YANG expert yet, and it's not much of a model. And it's = very > far from complete. But it compiles, and all the examples in the draft > validate against that model with libyang. If it's worthwhile, I think > something like this can be good (and extensible!), if done right. >=20 > I believe something along these lines would sharpen up taps-interface > a lot. (After filling in all the taps-interface properties.) >=20 >=20 > The reason I'm asking is because right now, taps-interface to me > seems _almost_ really good, except too confusing and vague to actually > build an API that can replace BSD sockets. I think with a solid = config > format with normative and testable examples, that could be fixed. >=20 > If consensus says "interesting", I'll want 15 minutes to discuss it, = and > to start digging into how to make it good. (And also to add multicast > support to the model and at least one implementation.) >=20 > Thanks for your consideration. >=20 >=20 > Cheers, > Jake >=20 >=20 >=20 > =EF=BB=BFOn 2019-03-04, 17:19, "Holland, Jake" = wrote: >=20 > Hi taps folks, >=20 > TL;DR: I think the spec should have a YANG model and I want to use = it > to get multicast support in an implementation. >=20 >=20 > I recently started digging into the taps API with the intent of = adding > multicast support, but it looks like it's basically already there, = as > far as it goes[*]. >=20 > But I ended up with a higher-level comment, so I thought I'd raise = it > to the wg and ask what you all think. >=20 > I found the whole "abstract interface" approach a little too > loosey-goosey, so I thought I'd try to suggest a way to tighten it = up. >=20 > My goal with this is to make it much more clear (to the point of = being > mechanically checkable) precisely what a compliant API provides. >=20 > I'm not attached to the structure I'm proposing or to any of the > particulars in the straw-man I've posted, but if it's not tightened = up > with something at a similar level of concreteness, I'm concerned = that > different implementations will be not only incompatible in random > underspecified corner cases (like BSD sockets today when you try to = make > cross-platform C code), but also are likely to end up with very = many > important differences that would make the whole taps effort more or = less > moot. >=20 > In a world where we end up with a doc at the level of abstraction = I'm > currently seeing in draft-taps-interface, it seems to me that if 2 > different API implementations were written in the same language, = it'll > be prohibitively difficult for an app to migrate from using one to = using > the other, just because so many aspects of it are left open to the > implementors. >=20 > In that context, I thought a YANG model would be useful here to > provide a cross-platform way to specify what exact properties and > objects exist, an exact format in which the values can be = specified, and > what exact semantics they have, while still allowing for a sane > extension path and language-specific implementation details. >=20 > I'm thinking some language a bit like the first bullet in Section = 4.2 of > taps-interface: >=20 > A compliant implementation SHOULD provide a language-appropriate = way to > configure a PreConnection using YANG instance data for this = model, and > SHOULD provide an API that outputs the YANG instance data for an > established Connection. >=20 > An implementation MAY also provide appropriate APIs for directly = editing > the objects without using YANG. It's RECOMMENDED where possible = to use > names that mechanically translate to the names in the YANG data = model, > using capitalization and punctuation conventions as expected for = the > language of the implementation. >=20 > And then of course a YANG model: > https://datatracker.ietf.org/doc/draft-jholland-taps-api-yang/ > (draft-jholland-taps-api-yang) >=20 > If this seems useful, it will need lots of refining. I'll be = surprised > if any part of it survives exactly as written. It's a quick and > dirty attempt to concretize a few of the things I saw listed in > draft-ietf-taps-interface, as a starting point to fill out if it = seems > useful. >=20 > But the model parses, and the example data instances in the draft > parse against the model (all with libyang). >=20 > One of the main reasons I'm doing this is because it seems to me = what's > specified in taps-interface-02 today is missing some key features, = like > an enumeration of the properties in the Local/RemoteEndpoint = examples in > section 5.1. And I don't see that listed as an open issue in = github, > which surprised me a bit. >=20 > I think oversights like this will become immediately and painfully > obvious when there's a reference implementation that includes a = YANG > parser and an explicit data model, as opposed to the combing of the > document and a sort of eyeballed comparison to NEAT that I tried > this week to reach that conclusion (which I found challenging even > though I thought both the document and the library were mostly = pretty > well written). >=20 > The whole thing at this point just smells to me much more abstract = than > it really has to be or than it's really useful to be, which bothers = me > because the idea of replacing BSD sockets with something usable = seems > like such a great idea. I'd like this to be something I can = actually > use in a way that makes my life easier someday soon. >=20 > But I think I'm at the point where I need a sanity check to see if = I'm > just missing something, or if this seems like a useful direction. >=20 > Thoughts? Suggestions? Worth discussing in Prague? (If so, can = I > get a slot?) >=20 > Cheers, > Jake >=20 > *: > I concluded that there's no reason multicast couldn't be supported > today, if there were an implementation that could reasonably claim = to be > compliant, by just adapting some of the examples in > draft-ietf-taps-interface-02 and understanding the semantic meaning = of > multicast address spaces inside the API. >=20 > For example, I couldn't find any reason this can't be expected to = set > up an SSM channel subscription without any further ado, given a = sane > implementation that supports it: >=20 > RemoteSpecifier :=3D NewRemoteEndpoint() > RemoteSpecifier.WithIPv4Address(192.0.2.21) >=20 > LocalSpecifier :=3D NewLocalEndpoint() > LocalSpecifier.WithPort(30000) > LocalSpecifier.WithIPv4Address(232.252.0.2) >=20 > NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(...) >=20 > Maybe there's some value in specifying a "JoinSSM()" to override = defaults > in the PreConnection, just to make sure you're specifically asking = for > multicast. I think that would be fine for native multicast, but = like I > said, a much smaller point than the looseness of the API. >=20 > Where it gets a bit more complicated is trying to handle multiple = options > for discovering a usable unicast tunnel for multicast traffic, as > described in Section 2.4.1 of = draft-ietf-mboned-driad-amt-discovery-01. >=20 > I'd like to have a decent place to tack on an extension to this API = that > can transparently, within the connection API, discover the best = available > AMT relay and start using it when native joining is unavailable = (and also > to provide normative controls for configuring it when there's > administrative configuration to be added). >=20 > But that's a 2nd order question for me at this point, because in = the > current TAPS API I don't see any obviously good spot to put = selection > controls for that kind of tunnel discovery selection, or really a = good > way to explain what it's supposed to do, if I tried to add controls = to > something that's there. >=20 > Solving that is my main motivation for being here. (Well, and that > the BSD socket API for multicast is kind of a disaster today.) >=20 > Anyway, if taps finds the whole YANG suggestion useful, I'll = probably > suggest some new extensions about this, and maybe a few other = points, > especially maybe around trying to put in a structure that can = support > some kind of sane explicit layering. >=20 > But I'm not sure I can articulate those suggestions in a way I'm = sure is > meaningful without first getting a more clear specification nailed = down > about what's actually in the taps spec. Because right now I'm = mostly > just confused about what an API implementation would really look = like, > and how you could tell whether it matches the taps-interface spec. >=20 >=20 >=20 > From: Aaron Falk > Date: 2019-03-04 at 10:53 > To: taps WG > Cc: Zaheduzzaman Sarker > Subject: [Taps] call for agenda items at TAPS IETF-104 >=20 > Hi All- > What should we use our time to discuss? Let=E2=80=99s focus on = things that would benefit from f2f discussion, consensus building, or = just argument. :) > =E2=80=A2 TAPS docs: are there open topics that need group = attention? Seems like we settled most of the remainder at the interim.=20= > =E2=80=A2 TAPS security: this seems nearly done. Anything to = discuss?=20 > =E2=80=A2 Implementations: a good topic for information sharing but = less important than anything needing agreement=20 > =E2=80=A2 Mobility: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&d=3DDwMFaQ&c=3D96ZbZZcaMF4w= 0F4jpN6LZg&r=3DbqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfV= e_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=3DHUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5w= d3D5_s&e=3D and = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dweste= rlund-2D2019-2D01-2D08_&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbqnFROiv= Do_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju= 2BgM2rpQo&s=3D0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=3D=20 > --aaron >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Mar 7 06:58:25 2019 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 75283127971 for ; Thu, 7 Mar 2019 06:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYoWV6xZKevY for ; Thu, 7 Mar 2019 06:58:19 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 17CD5127967 for ; Thu, 7 Mar 2019 06:58:19 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x27EuWLu031017; Thu, 7 Mar 2019 06:58:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=vCMDx0UPSVIBoq+gc1S/vgWMEeEfX5mrNatF+uwmexc=; b=h74VMUfqyBIC2GV5W0Mj5766OaNsXvXJlXPyBb6mW9xHXFtDuqzwHWaUT0TrZk+adhnd 3n97zsvJNOy8VnPuDH3F/hGO1iBjz6KKh0u483iBHzrg7Q4JY22Nz6rfy4IP4LwyS/el uBAwZ1mJuLC5oXmcF15znqhSnI3YisDpd/DNXIFr7CSHDAZRaEaJBDCs2uvUwcuYF1WR Ofkvft4w2yRZ9wnQSk5pUn/aokvayoRSVFbscL9XC+si1mr26SnQbIzUIPv08rN/VtpR ACVHtyv/IAH/5GltRkwa2f4FVqXlhu/3Wik+41Qfc0spXbbJ17ttcBuc3+IjiEMmkNdp 6Q== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2qyq9usmgm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 07 Mar 2019 06:58:17 -0800 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO000FYE494UC40@ma1-mtap-s03.corp.apple.com>; Thu, 07 Mar 2019 06:58:16 -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.3.20181024 64bit (built Oct 24 2018)) id <0PO000K0048UB900@nwk-mmpp-sz09.apple.com>; Thu, 07 Mar 2019 06:58:16 -0800 (PST) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: b7992a9d747c7fc2a60ee66a4ee9c0cd X-Va-R-CD: 751ae8d9674db45f87333cb50b20978c X-Va-CD: 0 X-Va-ID: ba6bdf74-1145-4880-b97f-619f365e0b6a X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: b7992a9d747c7fc2a60ee66a4ee9c0cd X-V-R-CD: 751ae8d9674db45f87333cb50b20978c X-V-CD: 0 X-V-ID: 198ca118-fe3c-4b71-a6e3-e85c6a019aeb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-07_08:,, signatures=0 Received: from [17.234.71.181] (unknown [17.234.71.181]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO000DGO4931280@nwk-mmpp-sz09.apple.com>; Thu, 07 Mar 2019 06:58:15 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> Date: Thu, 07 Mar 2019 06:58:14 -0800 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_08:, , signatures=0 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 14:58:23 -0000 Hi Jake, Sorry I hadn't replied! Apparently my Mail decided to sort your emails = into junk, so I only just saw Michael's response now to alert me to this = thread. Regarding the YANG format, I think that's a really interesting idea and = I would definitely like to see a presentation in Prague regarding your = proposal. I'm certainly not well-versed in YANG myself, but I think that = the rigor of making the API document concrete would be highly useful = both for proving the completeness of the model and for providing a = reference for implementations to check against. It can serve the purpose = of creating an implementation of the API, but can be represented as an = IETF document. Regarding multicast, I do think that is a separate topic and one we need = to address in general some time this year. That's one of the = acknowledged gaps in my own implementation right now, and one that I = hope to start fleshing out as well. I think that would be better served = as a separate topic, although I imagine talking about that will spill = over into future meetings as well. Best, Tommy > On Mar 6, 2019, at 7:55 PM, Holland, Jake wrote: >=20 > Hi taps, >=20 > (Trying again, but simpler.) >=20 > I'm looking for a consensus yes or no answer: >=20 > Is a normative config input format an interesting and useful > direction? >=20 >=20 > The idea is to add functionality like this, in taps-interface: >=20 > newPre =3D PreConnection.NewFromJson('''{ > "remote-endpoint":{ > "hosts":[ > { "host":"example.com" } > ] > } > }''') >=20 > With a fully specified json input format that can provide all the > configurable values. >=20 >=20 > If no, I'll move on and assume I just don't understand taps goals. >=20 > If yes, I'd like 15 minutes to discuss in Prague, and keep reading: >=20 > I think a full definition of an input json format can be exactly > specified by a YANG model. (With xml for free, if you want it.) >=20 > I tried to sketch a start at what a YANG model for this might look = like: > https://tools.ietf.org/html/draft-jholland-taps-api-yang-00#section-3 >=20 > I'm not a YANG expert yet, and it's not much of a model. And it's = very > far from complete. But it compiles, and all the examples in the draft > validate against that model with libyang. If it's worthwhile, I think > something like this can be good (and extensible!), if done right. >=20 > I believe something along these lines would sharpen up taps-interface > a lot. (After filling in all the taps-interface properties.) >=20 >=20 > The reason I'm asking is because right now, taps-interface to me > seems _almost_ really good, except too confusing and vague to actually > build an API that can replace BSD sockets. I think with a solid = config > format with normative and testable examples, that could be fixed. >=20 > If consensus says "interesting", I'll want 15 minutes to discuss it, = and > to start digging into how to make it good. (And also to add multicast > support to the model and at least one implementation.) >=20 > Thanks for your consideration. >=20 >=20 > Cheers, > Jake >=20 >=20 >=20 > =EF=BB=BFOn 2019-03-04, 17:19, "Holland, Jake" = wrote: >=20 > Hi taps folks, >=20 > TL;DR: I think the spec should have a YANG model and I want to use = it > to get multicast support in an implementation. >=20 >=20 > I recently started digging into the taps API with the intent of = adding > multicast support, but it looks like it's basically already there, = as > far as it goes[*]. >=20 > But I ended up with a higher-level comment, so I thought I'd raise = it > to the wg and ask what you all think. >=20 > I found the whole "abstract interface" approach a little too > loosey-goosey, so I thought I'd try to suggest a way to tighten it = up. >=20 > My goal with this is to make it much more clear (to the point of = being > mechanically checkable) precisely what a compliant API provides. >=20 > I'm not attached to the structure I'm proposing or to any of the > particulars in the straw-man I've posted, but if it's not tightened = up > with something at a similar level of concreteness, I'm concerned = that > different implementations will be not only incompatible in random > underspecified corner cases (like BSD sockets today when you try to = make > cross-platform C code), but also are likely to end up with very = many > important differences that would make the whole taps effort more or = less > moot. >=20 > In a world where we end up with a doc at the level of abstraction = I'm > currently seeing in draft-taps-interface, it seems to me that if 2 > different API implementations were written in the same language, = it'll > be prohibitively difficult for an app to migrate from using one to = using > the other, just because so many aspects of it are left open to the > implementors. >=20 > In that context, I thought a YANG model would be useful here to > provide a cross-platform way to specify what exact properties and > objects exist, an exact format in which the values can be = specified, and > what exact semantics they have, while still allowing for a sane > extension path and language-specific implementation details. >=20 > I'm thinking some language a bit like the first bullet in Section = 4.2 of > taps-interface: >=20 > A compliant implementation SHOULD provide a language-appropriate = way to > configure a PreConnection using YANG instance data for this = model, and > SHOULD provide an API that outputs the YANG instance data for an > established Connection. >=20 > An implementation MAY also provide appropriate APIs for directly = editing > the objects without using YANG. It's RECOMMENDED where possible = to use > names that mechanically translate to the names in the YANG data = model, > using capitalization and punctuation conventions as expected for = the > language of the implementation. >=20 > And then of course a YANG model: > https://datatracker.ietf.org/doc/draft-jholland-taps-api-yang/ > (draft-jholland-taps-api-yang) >=20 > If this seems useful, it will need lots of refining. I'll be = surprised > if any part of it survives exactly as written. It's a quick and > dirty attempt to concretize a few of the things I saw listed in > draft-ietf-taps-interface, as a starting point to fill out if it = seems > useful. >=20 > But the model parses, and the example data instances in the draft > parse against the model (all with libyang). >=20 > One of the main reasons I'm doing this is because it seems to me = what's > specified in taps-interface-02 today is missing some key features, = like > an enumeration of the properties in the Local/RemoteEndpoint = examples in > section 5.1. And I don't see that listed as an open issue in = github, > which surprised me a bit. >=20 > I think oversights like this will become immediately and painfully > obvious when there's a reference implementation that includes a = YANG > parser and an explicit data model, as opposed to the combing of the > document and a sort of eyeballed comparison to NEAT that I tried > this week to reach that conclusion (which I found challenging even > though I thought both the document and the library were mostly = pretty > well written). >=20 > The whole thing at this point just smells to me much more abstract = than > it really has to be or than it's really useful to be, which bothers = me > because the idea of replacing BSD sockets with something usable = seems > like such a great idea. I'd like this to be something I can = actually > use in a way that makes my life easier someday soon. >=20 > But I think I'm at the point where I need a sanity check to see if = I'm > just missing something, or if this seems like a useful direction. >=20 > Thoughts? Suggestions? Worth discussing in Prague? (If so, can = I > get a slot?) >=20 > Cheers, > Jake >=20 > *: > I concluded that there's no reason multicast couldn't be supported > today, if there were an implementation that could reasonably claim = to be > compliant, by just adapting some of the examples in > draft-ietf-taps-interface-02 and understanding the semantic meaning = of > multicast address spaces inside the API. >=20 > For example, I couldn't find any reason this can't be expected to = set > up an SSM channel subscription without any further ado, given a = sane > implementation that supports it: >=20 > RemoteSpecifier :=3D NewRemoteEndpoint() > RemoteSpecifier.WithIPv4Address(192.0.2.21) >=20 > LocalSpecifier :=3D NewLocalEndpoint() > LocalSpecifier.WithPort(30000) > LocalSpecifier.WithIPv4Address(232.252.0.2) >=20 > NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(...) >=20 > Maybe there's some value in specifying a "JoinSSM()" to override = defaults > in the PreConnection, just to make sure you're specifically asking = for > multicast. I think that would be fine for native multicast, but = like I > said, a much smaller point than the looseness of the API. >=20 > Where it gets a bit more complicated is trying to handle multiple = options > for discovering a usable unicast tunnel for multicast traffic, as > described in Section 2.4.1 of = draft-ietf-mboned-driad-amt-discovery-01. >=20 > I'd like to have a decent place to tack on an extension to this API = that > can transparently, within the connection API, discover the best = available > AMT relay and start using it when native joining is unavailable = (and also > to provide normative controls for configuring it when there's > administrative configuration to be added). >=20 > But that's a 2nd order question for me at this point, because in = the > current TAPS API I don't see any obviously good spot to put = selection > controls for that kind of tunnel discovery selection, or really a = good > way to explain what it's supposed to do, if I tried to add controls = to > something that's there. >=20 > Solving that is my main motivation for being here. (Well, and that > the BSD socket API for multicast is kind of a disaster today.) >=20 > Anyway, if taps finds the whole YANG suggestion useful, I'll = probably > suggest some new extensions about this, and maybe a few other = points, > especially maybe around trying to put in a structure that can = support > some kind of sane explicit layering. >=20 > But I'm not sure I can articulate those suggestions in a way I'm = sure is > meaningful without first getting a more clear specification nailed = down > about what's actually in the taps spec. Because right now I'm = mostly > just confused about what an API implementation would really look = like, > and how you could tell whether it matches the taps-interface spec. >=20 >=20 >=20 > From: Aaron Falk > Date: 2019-03-04 at 10:53 > To: taps WG > Cc: Zaheduzzaman Sarker > Subject: [Taps] call for agenda items at TAPS IETF-104 >=20 > Hi All- > What should we use our time to discuss? Let=E2=80=99s focus on = things that would benefit from f2f discussion, consensus building, or = just argument. :) > =E2=80=A2 TAPS docs: are there open topics that need group = attention? Seems like we settled most of the remainder at the interim.=20= > =E2=80=A2 TAPS security: this seems nearly done. Anything to = discuss?=20 > =E2=80=A2 Implementations: a good topic for information sharing but = less important than anything needing agreement=20 > =E2=80=A2 Mobility: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&d=3DDwMFaQ&c=3D96ZbZZcaMF4w= 0F4jpN6LZg&r=3DbqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfV= e_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=3DHUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5w= d3D5_s&e=3D and = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dweste= rlund-2D2019-2D01-2D08_&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbqnFROiv= Do_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju= 2BgM2rpQo&s=3D0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=3D=20 > --aaron >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Mar 7 07:09:41 2019 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 71DF81277D0 for ; Thu, 7 Mar 2019 07:09:39 -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_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 ErMgh0A-M5kD for ; Thu, 7 Mar 2019 07:09:35 -0800 (PST) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 6459412788F for ; Thu, 7 Mar 2019 07:09:34 -0800 (PST) Received: by mail-qk1-x741.google.com with SMTP id s26so1086430qkm.10 for ; Thu, 07 Mar 2019 07:09:34 -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; bh=JivwIdD6bRTTK3/m9p4l6YTVSfS366449e+8BWDGNZY=; b=K7o4TYIyMA+VxtUn/m4AJGFan+Sdmd5J9Ke+cAKXYJSRG87yFOWi68cjZb8jdFuhQB FezyxNG6XdGuarKG8qIutMLKCBoVEhbvmlbfLwADsgEwafcas3GZceHk6vdCZkrAqOhW w6lx2bROnzfkHLVtx0foPxe2E2YzftY3IdjeTPgMZgd6+QvjOdRwZzTYLy2PXcGXQbCj BoiInP2OHLYZdz5O+4i6/Jl7y20s0Oxn1+OpGJINzdeOZHE23VRsQP3CZK0/cFNjSG3k 0HngoNTiW1ssgeUjAesngiIyeygb6uC89e5QtRbN1ca1WQ3dWwKAUeHdXAUuRUNktA/r bhNg== 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; bh=JivwIdD6bRTTK3/m9p4l6YTVSfS366449e+8BWDGNZY=; b=lQDoHNTwT/R1hGXBC5dI39X9dYYuMfigzYSjDSW1NMIMiB/PhhIeqjiLzRNGTKckBj AsQJc8qf0I92PiOw7k812dueCfyEqvgxXFOERQ5rxtGZELmOB6ThNrEnYEbUpG8U9pLX yOlxFRX5ctJ0Pp7dNWy1Q5ltIC0jIztBWXbezSObDlb5wc6SMMqOxG+X710KKmNCrn8o kFUEcRTKFAYkBDDCw5eLE9GfgDjxZAzG2pTKvMJ54AfjGQIbYLJ+Co5CAPU+Hl5k80wQ Cs2KAqcKNZotojykz06OkP8TqJ1PcMfeBKNnZFElc7wwN3Tgoe8KEANuFBisHFup5ceI Ifow== X-Gm-Message-State: APjAAAXt0nYO34tWAKtcMVvsslt/K+t4sBi5Xx435njtL9Qjn99vsk5R KV54GLvzVVNY20gvI20whuQ= X-Google-Smtp-Source: APXvYqw1jx5pA4P4YX2xQGbnbxPygcmDfU1958YNXChZcX3IEBAcN+szaJNeYQaKSH27wQPmhnErNA== X-Received: by 2002:a37:6894:: with SMTP id d142mr9811799qkc.332.1551971373021; Thu, 07 Mar 2019 07:09:33 -0800 (PST) Received: from [172.19.37.49] ([2001:4878:a000:3000:c5da:7c32:c103:c31b]) by smtp.gmail.com with ESMTPSA id k37sm3049782qtc.91.2019.03.07.07.09.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 07:09:29 -0800 (PST) From: "Aaron Falk" To: "Michael Welzl" Cc: "Holland, Jake" , "taps WG" Date: Thu, 07 Mar 2019 10:09:28 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: <2A8C7863-4B7B-4AB6-8409-3D0C5A68B536@gmail.com> In-Reply-To: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4CB8EDFB-30DA-43F4-A317-7A167718CDF5_=" Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 15:09:40 -0000 --=_MailMate_4CB8EDFB-30DA-43F4-A317-7A167718CDF5_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Seems to me that Michael=E2=80=99s 3) below is a comment on the interface= = specification so I think it could be discussed during the agenda time on = that doc. Seems like there is agreement that the questions of whether the wg wants = to produce a YANG model and how to support multicast are separable and = worth putting on the agenda for Prague. Any disagreement? --aaron On 7 Mar 2019, at 3:32, Michael Welzl wrote: > Hi, > > Very sorry for the silence. I can only speak for myself, but here's an = > example of why this one person was silent: > - When you created your issue on multicast in github, I thought of = > answering (positively), but then thought that the repo is about to = > move, and it would probably be better to delay things until the move = > is finished. > - Then, the issue was overruled by your email. I read it and found it = > interesting, but hoped for someone else to answer because, frankly, I = > was afraid to make a fool of myself ... because I know almost nothing = > about YANG. > > But now I'll be brave :) I'll go ahead and ask: how exactly is this = > YANG proposal more than just a syntax change? What would it give us? > (I understand that YANG can be automatically parsed / checked by some = > tools, but... what does THAT give us?) > > Also, I actually see 3 separable things being proposed here: > > 1) the YANG model > > 2) multicast support (I find your conclusion that not much needs to = > change interesting! Though the example you're giving (joining an SSM = > channel) is only a part of what we'd need, as you also say...) > > 3) applying preferences to addresses and port numbers (which you seem = > to take for granted in your draft, but which I don't think is = > supported by our current document). > Side note: unless I'm mistaken, this wouldn't fit our structure well: = > e.g. a port number would then be a Transport Property that has a = > certain value, but also has a preference, but currently we say that a = > Transport Property has "one of a set of data types", one of which is a = > Preference. Isn't that structure too limiting? Or am I missing = > something? > > I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) as = > separate... maybe there are other use cases for 3) alone ? > IMO, all of these things are interesting, and would be good to discuss = > on site. However, I doubt that we can deal with them all in only 15 = > minutes :-) > > Cheers, > Michael > > PS: Travis is down, or something. At least the "Editor's Copy" links = > don't currently work. > > > >> On 7 Mar 2019, at 04:55, Holland, Jake wrote: >> >> Hi taps, >> >> (Trying again, but simpler.) >> >> I'm looking for a consensus yes or no answer: >> >> Is a normative config input format an interesting and useful >> direction? >> >> >> The idea is to add functionality like this, in taps-interface: >> >> newPre =3D PreConnection.NewFromJson('''{ >> "remote-endpoint":{ >> "hosts":[ >> { "host":"example.com" } >> ] >> } >> }''') >> >> With a fully specified json input format that can provide all the >> configurable values. >> >> >> If no, I'll move on and assume I just don't understand taps goals. >> >> If yes, I'd like 15 minutes to discuss in Prague, and keep reading: >> >> I think a full definition of an input json format can be exactly >> specified by a YANG model. (With xml for free, if you want it.) >> >> I tried to sketch a start at what a YANG model for this might look = >> like: >> https://tools.ietf.org/html/draft-jholland-taps-api-yang-00#section-3 >> >> I'm not a YANG expert yet, and it's not much of a model. And it's = >> very >> far from complete. But it compiles, and all the examples in the = >> draft >> validate against that model with libyang. If it's worthwhile, I = >> think >> something like this can be good (and extensible!), if done right. >> >> I believe something along these lines would sharpen up taps-interface >> a lot. (After filling in all the taps-interface properties.) >> >> >> The reason I'm asking is because right now, taps-interface to me >> seems _almost_ really good, except too confusing and vague to = >> actually >> build an API that can replace BSD sockets. I think with a solid = >> config >> format with normative and testable examples, that could be fixed. >> >> If consensus says "interesting", I'll want 15 minutes to discuss it, = >> and >> to start digging into how to make it good. (And also to add = >> multicast >> support to the model and at least one implementation.) >> >> Thanks for your consideration. >> >> >> Cheers, >> Jake >> >> >> >> =EF=BB=BFOn 2019-03-04, 17:19, "Holland, Jake" w= rote: >> >> Hi taps folks, >> >> TL;DR: I think the spec should have a YANG model and I want to use = >> it >> to get multicast support in an implementation. >> >> >> I recently started digging into the taps API with the intent of = >> adding >> multicast support, but it looks like it's basically already there, = >> as >> far as it goes[*]. >> >> But I ended up with a higher-level comment, so I thought I'd raise = >> it >> to the wg and ask what you all think. >> >> I found the whole "abstract interface" approach a little too >> loosey-goosey, so I thought I'd try to suggest a way to tighten it = >> up. >> >> My goal with this is to make it much more clear (to the point of = >> being >> mechanically checkable) precisely what a compliant API provides. >> >> I'm not attached to the structure I'm proposing or to any of the >> particulars in the straw-man I've posted, but if it's not = >> tightened up >> with something at a similar level of concreteness, I'm concerned = >> that >> different implementations will be not only incompatible in random >> underspecified corner cases (like BSD sockets today when you try = >> to make >> cross-platform C code), but also are likely to end up with very = >> many >> important differences that would make the whole taps effort more = >> or less >> moot. >> >> In a world where we end up with a doc at the level of abstraction = >> I'm >> currently seeing in draft-taps-interface, it seems to me that if 2 >> different API implementations were written in the same language, = >> it'll >> be prohibitively difficult for an app to migrate from using one to = >> using >> the other, just because so many aspects of it are left open to the >> implementors. >> >> In that context, I thought a YANG model would be useful here to >> provide a cross-platform way to specify what exact properties and >> objects exist, an exact format in which the values can be = >> specified, and >> what exact semantics they have, while still allowing for a sane >> extension path and language-specific implementation details. >> >> I'm thinking some language a bit like the first bullet in Section = >> 4.2 of >> taps-interface: >> >> A compliant implementation SHOULD provide a language-appropriate = >> way to >> configure a PreConnection using YANG instance data for this = >> model, and >> SHOULD provide an API that outputs the YANG instance data for an >> established Connection. >> >> An implementation MAY also provide appropriate APIs for directly = >> editing >> the objects without using YANG. It's RECOMMENDED where possible = >> to use >> names that mechanically translate to the names in the YANG data = >> model, >> using capitalization and punctuation conventions as expected for = >> the >> language of the implementation. >> >> And then of course a YANG model: >> https://datatracker.ietf.org/doc/draft-jholland-taps-api-yang/ >> (draft-jholland-taps-api-yang) >> >> If this seems useful, it will need lots of refining. I'll be = >> surprised >> if any part of it survives exactly as written. It's a quick and >> dirty attempt to concretize a few of the things I saw listed in >> draft-ietf-taps-interface, as a starting point to fill out if it = >> seems >> useful. >> >> But the model parses, and the example data instances in the draft >> parse against the model (all with libyang). >> >> One of the main reasons I'm doing this is because it seems to me = >> what's >> specified in taps-interface-02 today is missing some key features, = >> like >> an enumeration of the properties in the Local/RemoteEndpoint = >> examples in >> section 5.1. And I don't see that listed as an open issue in = >> github, >> which surprised me a bit. >> >> I think oversights like this will become immediately and painfully >> obvious when there's a reference implementation that includes a = >> YANG >> parser and an explicit data model, as opposed to the combing of = >> the >> document and a sort of eyeballed comparison to NEAT that I tried >> this week to reach that conclusion (which I found challenging even >> though I thought both the document and the library were mostly = >> pretty >> well written). >> >> The whole thing at this point just smells to me much more abstract = >> than >> it really has to be or than it's really useful to be, which = >> bothers me >> because the idea of replacing BSD sockets with something usable = >> seems >> like such a great idea. I'd like this to be something I can = >> actually >> use in a way that makes my life easier someday soon. >> >> But I think I'm at the point where I need a sanity check to see if = >> I'm >> just missing something, or if this seems like a useful direction. >> >> Thoughts? Suggestions? Worth discussing in Prague? (If so, can = >> I >> get a slot?) >> >> Cheers, >> Jake >> >> *: >> I concluded that there's no reason multicast couldn't be supported >> today, if there were an implementation that could reasonably claim = >> to be >> compliant, by just adapting some of the examples in >> draft-ietf-taps-interface-02 and understanding the semantic = >> meaning of >> multicast address spaces inside the API. >> >> For example, I couldn't find any reason this can't be expected to = >> set >> up an SSM channel subscription without any further ado, given a = >> sane >> implementation that supports it: >> >> RemoteSpecifier :=3D NewRemoteEndpoint() >> RemoteSpecifier.WithIPv4Address(192.0.2.21) >> >> LocalSpecifier :=3D NewLocalEndpoint() >> LocalSpecifier.WithPort(30000) >> LocalSpecifier.WithIPv4Address(232.252.0.2) >> >> NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(...) >> >> Maybe there's some value in specifying a "JoinSSM()" to override = >> defaults >> in the PreConnection, just to make sure you're specifically asking = >> for >> multicast. I think that would be fine for native multicast, but = >> like I >> said, a much smaller point than the looseness of the API. >> >> Where it gets a bit more complicated is trying to handle multiple = >> options >> for discovering a usable unicast tunnel for multicast traffic, as >> described in Section 2.4.1 of = >> draft-ietf-mboned-driad-amt-discovery-01. >> >> I'd like to have a decent place to tack on an extension to this = >> API that >> can transparently, within the connection API, discover the best = >> available >> AMT relay and start using it when native joining is unavailable = >> (and also >> to provide normative controls for configuring it when there's >> administrative configuration to be added). >> >> But that's a 2nd order question for me at this point, because in = >> the >> current TAPS API I don't see any obviously good spot to put = >> selection >> controls for that kind of tunnel discovery selection, or really a = >> good >> way to explain what it's supposed to do, if I tried to add = >> controls to >> something that's there. >> >> Solving that is my main motivation for being here. (Well, and = >> that >> the BSD socket API for multicast is kind of a disaster today.) >> >> Anyway, if taps finds the whole YANG suggestion useful, I'll = >> probably >> suggest some new extensions about this, and maybe a few other = >> points, >> especially maybe around trying to put in a structure that can = >> support >> some kind of sane explicit layering. >> >> But I'm not sure I can articulate those suggestions in a way I'm = >> sure is >> meaningful without first getting a more clear specification nailed = >> down >> about what's actually in the taps spec. Because right now I'm = >> mostly >> just confused about what an API implementation would really look = >> like, >> and how you could tell whether it matches the taps-interface spec. >> >> >> >> From: Aaron Falk >> Date: 2019-03-04 at 10:53 >> To: taps WG >> Cc: Zaheduzzaman Sarker >> Subject: [Taps] call for agenda items at TAPS IETF-104 >> >> Hi All- >> What should we use our time to discuss? Let=E2=80=99s focus on thin= gs = >> that would benefit from f2f discussion, consensus building, or just = >> argument. :) >> =E2=80=A2 TAPS docs: are there open topics that need group attentio= n? = >> Seems like we settled most of the remainder at the interim. >> =E2=80=A2 TAPS security: this seems nearly done. Anything to discus= s? >> =E2=80=A2 Implementations: a good topic for information sharing but= less = >> important than anything needing agreement >> =E2=80=A2 Mobility: = >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_= html_draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&d=3DDwMFaQ&c=3D96ZbZZc= aMF4w0F4jpN6LZg&r=3DbqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5g= SyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=3DHUsBVBF_GhNiOk3gqY_m5qZMD-sPmB= J93GE5wd3D5_s&e=3D = >> and = >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= f.org_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2D= westerlund-2D2019-2D01-2D08_&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3Dbq= nFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_Vcj= IqzN7Ju2BgM2rpQo&s=3D0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=3D >> --aaron >> >> >> >> _______________________________________________ >> 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 --=_MailMate_4CB8EDFB-30DA-43F4-A317-7A167718CDF5_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Seems to me that Michael=E2=80=99s 3) below is a comment o= n the interface specification so I think it could be discussed during the= agenda time on that doc.

Seems like there is agreement that the questions of wheth= er the wg wants to produce a YANG model and how to support multicast are = separable and worth putting on the agenda for Prague.

Any disagreement?

--aaron

On 7 Mar 2019, at 3:32, Michael Welzl wrote:

Hi,

Very sorry for the silence. I can only speak for myself, but here's an ex= ample of why this one person was silent:
- When you created your issue on multicast in github, I thought of answer= ing (positively), but then thought that the repo is about to move, and it= would probably be better to delay things until the move is finished.
= - Then, the issue was overruled by your email. I read it and found it int= eresting, but hoped for someone else to answer because, frankly, I was af= raid to make a fool of myself ... because I know almost nothing about YAN= G.

But now I'll be brave :) I'll go ahead and ask: how exactly is this YA= NG proposal more than just a syntax change? What would it give us?
(I understand that YANG can be automatically parsed / checked by some too= ls, but... what does THAT give us?)

Also, I actually see 3 separable things being proposed here:

1) the YANG model

2) multicast support (I find your conclusion that not much needs to chan= ge interesting! Though the example you're giving (joining an SSM channel= ) is only a part of what we'd need, as you also say...)

3) applying preferences to addresses and port numbers (which you seem to= take for granted in your draft, but which I don't think is supported by = our current document).
Side note: unless I'm mistaken, this wouldn't fit our structure well: e.g= =2E a port number would then be a Transport Property that has a certain v= alue, but also has a preference, but currently we say that a Transport Pr= operty has "one of a set of data types", one of which is a Preference. Is= n't that structure too limiting? Or am I missing something?

I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) as sep= arate... maybe there are other use cases for 3) alone ?
IMO, all of these things are interesting, and would be good to discuss on= site. However, I doubt that we can deal with them all in only 15 minutes= :-)

Cheers,
Michael

PS: Travis is down, or something. At least the "Editor's Copy" links don'= t currently work.


On 7 Mar 20= 19, at 04:55, Holland, Jake <jholland@akamai.com> wrote:

Hi taps,

(Trying again, but simpler.)

I'm looking for a consensus yes or no answer:

Is a normative config input format an interesting and useful
direction?


The idea is to add functionality like this, in taps-interface:

newPre =3D PreConnection.NewFromJson('''{
"remote-endpoint":{
"hosts":[
{ "host":"example.com" }
]
}
}''')

With a fully specified json input format that can provide all the
configurable values.


If no, I'll move on and assume I just don't understand taps goals.

If yes, I'd like 15 minutes to discuss in Prague, and keep reading:

I think a full definition of an input json format can be exactly
specified by a YANG model. (With xml for free, if you want it.)

I tried to sketch a start at what a YANG model for this might look like:<= br> https://tools.ietf.org/html/draft-jholland-= taps-api-yang-00#section-3

I'm not a YANG expert yet, and it's not much of a model. And it's very far from complete. But it compiles, and all the examples in the draft validate against that model with libyang. If it's worthwhile, I think something like this can be good (and extensible!), if done right.

I believe something along these lines would sharpen up taps-interface
= a lot. (After filling in all the taps-interface properties.)


The reason I'm asking is because right now, taps-interface to me
seems _almost_ really good, except too confusing and vague to actually build an API that can replace BSD sockets. I think with a solid config format with normative and testable examples, that could be fixed.

If consensus says "interesting", I'll want 15 minutes to discuss it, and<= br> to start digging into how to make it good. (And also to add multicast support to the model and at least one implementation.)

Thanks for your consideration.


Cheers,
Jake



=EF=BB=BFOn 2019-03-04, 17:19, "Holland, Jake" <jholland@akamai.com>= ; wrote:

Hi taps folks,

TL;DR: I think the spec should have a YANG model and I want to use it<= br> to get multicast support in an implementation.


I recently started digging into the taps API with the intent of adding=
multicast support, but it looks like it's basically already there, as<= br> far as it goes[*].

But I ended up with a higher-level comment, so I thought I'd raise it<= br> to the wg and ask what you all think.

I found the whole "abstract interface" approach a little too
loosey-goosey, so I thought I'd try to suggest a way to tighten it up.=

My goal with this is to make it much more clear (to the point of being=
mechanically checkable) precisely what a compliant API provides.

I'm not attached to the structure I'm proposing or to any of the
particulars in the straw-man I've posted, but if it's not tightened up=
with something at a similar level of concreteness, I'm concerned that<= br> different implementations will be not only incompatible in random
underspecified corner cases (like BSD sockets today when you try to ma= ke
cross-platform C code), but also are likely to end up with very many important differences that would make the whole taps effort more or le= ss
moot.

In a world where we end up with a doc at the level of abstraction I'm<= br> currently seeing in draft-taps-interface, it seems to me that if 2
= different API implementations were written in the same language, it'll=
be prohibitively difficult for an app to migrate from using one to usi= ng
the other, just because so many aspects of it are left open to the
= implementors.

In that context, I thought a YANG model would be useful here to
provide a cross-platform way to specify what exact properties and
objects exist, an exact format in which the values can be specified, a= nd
what exact semantics they have, while still allowing for a sane
extension path and language-specific implementation details.

I'm thinking some language a bit like the first bullet in Section 4.2 = of
taps-interface:

A compliant implementation SHOULD provide a language-appropriate way= to
configure a PreConnection using YANG instance data for this model, a= nd
SHOULD provide an API that outputs the YANG instance data for an
= established Connection.

An implementation MAY also provide appropriate APIs for directly edi= ting
the objects without using YANG. It's RECOMMENDED where possible to = use
names that mechanically translate to the names in the YANG data mode= l,
using capitalization and punctuation conventions as expected for the=
language of the implementation.

And then of course a YANG model:
https://datatracker.ietf.org/doc/draft-jholland= -taps-api-yang/
(draft-jholland-taps-api-yang)

If this seems useful, it will need lots of refining. I'll be surprise= d
if any part of it survives exactly as written. It's a quick and
dirty attempt to concretize a few of the things I saw listed in
draft-ietf-taps-interface, as a starting point to fill out if it seems=
useful.

But the model parses, and the example data instances in the draft
parse against the model (all with libyang).

One of the main reasons I'm doing this is because it seems to me what'= s
specified in taps-interface-02 today is missing some key features, lik= e
an enumeration of the properties in the Local/RemoteEndpoint examples = in
section 5.1. And I don't see that listed as an open issue in github,<= br> which surprised me a bit.

I think oversights like this will become immediately and painfully
= obvious when there's a reference implementation that includes a YANG parser and an explicit data model, as opposed to the combing of the document and a sort of eyeballed comparison to NEAT that I tried
this week to reach that conclusion (which I found challenging even
= though I thought both the document and the library were mostly pretty<= br> well written).

The whole thing at this point just smells to me much more abstract tha= n
it really has to be or than it's really useful to be, which bothers me=
because the idea of replacing BSD sockets with something usable seems<= br> like such a great idea. I'd like this to be something I can actually<= br> use in a way that makes my life easier someday soon.

But I think I'm at the point where I need a sanity check to see if I'm=
just missing something, or if this seems like a useful direction.

Thoughts? Suggestions? Worth discussing in Prague? (If so, can I get a slot?)

Cheers,
Jake

*:
I concluded that there's no reason multicast couldn't be supported
= today, if there were an implementation that could reasonably claim to = be
compliant, by just adapting some of the examples in
draft-ietf-taps-interface-02 and understanding the semantic meaning of=
multicast address spaces inside the API.

For example, I couldn't find any reason this can't be expected to set<= br> up an SSM channel subscription without any further ado, given a sane implementation that supports it:

RemoteSpecifier :=3D NewRemoteEndpoint()
RemoteSpecifier.WithIPv4Address(192.0.2.21)

LocalSpecifier :=3D NewLocalEndpoint()
LocalSpecifier.WithPort(30000)
LocalSpecifier.WithIPv4Address(232.252.0.2)

NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(...)

Maybe there's some value in specifying a "JoinSSM()" to override defau= lts
in the PreConnection, just to make sure you're specifically asking for=
multicast. I think that would be fine for native multicast, but like = I
said, a much smaller point than the looseness of the API.

Where it gets a bit more complicated is trying to handle multiple opti= ons
for discovering a usable unicast tunnel for multicast traffic, as
described in Section 2.4.1 of draft-ietf-mboned-driad-amt-discovery-01= =2E

I'd like to have a decent place to tack on an extension to this API th= at
can transparently, within the connection API, discover the best availa= ble
AMT relay and start using it when native joining is unavailable (and a= lso
to provide normative controls for configuring it when there's
administrative configuration to be added).

But that's a 2nd order question for me at this point, because in the current TAPS API I don't see any obviously good spot to put selection<= br> controls for that kind of tunnel discovery selection, or really a good=
way to explain what it's supposed to do, if I tried to add controls to=
something that's there.

Solving that is my main motivation for being here. (Well, and that the BSD socket API for multicast is kind of a disaster today.)

Anyway, if taps finds the whole YANG suggestion useful, I'll probably<= br> suggest some new extensions about this, and maybe a few other points,<= br> especially maybe around trying to put in a structure that can support<= br> some kind of sane explicit layering.

But I'm not sure I can articulate those suggestions in a way I'm sure = is
meaningful without first getting a more clear specification nailed dow= n
about what's actually in the taps spec. Because right now I'm mostly just confused about what an API implementation would really look like,=
and how you could tell whether it matches the taps-interface spec.
=


From: Aaron Falk <aaron.falk@gmail.com>
Date: 2019-03-04 at 10:53
To: taps WG <taps@ietf.org>
Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Subject: [Taps] call for agenda items at TAPS IETF-104

Hi All-
What should we use our time to discuss? Let=E2=80=99s focus on things = that would benefit from f2f discussion, consensus building, or just argum= ent. :)
=E2=80=A2 TAPS docs: are there open topics that need group attention? = Seems like we settled most of the remainder at the interim.
=E2=80=A2 TAPS security: this seems nearly done. Anything to discuss?<= br> =E2=80=A2 Implementations: a good topic for information sharing but le= ss important than anything needing agreement
=E2=80=A2 Mobility: https://urldefense.proofpoint.com/v2/url?u=3Dhttps= -3A__tools.ietf.org_html_draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&am= p;d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbqnFROivDo_4iF8Z3R4Dy= NWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQ= o&s=3DHUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5wd3D5_s&e=3D and https://urldefense.proof= point.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_review-2Dietf-2Dd= mm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dwesterlund-2D2019-2D01-2D08= _&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbqnFROivDo_4iF8Z3= R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM= 2rpQo&s=3D0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=3D --aaron



_______________________________________________
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

--=_MailMate_4CB8EDFB-30DA-43F4-A317-7A167718CDF5_=-- From nobody Thu Mar 7 07:13:40 2019 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 9DA9C127971 for ; Thu, 7 Mar 2019 07:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 QfaT7LCQCIkj for ; Thu, 7 Mar 2019 07:13:36 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 826781313DC for ; Thu, 7 Mar 2019 07:13:29 -0800 (PST) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x27FDQqT030439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Mar 2019 16:13:26 +0100 Received: from [IPv6:2a00:79e0:42:206:ddde:493a:a53e:8c37] ([IPv6:2a00:79e0:42:206:ddde:493a:a53e:8c37]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x27FDPq3051823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 16:13:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: "Brian Trammell (IETF)" In-Reply-To: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> Date: Thu, 7 Mar 2019 16:13:25 +0100 Cc: taps WG , Zaheduzzaman Sarker Content-Transfer-Encoding: quoted-printable Message-Id: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.3445.102.3) 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] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 15:13:40 -0000 > On 4 Mar 2019, at 19:53, Aaron Falk wrote: >=20 > Hi All- >=20 > What should we use our time to discuss? Let=E2=80=99s focus on things = that would benefit from f2f discussion, consensus building, or just = argument. :) >=20 > =E2=80=A2 TAPS docs: are there open topics that need group = attention? Seems like we settled most of the remainder at the interim. > =E2=80=A2 TAPS security: this seems nearly done. Anything to = discuss? > =E2=80=A2 Implementations: a good topic for information sharing = but less important than anything needing agreement An MSc student of mine at ETH did an implementation of TAPS (or at least = something very TAPSish) and I=E2=80=99d like 5-10 minutes to present an = implementation report, as time allows. Thanks, cheers, Brian > =E2=80=A2 Mobility: non-TAPS draft on API & mobility and = incoming TSV AD suggestion to collaborate > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Mar 7 09:28:56 2019 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 CB50D12AF7B for ; Thu, 7 Mar 2019 09:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 ByiRbKTSf0Ie for ; Thu, 7 Mar 2019 09:28:42 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30136.outbound.protection.outlook.com [40.107.3.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCF91310A1 for ; Thu, 7 Mar 2019 09:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OIUHFyabX3JKTE2ZHQrGUu+pazZkUlHIQhX4Lrn76QY=; b=Yi5k3sPpcGiZEOzA7rH+mG7kvznbz8ZBnYk7hCqnK7Y+rmm3vv46KdGoE9O0hkKroFxcUyhRh0Ad4ZKHuHIULXVVQf6NL+3X8EoEoSg/AR/t3ryqf8ljgvqKQj8agVlsEzkpBzIgKxW9kdm/CIb8UOGHE9zoQTHFLYss4UiQmAE= Received: from DB6PR0701MB2182.eurprd07.prod.outlook.com (10.168.55.16) by DB6PR0701MB2294.eurprd07.prod.outlook.com (10.168.77.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.6; Thu, 7 Mar 2019 17:28:31 +0000 Received: from DB6PR0701MB2182.eurprd07.prod.outlook.com ([fe80::2ca5:1eed:afe4:86ea]) by DB6PR0701MB2182.eurprd07.prod.outlook.com ([fe80::2ca5:1eed:afe4:86ea%11]) with mapi id 15.20.1686.016; Thu, 7 Mar 2019 17:28:31 +0000 From: tom petch To: Michael Welzl , "Holland, Jake" CC: taps WG Thread-Topic: [Taps] call for agenda items at TAPS IETF-104 Thread-Index: AQHU1QsuujEGBYzapkKtLlT0v3ohmQ== Date: Thu, 7 Mar 2019 17:28:30 +0000 Message-ID: <006501d4d50a$e421da00$4001a8c0@gateway.2wire.net> References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0031.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:61::19) To DB6PR0701MB2182.eurprd07.prod.outlook.com (2603:10a6:4:4a::16) x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7860e19-d839-46e6-3416-08d6a3225129 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6PR0701MB2294; x-ms-traffictypediagnostic: DB6PR0701MB2294: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(376002)(366004)(396003)(199004)(189003)(53754006)(52314003)(51444003)(13464003)(4720700003)(81166006)(84392002)(81816011)(2906002)(316002)(52116002)(61296003)(4326008)(7736002)(561944003)(76176011)(14496001)(446003)(476003)(97736004)(8676002)(93886005)(53946003)(86362001)(30864003)(110136005)(8936002)(229853002)(66066001)(486006)(71200400001)(14444005)(6486002)(44736005)(81156014)(99286004)(25786009)(186003)(105586002)(5024004)(86152003)(71190400001)(9686003)(68736007)(5660300002)(6512007)(6306002)(6436002)(3846002)(386003)(305945005)(62236002)(14454004)(26005)(6246003)(6346003)(106356001)(1556002)(478600001)(50226002)(44716002)(102836004)(6506007)(53546011)(53936002)(966005)(256004)(81686011)(6116002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2294; H:DB6PR0701MB2182.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Fk2Z+5Bhcnzbu00XjL33aODnWvHDgkJzwbZqSqV2Gw+rABAftQeY35gK0XdgtlJKHfvgzPwcA1QZZktNhzfoY+yLCHcBnl7+O+veAwjW69hWukyBF6F84WaxXVZmspEpsPcA3O7fDi3NeDs9GxUADcRduPPm8d7pLCPsoBCNIN98Y26HVUNMpv/ZPrgAvFPDoOClFsQ2mcwn2ChHcaMr6XsoPALrfrTXs79cDjJTqhLk0ZDWbHVCM1UCQV68v2YsBfh1KQifHoruFRpoWsz3ksrjMCBg550QoDhZpnSbkSKxAMAB70hq5di+uJvjDdU3h3W6wFpmK4ctFvYt0BVnFLdRV+IzD8EHjuMV8sPy/QjG2F3VVwOd6SSVrmHAQOgV057Tw2AaV6WFCE21fHeHe+x+QB/uG+Rksl3akyUFXjY= Content-Type: text/plain; charset="utf-8" Content-ID: <648146E59ED5A349A0C2A8276188072D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7860e19-d839-46e6-3416-08d6a3225129 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 17:28:30.9797 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2294 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 17:28:50 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIk1pY2hhZWwgV2VsemwiIDxtaWNo YXdlQGlmaS51aW8ubm8+DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDcsIDIwMTkgODozMiBBTQ0K Pg0KPiBWZXJ5IHNvcnJ5IGZvciB0aGUgc2lsZW5jZS4gSSBjYW4gb25seSBzcGVhayBmb3IgbXlz ZWxmLCBidXQgaGVyZSdzIGFuDQpleGFtcGxlIG9mIHdoeSB0aGlzIG9uZSBwZXJzb24gd2FzIHNp bGVudDoNCj4gLSBXaGVuIHlvdSBjcmVhdGVkIHlvdXIgaXNzdWUgb24gbXVsdGljYXN0IGluIGdp dGh1YiwgSSB0aG91Z2h0IG9mDQphbnN3ZXJpbmcgKHBvc2l0aXZlbHkpLCBidXQgdGhlbiB0aG91 Z2h0IHRoYXQgdGhlIHJlcG8gaXMgYWJvdXQgdG8gbW92ZSwNCmFuZCBpdCB3b3VsZCBwcm9iYWJs eSBiZSBiZXR0ZXIgdG8gZGVsYXkgdGhpbmdzIHVudGlsIHRoZSBtb3ZlIGlzDQpmaW5pc2hlZC4N Cj4gLSBUaGVuLCB0aGUgaXNzdWUgd2FzIG92ZXJydWxlZCBieSB5b3VyIGVtYWlsLiBJIHJlYWQg aXQgYW5kIGZvdW5kIGl0DQppbnRlcmVzdGluZywgYnV0IGhvcGVkIGZvciBzb21lb25lIGVsc2Ug dG8gYW5zd2VyIGJlY2F1c2UsIGZyYW5rbHksIEkNCndhcyBhZnJhaWQgdG8gbWFrZSBhIGZvb2wg b2YgbXlzZWxmIC4uLiBiZWNhdXNlIEkga25vdyBhbG1vc3Qgbm90aGluZw0KYWJvdXQgWUFORy4N Cj4NCj4gQnV0IG5vdyBJJ2xsIGJlIGJyYXZlICA6KSAgIEknbGwgZ28gYWhlYWQgYW5kIGFzazog aG93IGV4YWN0bHkgaXMgdGhpcw0KWUFORyBwcm9wb3NhbCBtb3JlIHRoYW4ganVzdCBhIHN5bnRh eCBjaGFuZ2U/ICBXaGF0IHdvdWxkIGl0IGdpdmUgdXM/DQo+IChJIHVuZGVyc3RhbmQgdGhhdCBZ QU5HIGNhbiBiZSBhdXRvbWF0aWNhbGx5IHBhcnNlZCAvIGNoZWNrZWQgYnkgc29tZQ0KdG9vbHMs IGJ1dC4uLiB3aGF0IGRvZXMgVEhBVCBnaXZlIHVzPykNCg0KWWVzLCBpbmRlZWQuICBZQU5HIGlz IGEgRERMIGNyZWF0ZWQgdG8gcHJvdmlkZSBkZWZpbml0aW9ucyBvZiBkYXRhDQpzdHJ1Y3R1cmVz IHRoYXQgbmVlZCB0byBiZSByZWFkIGFuZC9vciB3cml0dGVuIHdoZW4gbWFuYWdpbmcgbmV0d29y a3Mgb3INCnNpbWlsYXIgc3lzdGVtcywgc28gaXQgbWF0Y2hlcyB3ZWxsIHdpdGggQkdQIG9yIExJ U1AsIE5BVCBvciBRT1MuICBJdCBpcw0KdmVyYm9zZSAoYSByZWFjdGlvbiBJTUhPIHRvIEFTTi4x KS4gIEl0IGxhY2tzLCBmb3IgbWUsIHJpZ291ciwgZm9ybWFsDQp1bmRlcnBpbm5pbmdzLCB3aGlj aCBzaG93cyB1cCBpbiBxdWlya3MsIGNvcm5lciBjYXNlcyBhbmQgaW4gdGhlIGxlbmd0aHkNCkFC TkYgZGVmaW5pdGlvbiBvZiBpdC4gIEl0IGhhcyBnb3QgY29uc3RyYWludHMgLSAnbXVzdCcgJ3do ZW4nIHJhbmdlIG9mDQp2YWx1ZXMgb3IgbGVuZ3RoIC0gc28geW91IGNhbiBzcGVjaWZ5IHRoYXQg dGhlIE1UVSBtdXN0IGJlIHByZXNlbnQgYW5kDQpiZSBpbiBhIGRpZmZlcmVudCByYW5nZSBkZXBl bmRpbmcgb24gd2hpY2ggaW50ZXJmYWNlIHR5cGUgaXMgcmVmZXJlbmNlZC4NCg0KSXQgaXMgY2xv c2VseSB0aWVkIHRvIFhNTCBhbmQgTmV0Y29uZiAoYXMgYSBtb3N0IGZsZWV0aW5nIGdsYW5jZSBh dA0KUkZDNzk1MCBzaG93cyk7IHJlcGVhdGVkIHRhbGsgb2YgZGVjb3VwbGluZyBpdCBoYXZlIHll dCB0byBsZWFkIHRvDQphY3Rpb24uICBUaGUgc3ludGF4IHdhcyBjaG9zZW4gdG8gYmUgQy1saWtl IChidXQgbm90IEMpLg0KDQpJdCBoYXMgbm8gc2Vuc2Ugb2YgZG9jdW1lbnQgb3JkZXIuICBUaGUg cGVybWl0dGVkIHJhbmdlIG9mIHZhbHVlcyBjYW4gYmUNCnRpZWQgdG8gd2hhdCB5b3UgbWlnaHQg c2VlIGluIGFuIElFVEYgcHJvdG9jb2wgKGFsdGhvdWdoIGEgc3RyaW5nIGNhbiBiZQ0KMTg0NDY3 NDQwNzM3MDk1NTE2MTUpLiAgRW51bWVyYXRpb25zIGNhbiBzcGVjaWZ5IGEgdmFsdWUgKGFsb25n IHdpdGggYQ0Kc3RyaW5nKSBidXQgdGhlIHZhbHVlIGlzIGRvY3VtZW50YXRpb24gb25seSAtIGl0 IGRvZXMgbm90IGFwcGVhciBvbiB0aGUNCndpcmUuICBUaGVyZSBpcyBubyBzZW5zZSBvZiBwcmVj ZWRlbmNlIGJldHdlZW4sIHNheSwgUHJlZmVyIGFuZCBSZXF1aXJlLg0KQ2FwaXRhbCBsZXR0ZXJz IGFyZSBub3QgcHJvaGliaXRlZCwgcmF0aGVyIGRpc2NvdXJhZ2VkIHNvIGZldyBwZW9wbGUgdXNl DQp0aGVtLg0KDQpXaGF0IGRvZXMgaXQgb2ZmZXIgVEFQUz8gIE1tbSBJIHRob3VnaHQgVExTIGZv b2xpc2ggd2hlbiBpdCBkZWZpbmVkIGl0cw0Kb3duIERETCBidXQgb3ZlciB0aW1lLCBoYXZlIGNv bWUgdG8gYXBwcmVjaWF0ZSB0aGF0IGNob2ljZS4NCg0KVG9tIFBldGNoDQoNCj4gQWxzbywgSSBh Y3R1YWxseSBzZWUgMyBzZXBhcmFibGUgdGhpbmdzIGJlaW5nIHByb3Bvc2VkIGhlcmU6DQo+DQo+ IDEpIHRoZSBZQU5HIG1vZGVsDQo+DQo+IDIpIG11bHRpY2FzdCBzdXBwb3J0ICAoSSBmaW5kIHlv dXIgY29uY2x1c2lvbiB0aGF0IG5vdCBtdWNoIG5lZWRzIHRvDQpjaGFuZ2UgaW50ZXJlc3Rpbmch ICBUaG91Z2ggdGhlIGV4YW1wbGUgeW91J3JlIGdpdmluZyAoam9pbmluZyBhbiBTU00NCmNoYW5u ZWwpIGlzIG9ubHkgYSBwYXJ0IG9mIHdoYXQgd2UnZCBuZWVkLCBhcyB5b3UgYWxzbyBzYXkuLi4p DQo+DQo+IDMpIGFwcGx5aW5nIHByZWZlcmVuY2VzIHRvIGFkZHJlc3NlcyBhbmQgcG9ydCBudW1i ZXJzICAod2hpY2ggeW91IHNlZW0NCnRvIHRha2UgZm9yIGdyYW50ZWQgaW4geW91ciBkcmFmdCwg YnV0IHdoaWNoIEkgZG9uJ3QgdGhpbmsgaXMgc3VwcG9ydGVkDQpieSBvdXIgY3VycmVudCBkb2N1 bWVudCkuDQo+IFNpZGUgbm90ZTogdW5sZXNzIEknbSBtaXN0YWtlbiwgdGhpcyB3b3VsZG4ndCBm aXQgb3VyIHN0cnVjdHVyZSB3ZWxsOg0KZS5nLiBhIHBvcnQgbnVtYmVyIHdvdWxkIHRoZW4gYmUg YSBUcmFuc3BvcnQgUHJvcGVydHkgdGhhdCBoYXMgYSBjZXJ0YWluDQp2YWx1ZSwgYnV0IGFsc28g aGFzIGEgcHJlZmVyZW5jZSwgYnV0IGN1cnJlbnRseSB3ZSBzYXkgdGhhdCBhIFRyYW5zcG9ydA0K UHJvcGVydHkgaGFzICJvbmUgb2YgYSBzZXQgb2YgZGF0YSB0eXBlcyIsIG9uZSBvZiB3aGljaCBp cyBhIFByZWZlcmVuY2UuDQpJc24ndCB0aGF0IHN0cnVjdHVyZSB0b28gbGltaXRpbmc/IE9yIGFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQo+DQo+IEkgZ3Vlc3MgdGhhdCAyKSBuZWVkcyAzKSwgYnV0 IHBlcmhhcHMgaXQncyB1c2VmdWwgdG8gc2VlIDIpIGFuZCAzKSBhcw0Kc2VwYXJhdGUuLi4gbWF5 YmUgdGhlcmUgYXJlIG90aGVyIHVzZSBjYXNlcyBmb3IgMykgYWxvbmUgPw0KPiBJTU8sIGFsbCBv ZiB0aGVzZSB0aGluZ3MgYXJlIGludGVyZXN0aW5nLCBhbmQgd291bGQgYmUgZ29vZCB0byBkaXNj dXNzDQpvbiBzaXRlLiBIb3dldmVyLCBJIGRvdWJ0IHRoYXQgd2UgY2FuIGRlYWwgd2l0aCB0aGVt IGFsbCBpbiBvbmx5IDE1DQptaW51dGVzICA6LSkNCj4NCj4gQ2hlZXJzLA0KPiBNaWNoYWVsDQo+ DQo+IFBTOiBUcmF2aXMgaXMgZG93biwgb3Igc29tZXRoaW5nLiBBdCBsZWFzdCB0aGUgIkVkaXRv cidzIENvcHkiIGxpbmtzDQpkb24ndCBjdXJyZW50bHkgd29yay4NCj4NCg0KPiA+IE9uIDcgTWFy IDIwMTksIGF0IDA0OjU1LCBIb2xsYW5kLCBKYWtlIDxqaG9sbGFuZEBha2FtYWkuY29tPiB3cm90 ZToNCj4gPg0KPiA+IEhpIHRhcHMsDQo+ID4NCj4gPiAoVHJ5aW5nIGFnYWluLCBidXQgc2ltcGxl ci4pDQo+ID4NCj4gPiBJJ20gbG9va2luZyBmb3IgYSBjb25zZW5zdXMgeWVzIG9yIG5vIGFuc3dl cjoNCj4gPg0KPiA+IElzIGEgbm9ybWF0aXZlIGNvbmZpZyBpbnB1dCBmb3JtYXQgYW4gaW50ZXJl c3RpbmcgYW5kIHVzZWZ1bA0KPiA+IGRpcmVjdGlvbj8NCj4gPg0KPiA+DQo+ID4gVGhlIGlkZWEg aXMgdG8gYWRkIGZ1bmN0aW9uYWxpdHkgbGlrZSB0aGlzLCBpbiB0YXBzLWludGVyZmFjZToNCj4g Pg0KPiA+ICBuZXdQcmUgPSBQcmVDb25uZWN0aW9uLk5ld0Zyb21Kc29uKCcnJ3sNCj4gPiAgICAi cmVtb3RlLWVuZHBvaW50Ijp7DQo+ID4gICAgICAiaG9zdHMiOlsNCj4gPiAgICAgICAgeyAiaG9z dCI6ImV4YW1wbGUuY29tIiB9DQo+ID4gICAgICBdDQo+ID4gICAgfQ0KPiA+ICB9JycnKQ0KPiA+ DQo+ID4gV2l0aCBhIGZ1bGx5IHNwZWNpZmllZCBqc29uIGlucHV0IGZvcm1hdCB0aGF0IGNhbiBw cm92aWRlIGFsbCB0aGUNCj4gPiBjb25maWd1cmFibGUgdmFsdWVzLg0KPiA+DQo+ID4NCj4gPiBJ ZiBubywgSSdsbCBtb3ZlIG9uIGFuZCBhc3N1bWUgSSBqdXN0IGRvbid0IHVuZGVyc3RhbmQgdGFw cyBnb2Fscy4NCj4gPg0KPiA+IElmIHllcywgSSdkIGxpa2UgMTUgbWludXRlcyB0byBkaXNjdXNz IGluIFByYWd1ZSwgYW5kIGtlZXAgcmVhZGluZzoNCj4gPg0KPiA+IEkgdGhpbmsgYSBmdWxsIGRl ZmluaXRpb24gb2YgYW4gaW5wdXQganNvbiBmb3JtYXQgY2FuIGJlIGV4YWN0bHkNCj4gPiBzcGVj aWZpZWQgYnkgYSBZQU5HIG1vZGVsLiAoV2l0aCB4bWwgZm9yIGZyZWUsIGlmIHlvdSB3YW50IGl0 LikNCj4gPg0KPiA+IEkgdHJpZWQgdG8gc2tldGNoIGEgc3RhcnQgYXQgd2hhdCBhIFlBTkcgbW9k ZWwgZm9yIHRoaXMgbWlnaHQgbG9vaw0KbGlrZToNCj4gPg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmctMDAjc2VjdGlvbi0zDQo+ID4NCj4g PiBJJ20gbm90IGEgWUFORyBleHBlcnQgeWV0LCBhbmQgaXQncyBub3QgbXVjaCBvZiBhIG1vZGVs LiAgQW5kIGl0J3MNCnZlcnkNCj4gPiBmYXIgZnJvbSBjb21wbGV0ZS4gIEJ1dCBpdCBjb21waWxl cywgYW5kIGFsbCB0aGUgZXhhbXBsZXMgaW4gdGhlDQpkcmFmdA0KPiA+IHZhbGlkYXRlIGFnYWlu c3QgdGhhdCBtb2RlbCB3aXRoIGxpYnlhbmcuICBJZiBpdCdzIHdvcnRod2hpbGUsIEkNCnRoaW5r DQo+ID4gc29tZXRoaW5nIGxpa2UgdGhpcyBjYW4gYmUgZ29vZCAoYW5kIGV4dGVuc2libGUhKSwg aWYgZG9uZSByaWdodC4NCj4gPg0KPiA+IEkgYmVsaWV2ZSBzb21ldGhpbmcgYWxvbmcgdGhlc2Ug bGluZXMgd291bGQgc2hhcnBlbiB1cA0KdGFwcy1pbnRlcmZhY2UNCj4gPiBhIGxvdC4gKEFmdGVy IGZpbGxpbmcgaW4gYWxsIHRoZSB0YXBzLWludGVyZmFjZSBwcm9wZXJ0aWVzLikNCj4gPg0KPiA+ DQo+ID4gVGhlIHJlYXNvbiBJJ20gYXNraW5nIGlzIGJlY2F1c2UgcmlnaHQgbm93LCB0YXBzLWlu dGVyZmFjZSB0byBtZQ0KPiA+IHNlZW1zIF9hbG1vc3RfIHJlYWxseSBnb29kLCBleGNlcHQgdG9v IGNvbmZ1c2luZyBhbmQgdmFndWUgdG8NCmFjdHVhbGx5DQo+ID4gYnVpbGQgYW4gQVBJIHRoYXQg Y2FuIHJlcGxhY2UgQlNEIHNvY2tldHMuICBJIHRoaW5rIHdpdGggYSBzb2xpZA0KY29uZmlnDQo+ ID4gZm9ybWF0IHdpdGggbm9ybWF0aXZlIGFuZCB0ZXN0YWJsZSBleGFtcGxlcywgdGhhdCBjb3Vs ZCBiZSBmaXhlZC4NCj4gPg0KPiA+IElmIGNvbnNlbnN1cyBzYXlzICJpbnRlcmVzdGluZyIsIEkn bGwgd2FudCAxNSBtaW51dGVzIHRvIGRpc2N1c3MgaXQsDQphbmQNCj4gPiB0byBzdGFydCBkaWdn aW5nIGludG8gaG93IHRvIG1ha2UgaXQgZ29vZC4gIChBbmQgYWxzbyB0byBhZGQNCm11bHRpY2Fz dA0KPiA+IHN1cHBvcnQgdG8gdGhlIG1vZGVsIGFuZCBhdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRp b24uKQ0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIGNvbnNpZGVyYXRpb24uDQo+ID4NCj4gPg0K PiA+IENoZWVycywNCj4gPiBKYWtlDQo+ID4NCj4gPg0KPiA+DQo+ID4g77u/T24gMjAxOS0wMy0w NCwgMTc6MTksICJIb2xsYW5kLCBKYWtlIiA8amhvbGxhbmRAYWthbWFpLmNvbT4gd3JvdGU6DQo+ ID4NCj4gPiAgICBIaSB0YXBzIGZvbGtzLA0KPiA+DQo+ID4gICAgVEw7RFI6IEkgdGhpbmsgdGhl IHNwZWMgc2hvdWxkIGhhdmUgYSBZQU5HIG1vZGVsIGFuZCBJIHdhbnQgdG8NCnVzZSBpdA0KPiA+ ICAgIHRvIGdldCBtdWx0aWNhc3Qgc3VwcG9ydCBpbiBhbiBpbXBsZW1lbnRhdGlvbi4NCj4gPg0K PiA+DQo+ID4gICAgSSByZWNlbnRseSBzdGFydGVkIGRpZ2dpbmcgaW50byB0aGUgdGFwcyBBUEkg d2l0aCB0aGUgaW50ZW50IG9mDQphZGRpbmcNCj4gPiAgICBtdWx0aWNhc3Qgc3VwcG9ydCwgYnV0 IGl0IGxvb2tzIGxpa2UgaXQncyBiYXNpY2FsbHkgYWxyZWFkeQ0KdGhlcmUsIGFzDQo+ID4gICAg ZmFyIGFzIGl0IGdvZXNbKl0uDQo+ID4NCj4gPiAgICBCdXQgSSBlbmRlZCB1cCB3aXRoIGEgaGln aGVyLWxldmVsIGNvbW1lbnQsIHNvIEkgdGhvdWdodCBJJ2QNCnJhaXNlIGl0DQo+ID4gICAgdG8g dGhlIHdnIGFuZCBhc2sgd2hhdCB5b3UgYWxsIHRoaW5rLg0KPiA+DQo+ID4gICAgSSBmb3VuZCB0 aGUgd2hvbGUgImFic3RyYWN0IGludGVyZmFjZSIgYXBwcm9hY2ggYSBsaXR0bGUgdG9vDQo+ID4g ICAgbG9vc2V5LWdvb3NleSwgc28gSSB0aG91Z2h0IEknZCB0cnkgdG8gc3VnZ2VzdCBhIHdheSB0 byB0aWdodGVuDQppdCB1cC4NCj4gPg0KPiA+ICAgIE15IGdvYWwgd2l0aCB0aGlzIGlzIHRvIG1h a2UgaXQgbXVjaCBtb3JlIGNsZWFyICh0byB0aGUgcG9pbnQgb2YNCmJlaW5nDQo+ID4gICAgbWVj aGFuaWNhbGx5IGNoZWNrYWJsZSkgcHJlY2lzZWx5IHdoYXQgYSBjb21wbGlhbnQgQVBJIHByb3Zp ZGVzLg0KPiA+DQo+ID4gICAgSSdtIG5vdCBhdHRhY2hlZCB0byB0aGUgc3RydWN0dXJlIEknbSBw cm9wb3Npbmcgb3IgdG8gYW55IG9mIHRoZQ0KPiA+ICAgIHBhcnRpY3VsYXJzIGluIHRoZSBzdHJh dy1tYW4gSSd2ZSBwb3N0ZWQsIGJ1dCBpZiBpdCdzIG5vdA0KdGlnaHRlbmVkIHVwDQo+ID4gICAg d2l0aCBzb21ldGhpbmcgYXQgYSBzaW1pbGFyIGxldmVsIG9mIGNvbmNyZXRlbmVzcywgSSdtIGNv bmNlcm5lZA0KdGhhdA0KPiA+ICAgIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBiZSBu b3Qgb25seSBpbmNvbXBhdGlibGUgaW4gcmFuZG9tDQo+ID4gICAgdW5kZXJzcGVjaWZpZWQgY29y bmVyIGNhc2VzIChsaWtlIEJTRCBzb2NrZXRzIHRvZGF5IHdoZW4geW91IHRyeQ0KdG8gbWFrZQ0K PiA+ICAgIGNyb3NzLXBsYXRmb3JtIEMgY29kZSksIGJ1dCBhbHNvIGFyZSBsaWtlbHkgdG8gZW5k IHVwIHdpdGggdmVyeQ0KbWFueQ0KPiA+ICAgIGltcG9ydGFudCBkaWZmZXJlbmNlcyB0aGF0IHdv dWxkIG1ha2UgdGhlIHdob2xlIHRhcHMgZWZmb3J0IG1vcmUNCm9yIGxlc3MNCj4gPiAgICBtb290 Lg0KPiA+DQo+ID4gICAgSW4gYSB3b3JsZCB3aGVyZSB3ZSBlbmQgdXAgd2l0aCBhIGRvYyBhdCB0 aGUgbGV2ZWwgb2YgYWJzdHJhY3Rpb24NCkknbQ0KPiA+ICAgIGN1cnJlbnRseSBzZWVpbmcgaW4g ZHJhZnQtdGFwcy1pbnRlcmZhY2UsIGl0IHNlZW1zIHRvIG1lIHRoYXQgaWYNCjINCj4gPiAgICBk aWZmZXJlbnQgQVBJIGltcGxlbWVudGF0aW9ucyB3ZXJlIHdyaXR0ZW4gaW4gdGhlIHNhbWUgbGFu Z3VhZ2UsDQppdCdsbA0KPiA+ICAgIGJlIHByb2hpYml0aXZlbHkgZGlmZmljdWx0IGZvciBhbiBh cHAgdG8gbWlncmF0ZSBmcm9tIHVzaW5nIG9uZQ0KdG8gdXNpbmcNCj4gPiAgICB0aGUgb3RoZXIs IGp1c3QgYmVjYXVzZSBzbyBtYW55IGFzcGVjdHMgb2YgaXQgYXJlIGxlZnQgb3BlbiB0bw0KdGhl DQo+ID4gICAgaW1wbGVtZW50b3JzLg0KPiA+DQo+ID4gICAgSW4gdGhhdCBjb250ZXh0LCBJIHRo b3VnaHQgYSBZQU5HIG1vZGVsIHdvdWxkIGJlIHVzZWZ1bCBoZXJlIHRvDQo+ID4gICAgcHJvdmlk ZSBhIGNyb3NzLXBsYXRmb3JtIHdheSB0byBzcGVjaWZ5IHdoYXQgZXhhY3QgcHJvcGVydGllcyBh bmQNCj4gPiAgICBvYmplY3RzIGV4aXN0LCBhbiBleGFjdCBmb3JtYXQgaW4gd2hpY2ggdGhlIHZh bHVlcyBjYW4gYmUNCnNwZWNpZmllZCwgYW5kDQo+ID4gICAgd2hhdCBleGFjdCBzZW1hbnRpY3Mg dGhleSBoYXZlLCB3aGlsZSBzdGlsbCBhbGxvd2luZyBmb3IgYSBzYW5lDQo+ID4gICAgZXh0ZW5z aW9uIHBhdGggYW5kIGxhbmd1YWdlLXNwZWNpZmljIGltcGxlbWVudGF0aW9uIGRldGFpbHMuDQo+ ID4NCj4gPiAgICBJJ20gdGhpbmtpbmcgc29tZSBsYW5ndWFnZSBhIGJpdCBsaWtlIHRoZSBmaXJz dCBidWxsZXQgaW4gU2VjdGlvbg0KNC4yIG9mDQo+ID4gICAgdGFwcy1pbnRlcmZhY2U6DQo+ID4N Cj4gPiAgICAgIEEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIFNIT1VMRCBwcm92aWRlIGENCmxh bmd1YWdlLWFwcHJvcHJpYXRlIHdheSB0bw0KPiA+ICAgICAgY29uZmlndXJlIGEgUHJlQ29ubmVj dGlvbiB1c2luZyBZQU5HIGluc3RhbmNlIGRhdGEgZm9yIHRoaXMNCm1vZGVsLCBhbmQNCj4gPiAg ICAgIFNIT1VMRCBwcm92aWRlIGFuIEFQSSB0aGF0IG91dHB1dHMgdGhlIFlBTkcgaW5zdGFuY2Ug ZGF0YSBmb3INCmFuDQo+ID4gICAgICBlc3RhYmxpc2hlZCBDb25uZWN0aW9uLg0KPiA+DQo+ID4g ICAgICBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgYWxzbyBwcm92aWRlIGFwcHJvcHJpYXRlIEFQSXMg Zm9yDQpkaXJlY3RseSBlZGl0aW5nDQo+ID4gICAgICB0aGUgb2JqZWN0cyB3aXRob3V0IHVzaW5n IFlBTkcuICBJdCdzIFJFQ09NTUVOREVEIHdoZXJlDQpwb3NzaWJsZSB0byB1c2UNCj4gPiAgICAg IG5hbWVzIHRoYXQgbWVjaGFuaWNhbGx5IHRyYW5zbGF0ZSB0byB0aGUgbmFtZXMgaW4gdGhlIFlB TkcgZGF0YQ0KbW9kZWwsDQo+ID4gICAgICB1c2luZyBjYXBpdGFsaXphdGlvbiBhbmQgcHVuY3R1 YXRpb24gY29udmVudGlvbnMgYXMgZXhwZWN0ZWQNCmZvciB0aGUNCj4gPiAgICAgIGxhbmd1YWdl IG9mIHRoZSBpbXBsZW1lbnRhdGlvbi4NCj4gPg0KPiA+ICAgIEFuZCB0aGVuIG9mIGNvdXJzZSBh IFlBTkcgbW9kZWw6DQo+ID4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtamhvbGxhbmQtdGFwcy1hcGkteWFuZy8NCj4gPiAgICAoZHJhZnQtamhvbGxhbmQtdGFwcy1h cGkteWFuZykNCj4gPg0KPiA+ICAgIElmIHRoaXMgc2VlbXMgdXNlZnVsLCBpdCB3aWxsIG5lZWQg bG90cyBvZiByZWZpbmluZy4gIEknbGwgYmUNCnN1cnByaXNlZA0KPiA+ICAgIGlmIGFueSBwYXJ0 IG9mIGl0IHN1cnZpdmVzIGV4YWN0bHkgYXMgd3JpdHRlbi4gIEl0J3MgYSBxdWljayBhbmQNCj4g PiAgICBkaXJ0eSBhdHRlbXB0IHRvIGNvbmNyZXRpemUgYSBmZXcgb2YgdGhlIHRoaW5ncyBJIHNh dyBsaXN0ZWQgaW4NCj4gPiAgICBkcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLCBhcyBhIHN0YXJ0 aW5nIHBvaW50IHRvIGZpbGwgb3V0IGlmIGl0DQpzZWVtcw0KPiA+ICAgIHVzZWZ1bC4NCj4gPg0K PiA+ICAgIEJ1dCB0aGUgbW9kZWwgcGFyc2VzLCBhbmQgdGhlIGV4YW1wbGUgZGF0YSBpbnN0YW5j ZXMgaW4gdGhlIGRyYWZ0DQo+ID4gICAgcGFyc2UgYWdhaW5zdCB0aGUgbW9kZWwgKGFsbCB3aXRo IGxpYnlhbmcpLg0KPiA+DQo+ID4gICAgT25lIG9mIHRoZSBtYWluIHJlYXNvbnMgSSdtIGRvaW5n IHRoaXMgaXMgYmVjYXVzZSBpdCBzZWVtcyB0byBtZQ0Kd2hhdCdzDQo+ID4gICAgc3BlY2lmaWVk IGluIHRhcHMtaW50ZXJmYWNlLTAyIHRvZGF5IGlzIG1pc3Npbmcgc29tZSBrZXkNCmZlYXR1cmVz LCBsaWtlDQo+ID4gICAgYW4gZW51bWVyYXRpb24gb2YgdGhlIHByb3BlcnRpZXMgaW4gdGhlIExv Y2FsL1JlbW90ZUVuZHBvaW50DQpleGFtcGxlcyBpbg0KPiA+ICAgIHNlY3Rpb24gNS4xLiAgQW5k IEkgZG9uJ3Qgc2VlIHRoYXQgbGlzdGVkIGFzIGFuIG9wZW4gaXNzdWUgaW4NCmdpdGh1YiwNCj4g PiAgICB3aGljaCBzdXJwcmlzZWQgbWUgYSBiaXQuDQo+ID4NCj4gPiAgICBJIHRoaW5rIG92ZXJz aWdodHMgbGlrZSB0aGlzIHdpbGwgYmVjb21lIGltbWVkaWF0ZWx5IGFuZA0KcGFpbmZ1bGx5DQo+ ID4gICAgb2J2aW91cyB3aGVuIHRoZXJlJ3MgYSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gdGhh dCBpbmNsdWRlcyBhDQpZQU5HDQo+ID4gICAgcGFyc2VyIGFuZCBhbiBleHBsaWNpdCBkYXRhIG1v ZGVsLCBhcyBvcHBvc2VkIHRvIHRoZSBjb21iaW5nIG9mDQp0aGUNCj4gPiAgICBkb2N1bWVudCBh bmQgYSBzb3J0IG9mIGV5ZWJhbGxlZCBjb21wYXJpc29uIHRvIE5FQVQgdGhhdCBJIHRyaWVkDQo+ ID4gICAgdGhpcyB3ZWVrIHRvIHJlYWNoIHRoYXQgY29uY2x1c2lvbiAod2hpY2ggSSBmb3VuZCBj aGFsbGVuZ2luZw0KZXZlbg0KPiA+ICAgIHRob3VnaCBJIHRob3VnaHQgYm90aCB0aGUgZG9jdW1l bnQgYW5kIHRoZSBsaWJyYXJ5IHdlcmUgbW9zdGx5DQpwcmV0dHkNCj4gPiAgICB3ZWxsIHdyaXR0 ZW4pLg0KPiA+DQo+ID4gICAgVGhlIHdob2xlIHRoaW5nIGF0IHRoaXMgcG9pbnQganVzdCBzbWVs bHMgdG8gbWUgbXVjaCBtb3JlDQphYnN0cmFjdCB0aGFuDQo+ID4gICAgaXQgcmVhbGx5IGhhcyB0 byBiZSBvciB0aGFuIGl0J3MgcmVhbGx5IHVzZWZ1bCB0byBiZSwgd2hpY2gNCmJvdGhlcnMgbWUN Cj4gPiAgICBiZWNhdXNlIHRoZSBpZGVhIG9mIHJlcGxhY2luZyBCU0Qgc29ja2V0cyB3aXRoIHNv bWV0aGluZyB1c2FibGUNCnNlZW1zDQo+ID4gICAgbGlrZSBzdWNoIGEgZ3JlYXQgaWRlYS4gIEkn ZCBsaWtlIHRoaXMgdG8gYmUgc29tZXRoaW5nIEkgY2FuDQphY3R1YWxseQ0KPiA+ICAgIHVzZSBp biBhIHdheSB0aGF0IG1ha2VzIG15IGxpZmUgZWFzaWVyIHNvbWVkYXkgc29vbi4NCj4gPg0KPiA+ ICAgIEJ1dCBJIHRoaW5rIEknbSBhdCB0aGUgcG9pbnQgd2hlcmUgSSBuZWVkIGEgc2FuaXR5IGNo ZWNrIHRvIHNlZQ0KaWYgSSdtDQo+ID4gICAganVzdCBtaXNzaW5nIHNvbWV0aGluZywgb3IgaWYg dGhpcyBzZWVtcyBsaWtlIGEgdXNlZnVsIGRpcmVjdGlvbi4NCj4gPg0KPiA+ICAgIFRob3VnaHRz PyAgU3VnZ2VzdGlvbnM/ICAgV29ydGggZGlzY3Vzc2luZyBpbiBQcmFndWU/ICAoSWYgc28sDQpj YW4gSQ0KPiA+ICAgIGdldCBhIHNsb3Q/KQ0KPiA+DQo+ID4gICAgQ2hlZXJzLA0KPiA+ICAgIEph a2UNCj4gPg0KPiA+ICAgICo6DQo+ID4gICAgSSBjb25jbHVkZWQgdGhhdCB0aGVyZSdzIG5vIHJl YXNvbiBtdWx0aWNhc3QgY291bGRuJ3QgYmUNCnN1cHBvcnRlZA0KPiA+ICAgIHRvZGF5LCBpZiB0 aGVyZSB3ZXJlIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgY291bGQgcmVhc29uYWJseQ0KY2xhaW0g dG8gYmUNCj4gPiAgICBjb21wbGlhbnQsIGJ5IGp1c3QgYWRhcHRpbmcgc29tZSBvZiB0aGUgZXhh bXBsZXMgaW4NCj4gPiAgICBkcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLTAyIGFuZCB1bmRlcnN0 YW5kaW5nIHRoZSBzZW1hbnRpYw0KbWVhbmluZyBvZg0KPiA+ICAgIG11bHRpY2FzdCBhZGRyZXNz IHNwYWNlcyBpbnNpZGUgdGhlIEFQSS4NCj4gPg0KPiA+ICAgIEZvciBleGFtcGxlLCBJIGNvdWxk bid0IGZpbmQgYW55IHJlYXNvbiB0aGlzIGNhbid0IGJlIGV4cGVjdGVkIHRvDQpzZXQNCj4gPiAg ICB1cCBhbiBTU00gY2hhbm5lbCBzdWJzY3JpcHRpb24gd2l0aG91dCBhbnkgZnVydGhlciBhZG8s IGdpdmVuIGENCnNhbmUNCj4gPiAgICBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIGl0Og0K PiA+DQo+ID4gICAgICBSZW1vdGVTcGVjaWZpZXIgOj0gTmV3UmVtb3RlRW5kcG9pbnQoKQ0KPiA+ ICAgICAgUmVtb3RlU3BlY2lmaWVyLldpdGhJUHY0QWRkcmVzcygxOTIuMC4yLjIxKQ0KPiA+DQo+ ID4gICAgICBMb2NhbFNwZWNpZmllciA6PSBOZXdMb2NhbEVuZHBvaW50KCkNCj4gPiAgICAgIExv Y2FsU3BlY2lmaWVyLldpdGhQb3J0KDMwMDAwKQ0KPiA+ICAgICAgTG9jYWxTcGVjaWZpZXIuV2l0 aElQdjRBZGRyZXNzKDIzMi4yNTIuMC4yKQ0KPiA+DQo+ID4gICAgICBOZXdQcmVjb25uZWN0aW9u KFJlbW90ZVNwZWNpZmllciwgTG9jYWxTcGVjaWZpZXIpLkxpc3RlbiguLi4pDQo+ID4NCj4gPiAg ICBNYXliZSB0aGVyZSdzIHNvbWUgdmFsdWUgaW4gc3BlY2lmeWluZyBhICJKb2luU1NNKCkiIHRv IG92ZXJyaWRlDQpkZWZhdWx0cw0KPiA+ICAgIGluIHRoZSBQcmVDb25uZWN0aW9uLCBqdXN0IHRv IG1ha2Ugc3VyZSB5b3UncmUgc3BlY2lmaWNhbGx5DQphc2tpbmcgZm9yDQo+ID4gICAgbXVsdGlj YXN0LiAgSSB0aGluayB0aGF0IHdvdWxkIGJlIGZpbmUgZm9yIG5hdGl2ZSBtdWx0aWNhc3QsIGJ1 dA0KbGlrZSBJDQo+ID4gICAgc2FpZCwgYSBtdWNoIHNtYWxsZXIgcG9pbnQgdGhhbiB0aGUgbG9v c2VuZXNzIG9mIHRoZSBBUEkuDQo+ID4NCj4gPiAgICBXaGVyZSBpdCBnZXRzIGEgYml0IG1vcmUg Y29tcGxpY2F0ZWQgaXMgdHJ5aW5nIHRvIGhhbmRsZSBtdWx0aXBsZQ0Kb3B0aW9ucw0KPiA+ICAg IGZvciBkaXNjb3ZlcmluZyBhIHVzYWJsZSB1bmljYXN0IHR1bm5lbCBmb3IgbXVsdGljYXN0IHRy YWZmaWMsIGFzDQo+ID4gICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi40LjEgb2YNCmRyYWZ0LWll dGYtbWJvbmVkLWRyaWFkLWFtdC1kaXNjb3ZlcnktMDEuDQo+ID4NCj4gPiAgICBJJ2QgbGlrZSB0 byBoYXZlIGEgZGVjZW50IHBsYWNlIHRvIHRhY2sgb24gYW4gZXh0ZW5zaW9uIHRvIHRoaXMNCkFQ SSB0aGF0DQo+ID4gICAgY2FuIHRyYW5zcGFyZW50bHksIHdpdGhpbiB0aGUgY29ubmVjdGlvbiBB UEksIGRpc2NvdmVyIHRoZSBiZXN0DQphdmFpbGFibGUNCj4gPiAgICBBTVQgcmVsYXkgYW5kIHN0 YXJ0IHVzaW5nIGl0IHdoZW4gbmF0aXZlIGpvaW5pbmcgaXMgdW5hdmFpbGFibGUNCihhbmQgYWxz bw0KPiA+ICAgIHRvIHByb3ZpZGUgbm9ybWF0aXZlIGNvbnRyb2xzIGZvciBjb25maWd1cmluZyBp dCB3aGVuIHRoZXJlJ3MNCj4gPiAgICBhZG1pbmlzdHJhdGl2ZSBjb25maWd1cmF0aW9uIHRvIGJl IGFkZGVkKS4NCj4gPg0KPiA+ICAgIEJ1dCB0aGF0J3MgYSAybmQgb3JkZXIgcXVlc3Rpb24gZm9y IG1lIGF0IHRoaXMgcG9pbnQsIGJlY2F1c2UgaW4NCnRoZQ0KPiA+ICAgIGN1cnJlbnQgVEFQUyBB UEkgSSBkb24ndCBzZWUgYW55IG9idmlvdXNseSBnb29kIHNwb3QgdG8gcHV0DQpzZWxlY3Rpb24N Cj4gPiAgICBjb250cm9scyBmb3IgdGhhdCBraW5kIG9mIHR1bm5lbCBkaXNjb3Zlcnkgc2VsZWN0 aW9uLCBvciByZWFsbHkgYQ0KZ29vZA0KPiA+ICAgIHdheSB0byBleHBsYWluIHdoYXQgaXQncyBz dXBwb3NlZCB0byBkbywgaWYgSSB0cmllZCB0byBhZGQNCmNvbnRyb2xzIHRvDQo+ID4gICAgc29t ZXRoaW5nIHRoYXQncyB0aGVyZS4NCj4gPg0KPiA+ICAgIFNvbHZpbmcgdGhhdCBpcyBteSBtYWlu IG1vdGl2YXRpb24gZm9yIGJlaW5nIGhlcmUuICAoV2VsbCwgYW5kDQp0aGF0DQo+ID4gICAgdGhl IEJTRCBzb2NrZXQgQVBJIGZvciBtdWx0aWNhc3QgaXMga2luZCBvZiBhIGRpc2FzdGVyIHRvZGF5 LikNCj4gPg0KPiA+ICAgIEFueXdheSwgaWYgdGFwcyBmaW5kcyB0aGUgd2hvbGUgWUFORyBzdWdn ZXN0aW9uIHVzZWZ1bCwgSSdsbA0KcHJvYmFibHkNCj4gPiAgICBzdWdnZXN0IHNvbWUgbmV3IGV4 dGVuc2lvbnMgYWJvdXQgdGhpcywgYW5kIG1heWJlIGEgZmV3IG90aGVyDQpwb2ludHMsDQo+ID4g ICAgZXNwZWNpYWxseSBtYXliZSBhcm91bmQgdHJ5aW5nIHRvIHB1dCBpbiBhIHN0cnVjdHVyZSB0 aGF0IGNhbg0Kc3VwcG9ydA0KPiA+ICAgIHNvbWUga2luZCBvZiBzYW5lIGV4cGxpY2l0IGxheWVy aW5nLg0KPiA+DQo+ID4gICAgQnV0IEknbSBub3Qgc3VyZSBJIGNhbiBhcnRpY3VsYXRlIHRob3Nl IHN1Z2dlc3Rpb25zIGluIGEgd2F5IEknbQ0Kc3VyZSBpcw0KPiA+ICAgIG1lYW5pbmdmdWwgd2l0 aG91dCBmaXJzdCBnZXR0aW5nIGEgbW9yZSBjbGVhciBzcGVjaWZpY2F0aW9uDQpuYWlsZWQgZG93 bg0KPiA+ICAgIGFib3V0IHdoYXQncyBhY3R1YWxseSBpbiB0aGUgdGFwcyBzcGVjLiBCZWNhdXNl IHJpZ2h0IG5vdyBJJ20NCm1vc3RseQ0KPiA+ICAgIGp1c3QgY29uZnVzZWQgYWJvdXQgd2hhdCBh biBBUEkgaW1wbGVtZW50YXRpb24gd291bGQgcmVhbGx5IGxvb2sNCmxpa2UsDQo+ID4gICAgYW5k IGhvdyB5b3UgY291bGQgdGVsbCB3aGV0aGVyIGl0IG1hdGNoZXMgdGhlIHRhcHMtaW50ZXJmYWNl DQpzcGVjLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIEZyb206IEFhcm9uIEZhbGsgPGFhcm9uLmZh bGtAZ21haWwuY29tPg0KPiA+ICAgIERhdGU6IDIwMTktMDMtMDQgYXQgMTA6NTMNCj4gPiAgICBU bzogdGFwcyBXRyA8dGFwc0BpZXRmLm9yZz4NCj4gPiAgICBDYzogWmFoZWR1enphbWFuIFNhcmtl ciA8emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20+DQo+ID4gICAgU3ViamVjdDogW1Rh cHNdIGNhbGwgZm9yIGFnZW5kYSBpdGVtcyBhdCBUQVBTIElFVEYtMTA0DQo+ID4NCj4gPiAgICBI aSBBbGwtDQo+ID4gICAgV2hhdCBzaG91bGQgd2UgdXNlIG91ciB0aW1lIHRvIGRpc2N1c3M/IExl dOKAmXMgZm9jdXMgb24gdGhpbmdzDQp0aGF0IHdvdWxkIGJlbmVmaXQgZnJvbSBmMmYgZGlzY3Vz c2lvbiwgY29uc2Vuc3VzIGJ1aWxkaW5nLCBvciBqdXN0DQphcmd1bWVudC4gOikNCj4gPiAgICDi gKIgVEFQUyBkb2NzOiBhcmUgdGhlcmUgb3BlbiB0b3BpY3MgdGhhdCBuZWVkIGdyb3VwIGF0dGVu dGlvbj8NClNlZW1zIGxpa2Ugd2Ugc2V0dGxlZCBtb3N0IG9mIHRoZSByZW1haW5kZXIgYXQgdGhl IGludGVyaW0uDQo+ID4gICAg4oCiIFRBUFMgc2VjdXJpdHk6IHRoaXMgc2VlbXMgbmVhcmx5IGRv bmUuIEFueXRoaW5nIHRvIGRpc2N1c3M/DQo+ID4gICAg4oCiIEltcGxlbWVudGF0aW9uczogYSBn b29kIHRvcGljIGZvciBpbmZvcm1hdGlvbiBzaGFyaW5nIGJ1dCBsZXNzDQppbXBvcnRhbnQgdGhh biBhbnl0aGluZyBuZWVkaW5nIGFncmVlbWVudA0KPiA+ICAgIOKAoiBNb2JpbGl0eToNCmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0 Zi5vcmdfaHRtbA0KX2RyYWZ0LTJEaWV0Zi0yRGRtbS0yRG9uZGVtYW5kLTJEbW9iaWxpdHktMkQx NyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGDQo0anBONkxaZyZyPWJxbkZST2l2RG9fNGlGOFoz UjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1wTFc1Z1N5ZXRmVmVfaXgNCkc0X3U3cUtYX1Zj aklxek43SnUyQmdNMnJwUW8mcz1IVXNCVkJGX0doTmlPazNncVlfbTVxWk1ELXNQbUJKOTNHRTV3 ZDNENQ0KX3MmZT0gYW5kDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3INCmdfZG9jX3Jldmlldy0yRGlldGYtMkRk bW0tMkRvbmRlbWFuZC0yRG1vYmlsaXR5LTJEMTUtMkR0c3ZhcnQtMkRsYy0yRHdlcw0KdGVybHVu ZC0yRDIwMTktMkQwMS0yRDA4XyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1i cW5GUk9pdkRvDQpfNGlGOFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1wTFc1Z1N5ZXRm VmVfaXhHNF91N3FLWF9WY2pJcXpON0p1MkINCmdNMnJwUW8mcz0wWW1DX1hDQXU0X0dWWWRGaTBI eGlLYUtCcGFuMkNPWXFCTDFtQjZiWHJZJmU9DQo+ID4gICAgLS1hYXJvbg0KPiA+DQo+ID4NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gVGFwcyBtYWlsaW5nIGxpc3QNCj4gPiBUYXBzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRhcHMgbWFpbGluZyBsaXN0DQo+IFRhcHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQo+ DQoNCg== From nobody Thu Mar 7 11:10:46 2019 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 61B851279B1 for ; Thu, 7 Mar 2019 11:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 beSgra8ok2cL for ; Thu, 7 Mar 2019 11:10:41 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 D167A127962 for ; Thu, 7 Mar 2019 11:10:40 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x27J7WcD013746; Thu, 7 Mar 2019 19:10:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=AptJDZX4gcRndLFwMjqj4my0k8On0q/E43GygeYksT4=; b=RIwMxO9eI3ZKykXIUcaGORHAKYteTUiSxCRo0mQNy9Oorgo4N9qtTc3lAmNg/lZoFy2+ heQkXiXEqo+Yal4bpNPRR+iw8SrJlX1RHTGfp/nlXdwz2AK+ElP1+OdNsFZetJUZcXM8 /ywJR0/m67t8GGa1cDzmXBARBf0F8lDFlTNWxmvVZlng34qi3oWw7aLuiEG2Q8owut4v 9gzFulvZHZsbjd9hzt4fDhCMumDQ3XpWQJJX9x9L0hZLbwTA6eucriCMHu+UyMuN2dwd mIYLEtLd7xYLIwoBqkpkbMemfHrXahDpYVS6andH2RX43zHrHCehSAyFWtm6n6vQZs5Z Sw== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2r2wna2cpr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Mar 2019 19:10:39 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x27J2O9i016546; Thu, 7 Mar 2019 14:10:38 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2qyp232f27-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Mar 2019 14:10:36 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 13:10:30 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Thu, 7 Mar 2019 13:10:30 -0600 From: "Holland, Jake" To: taps WG CC: Michael Welzl Thread-Topic: [Taps] call for agenda items at TAPS IETF-104 Thread-Index: AQHU0ruJg/BpMSiZnkS1XjtUnIdzOKX8G+mAgAM/gYCAANNpgIAAPQgA Date: Thu, 7 Mar 2019 19:10:29 +0000 Message-ID: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.22] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070129 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 19:10:44 -0000 SGkgTWljaGFlbCwNCg0KVGhhbmtzIGZvciByZXNwb25kaW5nLCBtdWNoIGFwcHJlY2lhdGVkLiAg KEFuZCBhbHNvIHRvIFRvbW15DQphbmQgQWFyb24uKQ0KDQpCYXNlZCBvbiB0aGUgcmVwbGllcyBm cm9tIHlvdSwgVG9tbXksIGFuZCBBYXJvbiwgSSdsbCBwbGFuDQp0byBwcmVzZW50IHNvbWV0aGlu ZyBpbiBQcmFndWUsIGFuZCBjYW4geW91IHBsZWFzZSBwdXQgbWUNCm9uIHRoZSBzY2hlZHVsZSwg QWFyb24/DQoNCk1vcmUgcmVzcG9uc2VzIGlubGluZSB3aXRoIDxqaD48L2poPiwgYW5kIHRoYW5r cywgdGhlc2UNCnF1ZXN0aW9ucyB3ZXJlIHZlcnkgaGVscGZ1bCB0byBoZWxwIG1lIGZvY3VzIG9u IHdoYXQgbmVlZHMNCmV4cGxhaW5pbmcgdnMuIHdoYXQncyBvYnZpb3VzLg0KDQoNCu+7v09uIDIw MTktMDMtMDcsIDAwOjMyLCAiTWljaGFlbCBXZWx6bCIgPG1pY2hhd2VAaWZpLnVpby5ubz4gd3Jv dGU6DQoNCiAgICBIaSwNCiAgICANCiAgICBWZXJ5IHNvcnJ5IGZvciB0aGUgc2lsZW5jZS4gSSBj YW4gb25seSBzcGVhayBmb3IgbXlzZWxmLCBidXQgaGVyZSdzIGFuIGV4YW1wbGUgb2Ygd2h5IHRo aXMgb25lIHBlcnNvbiB3YXMgc2lsZW50Og0KICAgIC0gV2hlbiB5b3UgY3JlYXRlZCB5b3VyIGlz c3VlIG9uIG11bHRpY2FzdCBpbiBnaXRodWIsIEkgdGhvdWdodCBvZiBhbnN3ZXJpbmcgKHBvc2l0 aXZlbHkpLCBidXQgdGhlbiB0aG91Z2h0IHRoYXQgdGhlIHJlcG8gaXMgYWJvdXQgdG8gbW92ZSwg YW5kIGl0IHdvdWxkIHByb2JhYmx5IGJlIGJldHRlciB0byBkZWxheSB0aGluZ3MgdW50aWwgdGhl IG1vdmUgaXMgZmluaXNoZWQuDQogICAgLSBUaGVuLCB0aGUgaXNzdWUgd2FzIG92ZXJydWxlZCBi eSB5b3VyIGVtYWlsLiBJIHJlYWQgaXQgYW5kIGZvdW5kIGl0IGludGVyZXN0aW5nLCBidXQgaG9w ZWQgZm9yIHNvbWVvbmUgZWxzZSB0byBhbnN3ZXIgYmVjYXVzZSwgZnJhbmtseSwgSSB3YXMgYWZy YWlkIHRvIG1ha2UgYSBmb29sIG9mIG15c2VsZiAuLi4gYmVjYXVzZSBJIGtub3cgYWxtb3N0IG5v dGhpbmcgYWJvdXQgWUFORy4NCg0KPGpoPg0KVGhhbmtzIGZvciBleHBsYWluaW5nLCBJJ20gc3lt cGF0aGV0aWMgYW5kIGdyYXRlZnVsIHRoYXQgeW91DQpvdmVyY2FtZSB5b3VyIGNvbmNlcm5zLiAg SSB3YXMgaW4gdGhlIHNhbWUgcGxhY2Ugb24gWUFORyBub3QNCnRvbyBsb25nIGFnbywgYW5kIEkg c3RpbGwgaGF2ZSBhIHdheXMgdG8gZ28sIHRob3VnaCBJIG5vdyB0aGluaw0KSSBzZWUgc29tZSBv ZiBpdHMgcHJvbWlzZS4NCg0KQnV0IEkgZG9uJ3QgdGhpbmsgSSBjcmVhdGVkIGEgbXVsdGljYXN0 IGlzc3VlIG9uIGdpdGh1Yj8gIEkganVzdA0Kbm90aWNlZCBhIGZldyBuaXRzIHdoaWxlIHJlYWRp bmcgYW5kIHNlbnQgYSBwdWxsIHJlcXVlc3QsIG5vdGhpbmcNCnJlYWxseSBzdWJzdGFudGlhbCB5 ZXQuDQo8L2poPg0KICAgIA0KICAgIEJ1dCBub3cgSSdsbCBiZSBicmF2ZSAgOikgICBJJ2xsIGdv IGFoZWFkIGFuZCBhc2s6IGhvdyBleGFjdGx5IGlzIHRoaXMgWUFORyBwcm9wb3NhbCBtb3JlIHRo YW4ganVzdCBhIHN5bnRheCBjaGFuZ2U/ICBXaGF0IHdvdWxkIGl0IGdpdmUgdXM/DQogICAgKEkg dW5kZXJzdGFuZCB0aGF0IFlBTkcgY2FuIGJlIGF1dG9tYXRpY2FsbHkgcGFyc2VkIC8gY2hlY2tl ZCBieSBzb21lIHRvb2xzLCBidXQuLi4gd2hhdCBkb2VzIFRIQVQgZ2l2ZSB1cz8pDQoNCjxqaD4N ClN5bnRheCBwbHVzIHRvb2wgc3VwcG9ydCBpcyB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4g bWFjaGluZSBjb2RlDQphbmQgPHlvdXIgZmF2b3JpdGUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2U+LCBz byBldmVuIGlmIHRoYXQncyB0aGUgb25seQ0KdGhpbmcgd2UgZ290LCBpdCdzIG5vdCB0byBiZSBz bmVlemVkIGF0LiAgKEFuZCB0aGVyZSBpcyBhIGxvdCBvZiByb29tDQpmb3IgZ3Jvd3RoIGhlcmUs IGJ1dCB0aGVyZSBhcmUgYWxyZWFkeSB0b29scyB0aGF0IGNhbiBnZW5lcmF0ZSBBUEkNCmhlYWRl ciBjb2RlIGZyb20geWFuZywgZS5nOg0KaHR0cHM6Ly93aWtpLm9ub3Nwcm9qZWN0Lm9yZy9kaXNw bGF5L09OT1MvWUFORytUb29scyApDQoNCkJ1dCBJJ20gYWN0dWFsbHkgcHVzaGluZyBmcm9tIHRo ZSBvdGhlciBkaXJlY3Rpb247IG15IHVuZGVyc3RhbmRpbmcNCm9mIHRoZSBjdXJyZW50IGRvY3Mg aXMgdGhhdCB0YXBzLWFyY2ggaXMgYSBoaWdoIGxldmVsIGRlc2lnbiBhbmQgZ29hbHMNCmRvY3Vt ZW50LCBhbmQgdGFwcy1pbnRlcmZhY2UgKGFuZCB0YXBzLW1pbnNldCkgbWFrZSBhbiBhdHRlbXB0 IHRvDQpsYXkgb3V0IHRoZSBjb25jcmV0ZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRoYXQgd291 bGQgbWFrZSB0YXBzLWFyY2ggYQ0KcmVhbGl0eSwgaWYgYW4gaW1wbGVtZW50YXRpb24gY292ZXJz IHRoZW0uDQoNCk15IGNsYWltIGhlcmUgaXMgdHdvZm9sZDoNCi0gdGhhdCB0YXBzLWludGVyZmFj ZSBhcyBpdCBzdGFuZHMgdG9kYXkgaXMgYW5vdGhlciBoaWdoIGxldmVsIGRlc2lnbg0KICBkb2N1 bWVudCwgd2hpY2ggd2lsbCBoYXZlIGEgbmVjZXNzYXJpbHkgZnV6enkgbWFwcGluZyB0byBhbnkg YWN0dWFsDQogIGltcGxlbWVudGF0aW9uLg0KLSB0aGF0IHRhcHMtaW50ZXJmYWNlIGlzIF9yZWFs bHlfIF9jbG9zZV8gdG8gbGF5aW5nIG91dCB0aGUgY29uY3JldGUNCiAgaW1wbGVtZW50YXRpb24g ZGV0YWlscyBpbiBhIG5vbi1mdXp6eSB3YXkgdGhhdCBjYW4gYmUgZGlyZWN0bHkgdXNlZA0KICBi eSBpbXBsZW1lbnRvcnMsIHNvIEknbSBzdWdnZXN0aW5nIHRoYXQgdGFraW5nIHRoYXQgZXh0cmEg c3RlcCBpcw0KICBoaWdobHkgdmFsdWFibGUuDQoNCk9uIHRoZSBxdWVzdGlvbiBvZiBiZW5lZml0 czogIEknbGwgbGF5IG91dCBzb21lIG9mIHRoZSBvbmVzDQp0aGF0IHNlZW0gaW1wb3J0YW50IHRv IG1lLCBidXQgSSdsbCBmaXJzdCBzYXkgdGhhdCBpbiB0aGVvcnksDQp0aGVzZSBiZW5lZml0cyBj b3VsZCBiZSByZWFsaXplZCBieSBhbnkgY29uY3JldGUgY29uZmlndXJhdGlvbg0KZm9ybWF0LiBU aGUgYmVuZWZpdCBvZiBZQU5HIHNwZWNpZmljYWxseSBjb21lcyBmcm9tIHRvb2wNCnN1cHBvcnQg YW5kIHRoZSBjb25maWRlbmNlIGZyb20gZXhpc3Rpbmcgd29yayB0aGF0IG1ha2UgaXQgY2xlYXIN Cml0J3MgYSByZWFzb25hYmxlIGZvcm1hdCBmb3IgbmV0d29ya2luZyBjb25maWd1cmF0aW9uLg0K DQpCYXNpY2FsbHksIGJlY2F1c2UgdGhlcmUncyBzbyBtdWNoIFlBTkcgd29yayBhbHJlYWR5IGRv bmUgZm9yDQpuZXR3b3JraW5nLCB1c2luZyBZQU5HIGxldHMgdXMgbGV2ZXJhZ2Ugc29tZSBvZiB0 aGF0IHdvcmsgaW4gYSB3YXkNCm90aGVyIG9wdGlvbnMgZG9uJ3QuDQoNCkluIHBhcnRpY3VsYXIs IHRoZXJlIGFyZSBhIGJ1bmNoIG9mIG5ldHdvcmtpbmctc3BlY2lmaWMgY29uY2VwdHMNCnRoYXQg YXJlIGFscmVhZHkgZGVmaW5lZCBpbiBkZXRhaWwuIEZvciBleGFtcGxlLCB0aGUgaXB2Ni1hZGRy ZXNzDQp0eXBlIGhhcyBhIGNvbXBsaWNhdGVkIHJlZ2V4IHRoYXQgbWFueSBpbXBsZW1lbnRvcnMg YXJlIGxpa2VseSB0bw0KZ2V0IHdyb25nIGlmIHRoZXkgdHJ5IHRvIHJvbGwgdGhlaXIgb3duIChh dCBsZWFzdCwgSSd2ZSBjZXJ0YWlubHkNCmRvbmUgc28sIGFuZCBzZWVuIGl0IGEgYnVuY2ggb2Yg dGltZXMpOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5OTEjcGFnZS0xOQ0KDQpC dXQgYnkgbWFraW5nIHRoZSBvYnZpb3VzIGNob2ljZSBvZiB1c2luZyB5YW5nIHRvb2xzIHRvIHBh cnNlIHlhbmcNCnN0dWZmLCBpbXBsZW1lbnRvcnMgYXV0b21hdGljYWxseSBnZXQgY2hlY2tpbmcg YWdhaW5zdCB0aGF0IA0KKG5vcm1hdGl2ZSEpIHJlZ2V4IGZvciBmcmVlIHdpdGhvdXQgaGF2aW5n IHRvIG5vdGljZSBhbmQgY2hlY2sgaXQNCnRoZW1zZWx2ZXMuDQoNClRoZXJlJ3Mgb3RoZXIgc2lk ZSBiZW5lZml0cywgbGlrZSB0aGF0IGludGVyZmFjZXMgYXJlIHRoZW1zZWx2ZXMNCmV4cGxpY2l0 bHkgZGVmaW5lZCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgzNDMjc2VjdGlvbi01 KSwNCmFuZCBzbyB3aGVyZSB0aGluZ3MgbGlrZSBpbnRlcmZhY2UgdHlwZXMgbWlnaHQgYmUgdXNl ZCwgdGhlIHBhc3QNCmFuZCBmdXR1cmUgd29yayBvZiBwZW9wbGUgd2hvIGZvcm1hbGl6ZSBhbmQg ZXh0ZW5kIHRoZSBzZXQgb2YNCmludGVyZmFjZSB0eXBlcyBnZXRzIGF1dG9tYXRpY2FsbHkgaW1w b3J0ZWQgYnkgcmVmZXJlbmNpbmcgdGhlDQpub3JtYXRpdmUgeWFuZyBkZWZpbml0aW9uIGZvciBu ZXR3b3JrIGludGVyZmFjZXMuDQoNCkJ1dCB0byBsaXN0IGEgZmV3IG9mIHRoZSBzcGVjaWZpYyBi ZW5lZml0cyBmcm9tIGhhdmluZyBhbiBleHBsaWNpdA0KY29uZmlnIGZvcm1hdDoNCg0KLSBjcm9z cy1wbGF0Zm9ybSBwb3J0YWJpbGl0eToNCklmIEkndmUgZ290IGEgcHJvZ3JhbSB1c2luZyBhIHRh cHMgYXBpIHRoYXQgdGFsa3MgdG8gc29tZSBzZXJ2aWNlLA0KYW5kIG5vdyBJIHdhbnQgdG8gd3Jp dGUgYSBuZXcgcHJvZ3JhbSBpbiBhIGRpZmZlcmVudCBsYW5ndWFnZSB0byB0YWxrDQp0byB0aGF0 IHNlcnZpY2UsIEkgY2FuIGV4cG9ydCB0aGUgY29uZmlnIGFuZCBsb2FkIGl0IGluIG15IG5ldw0K cHJvZ3JhbSAoZXZlbiBpbiBhIG5ldyBsYW5ndWFnZSksIGFuZCBJIGNhbiBiZSByZWFzb25hYmx5 IHN1cmUNCml0J2xsIGZvcm0gdGhlIHNhbWUga2luZCBvZiBjb25uZWN0aW9uLg0KDQpBbHRob3Vn aCBpdCdzIHBvc3NpYmxlIHRvIG1ha2UgaXQgd29yayBhbnl3YXkgYXMgbG9uZyBhcyB0aGUgQVBJ cw0KaGF2ZSBhIDEtdG8tMSBtYXBwaW5nLCBub3JtYWxpemluZyBvbiBhIGNvbmZpZyBmaWxlIGZv cm1hdCBpbnN0ZWFkDQpvZiBhIGxpc3Qgb2YgZmVhdHVyZXMgc2VlbXMgdG8gbWUgbGlrZSBpdCds bCBzYXZlIG1lIHBlcmhhcHMgdXAgdG8gYQ0KZGF5IG9yIHNvIG9mIGVmZm9ydCBlYWNoIHRpbWUg SSBoYXZlIHRvIGRvIHRoaXMsIHdoaWNoIHdoZW4gbXVsdGlwbGllZA0KYnkgYWxsIHRoZSBpbXBs ZW1lbnRvcnMgaW4gdGhlIHdvcmxkIG92ZXIgdGhlIG5leHQgZGVjYWRlIG9yIDIsIHN0YXJ0cw0K dG8gYWRkIHVwLg0KDQotIHRlc3RhYmlsaXR5Og0KQWdhaW4sIHRoaXMgbW9zdGx5IHNhdmVzIHRp bWUsIGJ1dCBieSBoYXZpbmcgYSBkZWZpbmVkIGlucHV0IGZvcm1hdCwNCml0J3MgcG9zc2libGUg Zm9yIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgdG8gdXNlIHRoZSBzYW1lIHN1aXRlIG9mDQp0 ZXN0IGNvbmZpZ3VyYXRpb24gZmlsZXMgdG8gdmVyaWZ5IHRoZSBzYW1lIGludGVycHJldGF0aW9u IG9mIHRoZWlyDQpjb250ZW50cy4gIElmIGVhY2ggaW1wbGVtZW50YXRpb24gaGFzIGl0cyBvd24g d2F5IG9mIGNvbmZpZ3VyaW5nIHRoZQ0KZmVhdHVyZXMsIGl0J3Mgbm90IGltcG9zc2libGUgdG8g ZGVzaWduIGEgc3VpdGUgdGhhdCBjYW4gdGVzdCB0aGVtLA0KYnV0IGl0J3MgdmFzdGx5IGhhcmRl ci4NCg0KLSBjb21wbGV0ZW5lc3M6DQpPbmUgb2YgdGhlIHBvaW50cyBvZiBjb25mdXNpb24gSSBo YWQgd2l0aCB0YXBzLWludGVyZmFjZSB3YXMgdGhhdCB0aGUNCkxvY2FsL1JlbW90ZUVuZHBvaW50 cyBzZWVtZWQgYm90aCBjcml0aWNhbCB0byBhbiBpbXBsZW1lbnRhdGlvbiBhbmQNCnZlcnkgdW5k ZXJzcGVjaWZpZWQuICBBbHRob3VnaCBpdCdzIHBvc3NpYmxlIHRvIGFkZHJlc3MgdGhhdCBieSBy YWlzaW5nDQpjb25jZXJucyBzcGVjaWZpY2FsbHkgYWJvdXQgdGhlIExvY2FsL1JlbW90ZSBFbmRw b2ludHMsIEknbSBub3Qgc3VyZQ0KdGhlcmUgYXJlbid0IG90aGVyIHVuZGVyc3BlY2lmaWVkIGFy ZWFzIG9mIHRoZSB0YXBzLWludGVyZmFjZSBkcmFmdC4NCg0KSSBleHBlY3QgdGhhdCBhIHJlZmVy ZW5jZSBpbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiBwYXJzaW5nIGEgY29uZmlnDQpmb3JtYXQgd291 bGQgdW5jb3ZlciBhbGwgc3VjaCB1bmRlcnNwZWNpZmllZCBhcmVhcyBvZiBjb25maWd1cmF0aW9u LA0KaWYgdGhlIGNvbmZpZyBmb3JtYXQgZXhhbXBsZXMgYXJlIHVzZWQgdG8gZGVzY3JpYmUgYWxs IHRoZSBzdXBwb3J0ZWQNCnVzZSBjYXNlcy4NCg0KKFNvIHBhcnQgb2YgbXkgZ29hbCB3aXRoIHRo aXMgcHJvcG9zYWwgaXMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGluDQp0aGUgZ2VuZXJhbCBjYXNl LCB3aGljaCBpbXBsaWVzIHRoYXQgaXQnbGwgYWxzbyBiZSBzb2x2ZWQgZm9yIHRoZQ0Kc3BlY2lm aWMgY2FzZXMgb2YgTG9jYWwvUmVtb3RlIEVuZHBvaW50cywgdGhvdWdoIG9mIGNvdXJzZSB0aGUN CmRldGFpbHMgZm9yIGVhY2ggaW5zdGFuY2Ugb2YgaW5jb21wbGV0ZW5lc3MgYXJlIHNlcGFyYXRl IHRvcGljcy4pDQoNClRoZXJlIG1pZ2h0IGJlIHNvbWUgb3RoZXIgYmVuZWZpdHMsIGJ1dCBJJ2xs IHN0b3AgdGhlcmUsIGhvcGluZyB0aGUNCnBvaW50IGlzIHN1ZmZpY2llbnRseSBjbGVhci4NCjwv amg+DQogICAgDQogICAgQWxzbywgSSBhY3R1YWxseSBzZWUgMyBzZXBhcmFibGUgdGhpbmdzIGJl aW5nIHByb3Bvc2VkIGhlcmU6DQogICAgDQogICAgMSkgdGhlIFlBTkcgbW9kZWwNCjxqaD4NCkkn ZCBwaHJhc2UgdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBwcm9wb3NhbCBhcyBhbiBpbi1wcmlu Y2lwbGUNCiJ1c2UgYSBZQU5HIG1vZGVsIiwgcmF0aGVyIHRoYW4gInVzZSB0aGlzIHNwZWNpZmlj IFlBTkcgbW9kZWwiLg0KDQpUaGUgY3VycmVudCBkcmFmdCBpcyBraW5kIG9mIGEgdGhyb3ctYXdh eSBleGFtcGxlIHByb29mIG9mIGNvbmNlcHQsDQp3aGljaCBpcyBjZXJ0YWlubHkgdmVyeSBpbmNv bXBsZXRlLCBhbmQgc29tZSBvZiBteSByZWFkaW5nIHllc3RlcmRheQ0Kc3VnZ2VzdHMgdGhhdCBp dCdzIGFjdHVhbGx5IG5vdCB2ZXJ5IHdlbGwgc3RydWN0dXJlZCBlaXRoZXIuICBJJ3ZlDQpwcm9i YWJseSBhbHJlYWR5IG1hZGUgYSBmb29sIG9mIG15c2VsZiB0byBhbnkgYWN0dWFsIFlBTkcgZXhw ZXJ0cywNCnRoYXQgZXZlciB0cnkgdG8gcmVhZCBpdCwgYnV0IHN1Y2ggYXJlIHRoZSByaXNrcyBv ZiBwb3N0aW5nIHB1YmxpYw0KY29tbWVudHMuLi4gOikNCjwvamg+DQogICAgDQogICAgMikgbXVs dGljYXN0IHN1cHBvcnQgIChJIGZpbmQgeW91ciBjb25jbHVzaW9uIHRoYXQgbm90IG11Y2ggbmVl ZHMgdG8gY2hhbmdlIGludGVyZXN0aW5nISAgVGhvdWdoIHRoZSBleGFtcGxlIHlvdSdyZSBnaXZp bmcgKGpvaW5pbmcgYW4gU1NNIGNoYW5uZWwpIGlzIG9ubHkgYSBwYXJ0IG9mIHdoYXQgd2UnZCBu ZWVkLCBhcyB5b3UgYWxzbyBzYXkuLi4pDQo8amg+DQpGYWlyIHBvaW50LCB0aGlzIHJlYWxseSBp cyBhIHNlcGFyYXRlIHRvcGljLiAgSSBicm91Z2h0IGl0IHVwDQpyZWFsbHkgb25seSBiZWNhdXNl IGl0J3MgYSBtb3RpdmF0aW5nIGZhY3RvciBpbiBteSBwYXJ0aWNpcGF0aW9uDQpoZXJlLCBub3Qg YmVjYXVzZSBpdCdzIGEgcHJpbWFyeSBmYWN0b3IgZm9yIHRhcHMgaW4gZ2VuZXJhbC4gIExldCdz DQpkcm9wIGl0IGZvciB0aGlzIHRocmVhZCwgYW5kIEknbGwgcGxhbiB0byByYWlzZSBpdCBhcyBh IHNlcGFyYXRlDQppc3N1ZSB3aGVuIHRoZSB5YW5nIHF1ZXN0aW9ucyBhcmUgc2V0dGxlZCBhbmQg SSd2ZSBnb3Qgc29tZXRoaW5nDQptb3JlIHRob3VnaHQgb3V0Lg0KPC9qaD4NCiAgICANCiAgICAz KSBhcHBseWluZyBwcmVmZXJlbmNlcyB0byBhZGRyZXNzZXMgYW5kIHBvcnQgbnVtYmVycyAgKHdo aWNoIHlvdSBzZWVtIHRvIHRha2UgZm9yIGdyYW50ZWQgaW4geW91ciBkcmFmdCwgYnV0IHdoaWNo IEkgZG9uJ3QgdGhpbmsgaXMgc3VwcG9ydGVkIGJ5IG91ciBjdXJyZW50IGRvY3VtZW50KS4NCg0K PGpoPg0KWWVzLCB0aGlzIGlzIGEgY2FzZSBpbiBwb2ludCBmb3IgbXkgY29uY2VybnMgYWJvdXQg aW5jb21wbGV0ZW5lc3MNCm9uIHRoZSBFbmRwb2ludCBzcGVjaWZpY2F0aW9ucy4NCg0KSSB3YXNu J3Qgc3VyZSBob3cgdG8gdHJlYXQgdGhpcywgc28gSSdtIG5vdCBzdXJwcmlzZWQgaWYgSSBnb3Qg aXQNCndyb25nLiAgSSB3YXMgc29ydCBvZiBwYXR0ZXJuLW1hdGNoaW5nIG9uIHRoZSByZXN0IG9m IHdoYXQgdGhlIHNwZWMNCmRvZXMsIHBsdXMgZ3Vlc3NpbmcgYXQgaW50ZW5kZWQgbWVhbmluZ3Mg b2YgdGhpcyBwYXJhZ3JhcGggZnJvbQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdGFwcy1pbnRlcmZhY2UtMDIjc2VjdGlvbi01LjE6DQoNCiAgIE11bHRpcGxlIGVuZHBv aW50IGlkZW50aWZpZXJzIGNhbiBiZSBzcGVjaWZpZWQgZm9yIGVhY2ggTG9jYWwNCiAgIEVuZHBv aW50IGFuZCBSZW1vdGUgRW5kcG9pbnQuICBGb3IgZXhhbXBsZSwgYSBMb2NhbCBFbmRwb2ludCBj b3VsZCBiZQ0KICAgY29uZmlndXJlZCB3aXRoIHR3byBpbnRlcmZhY2UgbmFtZXMsIG9yIGEgUmVt b3RlIEVuZHBvaW50IGNvdWxkIGJlDQogICBzcGVjaWZpZWQgdmlhIGJvdGggSVB2NCBhbmQgSVB2 NiBhZGRyZXNzZXMuICBUaGVzZSBtdWx0aXBsZQ0KICAgaWRlbnRpZmllcnMgcmVmZXIgdG8gdGhl IHNhbWUgdHJhbnNwb3J0IGVuZHBvaW50Lg0KDQpCeSB0aGUgdGltZSBJIGZpbmlzaGVkIG1ha2lu ZyB0aGUgZXhhbXBsZXMsIEkgaGFkIG5vdGljZWQgSSB3YXMNCm1heWJlIGRvaW5nIGl0IHdyb25n LCBidXQgSSBkaWRuJ3Qgd2FudCB0byBib3RoZXIgZml4aW5nIGl0IHVubGVzcw0KcGVvcGxlIGFn cmVlIGl0J3Mgd29ydGggc3BlbmRpbmcgZWZmb3J0IGluIHRoaXMgZ2VuZXJhbCBkaXJlY3Rpb24s IGFuZA0KSSBkaWRuJ3Qgd2FudCB0byBob2xkIG9mZiBvbiBvcGVuaW5nIHRoZSBkaXNjdXNzaW9u LiAgT2YgY291cnNlLCBpdA0Kc2hvdWxkIGJlIGNoYW5nZWQgdG8gbWF0Y2ggdGhlIGNvbnNlbnN1 cyBvZiB0aGUgd2cgb24gd2hhdCBiZWxvbmdzDQpoZXJlLg0KPC9qaD4NCg0KICAgIFNpZGUgbm90 ZTogdW5sZXNzIEknbSBtaXN0YWtlbiwgdGhpcyB3b3VsZG4ndCBmaXQgb3VyIHN0cnVjdHVyZSB3 ZWxsOiBlLmcuIGEgcG9ydCBudW1iZXIgd291bGQgdGhlbiBiZSBhIFRyYW5zcG9ydCBQcm9wZXJ0 eSB0aGF0IGhhcyBhIGNlcnRhaW4gdmFsdWUsIGJ1dCBhbHNvIGhhcyBhIHByZWZlcmVuY2UsIGJ1 dCBjdXJyZW50bHkgd2Ugc2F5IHRoYXQgYSBUcmFuc3BvcnQgUHJvcGVydHkgaGFzICJvbmUgb2Yg YSBzZXQgb2YgZGF0YSB0eXBlcyIsIG9uZSBvZiB3aGljaCBpcyBhIFByZWZlcmVuY2UuIElzbid0 IHRoYXQgc3RydWN0dXJlIHRvbyBsaW1pdGluZz8gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8N Cg0KPGpoPg0KSSdtIG5vdCBzdXJlLiAgVGhpcyBpcyBwYXJ0IG9mIHdoYXQgSSBtZWFuIHdoZW4g SSBzYXkgSSBmaW5kIHRoZQ0KY3VycmVudCB0YXBzLWludGVyZmFjZSBhIGxpdHRsZSB0b28gbG9v c2UuICBJIF90aGlua18gd2hhdCBJIHBvc3RlZA0KaXMgYSB2YWxpZCAodGhvdWdoIHBlcmhhcHMg bm90IG9wdGltYWwpIGludGVycHJldGF0aW9uIG9mIHRoZSBjdXJyZW50DQp0ZXh0LiAgSSBtaWdo dCBiZSB3cm9uZyBhYm91dCB0aGF0LCBzbyBJJ2QgYmUgZ3JhdGVmdWwgZm9yIGEgcG9pbnRlcg0K dG8gdGhlIHRleHQgdGhhdCBwcm9oaWJpdHMgdGhpcyBpbnRlcnByZXRhdGlvbi4NCg0KQnV0IHJl YWxseSwgdGhhdCdzIGJlc2lkZSB0aGUgcG9pbnQuICBJJ2QgYmUgZXZlbiBtb3JlIGdyYXRlZnVs IGZvciBhbg0KYWx0ZXJuYXRlIHByb3Bvc2FsIHRoYXQgbW9yZSBjbG9zZWx5IG1hdGNoZXMgdGhl IGludGVuZGVkIGRlc2lnbiBmb3INCmEgdGFwcyBBUEksIHdpdGggdGhlIHNhbWUgbGV2ZWwgb2Yg Y29uY3JldGVuZXNzLg0KPC9qaD4NCiAgICANCiAgICBJIGd1ZXNzIHRoYXQgMikgbmVlZHMgMyks IGJ1dCBwZXJoYXBzIGl0J3MgdXNlZnVsIHRvIHNlZSAyKSBhbmQgMykgYXMgc2VwYXJhdGUuLi4g bWF5YmUgdGhlcmUgYXJlIG90aGVyIHVzZSBjYXNlcyBmb3IgMykgYWxvbmUgPw0KDQo8amg+DQpZ ZXMsIEkgdGhpbmsgc28uICBJIHRoaW5rIEkgdW5kZXJzdGFuZCBhbiB1bHRpbWF0ZSBnb2FsIGZv ciB0YXBzIHRvDQpiZSAiYXMgYW4gYXBwIGRlc2lnbmVyLCBkb24ndCB3b3JyeSBhYm91dCB3aGlj aCB0cmFuc3BvcnQsIGp1c3QNCnNlbmQgdGhlIG1hZ2ljIEFQSSB0byBnbyBkaXNjb3ZlciBvbmUg dGhhdCB3b3JrcyIuDQoNCkhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lIGluIHRoZSBpbnRlcmltIHRo YXQgaXQnbGwgYmUgbmVjZXNzYXJ5DQp0byBzcGVjaWZ5IHBvcnQgbnVtYmVycyBpbiBvcmRlciB0 byBpbnRlcm9wZXJhdGUgd2l0aCBhIGxvdCBvZg0KZXhpc3Rpbmcgc2VydmljZXMsIGVzcGVjaWFs bHkgaW4gY2FzZXMgbGlrZSBSVFAgKG9yIGEgbG90IG9mDQpvdGhlciBnZW5lcmFsaXplZCBVRFAg c3R1ZmYpLCB3aGVyZSB0aGVyZSdzIG5vdCBhbiBleHBsaWNpdA0Kc2VydmljZS10by1wb3J0IG1h cHBpbmcuIChBbHNvIHRvIGludGVyb3BlcmF0ZSB3aXRoIGEgbG90IG9mDQpvdGhlciBkZXBsb3ll ZCBzeXN0ZW1zIGxpa2UgZmlyZXdhbGxzLikNCg0KSSBoYXZlIGEgZmV3IG5lYnVsb3VzIGlkZWFz IGFib3V0IGhvdyBleHBsaWNpdCBsYXllcmluZyBtaWdodCBiZSBhDQpnb29kIHdheSB0byBzb2x2 ZSB0aGlzLCBidXQgSSB0aGluayBpbiBvcmRlciB0byBtYWtlIHRoZSBpZGVhcyBzaGFycA0KZW5v dWdoIHRvIGV2YWx1YXRlLCBJIHRob3VnaHQgSSdkIGZpcnN0IHRyeSB0aGUgZWFzaWVyIHRhc2sg b2YgbWFraW5nDQp0YXBzIHNoYXJwIGVub3VnaCB0aGF0IEkgY2FuIGV4cHJlc3MgdGhlIGlkZWFz IGFzIHByb3Bvc2VkIGNoYW5nZXMNCnRvIGFuIGV4aXN0aW5nIHdlbGwtZm9ybWVkIGNvbmNlcHQu DQo8L2poPg0KDQogICAgSU1PLCBhbGwgb2YgdGhlc2UgdGhpbmdzIGFyZSBpbnRlcmVzdGluZywg YW5kIHdvdWxkIGJlIGdvb2QgdG8gZGlzY3VzcyBvbiBzaXRlLiBIb3dldmVyLCBJIGRvdWJ0IHRo YXQgd2UgY2FuIGRlYWwgd2l0aCB0aGVtIGFsbCBpbiBvbmx5IDE1IG1pbnV0ZXMgIDotKQ0KDQo8 amg+DQpGYWlyIHBvaW50Lg0KDQpJIHByb3Bvc2UgZHVyaW5nIHRoZSB0YXBzIG1lZXRpbmcgdG8g Y2hlY2sgcHJlbGltaW5hcnkgY29uc2Vuc3VzIGFib3V0DQptb3ZpbmcgZm9yd2FyZCB3aXRoIGEg WUFORyBtb2RlbCB3aXRoaW4gdGFwcywgYW5kIGlmIHNvIHdoZXRoZXIgdG8NCmludGVncmF0ZSwg cmVwbGFjZSwgb3IgbWFrZSBhIHBhaXJlZCBkb2Mgd2l0aCB0aGUgZXhpc3RpbmcgdGFwcy1pbnRl cmZhY2UuDQpTZXBhcmF0ZWx5LCBJJ2xsIGVuY291cmFnZSB0aG9zZSBpbnRlcmVzdGVkIGFuZCBh dmFpbGFibGUgdG8gc3BlbmQgc29tZQ0KdGltZSBpbiBvZmZsaW5lIGNsYXJpZnlpbmcgZGlzY3Vz c2lvbiBkdXJpbmcgdGhlIHdlZWsgcHJpb3IuDQoNCkNoZWVycywNCkpha2UNCjwvamg+DQogICAg DQogICAgQ2hlZXJzLA0KICAgIE1pY2hhZWwNCiAgICANCiAgICBQUzogVHJhdmlzIGlzIGRvd24s IG9yIHNvbWV0aGluZy4gQXQgbGVhc3QgdGhlICJFZGl0b3IncyBDb3B5IiBsaW5rcyBkb24ndCBj dXJyZW50bHkgd29yay4NCiAgICANCiAgICANCiAgICANCiAgICA+IE9uIDcgTWFyIDIwMTksIGF0 IDA0OjU1LCBIb2xsYW5kLCBKYWtlIDxqaG9sbGFuZEBha2FtYWkuY29tPiB3cm90ZToNCiAgICA+ IA0KICAgID4gSGkgdGFwcywNCiAgICA+IA0KICAgID4gKFRyeWluZyBhZ2FpbiwgYnV0IHNpbXBs ZXIuKQ0KICAgID4gDQogICAgPiBJJ20gbG9va2luZyBmb3IgYSBjb25zZW5zdXMgeWVzIG9yIG5v IGFuc3dlcjoNCiAgICA+IA0KICAgID4gSXMgYSBub3JtYXRpdmUgY29uZmlnIGlucHV0IGZvcm1h dCBhbiBpbnRlcmVzdGluZyBhbmQgdXNlZnVsDQogICAgPiBkaXJlY3Rpb24/DQogICAgPiANCiAg ICA+IA0KICAgID4gVGhlIGlkZWEgaXMgdG8gYWRkIGZ1bmN0aW9uYWxpdHkgbGlrZSB0aGlzLCBp biB0YXBzLWludGVyZmFjZToNCiAgICA+IA0KICAgID4gIG5ld1ByZSA9IFByZUNvbm5lY3Rpb24u TmV3RnJvbUpzb24oJycnew0KICAgID4gICAgInJlbW90ZS1lbmRwb2ludCI6ew0KICAgID4gICAg ICAiaG9zdHMiOlsNCiAgICA+ICAgICAgICB7ICJob3N0IjoiZXhhbXBsZS5jb20iIH0NCiAgICA+ ICAgICAgXQ0KICAgID4gICAgfQ0KICAgID4gIH0nJycpDQogICAgPiANCiAgICA+IFdpdGggYSBm dWxseSBzcGVjaWZpZWQganNvbiBpbnB1dCBmb3JtYXQgdGhhdCBjYW4gcHJvdmlkZSBhbGwgdGhl DQogICAgPiBjb25maWd1cmFibGUgdmFsdWVzLg0KICAgID4gDQogICAgPiANCiAgICA+IElmIG5v LCBJJ2xsIG1vdmUgb24gYW5kIGFzc3VtZSBJIGp1c3QgZG9uJ3QgdW5kZXJzdGFuZCB0YXBzIGdv YWxzLg0KICAgID4gDQogICAgPiBJZiB5ZXMsIEknZCBsaWtlIDE1IG1pbnV0ZXMgdG8gZGlzY3Vz cyBpbiBQcmFndWUsIGFuZCBrZWVwIHJlYWRpbmc6DQogICAgPiANCiAgICA+IEkgdGhpbmsgYSBm dWxsIGRlZmluaXRpb24gb2YgYW4gaW5wdXQganNvbiBmb3JtYXQgY2FuIGJlIGV4YWN0bHkNCiAg ICA+IHNwZWNpZmllZCBieSBhIFlBTkcgbW9kZWwuIChXaXRoIHhtbCBmb3IgZnJlZSwgaWYgeW91 IHdhbnQgaXQuKQ0KICAgID4gDQogICAgPiBJIHRyaWVkIHRvIHNrZXRjaCBhIHN0YXJ0IGF0IHdo YXQgYSBZQU5HIG1vZGVsIGZvciB0aGlzIG1pZ2h0IGxvb2sgbGlrZToNCiAgICA+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaG9sbGFuZC10YXBzLWFwaS15YW5nLTAwI3NlY3Rp b24tMw0KICAgID4gDQogICAgPiBJJ20gbm90IGEgWUFORyBleHBlcnQgeWV0LCBhbmQgaXQncyBu b3QgbXVjaCBvZiBhIG1vZGVsLiAgQW5kIGl0J3MgdmVyeQ0KICAgID4gZmFyIGZyb20gY29tcGxl dGUuICBCdXQgaXQgY29tcGlsZXMsIGFuZCBhbGwgdGhlIGV4YW1wbGVzIGluIHRoZSBkcmFmdA0K ICAgID4gdmFsaWRhdGUgYWdhaW5zdCB0aGF0IG1vZGVsIHdpdGggbGlieWFuZy4gIElmIGl0J3Mg d29ydGh3aGlsZSwgSSB0aGluaw0KICAgID4gc29tZXRoaW5nIGxpa2UgdGhpcyBjYW4gYmUgZ29v ZCAoYW5kIGV4dGVuc2libGUhKSwgaWYgZG9uZSByaWdodC4NCiAgICA+IA0KICAgID4gSSBiZWxp ZXZlIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5lcyB3b3VsZCBzaGFycGVuIHVwIHRhcHMtaW50 ZXJmYWNlDQogICAgPiBhIGxvdC4gKEFmdGVyIGZpbGxpbmcgaW4gYWxsIHRoZSB0YXBzLWludGVy ZmFjZSBwcm9wZXJ0aWVzLikNCiAgICA+IA0KICAgID4gDQogICAgPiBUaGUgcmVhc29uIEknbSBh c2tpbmcgaXMgYmVjYXVzZSByaWdodCBub3csIHRhcHMtaW50ZXJmYWNlIHRvIG1lDQogICAgPiBz ZWVtcyBfYWxtb3N0XyByZWFsbHkgZ29vZCwgZXhjZXB0IHRvbyBjb25mdXNpbmcgYW5kIHZhZ3Vl IHRvIGFjdHVhbGx5DQogICAgPiBidWlsZCBhbiBBUEkgdGhhdCBjYW4gcmVwbGFjZSBCU0Qgc29j a2V0cy4gIEkgdGhpbmsgd2l0aCBhIHNvbGlkIGNvbmZpZw0KICAgID4gZm9ybWF0IHdpdGggbm9y bWF0aXZlIGFuZCB0ZXN0YWJsZSBleGFtcGxlcywgdGhhdCBjb3VsZCBiZSBmaXhlZC4NCiAgICA+ IA0KICAgID4gSWYgY29uc2Vuc3VzIHNheXMgImludGVyZXN0aW5nIiwgSSdsbCB3YW50IDE1IG1p bnV0ZXMgdG8gZGlzY3VzcyBpdCwgYW5kDQogICAgPiB0byBzdGFydCBkaWdnaW5nIGludG8gaG93 IHRvIG1ha2UgaXQgZ29vZC4gIChBbmQgYWxzbyB0byBhZGQgbXVsdGljYXN0DQogICAgPiBzdXBw b3J0IHRvIHRoZSBtb2RlbCBhbmQgYXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uLikNCiAgICA+ IA0KICAgID4gVGhhbmtzIGZvciB5b3VyIGNvbnNpZGVyYXRpb24uDQogICAgPiANCiAgICA+IA0K ICAgID4gQ2hlZXJzLA0KICAgID4gSmFrZQ0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4g T24gMjAxOS0wMy0wNCwgMTc6MTksICJIb2xsYW5kLCBKYWtlIiA8amhvbGxhbmRAYWthbWFpLmNv bT4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgIEhpIHRhcHMgZm9sa3MsDQogICAgPiANCiAgICA+ ICAgIFRMO0RSOiBJIHRoaW5rIHRoZSBzcGVjIHNob3VsZCBoYXZlIGEgWUFORyBtb2RlbCBhbmQg SSB3YW50IHRvIHVzZSBpdA0KICAgID4gICAgdG8gZ2V0IG11bHRpY2FzdCBzdXBwb3J0IGluIGFu IGltcGxlbWVudGF0aW9uLg0KICAgID4gDQogICAgPiANCiAgICA+ICAgIEkgcmVjZW50bHkgc3Rh cnRlZCBkaWdnaW5nIGludG8gdGhlIHRhcHMgQVBJIHdpdGggdGhlIGludGVudCBvZiBhZGRpbmcN CiAgICA+ICAgIG11bHRpY2FzdCBzdXBwb3J0LCBidXQgaXQgbG9va3MgbGlrZSBpdCdzIGJhc2lj YWxseSBhbHJlYWR5IHRoZXJlLCBhcw0KICAgID4gICAgZmFyIGFzIGl0IGdvZXNbKl0uDQogICAg PiANCiAgICA+ICAgIEJ1dCBJIGVuZGVkIHVwIHdpdGggYSBoaWdoZXItbGV2ZWwgY29tbWVudCwg c28gSSB0aG91Z2h0IEknZCByYWlzZSBpdA0KICAgID4gICAgdG8gdGhlIHdnIGFuZCBhc2sgd2hh dCB5b3UgYWxsIHRoaW5rLg0KICAgID4gDQogICAgPiAgICBJIGZvdW5kIHRoZSB3aG9sZSAiYWJz dHJhY3QgaW50ZXJmYWNlIiBhcHByb2FjaCBhIGxpdHRsZSB0b28NCiAgICA+ICAgIGxvb3NleS1n b29zZXksIHNvIEkgdGhvdWdodCBJJ2QgdHJ5IHRvIHN1Z2dlc3QgYSB3YXkgdG8gdGlnaHRlbiBp dCB1cC4NCiAgICA+IA0KICAgID4gICAgTXkgZ29hbCB3aXRoIHRoaXMgaXMgdG8gbWFrZSBpdCBt dWNoIG1vcmUgY2xlYXIgKHRvIHRoZSBwb2ludCBvZiBiZWluZw0KICAgID4gICAgbWVjaGFuaWNh bGx5IGNoZWNrYWJsZSkgcHJlY2lzZWx5IHdoYXQgYSBjb21wbGlhbnQgQVBJIHByb3ZpZGVzLg0K ICAgID4gDQogICAgPiAgICBJJ20gbm90IGF0dGFjaGVkIHRvIHRoZSBzdHJ1Y3R1cmUgSSdtIHBy b3Bvc2luZyBvciB0byBhbnkgb2YgdGhlDQogICAgPiAgICBwYXJ0aWN1bGFycyBpbiB0aGUgc3Ry YXctbWFuIEkndmUgcG9zdGVkLCBidXQgaWYgaXQncyBub3QgdGlnaHRlbmVkIHVwDQogICAgPiAg ICB3aXRoIHNvbWV0aGluZyBhdCBhIHNpbWlsYXIgbGV2ZWwgb2YgY29uY3JldGVuZXNzLCBJJ20g Y29uY2VybmVkIHRoYXQNCiAgICA+ICAgIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBi ZSBub3Qgb25seSBpbmNvbXBhdGlibGUgaW4gcmFuZG9tDQogICAgPiAgICB1bmRlcnNwZWNpZmll ZCBjb3JuZXIgY2FzZXMgKGxpa2UgQlNEIHNvY2tldHMgdG9kYXkgd2hlbiB5b3UgdHJ5IHRvIG1h a2UNCiAgICA+ICAgIGNyb3NzLXBsYXRmb3JtIEMgY29kZSksIGJ1dCBhbHNvIGFyZSBsaWtlbHkg dG8gZW5kIHVwIHdpdGggdmVyeSBtYW55DQogICAgPiAgICBpbXBvcnRhbnQgZGlmZmVyZW5jZXMg dGhhdCB3b3VsZCBtYWtlIHRoZSB3aG9sZSB0YXBzIGVmZm9ydCBtb3JlIG9yIGxlc3MNCiAgICA+ ICAgIG1vb3QuDQogICAgPiANCiAgICA+ICAgIEluIGEgd29ybGQgd2hlcmUgd2UgZW5kIHVwIHdp dGggYSBkb2MgYXQgdGhlIGxldmVsIG9mIGFic3RyYWN0aW9uIEknbQ0KICAgID4gICAgY3VycmVu dGx5IHNlZWluZyBpbiBkcmFmdC10YXBzLWludGVyZmFjZSwgaXQgc2VlbXMgdG8gbWUgdGhhdCBp ZiAyDQogICAgPiAgICBkaWZmZXJlbnQgQVBJIGltcGxlbWVudGF0aW9ucyB3ZXJlIHdyaXR0ZW4g aW4gdGhlIHNhbWUgbGFuZ3VhZ2UsIGl0J2xsDQogICAgPiAgICBiZSBwcm9oaWJpdGl2ZWx5IGRp ZmZpY3VsdCBmb3IgYW4gYXBwIHRvIG1pZ3JhdGUgZnJvbSB1c2luZyBvbmUgdG8gdXNpbmcNCiAg ICA+ICAgIHRoZSBvdGhlciwganVzdCBiZWNhdXNlIHNvIG1hbnkgYXNwZWN0cyBvZiBpdCBhcmUg bGVmdCBvcGVuIHRvIHRoZQ0KICAgID4gICAgaW1wbGVtZW50b3JzLg0KICAgID4gDQogICAgPiAg ICBJbiB0aGF0IGNvbnRleHQsIEkgdGhvdWdodCBhIFlBTkcgbW9kZWwgd291bGQgYmUgdXNlZnVs IGhlcmUgdG8NCiAgICA+ICAgIHByb3ZpZGUgYSBjcm9zcy1wbGF0Zm9ybSB3YXkgdG8gc3BlY2lm eSB3aGF0IGV4YWN0IHByb3BlcnRpZXMgYW5kDQogICAgPiAgICBvYmplY3RzIGV4aXN0LCBhbiBl eGFjdCBmb3JtYXQgaW4gd2hpY2ggdGhlIHZhbHVlcyBjYW4gYmUgc3BlY2lmaWVkLCBhbmQNCiAg ICA+ICAgIHdoYXQgZXhhY3Qgc2VtYW50aWNzIHRoZXkgaGF2ZSwgd2hpbGUgc3RpbGwgYWxsb3dp bmcgZm9yIGEgc2FuZQ0KICAgID4gICAgZXh0ZW5zaW9uIHBhdGggYW5kIGxhbmd1YWdlLXNwZWNp ZmljIGltcGxlbWVudGF0aW9uIGRldGFpbHMuDQogICAgPiANCiAgICA+ICAgIEknbSB0aGlua2lu ZyBzb21lIGxhbmd1YWdlIGEgYml0IGxpa2UgdGhlIGZpcnN0IGJ1bGxldCBpbiBTZWN0aW9uIDQu MiBvZg0KICAgID4gICAgdGFwcy1pbnRlcmZhY2U6DQogICAgPiANCiAgICA+ICAgICAgQSBjb21w bGlhbnQgaW1wbGVtZW50YXRpb24gU0hPVUxEIHByb3ZpZGUgYSBsYW5ndWFnZS1hcHByb3ByaWF0 ZSB3YXkgdG8NCiAgICA+ICAgICAgY29uZmlndXJlIGEgUHJlQ29ubmVjdGlvbiB1c2luZyBZQU5H IGluc3RhbmNlIGRhdGEgZm9yIHRoaXMgbW9kZWwsIGFuZA0KICAgID4gICAgICBTSE9VTEQgcHJv dmlkZSBhbiBBUEkgdGhhdCBvdXRwdXRzIHRoZSBZQU5HIGluc3RhbmNlIGRhdGEgZm9yIGFuDQog ICAgPiAgICAgIGVzdGFibGlzaGVkIENvbm5lY3Rpb24uDQogICAgPiANCiAgICA+ICAgICAgQW4g aW1wbGVtZW50YXRpb24gTUFZIGFsc28gcHJvdmlkZSBhcHByb3ByaWF0ZSBBUElzIGZvciBkaXJl Y3RseSBlZGl0aW5nDQogICAgPiAgICAgIHRoZSBvYmplY3RzIHdpdGhvdXQgdXNpbmcgWUFORy4g IEl0J3MgUkVDT01NRU5ERUQgd2hlcmUgcG9zc2libGUgdG8gdXNlDQogICAgPiAgICAgIG5hbWVz IHRoYXQgbWVjaGFuaWNhbGx5IHRyYW5zbGF0ZSB0byB0aGUgbmFtZXMgaW4gdGhlIFlBTkcgZGF0 YSBtb2RlbCwNCiAgICA+ICAgICAgdXNpbmcgY2FwaXRhbGl6YXRpb24gYW5kIHB1bmN0dWF0aW9u IGNvbnZlbnRpb25zIGFzIGV4cGVjdGVkIGZvciB0aGUNCiAgICA+ICAgICAgbGFuZ3VhZ2Ugb2Yg dGhlIGltcGxlbWVudGF0aW9uLg0KICAgID4gDQogICAgPiAgICBBbmQgdGhlbiBvZiBjb3Vyc2Ug YSBZQU5HIG1vZGVsOg0KICAgID4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtamhvbGxhbmQtdGFwcy1hcGkteWFuZy8NCiAgICA+ICAgIChkcmFmdC1qaG9sbGFuZC10 YXBzLWFwaS15YW5nKQ0KICAgID4gDQogICAgPiAgICBJZiB0aGlzIHNlZW1zIHVzZWZ1bCwgaXQg d2lsbCBuZWVkIGxvdHMgb2YgcmVmaW5pbmcuICBJJ2xsIGJlIHN1cnByaXNlZA0KICAgID4gICAg aWYgYW55IHBhcnQgb2YgaXQgc3Vydml2ZXMgZXhhY3RseSBhcyB3cml0dGVuLiAgSXQncyBhIHF1 aWNrIGFuZA0KICAgID4gICAgZGlydHkgYXR0ZW1wdCB0byBjb25jcmV0aXplIGEgZmV3IG9mIHRo ZSB0aGluZ3MgSSBzYXcgbGlzdGVkIGluDQogICAgPiAgICBkcmFmdC1pZXRmLXRhcHMtaW50ZXJm YWNlLCBhcyBhIHN0YXJ0aW5nIHBvaW50IHRvIGZpbGwgb3V0IGlmIGl0IHNlZW1zDQogICAgPiAg ICB1c2VmdWwuDQogICAgPiANCiAgICA+ICAgIEJ1dCB0aGUgbW9kZWwgcGFyc2VzLCBhbmQgdGhl IGV4YW1wbGUgZGF0YSBpbnN0YW5jZXMgaW4gdGhlIGRyYWZ0DQogICAgPiAgICBwYXJzZSBhZ2Fp bnN0IHRoZSBtb2RlbCAoYWxsIHdpdGggbGlieWFuZykuDQogICAgPiANCiAgICA+ICAgIE9uZSBv ZiB0aGUgbWFpbiByZWFzb25zIEknbSBkb2luZyB0aGlzIGlzIGJlY2F1c2UgaXQgc2VlbXMgdG8g bWUgd2hhdCdzDQogICAgPiAgICBzcGVjaWZpZWQgaW4gdGFwcy1pbnRlcmZhY2UtMDIgdG9kYXkg aXMgbWlzc2luZyBzb21lIGtleSBmZWF0dXJlcywgbGlrZQ0KICAgID4gICAgYW4gZW51bWVyYXRp b24gb2YgdGhlIHByb3BlcnRpZXMgaW4gdGhlIExvY2FsL1JlbW90ZUVuZHBvaW50IGV4YW1wbGVz IGluDQogICAgPiAgICBzZWN0aW9uIDUuMS4gIEFuZCBJIGRvbid0IHNlZSB0aGF0IGxpc3RlZCBh cyBhbiBvcGVuIGlzc3VlIGluIGdpdGh1YiwNCiAgICA+ICAgIHdoaWNoIHN1cnByaXNlZCBtZSBh IGJpdC4NCiAgICA+IA0KICAgID4gICAgSSB0aGluayBvdmVyc2lnaHRzIGxpa2UgdGhpcyB3aWxs IGJlY29tZSBpbW1lZGlhdGVseSBhbmQgcGFpbmZ1bGx5DQogICAgPiAgICBvYnZpb3VzIHdoZW4g dGhlcmUncyBhIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiB0aGF0IGluY2x1ZGVzIGEgWUFORw0K ICAgID4gICAgcGFyc2VyIGFuZCBhbiBleHBsaWNpdCBkYXRhIG1vZGVsLCBhcyBvcHBvc2VkIHRv IHRoZSBjb21iaW5nIG9mIHRoZQ0KICAgID4gICAgZG9jdW1lbnQgYW5kIGEgc29ydCBvZiBleWVi YWxsZWQgY29tcGFyaXNvbiB0byBORUFUIHRoYXQgSSB0cmllZA0KICAgID4gICAgdGhpcyB3ZWVr IHRvIHJlYWNoIHRoYXQgY29uY2x1c2lvbiAod2hpY2ggSSBmb3VuZCBjaGFsbGVuZ2luZyBldmVu DQogICAgPiAgICB0aG91Z2ggSSB0aG91Z2h0IGJvdGggdGhlIGRvY3VtZW50IGFuZCB0aGUgbGli cmFyeSB3ZXJlIG1vc3RseSBwcmV0dHkNCiAgICA+ICAgIHdlbGwgd3JpdHRlbikuDQogICAgPiAN CiAgICA+ICAgIFRoZSB3aG9sZSB0aGluZyBhdCB0aGlzIHBvaW50IGp1c3Qgc21lbGxzIHRvIG1l IG11Y2ggbW9yZSBhYnN0cmFjdCB0aGFuDQogICAgPiAgICBpdCByZWFsbHkgaGFzIHRvIGJlIG9y IHRoYW4gaXQncyByZWFsbHkgdXNlZnVsIHRvIGJlLCB3aGljaCBib3RoZXJzIG1lDQogICAgPiAg ICBiZWNhdXNlIHRoZSBpZGVhIG9mIHJlcGxhY2luZyBCU0Qgc29ja2V0cyB3aXRoIHNvbWV0aGlu ZyB1c2FibGUgc2VlbXMNCiAgICA+ICAgIGxpa2Ugc3VjaCBhIGdyZWF0IGlkZWEuICBJJ2QgbGlr ZSB0aGlzIHRvIGJlIHNvbWV0aGluZyBJIGNhbiBhY3R1YWxseQ0KICAgID4gICAgdXNlIGluIGEg d2F5IHRoYXQgbWFrZXMgbXkgbGlmZSBlYXNpZXIgc29tZWRheSBzb29uLg0KICAgID4gDQogICAg PiAgICBCdXQgSSB0aGluayBJJ20gYXQgdGhlIHBvaW50IHdoZXJlIEkgbmVlZCBhIHNhbml0eSBj aGVjayB0byBzZWUgaWYgSSdtDQogICAgPiAgICBqdXN0IG1pc3Npbmcgc29tZXRoaW5nLCBvciBp ZiB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgZGlyZWN0aW9uLg0KICAgID4gDQogICAgPiAgICBU aG91Z2h0cz8gIFN1Z2dlc3Rpb25zPyAgIFdvcnRoIGRpc2N1c3NpbmcgaW4gUHJhZ3VlPyAgKElm IHNvLCBjYW4gSQ0KICAgID4gICAgZ2V0IGEgc2xvdD8pDQogICAgPiANCiAgICA+ICAgIENoZWVy cywNCiAgICA+ICAgIEpha2UNCiAgICA+IA0KICAgID4gICAgKjoNCiAgICA+ICAgIEkgY29uY2x1 ZGVkIHRoYXQgdGhlcmUncyBubyByZWFzb24gbXVsdGljYXN0IGNvdWxkbid0IGJlIHN1cHBvcnRl ZA0KICAgID4gICAgdG9kYXksIGlmIHRoZXJlIHdlcmUgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBj b3VsZCByZWFzb25hYmx5IGNsYWltIHRvIGJlDQogICAgPiAgICBjb21wbGlhbnQsIGJ5IGp1c3Qg YWRhcHRpbmcgc29tZSBvZiB0aGUgZXhhbXBsZXMgaW4NCiAgICA+ICAgIGRyYWZ0LWlldGYtdGFw cy1pbnRlcmZhY2UtMDIgYW5kIHVuZGVyc3RhbmRpbmcgdGhlIHNlbWFudGljIG1lYW5pbmcgb2YN CiAgICA+ICAgIG11bHRpY2FzdCBhZGRyZXNzIHNwYWNlcyBpbnNpZGUgdGhlIEFQSS4NCiAgICA+ IA0KICAgID4gICAgRm9yIGV4YW1wbGUsIEkgY291bGRuJ3QgZmluZCBhbnkgcmVhc29uIHRoaXMg Y2FuJ3QgYmUgZXhwZWN0ZWQgdG8gc2V0DQogICAgPiAgICB1cCBhbiBTU00gY2hhbm5lbCBzdWJz Y3JpcHRpb24gd2l0aG91dCBhbnkgZnVydGhlciBhZG8sIGdpdmVuIGEgc2FuZQ0KICAgID4gICAg aW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBpdDoNCiAgICA+IA0KICAgID4gICAgICBSZW1v dGVTcGVjaWZpZXIgOj0gTmV3UmVtb3RlRW5kcG9pbnQoKQ0KICAgID4gICAgICBSZW1vdGVTcGVj aWZpZXIuV2l0aElQdjRBZGRyZXNzKDE5Mi4wLjIuMjEpDQogICAgPiANCiAgICA+ICAgICAgTG9j YWxTcGVjaWZpZXIgOj0gTmV3TG9jYWxFbmRwb2ludCgpDQogICAgPiAgICAgIExvY2FsU3BlY2lm aWVyLldpdGhQb3J0KDMwMDAwKQ0KICAgID4gICAgICBMb2NhbFNwZWNpZmllci5XaXRoSVB2NEFk ZHJlc3MoMjMyLjI1Mi4wLjIpDQogICAgPiANCiAgICA+ICAgICAgTmV3UHJlY29ubmVjdGlvbihS ZW1vdGVTcGVjaWZpZXIsIExvY2FsU3BlY2lmaWVyKS5MaXN0ZW4oLi4uKQ0KICAgID4gDQogICAg PiAgICBNYXliZSB0aGVyZSdzIHNvbWUgdmFsdWUgaW4gc3BlY2lmeWluZyBhICJKb2luU1NNKCki IHRvIG92ZXJyaWRlIGRlZmF1bHRzDQogICAgPiAgICBpbiB0aGUgUHJlQ29ubmVjdGlvbiwganVz dCB0byBtYWtlIHN1cmUgeW91J3JlIHNwZWNpZmljYWxseSBhc2tpbmcgZm9yDQogICAgPiAgICBt dWx0aWNhc3QuICBJIHRoaW5rIHRoYXQgd291bGQgYmUgZmluZSBmb3IgbmF0aXZlIG11bHRpY2Fz dCwgYnV0IGxpa2UgSQ0KICAgID4gICAgc2FpZCwgYSBtdWNoIHNtYWxsZXIgcG9pbnQgdGhhbiB0 aGUgbG9vc2VuZXNzIG9mIHRoZSBBUEkuDQogICAgPiANCiAgICA+ICAgIFdoZXJlIGl0IGdldHMg YSBiaXQgbW9yZSBjb21wbGljYXRlZCBpcyB0cnlpbmcgdG8gaGFuZGxlIG11bHRpcGxlIG9wdGlv bnMNCiAgICA+ICAgIGZvciBkaXNjb3ZlcmluZyBhIHVzYWJsZSB1bmljYXN0IHR1bm5lbCBmb3Ig bXVsdGljYXN0IHRyYWZmaWMsIGFzDQogICAgPiAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjQu MSBvZiBkcmFmdC1pZXRmLW1ib25lZC1kcmlhZC1hbXQtZGlzY292ZXJ5LTAxLg0KICAgID4gDQog ICAgPiAgICBJJ2QgbGlrZSB0byBoYXZlIGEgZGVjZW50IHBsYWNlIHRvIHRhY2sgb24gYW4gZXh0 ZW5zaW9uIHRvIHRoaXMgQVBJIHRoYXQNCiAgICA+ICAgIGNhbiB0cmFuc3BhcmVudGx5LCB3aXRo aW4gdGhlIGNvbm5lY3Rpb24gQVBJLCBkaXNjb3ZlciB0aGUgYmVzdCBhdmFpbGFibGUNCiAgICA+ ICAgIEFNVCByZWxheSBhbmQgc3RhcnQgdXNpbmcgaXQgd2hlbiBuYXRpdmUgam9pbmluZyBpcyB1 bmF2YWlsYWJsZSAoYW5kIGFsc28NCiAgICA+ICAgIHRvIHByb3ZpZGUgbm9ybWF0aXZlIGNvbnRy b2xzIGZvciBjb25maWd1cmluZyBpdCB3aGVuIHRoZXJlJ3MNCiAgICA+ICAgIGFkbWluaXN0cmF0 aXZlIGNvbmZpZ3VyYXRpb24gdG8gYmUgYWRkZWQpLg0KICAgID4gDQogICAgPiAgICBCdXQgdGhh dCdzIGEgMm5kIG9yZGVyIHF1ZXN0aW9uIGZvciBtZSBhdCB0aGlzIHBvaW50LCBiZWNhdXNlIGlu IHRoZQ0KICAgID4gICAgY3VycmVudCBUQVBTIEFQSSBJIGRvbid0IHNlZSBhbnkgb2J2aW91c2x5 IGdvb2Qgc3BvdCB0byBwdXQgc2VsZWN0aW9uDQogICAgPiAgICBjb250cm9scyBmb3IgdGhhdCBr aW5kIG9mIHR1bm5lbCBkaXNjb3Zlcnkgc2VsZWN0aW9uLCBvciByZWFsbHkgYSBnb29kDQogICAg PiAgICB3YXkgdG8gZXhwbGFpbiB3aGF0IGl0J3Mgc3VwcG9zZWQgdG8gZG8sIGlmIEkgdHJpZWQg dG8gYWRkIGNvbnRyb2xzIHRvDQogICAgPiAgICBzb21ldGhpbmcgdGhhdCdzIHRoZXJlLg0KICAg ID4gDQogICAgPiAgICBTb2x2aW5nIHRoYXQgaXMgbXkgbWFpbiBtb3RpdmF0aW9uIGZvciBiZWlu ZyBoZXJlLiAgKFdlbGwsIGFuZCB0aGF0DQogICAgPiAgICB0aGUgQlNEIHNvY2tldCBBUEkgZm9y IG11bHRpY2FzdCBpcyBraW5kIG9mIGEgZGlzYXN0ZXIgdG9kYXkuKQ0KICAgID4gDQogICAgPiAg ICBBbnl3YXksIGlmIHRhcHMgZmluZHMgdGhlIHdob2xlIFlBTkcgc3VnZ2VzdGlvbiB1c2VmdWws IEknbGwgcHJvYmFibHkNCiAgICA+ICAgIHN1Z2dlc3Qgc29tZSBuZXcgZXh0ZW5zaW9ucyBhYm91 dCB0aGlzLCBhbmQgbWF5YmUgYSBmZXcgb3RoZXIgcG9pbnRzLA0KICAgID4gICAgZXNwZWNpYWxs eSBtYXliZSBhcm91bmQgdHJ5aW5nIHRvIHB1dCBpbiBhIHN0cnVjdHVyZSB0aGF0IGNhbiBzdXBw b3J0DQogICAgPiAgICBzb21lIGtpbmQgb2Ygc2FuZSBleHBsaWNpdCBsYXllcmluZy4NCiAgICA+ IA0KICAgID4gICAgQnV0IEknbSBub3Qgc3VyZSBJIGNhbiBhcnRpY3VsYXRlIHRob3NlIHN1Z2dl c3Rpb25zIGluIGEgd2F5IEknbSBzdXJlIGlzDQogICAgPiAgICBtZWFuaW5nZnVsIHdpdGhvdXQg Zmlyc3QgZ2V0dGluZyBhIG1vcmUgY2xlYXIgc3BlY2lmaWNhdGlvbiBuYWlsZWQgZG93bg0KICAg ID4gICAgYWJvdXQgd2hhdCdzIGFjdHVhbGx5IGluIHRoZSB0YXBzIHNwZWMuIEJlY2F1c2Ugcmln aHQgbm93IEknbSBtb3N0bHkNCiAgICA+ICAgIGp1c3QgY29uZnVzZWQgYWJvdXQgd2hhdCBhbiBB UEkgaW1wbGVtZW50YXRpb24gd291bGQgcmVhbGx5IGxvb2sgbGlrZSwNCiAgICA+ICAgIGFuZCBo b3cgeW91IGNvdWxkIHRlbGwgd2hldGhlciBpdCBtYXRjaGVzIHRoZSB0YXBzLWludGVyZmFjZSBz cGVjLg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gICAgRnJvbTogQWFyb24gRmFsayA8 YWFyb24uZmFsa0BnbWFpbC5jb20+DQogICAgPiAgICBEYXRlOiAyMDE5LTAzLTA0IGF0IDEwOjUz DQogICAgPiAgICBUbzogdGFwcyBXRyA8dGFwc0BpZXRmLm9yZz4NCiAgICA+ICAgIENjOiBaYWhl ZHV6emFtYW4gU2Fya2VyIDx6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbT4NCiAgICA+ ICAgIFN1YmplY3Q6IFtUYXBzXSBjYWxsIGZvciBhZ2VuZGEgaXRlbXMgYXQgVEFQUyBJRVRGLTEw NA0KICAgID4gDQogICAgPiAgICBIaSBBbGwtDQogICAgPiAgICBXaGF0IHNob3VsZCB3ZSB1c2Ug b3VyIHRpbWUgdG8gZGlzY3Vzcz8gTGV04oCZcyBmb2N1cyBvbiB0aGluZ3MgdGhhdCB3b3VsZCBi ZW5lZml0IGZyb20gZjJmIGRpc2N1c3Npb24sIGNvbnNlbnN1cyBidWlsZGluZywgb3IganVzdCBh cmd1bWVudC4gOikNCiAgICA+ICAgIOKAoiBUQVBTIGRvY3M6IGFyZSB0aGVyZSBvcGVuIHRvcGlj cyB0aGF0IG5lZWQgZ3JvdXAgYXR0ZW50aW9uPyBTZWVtcyBsaWtlIHdlIHNldHRsZWQgbW9zdCBv ZiB0aGUgcmVtYWluZGVyIGF0IHRoZSBpbnRlcmltLiANCiAgICA+ICAgIOKAoiBUQVBTIHNlY3Vy aXR5OiB0aGlzIHNlZW1zIG5lYXJseSBkb25lLiBBbnl0aGluZyB0byBkaXNjdXNzPyANCiAgICA+ ICAgIOKAoiBJbXBsZW1lbnRhdGlvbnM6IGEgZ29vZCB0b3BpYyBmb3IgaW5mb3JtYXRpb24gc2hh cmluZyBidXQgbGVzcyBpbXBvcnRhbnQgdGhhbiBhbnl0aGluZyBuZWVkaW5nIGFncmVlbWVudCAN CiAgICA+ICAgIOKAoiBNb2JpbGl0eTogaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRGRt bS0yRG9uZGVtYW5kLTJEbW9iaWxpdHktMkQxNyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpw TjZMWmcmcj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJm09cExX NWdTeWV0ZlZlX2l4RzRfdTdxS1hfVmNqSXF6TjdKdTJCZ00ycnBRbyZzPUhVc0JWQkZfR2hOaU9r M2dxWV9tNXFaTUQtc1BtQko5M0dFNXdkM0Q1X3MmZT0gYW5kIGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9j X3Jldmlldy0yRGlldGYtMkRkbW0tMkRvbmRlbWFuZC0yRG1vYmlsaXR5LTJEMTUtMkR0c3ZhcnQt MkRsYy0yRHdlc3Rlcmx1bmQtMkQyMDE5LTJEMDEtMkQwOF8mZD1Ed01GYVEmYz05NlpiWlpjYU1G NHcwRjRqcE42TFpnJnI9YnFuRlJPaXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9v ayZtPXBMVzVnU3lldGZWZV9peEc0X3U3cUtYX1Zjaklxek43SnUyQmdNMnJwUW8mcz0wWW1DX1hD QXU0X0dWWWRGaTBIeGlLYUtCcGFuMkNPWXFCTDFtQjZiWHJZJmU9IA0KICAgID4gICAgLS1hYXJv bg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IFRhcHMgbWFpbGluZyBsaXN0DQogICAgPiBU YXBzQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RhcHMNCiAgICANCiAgICANCg0K From nobody Thu Mar 7 12:54:57 2019 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 24B47130F1E for ; Thu, 7 Mar 2019 12:54:56 -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_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 BHk7VVivwJue for ; Thu, 7 Mar 2019 12:54:50 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 7A164128701 for ; Thu, 7 Mar 2019 12:54:50 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id f11so1576314qti.7 for ; Thu, 07 Mar 2019 12:54:50 -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; bh=sardAOco9bFJbi8WYEMHls4tX5eB9L+y2TX2vs5k0z4=; b=kKTYcpqkHHqTim9MCALUDsK5NIfPu3vbbJotTrpPAhlEau/X7IqrKFqICqavBHTX6L IbrF4q4FJhQHLB7yoRgReNdz7oQL6FaMqFPl8g/wwP1JNDhgosFppRu0GpGPGgwI4+1y nQFXPEgBVMJ0XubX6/wzwUToLeAIXy6LWFjxD4ZQqbVUyG5ywNT56WY3fF/L1liX7+K0 2RUPj8IIP64NTpdh6o4g0pV/ffh31GCjNSwQoeNSh5UM3BAsMTuaPvbMQTuaKlRZR1Wq klwevDSbx/eTfq/vKd8Ua5svihb528syLU2JWlMN1BTgW4/1r/0yTJioE7hmHOvOqeVg Je5A== 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; bh=sardAOco9bFJbi8WYEMHls4tX5eB9L+y2TX2vs5k0z4=; b=J0DI30OxLm6oQ0j34XhFYdO6uMNPWNvfs0vX0iXbAs2ZaQ4clgVj7in18qYnCK6YhI THls/8jP2lsI27l/gaUJDHTF7Nm8dV/0Nj3Pj/P8hZtomVT54+FRNdEiQh33tMvcG++c 5CShqMmWFZBebdbci9IuDgUxTbG6yh3AEo9fl0Ll1DAKxCYsvNW4pGE1WsebLX3AMPOj Tnp9gf+psNIereaVioTtC8usEAKIDyZqSFUggrWrgQ9RBh20TT6rcdTdyLTV4r+D9VKP haetvZcGRhuVLsX1WKfM2FseiwfkCT+CEDjlTAk15yf9XXQrFq6ygXxI2YUm/OSznGyM XtuA== X-Gm-Message-State: APjAAAXxWd4BnWCZn01ouJHeenzqs1T0DgXB5BX7ekBCz9Kx5rFctjuR Ij7/1PTKVnLJU+zUmBQNmgU= X-Google-Smtp-Source: APXvYqxPS90woEuRLgk2YgZ/lLmys1qwlKbZE23qAPKwG3iHXx7OLWrKT5HVkIkRkxF+IbOUEo62BQ== X-Received: by 2002:ac8:2b51:: with SMTP id 17mr11708925qtv.328.1551992088909; Thu, 07 Mar 2019 12:54:48 -0800 (PST) Received: from [172.19.37.49] ([2001:4878:a000:3000:d113:abb9:4bf3:8f75]) by smtp.gmail.com with ESMTPSA id t1sm3602001qtj.54.2019.03.07.12.54.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 12:54:47 -0800 (PST) From: "Aaron Falk" To: "Holland, Jake" Cc: "taps WG" , "Michael Welzl" Date: Thu, 07 Mar 2019 15:54:45 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: <852D2DBC-3C7D-4D54-82CB-0956F3844E58@gmail.com> In-Reply-To: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_72DE4123-A867-4751-B300-DA4767929743_=" Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 20:54:56 -0000 --=_MailMate_72DE4123-A867-4751-B300-DA4767929743_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Jake- I=E2=80=99m unclear, do you want to discuss multicast in Prague or just Y= ANG? --aaron On 7 Mar 2019, at 14:10, Holland, Jake wrote: > Hi Michael, > > Thanks for responding, much appreciated. (And also to Tommy > and Aaron.) > > Based on the replies from you, Tommy, and Aaron, I'll plan > to present something in Prague, and can you please put me > on the schedule, Aaron? > > More responses inline with , and thanks, these > questions were very helpful to help me focus on what needs > explaining vs. what's obvious. > > > =EF=BB=BFOn 2019-03-07, 00:32, "Michael Welzl" wro= te: > > Hi, > > Very sorry for the silence. I can only speak for myself, but = > here's an example of why this one person was silent: > - When you created your issue on multicast in github, I thought of = > answering (positively), but then thought that the repo is about to = > move, and it would probably be better to delay things until the move = > is finished. > - Then, the issue was overruled by your email. I read it and found = > it interesting, but hoped for someone else to answer because, frankly, = > I was afraid to make a fool of myself ... because I know almost = > nothing about YANG. > > > Thanks for explaining, I'm sympathetic and grateful that you > overcame your concerns. I was in the same place on YANG not > too long ago, and I still have a ways to go, though I now think > I see some of its promise. > > But I don't think I created a multicast issue on github? I just > noticed a few nits while reading and sent a pull request, nothing > really substantial yet. > > > But now I'll be brave :) I'll go ahead and ask: how exactly is = > this YANG proposal more than just a syntax change? What would it give = > us? > (I understand that YANG can be automatically parsed / checked by = > some tools, but... what does THAT give us?) > > > Syntax plus tool support is the only difference between machine code > and , so even if that's the only > thing we got, it's not to be sneezed at. (And there is a lot of room > for growth here, but there are already tools that can generate API > header code from yang, e.g: > https://wiki.onosproject.org/display/ONOS/YANG+Tools ) > > But I'm actually pushing from the other direction; my understanding > of the current docs is that taps-arch is a high level design and goals > document, and taps-interface (and taps-minset) make an attempt to > lay out the concrete implementation details that would make taps-arch = > a > reality, if an implementation covers them. > > My claim here is twofold: > - that taps-interface as it stands today is another high level design > document, which will have a necessarily fuzzy mapping to any actual > implementation. > - that taps-interface is _really_ _close_ to laying out the concrete > implementation details in a non-fuzzy way that can be directly used > by implementors, so I'm suggesting that taking that extra step is > highly valuable. > > On the question of benefits: I'll lay out some of the ones > that seem important to me, but I'll first say that in theory, > these benefits could be realized by any concrete configuration > format. The benefit of YANG specifically comes from tool > support and the confidence from existing work that make it clear > it's a reasonable format for networking configuration. > > Basically, because there's so much YANG work already done for > networking, using YANG lets us leverage some of that work in a way > other options don't. > > In particular, there are a bunch of networking-specific concepts > that are already defined in detail. For example, the ipv6-address > type has a complicated regex that many implementors are likely to > get wrong if they try to roll their own (at least, I've certainly > done so, and seen it a bunch of times): > https://tools.ietf.org/html/rfc6991#page-19 > > But by making the obvious choice of using yang tools to parse yang > stuff, implementors automatically get checking against that > (normative!) regex for free without having to notice and check it > themselves. > > There's other side benefits, like that interfaces are themselves > explicitly defined (https://tools.ietf.org/html/rfc8343#section-5), > and so where things like interface types might be used, the past > and future work of people who formalize and extend the set of > interface types gets automatically imported by referencing the > normative yang definition for network interfaces. > > But to list a few of the specific benefits from having an explicit > config format: > > - cross-platform portability: > If I've got a program using a taps api that talks to some service, > and now I want to write a new program in a different language to talk > to that service, I can export the config and load it in my new > program (even in a new language), and I can be reasonably sure > it'll form the same kind of connection. > > Although it's possible to make it work anyway as long as the APIs > have a 1-to-1 mapping, normalizing on a config file format instead > of a list of features seems to me like it'll save me perhaps up to a > day or so of effort each time I have to do this, which when multiplied > by all the implementors in the world over the next decade or 2, starts > to add up. > > - testability: > Again, this mostly saves time, but by having a defined input format, > it's possible for different implementations to use the same suite of > test configuration files to verify the same interpretation of their > contents. If each implementation has its own way of configuring the > features, it's not impossible to design a suite that can test them, > but it's vastly harder. > > - completeness: > One of the points of confusion I had with taps-interface was that the > Local/RemoteEndpoints seemed both critical to an implementation and > very underspecified. Although it's possible to address that by = > raising > concerns specifically about the Local/Remote Endpoints, I'm not sure > there aren't other underspecified areas of the taps-interface draft. > > I expect that a reference implementation based on parsing a config > format would uncover all such underspecified areas of configuration, > if the config format examples are used to describe all the supported > use cases. > > (So part of my goal with this proposal is to solve this problem in > the general case, which implies that it'll also be solved for the > specific cases of Local/Remote Endpoints, though of course the > details for each instance of incompleteness are separate topics.) > > There might be some other benefits, but I'll stop there, hoping the > point is sufficiently clear. > > > Also, I actually see 3 separable things being proposed here: > > 1) the YANG model > > I'd phrase the current status of the proposal as an in-principle > "use a YANG model", rather than "use this specific YANG model". > > The current draft is kind of a throw-away example proof of concept, > which is certainly very incomplete, and some of my reading yesterday > suggests that it's actually not very well structured either. I've > probably already made a fool of myself to any actual YANG experts, > that ever try to read it, but such are the risks of posting public > comments... :) > > > 2) multicast support (I find your conclusion that not much needs = > to change interesting! Though the example you're giving (joining an = > SSM channel) is only a part of what we'd need, as you also say...) > > Fair point, this really is a separate topic. I brought it up > really only because it's a motivating factor in my participation > here, not because it's a primary factor for taps in general. Let's > drop it for this thread, and I'll plan to raise it as a separate > issue when the yang questions are settled and I've got something > more thought out. > > > 3) applying preferences to addresses and port numbers (which you = > seem to take for granted in your draft, but which I don't think is = > supported by our current document). > > > Yes, this is a case in point for my concerns about incompleteness > on the Endpoint specifications. > > I wasn't sure how to treat this, so I'm not surprised if I got it > wrong. I was sort of pattern-matching on the rest of what the spec > does, plus guessing at intended meanings of this paragraph from > https://tools.ietf.org/html/draft-ietf-taps-interface-02#section-5.1: > > Multiple endpoint identifiers can be specified for each Local > Endpoint and Remote Endpoint. For example, a Local Endpoint could = > be > configured with two interface names, or a Remote Endpoint could be > specified via both IPv4 and IPv6 addresses. These multiple > identifiers refer to the same transport endpoint. > > By the time I finished making the examples, I had noticed I was > maybe doing it wrong, but I didn't want to bother fixing it unless > people agree it's worth spending effort in this general direction, and > I didn't want to hold off on opening the discussion. Of course, it > should be changed to match the consensus of the wg on what belongs > here. > > > Side note: unless I'm mistaken, this wouldn't fit our structure = > well: e.g. a port number would then be a Transport Property that has a = > certain value, but also has a preference, but currently we say that a = > Transport Property has "one of a set of data types", one of which is a = > Preference. Isn't that structure too limiting? Or am I missing = > something? > > > I'm not sure. This is part of what I mean when I say I find the > current taps-interface a little too loose. I _think_ what I posted > is a valid (though perhaps not optimal) interpretation of the current > text. I might be wrong about that, so I'd be grateful for a pointer > to the text that prohibits this interpretation. > > But really, that's beside the point. I'd be even more grateful for an > alternate proposal that more closely matches the intended design for > a taps API, with the same level of concreteness. > > > I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) = > as separate... maybe there are other use cases for 3) alone ? > > > Yes, I think so. I think I understand an ultimate goal for taps to > be "as an app designer, don't worry about which transport, just > send the magic API to go discover one that works". > > However, it seems to me in the interim that it'll be necessary > to specify port numbers in order to interoperate with a lot of > existing services, especially in cases like RTP (or a lot of > other generalized UDP stuff), where there's not an explicit > service-to-port mapping. (Also to interoperate with a lot of > other deployed systems like firewalls.) > > I have a few nebulous ideas about how explicit layering might be a > good way to solve this, but I think in order to make the ideas sharp > enough to evaluate, I thought I'd first try the easier task of making > taps sharp enough that I can express the ideas as proposed changes > to an existing well-formed concept. > > > IMO, all of these things are interesting, and would be good to = > discuss on site. However, I doubt that we can deal with them all in = > only 15 minutes :-) > > > Fair point. > > I propose during the taps meeting to check preliminary consensus about > moving forward with a YANG model within taps, and if so whether to > integrate, replace, or make a paired doc with the existing = > taps-interface. > Separately, I'll encourage those interested and available to spend = > some > time in offline clarifying discussion during the week prior. > > Cheers, > Jake > > > Cheers, > Michael > > PS: Travis is down, or something. At least the "Editor's Copy" = > links don't currently work. > > > > > On 7 Mar 2019, at 04:55, Holland, Jake = > wrote: > > > > Hi taps, > > > > (Trying again, but simpler.) > > > > I'm looking for a consensus yes or no answer: > > > > Is a normative config input format an interesting and useful > > direction? > > > > > > The idea is to add functionality like this, in taps-interface: > > > > newPre =3D PreConnection.NewFromJson('''{ > > "remote-endpoint":{ > > "hosts":[ > > { "host":"example.com" } > > ] > > } > > }''') > > > > With a fully specified json input format that can provide all = > the > > configurable values. > > > > > > If no, I'll move on and assume I just don't understand taps = > goals. > > > > If yes, I'd like 15 minutes to discuss in Prague, and keep = > reading: > > > > I think a full definition of an input json format can be exactly > > specified by a YANG model. (With xml for free, if you want it.) > > > > I tried to sketch a start at what a YANG model for this might = > look like: > > = > https://tools.ietf.org/html/draft-jholland-taps-api-yang-00#section-3 > > > > I'm not a YANG expert yet, and it's not much of a model. And = > it's very > > far from complete. But it compiles, and all the examples in the = > draft > > validate against that model with libyang. If it's worthwhile, I = > think > > something like this can be good (and extensible!), if done = > right. > > > > I believe something along these lines would sharpen up = > taps-interface > > a lot. (After filling in all the taps-interface properties.) > > > > > > The reason I'm asking is because right now, taps-interface to me > > seems _almost_ really good, except too confusing and vague to = > actually > > build an API that can replace BSD sockets. I think with a solid = > config > > format with normative and testable examples, that could be = > fixed. > > > > If consensus says "interesting", I'll want 15 minutes to discuss = > it, and > > to start digging into how to make it good. (And also to add = > multicast > > support to the model and at least one implementation.) > > > > Thanks for your consideration. > > > > > > Cheers, > > Jake > > > > > > > > On 2019-03-04, 17:19, "Holland, Jake" = > wrote: > > > > Hi taps folks, > > > > TL;DR: I think the spec should have a YANG model and I want = > to use it > > to get multicast support in an implementation. > > > > > > I recently started digging into the taps API with the intent = > of adding > > multicast support, but it looks like it's basically already = > there, as > > far as it goes[*]. > > > > But I ended up with a higher-level comment, so I thought I'd = > raise it > > to the wg and ask what you all think. > > > > I found the whole "abstract interface" approach a little too > > loosey-goosey, so I thought I'd try to suggest a way to = > tighten it up. > > > > My goal with this is to make it much more clear (to the point = > of being > > mechanically checkable) precisely what a compliant API = > provides. > > > > I'm not attached to the structure I'm proposing or to any of = > the > > particulars in the straw-man I've posted, but if it's not = > tightened up > > with something at a similar level of concreteness, I'm = > concerned that > > different implementations will be not only incompatible in = > random > > underspecified corner cases (like BSD sockets today when you = > try to make > > cross-platform C code), but also are likely to end up with = > very many > > important differences that would make the whole taps effort = > more or less > > moot. > > > > In a world where we end up with a doc at the level of = > abstraction I'm > > currently seeing in draft-taps-interface, it seems to me that = > if 2 > > different API implementations were written in the same = > language, it'll > > be prohibitively difficult for an app to migrate from using = > one to using > > the other, just because so many aspects of it are left open = > to the > > implementors. > > > > In that context, I thought a YANG model would be useful here = > to > > provide a cross-platform way to specify what exact properties = > and > > objects exist, an exact format in which the values can be = > specified, and > > what exact semantics they have, while still allowing for a = > sane > > extension path and language-specific implementation details. > > > > I'm thinking some language a bit like the first bullet in = > Section 4.2 of > > taps-interface: > > > > A compliant implementation SHOULD provide a = > language-appropriate way to > > configure a PreConnection using YANG instance data for this = > model, and > > SHOULD provide an API that outputs the YANG instance data = > for an > > established Connection. > > > > An implementation MAY also provide appropriate APIs for = > directly editing > > the objects without using YANG. It's RECOMMENDED where = > possible to use > > names that mechanically translate to the names in the YANG = > data model, > > using capitalization and punctuation conventions as = > expected for the > > language of the implementation. > > > > And then of course a YANG model: > > = > https://datatracker.ietf.org/doc/draft-jholland-taps-api-yang/ > > (draft-jholland-taps-api-yang) > > > > If this seems useful, it will need lots of refining. I'll be = > surprised > > if any part of it survives exactly as written. It's a quick = > and > > dirty attempt to concretize a few of the things I saw listed = > in > > draft-ietf-taps-interface, as a starting point to fill out if = > it seems > > useful. > > > > But the model parses, and the example data instances in the = > draft > > parse against the model (all with libyang). > > > > One of the main reasons I'm doing this is because it seems to = > me what's > > specified in taps-interface-02 today is missing some key = > features, like > > an enumeration of the properties in the Local/RemoteEndpoint = > examples in > > section 5.1. And I don't see that listed as an open issue in = > github, > > which surprised me a bit. > > > > I think oversights like this will become immediately and = > painfully > > obvious when there's a reference implementation that includes = > a YANG > > parser and an explicit data model, as opposed to the combing = > of the > > document and a sort of eyeballed comparison to NEAT that I = > tried > > this week to reach that conclusion (which I found challenging = > even > > though I thought both the document and the library were = > mostly pretty > > well written). > > > > The whole thing at this point just smells to me much more = > abstract than > > it really has to be or than it's really useful to be, which = > bothers me > > because the idea of replacing BSD sockets with something = > usable seems > > like such a great idea. I'd like this to be something I can = > actually > > use in a way that makes my life easier someday soon. > > > > But I think I'm at the point where I need a sanity check to = > see if I'm > > just missing something, or if this seems like a useful = > direction. > > > > Thoughts? Suggestions? Worth discussing in Prague? (If = > so, can I > > get a slot?) > > > > Cheers, > > Jake > > > > *: > > I concluded that there's no reason multicast couldn't be = > supported > > today, if there were an implementation that could reasonably = > claim to be > > compliant, by just adapting some of the examples in > > draft-ietf-taps-interface-02 and understanding the semantic = > meaning of > > multicast address spaces inside the API. > > > > For example, I couldn't find any reason this can't be = > expected to set > > up an SSM channel subscription without any further ado, given = > a sane > > implementation that supports it: > > > > RemoteSpecifier :=3D NewRemoteEndpoint() > > RemoteSpecifier.WithIPv4Address(192.0.2.21) > > > > LocalSpecifier :=3D NewLocalEndpoint() > > LocalSpecifier.WithPort(30000) > > LocalSpecifier.WithIPv4Address(232.252.0.2) > > > > NewPreconnection(RemoteSpecifier, = > LocalSpecifier).Listen(...) > > > > Maybe there's some value in specifying a "JoinSSM()" to = > override defaults > > in the PreConnection, just to make sure you're specifically = > asking for > > multicast. I think that would be fine for native multicast, = > but like I > > said, a much smaller point than the looseness of the API. > > > > Where it gets a bit more complicated is trying to handle = > multiple options > > for discovering a usable unicast tunnel for multicast = > traffic, as > > described in Section 2.4.1 of = > draft-ietf-mboned-driad-amt-discovery-01. > > > > I'd like to have a decent place to tack on an extension to = > this API that > > can transparently, within the connection API, discover the = > best available > > AMT relay and start using it when native joining is = > unavailable (and also > > to provide normative controls for configuring it when there's > > administrative configuration to be added). > > > > But that's a 2nd order question for me at this point, because = > in the > > current TAPS API I don't see any obviously good spot to put = > selection > > controls for that kind of tunnel discovery selection, or = > really a good > > way to explain what it's supposed to do, if I tried to add = > controls to > > something that's there. > > > > Solving that is my main motivation for being here. (Well, = > and that > > the BSD socket API for multicast is kind of a disaster = > today.) > > > > Anyway, if taps finds the whole YANG suggestion useful, I'll = > probably > > suggest some new extensions about this, and maybe a few other = > points, > > especially maybe around trying to put in a structure that can = > support > > some kind of sane explicit layering. > > > > But I'm not sure I can articulate those suggestions in a way = > I'm sure is > > meaningful without first getting a more clear specification = > nailed down > > about what's actually in the taps spec. Because right now I'm = > mostly > > just confused about what an API implementation would really = > look like, > > and how you could tell whether it matches the taps-interface = > spec. > > > > > > > > From: Aaron Falk > > Date: 2019-03-04 at 10:53 > > To: taps WG > > Cc: Zaheduzzaman Sarker > > Subject: [Taps] call for agenda items at TAPS IETF-104 > > > > Hi All- > > What should we use our time to discuss? Let=E2=80=99s focus on= = > things that would benefit from f2f discussion, consensus building, or = > just argument. :) > > =E2=80=A2 TAPS docs: are there open topics that need group = > attention? Seems like we settled most of the remainder at the interim. > > =E2=80=A2 TAPS security: this seems nearly done. Anything to = > discuss? > > =E2=80=A2 Implementations: a good topic for information sharin= g but = > less important than anything needing agreement > > =E2=80=A2 Mobility: = > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_h= tml_draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&d=3DDwMFaQ&c=3D96ZbZZca= MF4w0F4jpN6LZg&r=3DbqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gS= yetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=3DHUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ= 93GE5wd3D5_s&e=3D = > and = > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= =2Eorg_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2= Dwesterlund-2D2019-2D01-2D08_&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3Db= qnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_Vc= jIqzN7Ju2BgM2rpQo&s=3D0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=3D > > --aaron > > > > > > > > _______________________________________________ > > 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 --=_MailMate_72DE4123-A867-4751-B300-DA4767929743_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Jake-

I=E2=80=99m unclear, do you want to discuss multicast in = Prague or just YANG?

--aaron

On 7 Mar 2019, at 14:10, Holland, Jake wrote:

Hi Michael,

Thanks for responding, much appreciated. (And also to Tommy
and Aaron.)

Based on the replies from you, Tommy, and Aaron, I'll plan
to present something in Prague, and can you please put me
on the schedule, Aaron?

More responses inline with <jh></jh>, and thanks, these
questions were very helpful to help me focus on what needs
explaining vs. what's obvious.


=EF=BB=BFOn 2019-03-07, 00:32, "Michael Welzl" <michawe@ifi.uio.no>= wrote:

Hi,

Very sorry for the silence. I can only speak for myself, but here's a= n example of why this one person was silent:
- When you created your issue on multicast in github, I thought of an= swering (positively), but then thought that the repo is about to move, an= d it would probably be better to delay things until the move is finished.=
- Then, the issue was overruled by your email. I read it and found it= interesting, but hoped for someone else to answer because, frankly, I wa= s afraid to make a fool of myself ... because I know almost nothing about= YANG.

<jh>
Thanks for explaining, I'm sympathetic and grateful that you
overcame your concerns. I was in the same place on YANG not
too long ago, and I still have a ways to go, though I now think
I see some of its promise.

But I don't think I created a multicast issue on github? I just
noticed a few nits while reading and sent a pull request, nothing
really substantial yet.
</jh>

But now I'll be brave :) I'll go ahead and ask: how exactly is thi= s YANG proposal more than just a syntax change? What would it give us? (I understand that YANG can be automatically parsed / checked by some= tools, but... what does THAT give us?)

<jh>
Syntax plus tool support is the only difference between machine code
and <your favorite programming language>, so even if that's the onl= y
thing we got, it's not to be sneezed at. (And there is a lot of room
= for growth here, but there are already tools that can generate API
header code from yang, e.g:
https://wiki.onosproject.org/display/ONOS/YANG+Tools )
But I'm actually pushing from the other direction; my understanding
of the current docs is that taps-arch is a high level design and goals document, and taps-interface (and taps-minset) make an attempt to
lay out the concrete implementation details that would make taps-arch a reality, if an implementation covers them.

My claim here is twofold:
- that taps-interface as it stands today is another high level design
= document, which will have a necessarily fuzzy mapping to any actual
= implementation.
- that taps-interface is _really_ _close_ to laying out the concrete
implementation details in a non-fuzzy way that can be directly used
= by implementors, so I'm suggesting that taking that extra step is
highly valuable.

On the question of benefits: I'll lay out some of the ones
that seem important to me, but I'll first say that in theory,
these benefits could be realized by any concrete configuration
format. The benefit of YANG specifically comes from tool
support and the confidence from existing work that make it clear
it's a reasonable format for networking configuration.

Basically, because there's so much YANG work already done for
networking, using YANG lets us leverage some of that work in a way
other options don't.

In particular, there are a bunch of networking-specific concepts
that are already defined in detail. For example, the ipv6-address
type has a complicated regex that many implementors are likely to
get wrong if they try to roll their own (at least, I've certainly
done so, and seen it a bunch of times):
https://tools.ietf.org/html/rfc6991#page-19

But by making the obvious choice of using yang tools to parse yang
stuff, implementors automatically get checking against that
(normative!) regex for free without having to notice and check it
themselves.

There's other side benefits, like that interfaces are themselves
explicitly defined (https://tools.ietf.org/html/rfc8343#section-5),
and so where things like interface types might be used, the past
and future work of people who formalize and extend the set of
interface types gets automatically imported by referencing the
normative yang definition for network interfaces.

But to list a few of the specific benefits from having an explicit
config format:

- cross-platform portability:
If I've got a program using a taps api that talks to some service,
and now I want to write a new program in a different language to talk
= to that service, I can export the config and load it in my new
program (even in a new language), and I can be reasonably sure
it'll form the same kind of connection.

Although it's possible to make it work anyway as long as the APIs
have a 1-to-1 mapping, normalizing on a config file format instead
of a list of features seems to me like it'll save me perhaps up to a
day or so of effort each time I have to do this, which when multiplied by all the implementors in the world over the next decade or 2, starts to add up.

- testability:
Again, this mostly saves time, but by having a defined input format,
it's possible for different implementations to use the same suite of
test configuration files to verify the same interpretation of their
contents. If each implementation has its own way of configuring the
features, it's not impossible to design a suite that can test them,
but it's vastly harder.

- completeness:
One of the points of confusion I had with taps-interface was that the
= Local/RemoteEndpoints seemed both critical to an implementation and
very underspecified. Although it's possible to address that by raising concerns specifically about the Local/Remote Endpoints, I'm not sure
there aren't other underspecified areas of the taps-interface draft.

I expect that a reference implementation based on parsing a config
format would uncover all such underspecified areas of configuration,
if the config format examples are used to describe all the supported
use cases.

(So part of my goal with this proposal is to solve this problem in
the general case, which implies that it'll also be solved for the
specific cases of Local/Remote Endpoints, though of course the
details for each instance of incompleteness are separate topics.)

There might be some other benefits, but I'll stop there, hoping the
point is sufficiently clear.
</jh>

Also, I actually see 3 separable things being proposed here:

1) the YANG model
<jh>
I'd phrase the current status of the proposal as an in-principle
"use a YANG model", rather than "use this specific YANG model".

The current draft is kind of a throw-away example proof of concept,
which is certainly very incomplete, and some of my reading yesterday
suggests that it's actually not very well structured either. I've
probably already made a fool of myself to any actual YANG experts,
that ever try to read it, but such are the risks of posting public
comments... :)
</jh>

2) multicast support (I find your conclusion that not much needs to = change interesting! Though the example you're giving (joining an SSM cha= nnel) is only a part of what we'd need, as you also say...)
<jh>
Fair point, this really is a separate topic. I brought it up
really only because it's a motivating factor in my participation
here, not because it's a primary factor for taps in general. Let's
drop it for this thread, and I'll plan to raise it as a separate
issue when the yang questions are settled and I've got something
more thought out.
</jh>

3) applying preferences to addresses and port numbers (which you see= m to take for granted in your draft, but which I don't think is supported= by our current document).

<jh>
Yes, this is a case in point for my concerns about incompleteness
on the Endpoint specifications.

I wasn't sure how to treat this, so I'm not surprised if I got it
wrong. I was sort of pattern-matching on the rest of what the spec
does, plus guessing at intended meanings of this paragraph from
https://tools.ietf.org/html/draft-ietf-taps-= interface-02#section-5.1:

Multiple endpoint identifiers can be specified for each Local
Endpoint and Remote Endpoint. For example, a Local Endpoint could be<= br> configured with two interface names, or a Remote Endpoint could be
= specified via both IPv4 and IPv6 addresses. These multiple
identifiers refer to the same transport endpoint.

By the time I finished making the examples, I had noticed I was
maybe doing it wrong, but I didn't want to bother fixing it unless
people agree it's worth spending effort in this general direction, and I didn't want to hold off on opening the discussion. Of course, it
should be changed to match the consensus of the wg on what belongs
here.
</jh>

Side note: unless I'm mistaken, this wouldn't fit our structure well:= e.g. a port number would then be a Transport Property that has a certain= value, but also has a preference, but currently we say that a Transport = Property has "one of a set of data types", one of which is a Preference. = Isn't that structure too limiting? Or am I missing something?

<jh>
I'm not sure. This is part of what I mean when I say I find the
current taps-interface a little too loose. I _think_ what I posted
is a valid (though perhaps not optimal) interpretation of the current
= text. I might be wrong about that, so I'd be grateful for a pointer
to the text that prohibits this interpretation.

But really, that's beside the point. I'd be even more grateful for an alternate proposal that more closely matches the intended design for
a taps API, with the same level of concreteness.
</jh>

I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) as= separate... maybe there are other use cases for 3) alone ?

<jh>
Yes, I think so. I think I understand an ultimate goal for taps to
be "as an app designer, don't worry about which transport, just
send the magic API to go discover one that works".

However, it seems to me in the interim that it'll be necessary
to specify port numbers in order to interoperate with a lot of
existing services, especially in cases like RTP (or a lot of
other generalized UDP stuff), where there's not an explicit
service-to-port mapping. (Also to interoperate with a lot of
other deployed systems like firewalls.)

I have a few nebulous ideas about how explicit layering might be a
good way to solve this, but I think in order to make the ideas sharp
enough to evaluate, I thought I'd first try the easier task of making
= taps sharp enough that I can express the ideas as proposed changes
to an existing well-formed concept.
</jh>

IMO, all of these things are interesting, and would be good to discus= s on site. However, I doubt that we can deal with them all in only 15 min= utes :-)

<jh>
Fair point.

I propose during the taps meeting to check preliminary consensus about moving forward with a YANG model within taps, and if so whether to
integrate, replace, or make a paired doc with the existing taps-interface= =2E
Separately, I'll encourage those interested and available to spend some time in offline clarifying discussion during the week prior.

Cheers,
Jake
</jh>

Cheers,
Michael

PS: Travis is down, or something. At least the "Editor's Copy" links = don't currently work.



> On 7 Mar 2019, at 04:55, Holland, Jake <jholland@akamai.com&g= t; wrote:
>
> Hi taps,
>
> (Trying again, but simpler.)
>
> I'm looking for a consensus yes or no answer:
>
> Is a normative config input format an interesting and useful
= > direction?
>
>
> The idea is to add functionality like this, in taps-interface: >
> newPre =3D PreConnection.NewFromJson('''{
> "remote-endpoint":{
> "hosts":[
> { "host":"example.com" }
> ]
> }
> }''')
>
> With a fully specified json input format that can provide all th= e
> configurable values.
>
>
> If no, I'll move on and assume I just don't understand taps goal= s.
>
> If yes, I'd like 15 minutes to discuss in Prague, and keep readi= ng:
>
> I think a full definition of an input json format can be exactly=
> specified by a YANG model. (With xml for free, if you want it.)<= br> >
> I tried to sketch a start at what a YANG model for this might lo= ok like:
> https://tools.ietf.org/html/draft-= jholland-taps-api-yang-00#section-3
>
> I'm not a YANG expert yet, and it's not much of a model. And it= 's very
> far from complete. But it compiles, and all the examples in the= draft
> validate against that model with libyang. If it's worthwhile, I= think
> something like this can be good (and extensible!), if done right= =2E
>
> I believe something along these lines would sharpen up taps-inte= rface
> a lot. (After filling in all the taps-interface properties.)
= >
>
> The reason I'm asking is because right now, taps-interface to me=
> seems _almost_ really good, except too confusing and vague to ac= tually
> build an API that can replace BSD sockets. I think with a solid= config
> format with normative and testable examples, that could be fixed= =2E
>
> If consensus says "interesting", I'll want 15 minutes to discuss= it, and
> to start digging into how to make it good. (And also to add mul= ticast
> support to the model and at least one implementation.)
>
> Thanks for your consideration.
>
>
> Cheers,
> Jake
>
>
>
> On 2019-03-04, 17:19, "Holland, Jake" <jholland@akamai.com>= ; wrote:
>
> Hi taps folks,
>
> TL;DR: I think the spec should have a YANG model and I want t= o use it
> to get multicast support in an implementation.
>
>
> I recently started digging into the taps API with the intent = of adding
> multicast support, but it looks like it's basically already t= here, as
> far as it goes[*].
>
> But I ended up with a higher-level comment, so I thought I'd = raise it
> to the wg and ask what you all think.
>
> I found the whole "abstract interface" approach a little too<= br> > loosey-goosey, so I thought I'd try to suggest a way to tight= en it up.
>
> My goal with this is to make it much more clear (to the point= of being
> mechanically checkable) precisely what a compliant API provid= es.
>
> I'm not attached to the structure I'm proposing or to any of = the
> particulars in the straw-man I've posted, but if it's not tig= htened up
> with something at a similar level of concreteness, I'm concer= ned that
> different implementations will be not only incompatible in ra= ndom
> underspecified corner cases (like BSD sockets today when you = try to make
> cross-platform C code), but also are likely to end up with ve= ry many
> important differences that would make the whole taps effort m= ore or less
> moot.
>
> In a world where we end up with a doc at the level of abstrac= tion I'm
> currently seeing in draft-taps-interface, it seems to me that= if 2
> different API implementations were written in the same langua= ge, it'll
> be prohibitively difficult for an app to migrate from using o= ne to using
> the other, just because so many aspects of it are left open t= o the
> implementors.
>
> In that context, I thought a YANG model would be useful here = to
> provide a cross-platform way to specify what exact properties= and
> objects exist, an exact format in which the values can be spe= cified, and
> what exact semantics they have, while still allowing for a sa= ne
> extension path and language-specific implementation details.<= br> >
> I'm thinking some language a bit like the first bullet in Sec= tion 4.2 of
> taps-interface:
>
> A compliant implementation SHOULD provide a language-approp= riate way to
> configure a PreConnection using YANG instance data for this= model, and
> SHOULD provide an API that outputs the YANG instance data f= or an
> established Connection.
>
> An implementation MAY also provide appropriate APIs for dir= ectly editing
> the objects without using YANG. It's RECOMMENDED where pos= sible to use
> names that mechanically translate to the names in the YANG = data model,
> using capitalization and punctuation conventions as expecte= d for the
> language of the implementation.
>
> And then of course a YANG model:
> https://datatracker.ietf.org/doc/draft= -jholland-taps-api-yang/
> (draft-jholland-taps-api-yang)
>
> If this seems useful, it will need lots of refining. I'll be= surprised
> if any part of it survives exactly as written. It's a quick = and
> dirty attempt to concretize a few of the things I saw listed = in
> draft-ietf-taps-interface, as a starting point to fill out if= it seems
> useful.
>
> But the model parses, and the example data instances in the d= raft
> parse against the model (all with libyang).
>
> One of the main reasons I'm doing this is because it seems to= me what's
> specified in taps-interface-02 today is missing some key feat= ures, like
> an enumeration of the properties in the Local/RemoteEndpoint = examples in
> section 5.1. And I don't see that listed as an open issue in= github,
> which surprised me a bit.
>
> I think oversights like this will become immediately and pain= fully
> obvious when there's a reference implementation that includes= a YANG
> parser and an explicit data model, as opposed to the combing = of the
> document and a sort of eyeballed comparison to NEAT that I tr= ied
> this week to reach that conclusion (which I found challenging= even
> though I thought both the document and the library were mostl= y pretty
> well written).
>
> The whole thing at this point just smells to me much more abs= tract than
> it really has to be or than it's really useful to be, which b= others me
> because the idea of replacing BSD sockets with something usab= le seems
> like such a great idea. I'd like this to be something I can = actually
> use in a way that makes my life easier someday soon.
>
> But I think I'm at the point where I need a sanity check to s= ee if I'm
> just missing something, or if this seems like a useful direct= ion.
>
> Thoughts? Suggestions? Worth discussing in Prague? (If so= , can I
> get a slot?)
>
> Cheers,
> Jake
>
> *:
> I concluded that there's no reason multicast couldn't be supp= orted
> today, if there were an implementation that could reasonably = claim to be
> compliant, by just adapting some of the examples in
> draft-ietf-taps-interface-02 and understanding the semantic m= eaning of
> multicast address spaces inside the API.
>
> For example, I couldn't find any reason this can't be expecte= d to set
> up an SSM channel subscription without any further ado, given= a sane
> implementation that supports it:
>
> RemoteSpecifier :=3D NewRemoteEndpoint()
> RemoteSpecifier.WithIPv4Address(192.0.2.21)
>
> LocalSpecifier :=3D NewLocalEndpoint()
> LocalSpecifier.WithPort(30000)
> LocalSpecifier.WithIPv4Address(232.252.0.2)
>
> NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(..= =2E)
>
> Maybe there's some value in specifying a "JoinSSM()" to overr= ide defaults
> in the PreConnection, just to make sure you're specifically a= sking for
> multicast. I think that would be fine for native multicast, = but like I
> said, a much smaller point than the looseness of the API.
= >
> Where it gets a bit more complicated is trying to handle mult= iple options
> for discovering a usable unicast tunnel for multicast traffic= , as
> described in Section 2.4.1 of draft-ietf-mboned-driad-amt-dis= covery-01.
>
> I'd like to have a decent place to tack on an extension to th= is API that
> can transparently, within the connection API, discover the be= st available
> AMT relay and start using it when native joining is unavailab= le (and also
> to provide normative controls for configuring it when there's=
> administrative configuration to be added).
>
> But that's a 2nd order question for me at this point, because= in the
> current TAPS API I don't see any obviously good spot to put s= election
> controls for that kind of tunnel discovery selection, or real= ly a good
> way to explain what it's supposed to do, if I tried to add co= ntrols to
> something that's there.
>
> Solving that is my main motivation for being here. (Well, an= d that
> the BSD socket API for multicast is kind of a disaster today.= )
>
> Anyway, if taps finds the whole YANG suggestion useful, I'll = probably
> suggest some new extensions about this, and maybe a few other= points,
> especially maybe around trying to put in a structure that can= support
> some kind of sane explicit layering.
>
> But I'm not sure I can articulate those suggestions in a way = I'm sure is
> meaningful without first getting a more clear specification n= ailed down
> about what's actually in the taps spec. Because right now I'm= mostly
> just confused about what an API implementation would really l= ook like,
> and how you could tell whether it matches the taps-interface = spec.
>
>
>
> From: Aaron Falk <aaron.falk@gmail.com>
> Date: 2019-03-04 at 10:53
> To: taps WG <taps@ietf.org>
> Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com&= gt;
> Subject: [Taps] call for agenda items at TAPS IETF-104
>
> Hi All-
> What should we use our time to discuss? Let=E2=80=99s focus o= n things that would benefit from f2f discussion, consensus building, or j= ust argument. :)
> =E2=80=A2 TAPS docs: are there open topics that need group at= tention? Seems like we settled most of the remainder at the interim.
> =E2=80=A2 TAPS security: this seems nearly done. Anything to = discuss?
> =E2=80=A2 Implementations: a good topic for information shari= ng but less important than anything needing agreement
> =E2=80=A2 Mobility: https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Ddmm-2Dondemand-2Dmobilit= y-2D17&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbqnFROivDo_4= iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7J= u2BgM2rpQo&s=3DHUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5wd3D5_s&e=3D and https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_review-2= Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dwesterlund-2D2019-= 2D01-2D08_&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbqnFROiv= Do_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=3DpLW5gSyetfVe_ixG4_u7qKX_VcjIq= zN7Ju2BgM2rpQo&s=3D0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e=3D=
> --aaron
>
>
>
> _______________________________________________
> 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

--=_MailMate_72DE4123-A867-4751-B300-DA4767929743_=-- From nobody Thu Mar 7 13:13:11 2019 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 DBEE21275E9 for ; Thu, 7 Mar 2019 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 A0Q_DPp-IRCJ for ; Thu, 7 Mar 2019 13:13:08 -0800 (PST) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 8C9EF12D4EB for ; Thu, 7 Mar 2019 13:13:08 -0800 (PST) Received: by mail-yw1-xc2d.google.com with SMTP id d129so688132ywe.10 for ; Thu, 07 Mar 2019 13:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=N2BiNPNFiDpoR2z7bJn+veLY8GTyWg37/jiUXaQFqqg=; b=FjVZ1TGvKAEbYO/dyuoZrL4kViKqsBkPoZZyp5sY8snJw6agX6o/OpAzYlHLWtLzH9 KUd4BTptIjXkleWVbsM0HE3yVxMe4f00Gp3C4JoVJDsDtp0PiAWax2QEQl3gqmZcCCPo 0sxl+bSRhjG6K06WsZHUcyDg3zrNSLJTIO2vlf1oNNbmfVVJ03MZGSbPKmvD0u8LBg57 LixmoMF+aCRrBDQ3qwC3mZTGbcxN54ajApXuX69XmuuOPI+SYNtzSxbAYNxyRMwEpKov Dtdoi+neIdkecXwtUbGXTIgiAjtFR14ifYkAh+XYWFivkhN2md5wE01BysCGRwS6wqGh 4blw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=N2BiNPNFiDpoR2z7bJn+veLY8GTyWg37/jiUXaQFqqg=; b=SGpd60hZtcfo92IvqcZiwbHNHPsbHycwcAzM07dVViNIgVvFtOpahuZ8THexpjsZ+l VqMS+xDbadpVY6AZZ4yY9guMOLoXdDXLYwR8Uh3edD1WFfvWDUYNcTDl9bLISB3kJU5G wI45iKIqoU+NjKHEcNweiu0by4idZj+AXKy9YXkwYuTzc9/1gMs7pWuGgKEwHqfCCr97 COgAT0jBgJ4Th87nRvXMJvXmmZsZv2Upy4F18ym31aAd8HCYLy9uBIKOshy6jsv/kHcg KhUKV7aufWbHZkj8EfKtnAMw3JCyMH36JJry4XEciZUf6UTvOUscxk45EcYdYmduSsqg BC1Q== X-Gm-Message-State: APjAAAWqkDRlbz09N8ReTRw4YX+arfhdJN1ni16Rn/Vww/5+KPZtFv/J IBqIsG7GrkmRVefwDp7OB8qtTLeCeauO6QruHW4= X-Google-Smtp-Source: APXvYqwdkPAgnRKnCHGod7IhDeRX366a3utpq5DF/rwxdDxxze3tfLg7udQa1lBG7hAxUkRQ1QO4y8q3gehgz+bX7fI= X-Received: by 2002:a25:7650:: with SMTP id r77mr12763280ybc.206.1551993187623; Thu, 07 Mar 2019 13:13:07 -0800 (PST) MIME-Version: 1.0 References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> In-Reply-To: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> From: Christopher Wood Date: Thu, 7 Mar 2019 13:12:56 -0800 Message-ID: To: Aaron Falk Cc: taps WG , Zaheduzzaman Sarker Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 21:13:10 -0000 On Mon, Mar 4, 2019 at 10:53 AM Aaron Falk wrote: > > Hi All- > > What should we use our time to discuss? Let=E2=80=99s focus on things tha= t would benefit from f2f discussion, consensus building, or just argument. = :) > > TAPS docs: are there open topics that need group attention? Seems like we= settled most of the remainder at the interim. > TAPS security: this seems nearly done. Anything to discuss? Yes, this is essentially done. We should WGLC it after the next revision is submitted. I'll do that soon. Best, Chris > Implementations: a good topic for information sharing but less important = than anything needing agreement > Mobility: non-TAPS draft on API & mobility and incoming TSV AD suggestion= to collaborate > > --aaron > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Mar 7 13:15:50 2019 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 46CD21275E9 for ; Thu, 7 Mar 2019 13:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.757 X-Spam-Level: X-Spam-Status: No, score=0.757 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, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 jpV6yt4Ful6X for ; Thu, 7 Mar 2019 13:15:43 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5457112DF72 for ; Thu, 7 Mar 2019 13:15:43 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x27L37wc005239; Thu, 7 Mar 2019 21:15:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=W/25Lp0hmVCTZPf07DuRljk6OXgcRaCJ7B+U4Gxrgqg=; b=luNzltsAqRa68AxjiBE5CZfyLoWhDJycZDpNe9ZbOsq8AgQU+UybhAPXJYyVpoMbQP3Z /fKCZCssDs5bs8WchUES3hMQosFTucSGkxWgKHvGY2+1rGKy8l1zffmEWjhnurGyhWWr LuQjqDE6Cti3VV/TFTeGZHCag4jxtguCt4acL/6S1d/noPoZh8z161gkVpOoaQap2enx wUDmj4uLITSvWmhiWLZRHoUUD9AAHdJ24ePsk8xFCOdbqxaACjSmoeUuKxgToyaceSrV xVnxWa4b0TxMpgpKHe9KAtmQpyBP/bqG8f1AoweUZ1vmgT8VBg7Xi4WPTfbQLzZqTpdA UA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2r2uqwk3sr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Mar 2019 21:15:41 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x27L20Q3010557; Thu, 7 Mar 2019 16:15:40 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2qyp232wtq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Mar 2019 16:15:37 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 15:15:33 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Thu, 7 Mar 2019 15:15:33 -0600 From: "Holland, Jake" To: Aaron Falk CC: taps WG , Michael Welzl Thread-Topic: [Taps] call for agenda items at TAPS IETF-104 Thread-Index: AQHU0ruJg/BpMSiZnkS1XjtUnIdzOKX8G+mAgAM/gYCAANNpgIAAPQgAgACjQID//3+yAA== Date: Thu, 7 Mar 2019 21:15:32 +0000 Message-ID: References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> <852D2DBC-3C7D-4D54-82CB-0956F3844E58@gmail.com> In-Reply-To: <852D2DBC-3C7D-4D54-82CB-0956F3844E58@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.22] Content-Type: multipart/alternative; boundary="_000_E66700D441F64C9AB2F29DE6519C9C5Cakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070140 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 07 Mar 2019 21:15:48 -0000 --_000_E66700D441F64C9AB2F29DE6519C9C5Cakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWFyb24sDQoNCkxldOKAmXMgdGFrZSAxNSBtaW51dGVzIG9uIHRoZSBhZ2VuZGEgZm9yIGp1 c3QgWUFORy4NCg0KSWYgdGhlcmXigJlzIHRpbWUsIEkgd291bGQgYWxzbyBiZSBoYXBweSB0byB0 YWtlIDEwIG1pbnV0ZXMgb24gbXVsdGljYXN0LCBidXQgd2l0aCBhIGxvd2VyIHByaW9yaXR5IG9u IHRoZSByZXF1ZXN0LiAgVGhlcmXigJlzIGEgYmV0dGVyIGNoYW5jZSBJIGNhbiBjb3ZlciB0aGF0 IG9uIHRoZSBsaXN0IG9yIGluIG9mZmxpbmUgZGlzY3Vzc2lvbi4NCg0KVGhhbmtzLA0KSmFrZQ0K DQpGcm9tOiBBYXJvbiBGYWxrIDxhYXJvbi5mYWxrQGdtYWlsLmNvbT4NCkRhdGU6IDIwMTktMDMt MDcgYXQgMTI6NTQNClRvOiAiSG9sbGFuZCwgSmFrZSIgPGpob2xsYW5kQGFrYW1haS5jb20+DQpD YzogdGFwcyBXRyA8dGFwc0BpZXRmLm9yZz4sIE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZpLnVp by5ubz4NClN1YmplY3Q6IFJlOiBbVGFwc10gY2FsbCBmb3IgYWdlbmRhIGl0ZW1zIGF0IFRBUFMg SUVURi0xMDQNCg0KDQpKYWtlLQ0KDQpJ4oCZbSB1bmNsZWFyLCBkbyB5b3Ugd2FudCB0byBkaXNj dXNzIG11bHRpY2FzdCBpbiBQcmFndWUgb3IganVzdCBZQU5HPw0KDQotLWFhcm9uDQoNCk9uIDcg TWFyIDIwMTksIGF0IDE0OjEwLCBIb2xsYW5kLCBKYWtlIHdyb3RlOg0KDQpIaSBNaWNoYWVsLA0K DQpUaGFua3MgZm9yIHJlc3BvbmRpbmcsIG11Y2ggYXBwcmVjaWF0ZWQuIChBbmQgYWxzbyB0byBU b21teQ0KYW5kIEFhcm9uLikNCg0KQmFzZWQgb24gdGhlIHJlcGxpZXMgZnJvbSB5b3UsIFRvbW15 LCBhbmQgQWFyb24sIEknbGwgcGxhbg0KdG8gcHJlc2VudCBzb21ldGhpbmcgaW4gUHJhZ3VlLCBh bmQgY2FuIHlvdSBwbGVhc2UgcHV0IG1lDQpvbiB0aGUgc2NoZWR1bGUsIEFhcm9uPw0KDQpNb3Jl IHJlc3BvbnNlcyBpbmxpbmUgd2l0aCA8amg+PC9qaD4sIGFuZCB0aGFua3MsIHRoZXNlDQpxdWVz dGlvbnMgd2VyZSB2ZXJ5IGhlbHBmdWwgdG8gaGVscCBtZSBmb2N1cyBvbiB3aGF0IG5lZWRzDQpl eHBsYWluaW5nIHZzLiB3aGF0J3Mgb2J2aW91cy4NCg0KDQpPbiAyMDE5LTAzLTA3LCAwMDozMiwg Ik1pY2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KDQpIaSwNCg0KVmVy eSBzb3JyeSBmb3IgdGhlIHNpbGVuY2UuIEkgY2FuIG9ubHkgc3BlYWsgZm9yIG15c2VsZiwgYnV0 IGhlcmUncyBhbiBleGFtcGxlIG9mIHdoeSB0aGlzIG9uZSBwZXJzb24gd2FzIHNpbGVudDoNCi0g V2hlbiB5b3UgY3JlYXRlZCB5b3VyIGlzc3VlIG9uIG11bHRpY2FzdCBpbiBnaXRodWIsIEkgdGhv dWdodCBvZiBhbnN3ZXJpbmcgKHBvc2l0aXZlbHkpLCBidXQgdGhlbiB0aG91Z2h0IHRoYXQgdGhl IHJlcG8gaXMgYWJvdXQgdG8gbW92ZSwgYW5kIGl0IHdvdWxkIHByb2JhYmx5IGJlIGJldHRlciB0 byBkZWxheSB0aGluZ3MgdW50aWwgdGhlIG1vdmUgaXMgZmluaXNoZWQuDQotIFRoZW4sIHRoZSBp c3N1ZSB3YXMgb3ZlcnJ1bGVkIGJ5IHlvdXIgZW1haWwuIEkgcmVhZCBpdCBhbmQgZm91bmQgaXQg aW50ZXJlc3RpbmcsIGJ1dCBob3BlZCBmb3Igc29tZW9uZSBlbHNlIHRvIGFuc3dlciBiZWNhdXNl LCBmcmFua2x5LCBJIHdhcyBhZnJhaWQgdG8gbWFrZSBhIGZvb2wgb2YgbXlzZWxmIC4uLiBiZWNh dXNlIEkga25vdyBhbG1vc3Qgbm90aGluZyBhYm91dCBZQU5HLg0KDQo8amg+DQpUaGFua3MgZm9y IGV4cGxhaW5pbmcsIEknbSBzeW1wYXRoZXRpYyBhbmQgZ3JhdGVmdWwgdGhhdCB5b3UNCm92ZXJj YW1lIHlvdXIgY29uY2VybnMuIEkgd2FzIGluIHRoZSBzYW1lIHBsYWNlIG9uIFlBTkcgbm90DQp0 b28gbG9uZyBhZ28sIGFuZCBJIHN0aWxsIGhhdmUgYSB3YXlzIHRvIGdvLCB0aG91Z2ggSSBub3cg dGhpbmsNCkkgc2VlIHNvbWUgb2YgaXRzIHByb21pc2UuDQoNCkJ1dCBJIGRvbid0IHRoaW5rIEkg Y3JlYXRlZCBhIG11bHRpY2FzdCBpc3N1ZSBvbiBnaXRodWI/IEkganVzdA0Kbm90aWNlZCBhIGZl dyBuaXRzIHdoaWxlIHJlYWRpbmcgYW5kIHNlbnQgYSBwdWxsIHJlcXVlc3QsIG5vdGhpbmcNCnJl YWxseSBzdWJzdGFudGlhbCB5ZXQuDQo8L2poPg0KDQpCdXQgbm93IEknbGwgYmUgYnJhdmUgOikg SSdsbCBnbyBhaGVhZCBhbmQgYXNrOiBob3cgZXhhY3RseSBpcyB0aGlzIFlBTkcgcHJvcG9zYWwg bW9yZSB0aGFuIGp1c3QgYSBzeW50YXggY2hhbmdlPyBXaGF0IHdvdWxkIGl0IGdpdmUgdXM/DQoo SSB1bmRlcnN0YW5kIHRoYXQgWUFORyBjYW4gYmUgYXV0b21hdGljYWxseSBwYXJzZWQgLyBjaGVj a2VkIGJ5IHNvbWUgdG9vbHMsIGJ1dC4uLiB3aGF0IGRvZXMgVEhBVCBnaXZlIHVzPykNCg0KPGpo Pg0KU3ludGF4IHBsdXMgdG9vbCBzdXBwb3J0IGlzIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2Vl biBtYWNoaW5lIGNvZGUNCmFuZCA8eW91ciBmYXZvcml0ZSBwcm9ncmFtbWluZyBsYW5ndWFnZT4s IHNvIGV2ZW4gaWYgdGhhdCdzIHRoZSBvbmx5DQp0aGluZyB3ZSBnb3QsIGl0J3Mgbm90IHRvIGJl IHNuZWV6ZWQgYXQuIChBbmQgdGhlcmUgaXMgYSBsb3Qgb2Ygcm9vbQ0KZm9yIGdyb3d0aCBoZXJl LCBidXQgdGhlcmUgYXJlIGFscmVhZHkgdG9vbHMgdGhhdCBjYW4gZ2VuZXJhdGUgQVBJDQpoZWFk ZXIgY29kZSBmcm9tIHlhbmcsIGUuZzoNCmh0dHBzOi8vd2lraS5vbm9zcHJvamVjdC5vcmcvZGlz cGxheS9PTk9TL1lBTkcrVG9vbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193aWtpLm9ub3Nwcm9qZWN0Lm9yZ19kaXNwbGF5X09OT1NfWUFORy0y QlRvb2xzJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWJxbkZST2l2RG9fNGlG OFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1MY3pQTS1XYy1qMkticWQzQ0FlRG9UeUtY aVhvTXplcFI3TURkczFBcHlBJnM9YTVZSm42NHEwUGZ5c2tJZWxwT3RKa2I1Y0hTZ0JBNE5OVFFa S3FxNkxiSSZlPT4gKQ0KDQpCdXQgSSdtIGFjdHVhbGx5IHB1c2hpbmcgZnJvbSB0aGUgb3RoZXIg ZGlyZWN0aW9uOyBteSB1bmRlcnN0YW5kaW5nDQpvZiB0aGUgY3VycmVudCBkb2NzIGlzIHRoYXQg dGFwcy1hcmNoIGlzIGEgaGlnaCBsZXZlbCBkZXNpZ24gYW5kIGdvYWxzDQpkb2N1bWVudCwgYW5k IHRhcHMtaW50ZXJmYWNlIChhbmQgdGFwcy1taW5zZXQpIG1ha2UgYW4gYXR0ZW1wdCB0bw0KbGF5 IG91dCB0aGUgY29uY3JldGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0aGF0IHdvdWxkIG1ha2Ug dGFwcy1hcmNoIGENCnJlYWxpdHksIGlmIGFuIGltcGxlbWVudGF0aW9uIGNvdmVycyB0aGVtLg0K DQpNeSBjbGFpbSBoZXJlIGlzIHR3b2ZvbGQ6DQotIHRoYXQgdGFwcy1pbnRlcmZhY2UgYXMgaXQg c3RhbmRzIHRvZGF5IGlzIGFub3RoZXIgaGlnaCBsZXZlbCBkZXNpZ24NCmRvY3VtZW50LCB3aGlj aCB3aWxsIGhhdmUgYSBuZWNlc3NhcmlseSBmdXp6eSBtYXBwaW5nIHRvIGFueSBhY3R1YWwNCmlt cGxlbWVudGF0aW9uLg0KLSB0aGF0IHRhcHMtaW50ZXJmYWNlIGlzIF9yZWFsbHlfIF9jbG9zZV8g dG8gbGF5aW5nIG91dCB0aGUgY29uY3JldGUNCmltcGxlbWVudGF0aW9uIGRldGFpbHMgaW4gYSBu b24tZnV6enkgd2F5IHRoYXQgY2FuIGJlIGRpcmVjdGx5IHVzZWQNCmJ5IGltcGxlbWVudG9ycywg c28gSSdtIHN1Z2dlc3RpbmcgdGhhdCB0YWtpbmcgdGhhdCBleHRyYSBzdGVwIGlzDQpoaWdobHkg dmFsdWFibGUuDQoNCk9uIHRoZSBxdWVzdGlvbiBvZiBiZW5lZml0czogSSdsbCBsYXkgb3V0IHNv bWUgb2YgdGhlIG9uZXMNCnRoYXQgc2VlbSBpbXBvcnRhbnQgdG8gbWUsIGJ1dCBJJ2xsIGZpcnN0 IHNheSB0aGF0IGluIHRoZW9yeSwNCnRoZXNlIGJlbmVmaXRzIGNvdWxkIGJlIHJlYWxpemVkIGJ5 IGFueSBjb25jcmV0ZSBjb25maWd1cmF0aW9uDQpmb3JtYXQuIFRoZSBiZW5lZml0IG9mIFlBTkcg c3BlY2lmaWNhbGx5IGNvbWVzIGZyb20gdG9vbA0Kc3VwcG9ydCBhbmQgdGhlIGNvbmZpZGVuY2Ug ZnJvbSBleGlzdGluZyB3b3JrIHRoYXQgbWFrZSBpdCBjbGVhcg0KaXQncyBhIHJlYXNvbmFibGUg Zm9ybWF0IGZvciBuZXR3b3JraW5nIGNvbmZpZ3VyYXRpb24uDQoNCkJhc2ljYWxseSwgYmVjYXVz ZSB0aGVyZSdzIHNvIG11Y2ggWUFORyB3b3JrIGFscmVhZHkgZG9uZSBmb3INCm5ldHdvcmtpbmcs IHVzaW5nIFlBTkcgbGV0cyB1cyBsZXZlcmFnZSBzb21lIG9mIHRoYXQgd29yayBpbiBhIHdheQ0K b3RoZXIgb3B0aW9ucyBkb24ndC4NCg0KSW4gcGFydGljdWxhciwgdGhlcmUgYXJlIGEgYnVuY2gg b2YgbmV0d29ya2luZy1zcGVjaWZpYyBjb25jZXB0cw0KdGhhdCBhcmUgYWxyZWFkeSBkZWZpbmVk IGluIGRldGFpbC4gRm9yIGV4YW1wbGUsIHRoZSBpcHY2LWFkZHJlc3MNCnR5cGUgaGFzIGEgY29t cGxpY2F0ZWQgcmVnZXggdGhhdCBtYW55IGltcGxlbWVudG9ycyBhcmUgbGlrZWx5IHRvDQpnZXQg d3JvbmcgaWYgdGhleSB0cnkgdG8gcm9sbCB0aGVpciBvd24gKGF0IGxlYXN0LCBJJ3ZlIGNlcnRh aW5seQ0KZG9uZSBzbywgYW5kIHNlZW4gaXQgYSBidW5jaCBvZiB0aW1lcyk6DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjk5MSNwYWdlLTE5PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM2OTkx LTIzcGFnZS0yRDE5JmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWJxbkZST2l2 RG9fNGlGOFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1MY3pQTS1XYy1qMkticWQzQ0Fl RG9UeUtYaVhvTXplcFI3TURkczFBcHlBJnM9WEtPdzJqb3hSSUNVWmVsU3FiRkI1OUxoeTFLS2NS a0NhZGNMd0xVaXhmbyZlPT4NCg0KQnV0IGJ5IG1ha2luZyB0aGUgb2J2aW91cyBjaG9pY2Ugb2Yg dXNpbmcgeWFuZyB0b29scyB0byBwYXJzZSB5YW5nDQpzdHVmZiwgaW1wbGVtZW50b3JzIGF1dG9t YXRpY2FsbHkgZ2V0IGNoZWNraW5nIGFnYWluc3QgdGhhdA0KKG5vcm1hdGl2ZSEpIHJlZ2V4IGZv ciBmcmVlIHdpdGhvdXQgaGF2aW5nIHRvIG5vdGljZSBhbmQgY2hlY2sgaXQNCnRoZW1zZWx2ZXMu DQoNClRoZXJlJ3Mgb3RoZXIgc2lkZSBiZW5lZml0cywgbGlrZSB0aGF0IGludGVyZmFjZXMgYXJl IHRoZW1zZWx2ZXMNCmV4cGxpY2l0bHkgZGVmaW5lZCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzgzNDMjc2VjdGlvbi01PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM4MzQzLTIzc2VjdGlvbi0y RDUmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9YnFuRlJPaXZEb180aUY4WjNS NER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZtPUxjelBNLVdjLWoyS2JxZDNDQWVEb1R5S1hpWG9N emVwUjdNRGRzMUFweUEmcz1GcFFQV1FFX3RtN0Zhb0lKa093YnVWenlBaWVISWxfdEpZWDNqdFBm bjVjJmU9PiksDQphbmQgc28gd2hlcmUgdGhpbmdzIGxpa2UgaW50ZXJmYWNlIHR5cGVzIG1pZ2h0 IGJlIHVzZWQsIHRoZSBwYXN0DQphbmQgZnV0dXJlIHdvcmsgb2YgcGVvcGxlIHdobyBmb3JtYWxp emUgYW5kIGV4dGVuZCB0aGUgc2V0IG9mDQppbnRlcmZhY2UgdHlwZXMgZ2V0cyBhdXRvbWF0aWNh bGx5IGltcG9ydGVkIGJ5IHJlZmVyZW5jaW5nIHRoZQ0Kbm9ybWF0aXZlIHlhbmcgZGVmaW5pdGlv biBmb3IgbmV0d29yayBpbnRlcmZhY2VzLg0KDQpCdXQgdG8gbGlzdCBhIGZldyBvZiB0aGUgc3Bl Y2lmaWMgYmVuZWZpdHMgZnJvbSBoYXZpbmcgYW4gZXhwbGljaXQNCmNvbmZpZyBmb3JtYXQ6DQoN Ci0gY3Jvc3MtcGxhdGZvcm0gcG9ydGFiaWxpdHk6DQpJZiBJJ3ZlIGdvdCBhIHByb2dyYW0gdXNp bmcgYSB0YXBzIGFwaSB0aGF0IHRhbGtzIHRvIHNvbWUgc2VydmljZSwNCmFuZCBub3cgSSB3YW50 IHRvIHdyaXRlIGEgbmV3IHByb2dyYW0gaW4gYSBkaWZmZXJlbnQgbGFuZ3VhZ2UgdG8gdGFsaw0K dG8gdGhhdCBzZXJ2aWNlLCBJIGNhbiBleHBvcnQgdGhlIGNvbmZpZyBhbmQgbG9hZCBpdCBpbiBt eSBuZXcNCnByb2dyYW0gKGV2ZW4gaW4gYSBuZXcgbGFuZ3VhZ2UpLCBhbmQgSSBjYW4gYmUgcmVh c29uYWJseSBzdXJlDQppdCdsbCBmb3JtIHRoZSBzYW1lIGtpbmQgb2YgY29ubmVjdGlvbi4NCg0K QWx0aG91Z2ggaXQncyBwb3NzaWJsZSB0byBtYWtlIGl0IHdvcmsgYW55d2F5IGFzIGxvbmcgYXMg dGhlIEFQSXMNCmhhdmUgYSAxLXRvLTEgbWFwcGluZywgbm9ybWFsaXppbmcgb24gYSBjb25maWcg ZmlsZSBmb3JtYXQgaW5zdGVhZA0Kb2YgYSBsaXN0IG9mIGZlYXR1cmVzIHNlZW1zIHRvIG1lIGxp a2UgaXQnbGwgc2F2ZSBtZSBwZXJoYXBzIHVwIHRvIGENCmRheSBvciBzbyBvZiBlZmZvcnQgZWFj aCB0aW1lIEkgaGF2ZSB0byBkbyB0aGlzLCB3aGljaCB3aGVuIG11bHRpcGxpZWQNCmJ5IGFsbCB0 aGUgaW1wbGVtZW50b3JzIGluIHRoZSB3b3JsZCBvdmVyIHRoZSBuZXh0IGRlY2FkZSBvciAyLCBz dGFydHMNCnRvIGFkZCB1cC4NCg0KLSB0ZXN0YWJpbGl0eToNCkFnYWluLCB0aGlzIG1vc3RseSBz YXZlcyB0aW1lLCBidXQgYnkgaGF2aW5nIGEgZGVmaW5lZCBpbnB1dCBmb3JtYXQsDQppdCdzIHBv c3NpYmxlIGZvciBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIHRvIHVzZSB0aGUgc2FtZSBzdWl0 ZSBvZg0KdGVzdCBjb25maWd1cmF0aW9uIGZpbGVzIHRvIHZlcmlmeSB0aGUgc2FtZSBpbnRlcnBy ZXRhdGlvbiBvZiB0aGVpcg0KY29udGVudHMuIElmIGVhY2ggaW1wbGVtZW50YXRpb24gaGFzIGl0 cyBvd24gd2F5IG9mIGNvbmZpZ3VyaW5nIHRoZQ0KZmVhdHVyZXMsIGl0J3Mgbm90IGltcG9zc2li bGUgdG8gZGVzaWduIGEgc3VpdGUgdGhhdCBjYW4gdGVzdCB0aGVtLA0KYnV0IGl0J3MgdmFzdGx5 IGhhcmRlci4NCg0KLSBjb21wbGV0ZW5lc3M6DQpPbmUgb2YgdGhlIHBvaW50cyBvZiBjb25mdXNp b24gSSBoYWQgd2l0aCB0YXBzLWludGVyZmFjZSB3YXMgdGhhdCB0aGUNCkxvY2FsL1JlbW90ZUVu ZHBvaW50cyBzZWVtZWQgYm90aCBjcml0aWNhbCB0byBhbiBpbXBsZW1lbnRhdGlvbiBhbmQNCnZl cnkgdW5kZXJzcGVjaWZpZWQuIEFsdGhvdWdoIGl0J3MgcG9zc2libGUgdG8gYWRkcmVzcyB0aGF0 IGJ5IHJhaXNpbmcNCmNvbmNlcm5zIHNwZWNpZmljYWxseSBhYm91dCB0aGUgTG9jYWwvUmVtb3Rl IEVuZHBvaW50cywgSSdtIG5vdCBzdXJlDQp0aGVyZSBhcmVuJ3Qgb3RoZXIgdW5kZXJzcGVjaWZp ZWQgYXJlYXMgb2YgdGhlIHRhcHMtaW50ZXJmYWNlIGRyYWZ0Lg0KDQpJIGV4cGVjdCB0aGF0IGEg cmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGJhc2VkIG9uIHBhcnNpbmcgYSBjb25maWcNCmZvcm1h dCB3b3VsZCB1bmNvdmVyIGFsbCBzdWNoIHVuZGVyc3BlY2lmaWVkIGFyZWFzIG9mIGNvbmZpZ3Vy YXRpb24sDQppZiB0aGUgY29uZmlnIGZvcm1hdCBleGFtcGxlcyBhcmUgdXNlZCB0byBkZXNjcmli ZSBhbGwgdGhlIHN1cHBvcnRlZA0KdXNlIGNhc2VzLg0KDQooU28gcGFydCBvZiBteSBnb2FsIHdp dGggdGhpcyBwcm9wb3NhbCBpcyB0byBzb2x2ZSB0aGlzIHByb2JsZW0gaW4NCnRoZSBnZW5lcmFs IGNhc2UsIHdoaWNoIGltcGxpZXMgdGhhdCBpdCdsbCBhbHNvIGJlIHNvbHZlZCBmb3IgdGhlDQpz cGVjaWZpYyBjYXNlcyBvZiBMb2NhbC9SZW1vdGUgRW5kcG9pbnRzLCB0aG91Z2ggb2YgY291cnNl IHRoZQ0KZGV0YWlscyBmb3IgZWFjaCBpbnN0YW5jZSBvZiBpbmNvbXBsZXRlbmVzcyBhcmUgc2Vw YXJhdGUgdG9waWNzLikNCg0KVGhlcmUgbWlnaHQgYmUgc29tZSBvdGhlciBiZW5lZml0cywgYnV0 IEknbGwgc3RvcCB0aGVyZSwgaG9waW5nIHRoZQ0KcG9pbnQgaXMgc3VmZmljaWVudGx5IGNsZWFy Lg0KPC9qaD4NCg0KQWxzbywgSSBhY3R1YWxseSBzZWUgMyBzZXBhcmFibGUgdGhpbmdzIGJlaW5n IHByb3Bvc2VkIGhlcmU6DQoNCjEpIHRoZSBZQU5HIG1vZGVsDQo8amg+DQpJJ2QgcGhyYXNlIHRo ZSBjdXJyZW50IHN0YXR1cyBvZiB0aGUgcHJvcG9zYWwgYXMgYW4gaW4tcHJpbmNpcGxlDQoidXNl IGEgWUFORyBtb2RlbCIsIHJhdGhlciB0aGFuICJ1c2UgdGhpcyBzcGVjaWZpYyBZQU5HIG1vZGVs Ii4NCg0KVGhlIGN1cnJlbnQgZHJhZnQgaXMga2luZCBvZiBhIHRocm93LWF3YXkgZXhhbXBsZSBw cm9vZiBvZiBjb25jZXB0LA0Kd2hpY2ggaXMgY2VydGFpbmx5IHZlcnkgaW5jb21wbGV0ZSwgYW5k IHNvbWUgb2YgbXkgcmVhZGluZyB5ZXN0ZXJkYXkNCnN1Z2dlc3RzIHRoYXQgaXQncyBhY3R1YWxs eSBub3QgdmVyeSB3ZWxsIHN0cnVjdHVyZWQgZWl0aGVyLiBJJ3ZlDQpwcm9iYWJseSBhbHJlYWR5 IG1hZGUgYSBmb29sIG9mIG15c2VsZiB0byBhbnkgYWN0dWFsIFlBTkcgZXhwZXJ0cywNCnRoYXQg ZXZlciB0cnkgdG8gcmVhZCBpdCwgYnV0IHN1Y2ggYXJlIHRoZSByaXNrcyBvZiBwb3N0aW5nIHB1 YmxpYw0KY29tbWVudHMuLi4gOikNCjwvamg+DQoNCjIpIG11bHRpY2FzdCBzdXBwb3J0IChJIGZp bmQgeW91ciBjb25jbHVzaW9uIHRoYXQgbm90IG11Y2ggbmVlZHMgdG8gY2hhbmdlIGludGVyZXN0 aW5nISBUaG91Z2ggdGhlIGV4YW1wbGUgeW91J3JlIGdpdmluZyAoam9pbmluZyBhbiBTU00gY2hh bm5lbCkgaXMgb25seSBhIHBhcnQgb2Ygd2hhdCB3ZSdkIG5lZWQsIGFzIHlvdSBhbHNvIHNheS4u LikNCjxqaD4NCkZhaXIgcG9pbnQsIHRoaXMgcmVhbGx5IGlzIGEgc2VwYXJhdGUgdG9waWMuIEkg YnJvdWdodCBpdCB1cA0KcmVhbGx5IG9ubHkgYmVjYXVzZSBpdCdzIGEgbW90aXZhdGluZyBmYWN0 b3IgaW4gbXkgcGFydGljaXBhdGlvbg0KaGVyZSwgbm90IGJlY2F1c2UgaXQncyBhIHByaW1hcnkg ZmFjdG9yIGZvciB0YXBzIGluIGdlbmVyYWwuIExldCdzDQpkcm9wIGl0IGZvciB0aGlzIHRocmVh ZCwgYW5kIEknbGwgcGxhbiB0byByYWlzZSBpdCBhcyBhIHNlcGFyYXRlDQppc3N1ZSB3aGVuIHRo ZSB5YW5nIHF1ZXN0aW9ucyBhcmUgc2V0dGxlZCBhbmQgSSd2ZSBnb3Qgc29tZXRoaW5nDQptb3Jl IHRob3VnaHQgb3V0Lg0KPC9qaD4NCg0KMykgYXBwbHlpbmcgcHJlZmVyZW5jZXMgdG8gYWRkcmVz c2VzIGFuZCBwb3J0IG51bWJlcnMgKHdoaWNoIHlvdSBzZWVtIHRvIHRha2UgZm9yIGdyYW50ZWQg aW4geW91ciBkcmFmdCwgYnV0IHdoaWNoIEkgZG9uJ3QgdGhpbmsgaXMgc3VwcG9ydGVkIGJ5IG91 ciBjdXJyZW50IGRvY3VtZW50KS4NCg0KPGpoPg0KWWVzLCB0aGlzIGlzIGEgY2FzZSBpbiBwb2lu dCBmb3IgbXkgY29uY2VybnMgYWJvdXQgaW5jb21wbGV0ZW5lc3MNCm9uIHRoZSBFbmRwb2ludCBz cGVjaWZpY2F0aW9ucy4NCg0KSSB3YXNuJ3Qgc3VyZSBob3cgdG8gdHJlYXQgdGhpcywgc28gSSdt IG5vdCBzdXJwcmlzZWQgaWYgSSBnb3QgaXQNCndyb25nLiBJIHdhcyBzb3J0IG9mIHBhdHRlcm4t bWF0Y2hpbmcgb24gdGhlIHJlc3Qgb2Ygd2hhdCB0aGUgc3BlYw0KZG9lcywgcGx1cyBndWVzc2lu ZyBhdCBpbnRlbmRlZCBtZWFuaW5ncyBvZiB0aGlzIHBhcmFncmFwaCBmcm9tDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10YXBzLWludGVyZmFjZS0wMiNzZWN0aW9uLTUu MTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv b2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEdGFwcy0yRGludGVyZmFjZS0yRDAyLTIz c2VjdGlvbi0yRDUuMSZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1icW5GUk9p dkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJm09TGN6UE0tV2MtajJLYnFkM0NB ZURvVHlLWGlYb016ZXBSN01EZHMxQXB5QSZzPVJqam4zT21ydUNYRGJLd2dEbUFNcUh2bmUtVUhO cWFfZ21Ja19nOXo2YWcmZT0+Og0KDQpNdWx0aXBsZSBlbmRwb2ludCBpZGVudGlmaWVycyBjYW4g YmUgc3BlY2lmaWVkIGZvciBlYWNoIExvY2FsDQpFbmRwb2ludCBhbmQgUmVtb3RlIEVuZHBvaW50 LiBGb3IgZXhhbXBsZSwgYSBMb2NhbCBFbmRwb2ludCBjb3VsZCBiZQ0KY29uZmlndXJlZCB3aXRo IHR3byBpbnRlcmZhY2UgbmFtZXMsIG9yIGEgUmVtb3RlIEVuZHBvaW50IGNvdWxkIGJlDQpzcGVj aWZpZWQgdmlhIGJvdGggSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMuIFRoZXNlIG11bHRpcGxlDQpp ZGVudGlmaWVycyByZWZlciB0byB0aGUgc2FtZSB0cmFuc3BvcnQgZW5kcG9pbnQuDQoNCkJ5IHRo ZSB0aW1lIEkgZmluaXNoZWQgbWFraW5nIHRoZSBleGFtcGxlcywgSSBoYWQgbm90aWNlZCBJIHdh cw0KbWF5YmUgZG9pbmcgaXQgd3JvbmcsIGJ1dCBJIGRpZG4ndCB3YW50IHRvIGJvdGhlciBmaXhp bmcgaXQgdW5sZXNzDQpwZW9wbGUgYWdyZWUgaXQncyB3b3J0aCBzcGVuZGluZyBlZmZvcnQgaW4g dGhpcyBnZW5lcmFsIGRpcmVjdGlvbiwgYW5kDQpJIGRpZG4ndCB3YW50IHRvIGhvbGQgb2ZmIG9u IG9wZW5pbmcgdGhlIGRpc2N1c3Npb24uIE9mIGNvdXJzZSwgaXQNCnNob3VsZCBiZSBjaGFuZ2Vk IHRvIG1hdGNoIHRoZSBjb25zZW5zdXMgb2YgdGhlIHdnIG9uIHdoYXQgYmVsb25ncw0KaGVyZS4N Cjwvamg+DQoNClNpZGUgbm90ZTogdW5sZXNzIEknbSBtaXN0YWtlbiwgdGhpcyB3b3VsZG4ndCBm aXQgb3VyIHN0cnVjdHVyZSB3ZWxsOiBlLmcuIGEgcG9ydCBudW1iZXIgd291bGQgdGhlbiBiZSBh IFRyYW5zcG9ydCBQcm9wZXJ0eSB0aGF0IGhhcyBhIGNlcnRhaW4gdmFsdWUsIGJ1dCBhbHNvIGhh cyBhIHByZWZlcmVuY2UsIGJ1dCBjdXJyZW50bHkgd2Ugc2F5IHRoYXQgYSBUcmFuc3BvcnQgUHJv cGVydHkgaGFzICJvbmUgb2YgYSBzZXQgb2YgZGF0YSB0eXBlcyIsIG9uZSBvZiB3aGljaCBpcyBh IFByZWZlcmVuY2UuIElzbid0IHRoYXQgc3RydWN0dXJlIHRvbyBsaW1pdGluZz8gT3IgYW0gSSBt aXNzaW5nIHNvbWV0aGluZz8NCg0KPGpoPg0KSSdtIG5vdCBzdXJlLiBUaGlzIGlzIHBhcnQgb2Yg d2hhdCBJIG1lYW4gd2hlbiBJIHNheSBJIGZpbmQgdGhlDQpjdXJyZW50IHRhcHMtaW50ZXJmYWNl IGEgbGl0dGxlIHRvbyBsb29zZS4gSSBfdGhpbmtfIHdoYXQgSSBwb3N0ZWQNCmlzIGEgdmFsaWQg KHRob3VnaCBwZXJoYXBzIG5vdCBvcHRpbWFsKSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgY3VycmVu dA0KdGV4dC4gSSBtaWdodCBiZSB3cm9uZyBhYm91dCB0aGF0LCBzbyBJJ2QgYmUgZ3JhdGVmdWwg Zm9yIGEgcG9pbnRlcg0KdG8gdGhlIHRleHQgdGhhdCBwcm9oaWJpdHMgdGhpcyBpbnRlcnByZXRh dGlvbi4NCg0KQnV0IHJlYWxseSwgdGhhdCdzIGJlc2lkZSB0aGUgcG9pbnQuIEknZCBiZSBldmVu IG1vcmUgZ3JhdGVmdWwgZm9yIGFuDQphbHRlcm5hdGUgcHJvcG9zYWwgdGhhdCBtb3JlIGNsb3Nl bHkgbWF0Y2hlcyB0aGUgaW50ZW5kZWQgZGVzaWduIGZvcg0KYSB0YXBzIEFQSSwgd2l0aCB0aGUg c2FtZSBsZXZlbCBvZiBjb25jcmV0ZW5lc3MuDQo8L2poPg0KDQpJIGd1ZXNzIHRoYXQgMikgbmVl ZHMgMyksIGJ1dCBwZXJoYXBzIGl0J3MgdXNlZnVsIHRvIHNlZSAyKSBhbmQgMykgYXMgc2VwYXJh dGUuLi4gbWF5YmUgdGhlcmUgYXJlIG90aGVyIHVzZSBjYXNlcyBmb3IgMykgYWxvbmUgPw0KDQo8 amg+DQpZZXMsIEkgdGhpbmsgc28uIEkgdGhpbmsgSSB1bmRlcnN0YW5kIGFuIHVsdGltYXRlIGdv YWwgZm9yIHRhcHMgdG8NCmJlICJhcyBhbiBhcHAgZGVzaWduZXIsIGRvbid0IHdvcnJ5IGFib3V0 IHdoaWNoIHRyYW5zcG9ydCwganVzdA0Kc2VuZCB0aGUgbWFnaWMgQVBJIHRvIGdvIGRpc2NvdmVy IG9uZSB0aGF0IHdvcmtzIi4NCg0KSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgaW4gdGhlIGludGVy aW0gdGhhdCBpdCdsbCBiZSBuZWNlc3NhcnkNCnRvIHNwZWNpZnkgcG9ydCBudW1iZXJzIGluIG9y ZGVyIHRvIGludGVyb3BlcmF0ZSB3aXRoIGEgbG90IG9mDQpleGlzdGluZyBzZXJ2aWNlcywgZXNw ZWNpYWxseSBpbiBjYXNlcyBsaWtlIFJUUCAob3IgYSBsb3Qgb2YNCm90aGVyIGdlbmVyYWxpemVk IFVEUCBzdHVmZiksIHdoZXJlIHRoZXJlJ3Mgbm90IGFuIGV4cGxpY2l0DQpzZXJ2aWNlLXRvLXBv cnQgbWFwcGluZy4gKEFsc28gdG8gaW50ZXJvcGVyYXRlIHdpdGggYSBsb3Qgb2YNCm90aGVyIGRl cGxveWVkIHN5c3RlbXMgbGlrZSBmaXJld2FsbHMuKQ0KDQpJIGhhdmUgYSBmZXcgbmVidWxvdXMg aWRlYXMgYWJvdXQgaG93IGV4cGxpY2l0IGxheWVyaW5nIG1pZ2h0IGJlIGENCmdvb2Qgd2F5IHRv IHNvbHZlIHRoaXMsIGJ1dCBJIHRoaW5rIGluIG9yZGVyIHRvIG1ha2UgdGhlIGlkZWFzIHNoYXJw DQplbm91Z2ggdG8gZXZhbHVhdGUsIEkgdGhvdWdodCBJJ2QgZmlyc3QgdHJ5IHRoZSBlYXNpZXIg dGFzayBvZiBtYWtpbmcNCnRhcHMgc2hhcnAgZW5vdWdoIHRoYXQgSSBjYW4gZXhwcmVzcyB0aGUg aWRlYXMgYXMgcHJvcG9zZWQgY2hhbmdlcw0KdG8gYW4gZXhpc3Rpbmcgd2VsbC1mb3JtZWQgY29u Y2VwdC4NCjwvamg+DQoNCklNTywgYWxsIG9mIHRoZXNlIHRoaW5ncyBhcmUgaW50ZXJlc3Rpbmcs IGFuZCB3b3VsZCBiZSBnb29kIHRvIGRpc2N1c3Mgb24gc2l0ZS4gSG93ZXZlciwgSSBkb3VidCB0 aGF0IHdlIGNhbiBkZWFsIHdpdGggdGhlbSBhbGwgaW4gb25seSAxNSBtaW51dGVzIDotKQ0KDQo8 amg+DQpGYWlyIHBvaW50Lg0KDQpJIHByb3Bvc2UgZHVyaW5nIHRoZSB0YXBzIG1lZXRpbmcgdG8g Y2hlY2sgcHJlbGltaW5hcnkgY29uc2Vuc3VzIGFib3V0DQptb3ZpbmcgZm9yd2FyZCB3aXRoIGEg WUFORyBtb2RlbCB3aXRoaW4gdGFwcywgYW5kIGlmIHNvIHdoZXRoZXIgdG8NCmludGVncmF0ZSwg cmVwbGFjZSwgb3IgbWFrZSBhIHBhaXJlZCBkb2Mgd2l0aCB0aGUgZXhpc3RpbmcgdGFwcy1pbnRl cmZhY2UuDQpTZXBhcmF0ZWx5LCBJJ2xsIGVuY291cmFnZSB0aG9zZSBpbnRlcmVzdGVkIGFuZCBh dmFpbGFibGUgdG8gc3BlbmQgc29tZQ0KdGltZSBpbiBvZmZsaW5lIGNsYXJpZnlpbmcgZGlzY3Vz c2lvbiBkdXJpbmcgdGhlIHdlZWsgcHJpb3IuDQoNCkNoZWVycywNCkpha2UNCjwvamg+DQoNCkNo ZWVycywNCk1pY2hhZWwNCg0KUFM6IFRyYXZpcyBpcyBkb3duLCBvciBzb21ldGhpbmcuIEF0IGxl YXN0IHRoZSAiRWRpdG9yJ3MgQ29weSIgbGlua3MgZG9uJ3QgY3VycmVudGx5IHdvcmsuDQoNCg0K DQo+IE9uIDcgTWFyIDIwMTksIGF0IDA0OjU1LCBIb2xsYW5kLCBKYWtlIDxqaG9sbGFuZEBha2Ft YWkuY29tPiB3cm90ZToNCj4NCj4gSGkgdGFwcywNCj4NCj4gKFRyeWluZyBhZ2FpbiwgYnV0IHNp bXBsZXIuKQ0KPg0KPiBJJ20gbG9va2luZyBmb3IgYSBjb25zZW5zdXMgeWVzIG9yIG5vIGFuc3dl cjoNCj4NCj4gSXMgYSBub3JtYXRpdmUgY29uZmlnIGlucHV0IGZvcm1hdCBhbiBpbnRlcmVzdGlu ZyBhbmQgdXNlZnVsDQo+IGRpcmVjdGlvbj8NCj4NCj4NCj4gVGhlIGlkZWEgaXMgdG8gYWRkIGZ1 bmN0aW9uYWxpdHkgbGlrZSB0aGlzLCBpbiB0YXBzLWludGVyZmFjZToNCj4NCj4gbmV3UHJlID0g UHJlQ29ubmVjdGlvbi5OZXdGcm9tSnNvbignJyd7DQo+ICJyZW1vdGUtZW5kcG9pbnQiOnsNCj4g Imhvc3RzIjpbDQo+IHsgImhvc3QiOiJleGFtcGxlLmNvbSIgfQ0KPiBdDQo+IH0NCj4gfScnJykN Cj4NCj4gV2l0aCBhIGZ1bGx5IHNwZWNpZmllZCBqc29uIGlucHV0IGZvcm1hdCB0aGF0IGNhbiBw cm92aWRlIGFsbCB0aGUNCj4gY29uZmlndXJhYmxlIHZhbHVlcy4NCj4NCj4NCj4gSWYgbm8sIEkn bGwgbW92ZSBvbiBhbmQgYXNzdW1lIEkganVzdCBkb24ndCB1bmRlcnN0YW5kIHRhcHMgZ29hbHMu DQo+DQo+IElmIHllcywgSSdkIGxpa2UgMTUgbWludXRlcyB0byBkaXNjdXNzIGluIFByYWd1ZSwg YW5kIGtlZXAgcmVhZGluZzoNCj4NCj4gSSB0aGluayBhIGZ1bGwgZGVmaW5pdGlvbiBvZiBhbiBp bnB1dCBqc29uIGZvcm1hdCBjYW4gYmUgZXhhY3RseQ0KPiBzcGVjaWZpZWQgYnkgYSBZQU5HIG1v ZGVsLiAoV2l0aCB4bWwgZm9yIGZyZWUsIGlmIHlvdSB3YW50IGl0LikNCj4NCj4gSSB0cmllZCB0 byBza2V0Y2ggYSBzdGFydCBhdCB3aGF0IGEgWUFORyBtb2RlbCBmb3IgdGhpcyBtaWdodCBsb29r IGxpa2U6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaG9sbGFuZC10YXBz LWFwaS15YW5nLTAwI3NlY3Rpb24tMzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRqaG9sbGFuZC0y RHRhcHMtMkRhcGktMkR5YW5nLTJEMDAtMjNzZWN0aW9uLTJEMyZkPUR3TUZhUSZjPTk2WmJaWmNh TUY0dzBGNGpwTjZMWmcmcj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQx T29rJm09TGN6UE0tV2MtajJLYnFkM0NBZURvVHlLWGlYb016ZXBSN01EZHMxQXB5QSZzPTFXcHhj eWZ1Nnp4RXZ0NUhvSUczdm5QX3AwMFBHQ3BRYjNtWVl2WEo3U1kmZT0+DQo+DQo+IEknbSBub3Qg YSBZQU5HIGV4cGVydCB5ZXQsIGFuZCBpdCdzIG5vdCBtdWNoIG9mIGEgbW9kZWwuIEFuZCBpdCdz IHZlcnkNCj4gZmFyIGZyb20gY29tcGxldGUuIEJ1dCBpdCBjb21waWxlcywgYW5kIGFsbCB0aGUg ZXhhbXBsZXMgaW4gdGhlIGRyYWZ0DQo+IHZhbGlkYXRlIGFnYWluc3QgdGhhdCBtb2RlbCB3aXRo IGxpYnlhbmcuIElmIGl0J3Mgd29ydGh3aGlsZSwgSSB0aGluaw0KPiBzb21ldGhpbmcgbGlrZSB0 aGlzIGNhbiBiZSBnb29kIChhbmQgZXh0ZW5zaWJsZSEpLCBpZiBkb25lIHJpZ2h0Lg0KPg0KPiBJ IGJlbGlldmUgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxpbmVzIHdvdWxkIHNoYXJwZW4gdXAgdGFw cy1pbnRlcmZhY2UNCj4gYSBsb3QuIChBZnRlciBmaWxsaW5nIGluIGFsbCB0aGUgdGFwcy1pbnRl cmZhY2UgcHJvcGVydGllcy4pDQo+DQo+DQo+IFRoZSByZWFzb24gSSdtIGFza2luZyBpcyBiZWNh dXNlIHJpZ2h0IG5vdywgdGFwcy1pbnRlcmZhY2UgdG8gbWUNCj4gc2VlbXMgX2FsbW9zdF8gcmVh bGx5IGdvb2QsIGV4Y2VwdCB0b28gY29uZnVzaW5nIGFuZCB2YWd1ZSB0byBhY3R1YWxseQ0KPiBi dWlsZCBhbiBBUEkgdGhhdCBjYW4gcmVwbGFjZSBCU0Qgc29ja2V0cy4gSSB0aGluayB3aXRoIGEg c29saWQgY29uZmlnDQo+IGZvcm1hdCB3aXRoIG5vcm1hdGl2ZSBhbmQgdGVzdGFibGUgZXhhbXBs ZXMsIHRoYXQgY291bGQgYmUgZml4ZWQuDQo+DQo+IElmIGNvbnNlbnN1cyBzYXlzICJpbnRlcmVz dGluZyIsIEknbGwgd2FudCAxNSBtaW51dGVzIHRvIGRpc2N1c3MgaXQsIGFuZA0KPiB0byBzdGFy dCBkaWdnaW5nIGludG8gaG93IHRvIG1ha2UgaXQgZ29vZC4gKEFuZCBhbHNvIHRvIGFkZCBtdWx0 aWNhc3QNCj4gc3VwcG9ydCB0byB0aGUgbW9kZWwgYW5kIGF0IGxlYXN0IG9uZSBpbXBsZW1lbnRh dGlvbi4pDQo+DQo+IFRoYW5rcyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLg0KPg0KPg0KPiBDaGVl cnMsDQo+IEpha2UNCj4NCj4NCj4NCj4gT24gMjAxOS0wMy0wNCwgMTc6MTksICJIb2xsYW5kLCBK YWtlIiA8amhvbGxhbmRAYWthbWFpLmNvbT4gd3JvdGU6DQo+DQo+IEhpIHRhcHMgZm9sa3MsDQo+ DQo+IFRMO0RSOiBJIHRoaW5rIHRoZSBzcGVjIHNob3VsZCBoYXZlIGEgWUFORyBtb2RlbCBhbmQg SSB3YW50IHRvIHVzZSBpdA0KPiB0byBnZXQgbXVsdGljYXN0IHN1cHBvcnQgaW4gYW4gaW1wbGVt ZW50YXRpb24uDQo+DQo+DQo+IEkgcmVjZW50bHkgc3RhcnRlZCBkaWdnaW5nIGludG8gdGhlIHRh cHMgQVBJIHdpdGggdGhlIGludGVudCBvZiBhZGRpbmcNCj4gbXVsdGljYXN0IHN1cHBvcnQsIGJ1 dCBpdCBsb29rcyBsaWtlIGl0J3MgYmFzaWNhbGx5IGFscmVhZHkgdGhlcmUsIGFzDQo+IGZhciBh cyBpdCBnb2VzWypdLg0KPg0KPiBCdXQgSSBlbmRlZCB1cCB3aXRoIGEgaGlnaGVyLWxldmVsIGNv bW1lbnQsIHNvIEkgdGhvdWdodCBJJ2QgcmFpc2UgaXQNCj4gdG8gdGhlIHdnIGFuZCBhc2sgd2hh dCB5b3UgYWxsIHRoaW5rLg0KPg0KPiBJIGZvdW5kIHRoZSB3aG9sZSAiYWJzdHJhY3QgaW50ZXJm YWNlIiBhcHByb2FjaCBhIGxpdHRsZSB0b28NCj4gbG9vc2V5LWdvb3NleSwgc28gSSB0aG91Z2h0 IEknZCB0cnkgdG8gc3VnZ2VzdCBhIHdheSB0byB0aWdodGVuIGl0IHVwLg0KPg0KPiBNeSBnb2Fs IHdpdGggdGhpcyBpcyB0byBtYWtlIGl0IG11Y2ggbW9yZSBjbGVhciAodG8gdGhlIHBvaW50IG9m IGJlaW5nDQo+IG1lY2hhbmljYWxseSBjaGVja2FibGUpIHByZWNpc2VseSB3aGF0IGEgY29tcGxp YW50IEFQSSBwcm92aWRlcy4NCj4NCj4gSSdtIG5vdCBhdHRhY2hlZCB0byB0aGUgc3RydWN0dXJl IEknbSBwcm9wb3Npbmcgb3IgdG8gYW55IG9mIHRoZQ0KPiBwYXJ0aWN1bGFycyBpbiB0aGUgc3Ry YXctbWFuIEkndmUgcG9zdGVkLCBidXQgaWYgaXQncyBub3QgdGlnaHRlbmVkIHVwDQo+IHdpdGgg c29tZXRoaW5nIGF0IGEgc2ltaWxhciBsZXZlbCBvZiBjb25jcmV0ZW5lc3MsIEknbSBjb25jZXJu ZWQgdGhhdA0KPiBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIHdpbGwgYmUgbm90IG9ubHkgaW5j b21wYXRpYmxlIGluIHJhbmRvbQ0KPiB1bmRlcnNwZWNpZmllZCBjb3JuZXIgY2FzZXMgKGxpa2Ug QlNEIHNvY2tldHMgdG9kYXkgd2hlbiB5b3UgdHJ5IHRvIG1ha2UNCj4gY3Jvc3MtcGxhdGZvcm0g QyBjb2RlKSwgYnV0IGFsc28gYXJlIGxpa2VseSB0byBlbmQgdXAgd2l0aCB2ZXJ5IG1hbnkNCj4g aW1wb3J0YW50IGRpZmZlcmVuY2VzIHRoYXQgd291bGQgbWFrZSB0aGUgd2hvbGUgdGFwcyBlZmZv cnQgbW9yZSBvciBsZXNzDQo+IG1vb3QuDQo+DQo+IEluIGEgd29ybGQgd2hlcmUgd2UgZW5kIHVw IHdpdGggYSBkb2MgYXQgdGhlIGxldmVsIG9mIGFic3RyYWN0aW9uIEknbQ0KPiBjdXJyZW50bHkg c2VlaW5nIGluIGRyYWZ0LXRhcHMtaW50ZXJmYWNlLCBpdCBzZWVtcyB0byBtZSB0aGF0IGlmIDIN Cj4gZGlmZmVyZW50IEFQSSBpbXBsZW1lbnRhdGlvbnMgd2VyZSB3cml0dGVuIGluIHRoZSBzYW1l IGxhbmd1YWdlLCBpdCdsbA0KPiBiZSBwcm9oaWJpdGl2ZWx5IGRpZmZpY3VsdCBmb3IgYW4gYXBw IHRvIG1pZ3JhdGUgZnJvbSB1c2luZyBvbmUgdG8gdXNpbmcNCj4gdGhlIG90aGVyLCBqdXN0IGJl Y2F1c2Ugc28gbWFueSBhc3BlY3RzIG9mIGl0IGFyZSBsZWZ0IG9wZW4gdG8gdGhlDQo+IGltcGxl bWVudG9ycy4NCj4NCj4gSW4gdGhhdCBjb250ZXh0LCBJIHRob3VnaHQgYSBZQU5HIG1vZGVsIHdv dWxkIGJlIHVzZWZ1bCBoZXJlIHRvDQo+IHByb3ZpZGUgYSBjcm9zcy1wbGF0Zm9ybSB3YXkgdG8g c3BlY2lmeSB3aGF0IGV4YWN0IHByb3BlcnRpZXMgYW5kDQo+IG9iamVjdHMgZXhpc3QsIGFuIGV4 YWN0IGZvcm1hdCBpbiB3aGljaCB0aGUgdmFsdWVzIGNhbiBiZSBzcGVjaWZpZWQsIGFuZA0KPiB3 aGF0IGV4YWN0IHNlbWFudGljcyB0aGV5IGhhdmUsIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciBh IHNhbmUNCj4gZXh0ZW5zaW9uIHBhdGggYW5kIGxhbmd1YWdlLXNwZWNpZmljIGltcGxlbWVudGF0 aW9uIGRldGFpbHMuDQo+DQo+IEknbSB0aGlua2luZyBzb21lIGxhbmd1YWdlIGEgYml0IGxpa2Ug dGhlIGZpcnN0IGJ1bGxldCBpbiBTZWN0aW9uIDQuMiBvZg0KPiB0YXBzLWludGVyZmFjZToNCj4N Cj4gQSBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24gU0hPVUxEIHByb3ZpZGUgYSBsYW5ndWFnZS1h cHByb3ByaWF0ZSB3YXkgdG8NCj4gY29uZmlndXJlIGEgUHJlQ29ubmVjdGlvbiB1c2luZyBZQU5H IGluc3RhbmNlIGRhdGEgZm9yIHRoaXMgbW9kZWwsIGFuZA0KPiBTSE9VTEQgcHJvdmlkZSBhbiBB UEkgdGhhdCBvdXRwdXRzIHRoZSBZQU5HIGluc3RhbmNlIGRhdGEgZm9yIGFuDQo+IGVzdGFibGlz aGVkIENvbm5lY3Rpb24uDQo+DQo+IEFuIGltcGxlbWVudGF0aW9uIE1BWSBhbHNvIHByb3ZpZGUg YXBwcm9wcmlhdGUgQVBJcyBmb3IgZGlyZWN0bHkgZWRpdGluZw0KPiB0aGUgb2JqZWN0cyB3aXRo b3V0IHVzaW5nIFlBTkcuIEl0J3MgUkVDT01NRU5ERUQgd2hlcmUgcG9zc2libGUgdG8gdXNlDQo+ IG5hbWVzIHRoYXQgbWVjaGFuaWNhbGx5IHRyYW5zbGF0ZSB0byB0aGUgbmFtZXMgaW4gdGhlIFlB TkcgZGF0YSBtb2RlbCwNCj4gdXNpbmcgY2FwaXRhbGl6YXRpb24gYW5kIHB1bmN0dWF0aW9uIGNv bnZlbnRpb25zIGFzIGV4cGVjdGVkIGZvciB0aGUNCj4gbGFuZ3VhZ2Ugb2YgdGhlIGltcGxlbWVu dGF0aW9uLg0KPg0KPiBBbmQgdGhlbiBvZiBjb3Vyc2UgYSBZQU5HIG1vZGVsOg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaG9sbGFuZC10YXBzLWFwaS15YW5nLzxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0 cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGpob2xsYW5kLTJEdGFwcy0yRGFwaS0yRHlhbmdf JmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWJxbkZST2l2RG9fNGlGOFozUjRE eU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1MY3pQTS1XYy1qMkticWQzQ0FlRG9UeUtYaVhvTXpl cFI3TURkczFBcHlBJnM9OS13TTg2MHl1aW1jOGZiTmRTN09LdDlWaVpwckF2VURfc1NNNllKTnk0 RSZlPT4NCj4gKGRyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcpDQo+DQo+IElmIHRoaXMgc2Vl bXMgdXNlZnVsLCBpdCB3aWxsIG5lZWQgbG90cyBvZiByZWZpbmluZy4gSSdsbCBiZSBzdXJwcmlz ZWQNCj4gaWYgYW55IHBhcnQgb2YgaXQgc3Vydml2ZXMgZXhhY3RseSBhcyB3cml0dGVuLiBJdCdz IGEgcXVpY2sgYW5kDQo+IGRpcnR5IGF0dGVtcHQgdG8gY29uY3JldGl6ZSBhIGZldyBvZiB0aGUg dGhpbmdzIEkgc2F3IGxpc3RlZCBpbg0KPiBkcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLCBhcyBh IHN0YXJ0aW5nIHBvaW50IHRvIGZpbGwgb3V0IGlmIGl0IHNlZW1zDQo+IHVzZWZ1bC4NCj4NCj4g QnV0IHRoZSBtb2RlbCBwYXJzZXMsIGFuZCB0aGUgZXhhbXBsZSBkYXRhIGluc3RhbmNlcyBpbiB0 aGUgZHJhZnQNCj4gcGFyc2UgYWdhaW5zdCB0aGUgbW9kZWwgKGFsbCB3aXRoIGxpYnlhbmcpLg0K Pg0KPiBPbmUgb2YgdGhlIG1haW4gcmVhc29ucyBJJ20gZG9pbmcgdGhpcyBpcyBiZWNhdXNlIGl0 IHNlZW1zIHRvIG1lIHdoYXQncw0KPiBzcGVjaWZpZWQgaW4gdGFwcy1pbnRlcmZhY2UtMDIgdG9k YXkgaXMgbWlzc2luZyBzb21lIGtleSBmZWF0dXJlcywgbGlrZQ0KPiBhbiBlbnVtZXJhdGlvbiBv ZiB0aGUgcHJvcGVydGllcyBpbiB0aGUgTG9jYWwvUmVtb3RlRW5kcG9pbnQgZXhhbXBsZXMgaW4N Cj4gc2VjdGlvbiA1LjEuIEFuZCBJIGRvbid0IHNlZSB0aGF0IGxpc3RlZCBhcyBhbiBvcGVuIGlz c3VlIGluIGdpdGh1YiwNCj4gd2hpY2ggc3VycHJpc2VkIG1lIGEgYml0Lg0KPg0KPiBJIHRoaW5r IG92ZXJzaWdodHMgbGlrZSB0aGlzIHdpbGwgYmVjb21lIGltbWVkaWF0ZWx5IGFuZCBwYWluZnVs bHkNCj4gb2J2aW91cyB3aGVuIHRoZXJlJ3MgYSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gdGhh dCBpbmNsdWRlcyBhIFlBTkcNCj4gcGFyc2VyIGFuZCBhbiBleHBsaWNpdCBkYXRhIG1vZGVsLCBh cyBvcHBvc2VkIHRvIHRoZSBjb21iaW5nIG9mIHRoZQ0KPiBkb2N1bWVudCBhbmQgYSBzb3J0IG9m IGV5ZWJhbGxlZCBjb21wYXJpc29uIHRvIE5FQVQgdGhhdCBJIHRyaWVkDQo+IHRoaXMgd2VlayB0 byByZWFjaCB0aGF0IGNvbmNsdXNpb24gKHdoaWNoIEkgZm91bmQgY2hhbGxlbmdpbmcgZXZlbg0K PiB0aG91Z2ggSSB0aG91Z2h0IGJvdGggdGhlIGRvY3VtZW50IGFuZCB0aGUgbGlicmFyeSB3ZXJl IG1vc3RseSBwcmV0dHkNCj4gd2VsbCB3cml0dGVuKS4NCj4NCj4gVGhlIHdob2xlIHRoaW5nIGF0 IHRoaXMgcG9pbnQganVzdCBzbWVsbHMgdG8gbWUgbXVjaCBtb3JlIGFic3RyYWN0IHRoYW4NCj4g aXQgcmVhbGx5IGhhcyB0byBiZSBvciB0aGFuIGl0J3MgcmVhbGx5IHVzZWZ1bCB0byBiZSwgd2hp Y2ggYm90aGVycyBtZQ0KPiBiZWNhdXNlIHRoZSBpZGVhIG9mIHJlcGxhY2luZyBCU0Qgc29ja2V0 cyB3aXRoIHNvbWV0aGluZyB1c2FibGUgc2VlbXMNCj4gbGlrZSBzdWNoIGEgZ3JlYXQgaWRlYS4g SSdkIGxpa2UgdGhpcyB0byBiZSBzb21ldGhpbmcgSSBjYW4gYWN0dWFsbHkNCj4gdXNlIGluIGEg d2F5IHRoYXQgbWFrZXMgbXkgbGlmZSBlYXNpZXIgc29tZWRheSBzb29uLg0KPg0KPiBCdXQgSSB0 aGluayBJJ20gYXQgdGhlIHBvaW50IHdoZXJlIEkgbmVlZCBhIHNhbml0eSBjaGVjayB0byBzZWUg aWYgSSdtDQo+IGp1c3QgbWlzc2luZyBzb21ldGhpbmcsIG9yIGlmIHRoaXMgc2VlbXMgbGlrZSBh IHVzZWZ1bCBkaXJlY3Rpb24uDQo+DQo+IFRob3VnaHRzPyBTdWdnZXN0aW9ucz8gV29ydGggZGlz Y3Vzc2luZyBpbiBQcmFndWU/IChJZiBzbywgY2FuIEkNCj4gZ2V0IGEgc2xvdD8pDQo+DQo+IENo ZWVycywNCj4gSmFrZQ0KPg0KPiAqOg0KPiBJIGNvbmNsdWRlZCB0aGF0IHRoZXJlJ3Mgbm8gcmVh c29uIG11bHRpY2FzdCBjb3VsZG4ndCBiZSBzdXBwb3J0ZWQNCj4gdG9kYXksIGlmIHRoZXJlIHdl cmUgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBjb3VsZCByZWFzb25hYmx5IGNsYWltIHRvIGJlDQo+ IGNvbXBsaWFudCwgYnkganVzdCBhZGFwdGluZyBzb21lIG9mIHRoZSBleGFtcGxlcyBpbg0KPiBk cmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLTAyIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBzZW1hbnRp YyBtZWFuaW5nIG9mDQo+IG11bHRpY2FzdCBhZGRyZXNzIHNwYWNlcyBpbnNpZGUgdGhlIEFQSS4N Cj4NCj4gRm9yIGV4YW1wbGUsIEkgY291bGRuJ3QgZmluZCBhbnkgcmVhc29uIHRoaXMgY2FuJ3Qg YmUgZXhwZWN0ZWQgdG8gc2V0DQo+IHVwIGFuIFNTTSBjaGFubmVsIHN1YnNjcmlwdGlvbiB3aXRo b3V0IGFueSBmdXJ0aGVyIGFkbywgZ2l2ZW4gYSBzYW5lDQo+IGltcGxlbWVudGF0aW9uIHRoYXQg c3VwcG9ydHMgaXQ6DQo+DQo+IFJlbW90ZVNwZWNpZmllciA6PSBOZXdSZW1vdGVFbmRwb2ludCgp DQo+IFJlbW90ZVNwZWNpZmllci5XaXRoSVB2NEFkZHJlc3MoMTkyLjAuMi4yMSkNCj4NCj4gTG9j YWxTcGVjaWZpZXIgOj0gTmV3TG9jYWxFbmRwb2ludCgpDQo+IExvY2FsU3BlY2lmaWVyLldpdGhQ b3J0KDMwMDAwKQ0KPiBMb2NhbFNwZWNpZmllci5XaXRoSVB2NEFkZHJlc3MoMjMyLjI1Mi4wLjIp DQo+DQo+IE5ld1ByZWNvbm5lY3Rpb24oUmVtb3RlU3BlY2lmaWVyLCBMb2NhbFNwZWNpZmllciku TGlzdGVuKC4uLikNCj4NCj4gTWF5YmUgdGhlcmUncyBzb21lIHZhbHVlIGluIHNwZWNpZnlpbmcg YSAiSm9pblNTTSgpIiB0byBvdmVycmlkZSBkZWZhdWx0cw0KPiBpbiB0aGUgUHJlQ29ubmVjdGlv biwganVzdCB0byBtYWtlIHN1cmUgeW91J3JlIHNwZWNpZmljYWxseSBhc2tpbmcgZm9yDQo+IG11 bHRpY2FzdC4gSSB0aGluayB0aGF0IHdvdWxkIGJlIGZpbmUgZm9yIG5hdGl2ZSBtdWx0aWNhc3Qs IGJ1dCBsaWtlIEkNCj4gc2FpZCwgYSBtdWNoIHNtYWxsZXIgcG9pbnQgdGhhbiB0aGUgbG9vc2Vu ZXNzIG9mIHRoZSBBUEkuDQo+DQo+IFdoZXJlIGl0IGdldHMgYSBiaXQgbW9yZSBjb21wbGljYXRl ZCBpcyB0cnlpbmcgdG8gaGFuZGxlIG11bHRpcGxlIG9wdGlvbnMNCj4gZm9yIGRpc2NvdmVyaW5n IGEgdXNhYmxlIHVuaWNhc3QgdHVubmVsIGZvciBtdWx0aWNhc3QgdHJhZmZpYywgYXMNCj4gZGVz Y3JpYmVkIGluIFNlY3Rpb24gMi40LjEgb2YgZHJhZnQtaWV0Zi1tYm9uZWQtZHJpYWQtYW10LWRp c2NvdmVyeS0wMS4NCj4NCj4gSSdkIGxpa2UgdG8gaGF2ZSBhIGRlY2VudCBwbGFjZSB0byB0YWNr IG9uIGFuIGV4dGVuc2lvbiB0byB0aGlzIEFQSSB0aGF0DQo+IGNhbiB0cmFuc3BhcmVudGx5LCB3 aXRoaW4gdGhlIGNvbm5lY3Rpb24gQVBJLCBkaXNjb3ZlciB0aGUgYmVzdCBhdmFpbGFibGUNCj4g QU1UIHJlbGF5IGFuZCBzdGFydCB1c2luZyBpdCB3aGVuIG5hdGl2ZSBqb2luaW5nIGlzIHVuYXZh aWxhYmxlIChhbmQgYWxzbw0KPiB0byBwcm92aWRlIG5vcm1hdGl2ZSBjb250cm9scyBmb3IgY29u ZmlndXJpbmcgaXQgd2hlbiB0aGVyZSdzDQo+IGFkbWluaXN0cmF0aXZlIGNvbmZpZ3VyYXRpb24g dG8gYmUgYWRkZWQpLg0KPg0KPiBCdXQgdGhhdCdzIGEgMm5kIG9yZGVyIHF1ZXN0aW9uIGZvciBt ZSBhdCB0aGlzIHBvaW50LCBiZWNhdXNlIGluIHRoZQ0KPiBjdXJyZW50IFRBUFMgQVBJIEkgZG9u J3Qgc2VlIGFueSBvYnZpb3VzbHkgZ29vZCBzcG90IHRvIHB1dCBzZWxlY3Rpb24NCj4gY29udHJv bHMgZm9yIHRoYXQga2luZCBvZiB0dW5uZWwgZGlzY292ZXJ5IHNlbGVjdGlvbiwgb3IgcmVhbGx5 IGEgZ29vZA0KPiB3YXkgdG8gZXhwbGFpbiB3aGF0IGl0J3Mgc3VwcG9zZWQgdG8gZG8sIGlmIEkg dHJpZWQgdG8gYWRkIGNvbnRyb2xzIHRvDQo+IHNvbWV0aGluZyB0aGF0J3MgdGhlcmUuDQo+DQo+ IFNvbHZpbmcgdGhhdCBpcyBteSBtYWluIG1vdGl2YXRpb24gZm9yIGJlaW5nIGhlcmUuIChXZWxs LCBhbmQgdGhhdA0KPiB0aGUgQlNEIHNvY2tldCBBUEkgZm9yIG11bHRpY2FzdCBpcyBraW5kIG9m IGEgZGlzYXN0ZXIgdG9kYXkuKQ0KPg0KPiBBbnl3YXksIGlmIHRhcHMgZmluZHMgdGhlIHdob2xl IFlBTkcgc3VnZ2VzdGlvbiB1c2VmdWwsIEknbGwgcHJvYmFibHkNCj4gc3VnZ2VzdCBzb21lIG5l dyBleHRlbnNpb25zIGFib3V0IHRoaXMsIGFuZCBtYXliZSBhIGZldyBvdGhlciBwb2ludHMsDQo+ IGVzcGVjaWFsbHkgbWF5YmUgYXJvdW5kIHRyeWluZyB0byBwdXQgaW4gYSBzdHJ1Y3R1cmUgdGhh dCBjYW4gc3VwcG9ydA0KPiBzb21lIGtpbmQgb2Ygc2FuZSBleHBsaWNpdCBsYXllcmluZy4NCj4N Cj4gQnV0IEknbSBub3Qgc3VyZSBJIGNhbiBhcnRpY3VsYXRlIHRob3NlIHN1Z2dlc3Rpb25zIGlu IGEgd2F5IEknbSBzdXJlIGlzDQo+IG1lYW5pbmdmdWwgd2l0aG91dCBmaXJzdCBnZXR0aW5nIGEg bW9yZSBjbGVhciBzcGVjaWZpY2F0aW9uIG5haWxlZCBkb3duDQo+IGFib3V0IHdoYXQncyBhY3R1 YWxseSBpbiB0aGUgdGFwcyBzcGVjLiBCZWNhdXNlIHJpZ2h0IG5vdyBJJ20gbW9zdGx5DQo+IGp1 c3QgY29uZnVzZWQgYWJvdXQgd2hhdCBhbiBBUEkgaW1wbGVtZW50YXRpb24gd291bGQgcmVhbGx5 IGxvb2sgbGlrZSwNCj4gYW5kIGhvdyB5b3UgY291bGQgdGVsbCB3aGV0aGVyIGl0IG1hdGNoZXMg dGhlIHRhcHMtaW50ZXJmYWNlIHNwZWMuDQo+DQo+DQo+DQo+IEZyb206IEFhcm9uIEZhbGsgPGFh cm9uLmZhbGtAZ21haWwuY29tPg0KPiBEYXRlOiAyMDE5LTAzLTA0IGF0IDEwOjUzDQo+IFRvOiB0 YXBzIFdHIDx0YXBzQGlldGYub3JnPg0KPiBDYzogWmFoZWR1enphbWFuIFNhcmtlciA8emFoZWR1 enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20+DQo+IFN1YmplY3Q6IFtUYXBzXSBjYWxsIGZvciBh Z2VuZGEgaXRlbXMgYXQgVEFQUyBJRVRGLTEwNA0KPg0KPiBIaSBBbGwtDQo+IFdoYXQgc2hvdWxk IHdlIHVzZSBvdXIgdGltZSB0byBkaXNjdXNzPyBMZXTigJlzIGZvY3VzIG9uIHRoaW5ncyB0aGF0 IHdvdWxkIGJlbmVmaXQgZnJvbSBmMmYgZGlzY3Vzc2lvbiwgY29uc2Vuc3VzIGJ1aWxkaW5nLCBv ciBqdXN0IGFyZ3VtZW50LiA6KQ0KPiDigKIgVEFQUyBkb2NzOiBhcmUgdGhlcmUgb3BlbiB0b3Bp Y3MgdGhhdCBuZWVkIGdyb3VwIGF0dGVudGlvbj8gU2VlbXMgbGlrZSB3ZSBzZXR0bGVkIG1vc3Qg b2YgdGhlIHJlbWFpbmRlciBhdCB0aGUgaW50ZXJpbS4NCj4g4oCiIFRBUFMgc2VjdXJpdHk6IHRo aXMgc2VlbXMgbmVhcmx5IGRvbmUuIEFueXRoaW5nIHRvIGRpc2N1c3M/DQo+IOKAoiBJbXBsZW1l bnRhdGlvbnM6IGEgZ29vZCB0b3BpYyBmb3IgaW5mb3JtYXRpb24gc2hhcmluZyBidXQgbGVzcyBp bXBvcnRhbnQgdGhhbiBhbnl0aGluZyBuZWVkaW5nIGFncmVlbWVudA0KPiDigKIgTW9iaWxpdHk6 IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRkbW0tMkRvbmRlbWFuZC0yRG1vYmlsaXR5 LTJEMTcmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9YnFuRlJPaXZEb180aUY4 WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZtPXBMVzVnU3lldGZWZV9peEc0X3U3cUtYX1Zj aklxek43SnUyQmdNMnJwUW8mcz1IVXNCVkJGX0doTmlPazNncVlfbTVxWk1ELXNQbUJKOTNHRTV3 ZDNENV9zJmU9IGFuZCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19yZXZpZXctMkRpZXRmLTJEZG1tLTJE b25kZW1hbmQtMkRtb2JpbGl0eS0yRDE1LTJEdHN2YXJ0LTJEbGMtMkR3ZXN0ZXJsdW5kLTJEMjAx OS0yRDAxLTJEMDhfJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWJxbkZST2l2 RG9fNGlGOFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1wTFc1Z1N5ZXRmVmVfaXhHNF91 N3FLWF9WY2pJcXpON0p1MkJnTTJycFFvJnM9MFltQ19YQ0F1NF9HVllkRmkwSHhpS2FLQnBhbjJD T1lxQkwxbUI2YlhyWSZlPQ0KPiAtLWFhcm9uDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRhcHMgbWFpbGluZyBsaXN0DQo+IFRh cHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBz PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGFwcyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmcj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJm09 TGN6UE0tV2MtajJLYnFkM0NBZURvVHlLWGlYb016ZXBSN01EZHMxQXB5QSZzPUZnYVpQeE5ZOXBN VXRsZXhwU3ZQU0dFc0xWYTBQazdhTFZON09BOXNnWDAmZT0+DQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGFwcyBtYWlsaW5nIGxpc3QNClRh cHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwczxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3RhcHMmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRq cE42TFpnJnI9YnFuRlJPaXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZtPUxj elBNLVdjLWoyS2JxZDNDQWVEb1R5S1hpWG9NemVwUjdNRGRzMUFweUEmcz1GZ2FaUHhOWTlwTVV0 bGV4cFN2UFNHRXNMVmEwUGs3YUxWTjdPQTlzZ1gwJmU9Pg0K --_000_E66700D441F64C9AB2F29DE6519C9C5Cakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <61427D14AC60174A902A303A815670D3@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsN Cgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVy dGljYWwtYWxpZ246YmFzZWxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBYXJvbiw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV04oCZcyB0YWtlIDE1IG1pbnV0ZXMgb24gdGhlIGFnZW5k YSBmb3IganVzdCBZQU5HLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGVyZeKAmXMgdGlt ZSwgSSB3b3VsZCBhbHNvIGJlIGhhcHB5IHRvIHRha2UgMTAgbWludXRlcyBvbiBtdWx0aWNhc3Qs IGJ1dCB3aXRoIGEgbG93ZXIgcHJpb3JpdHkgb24gdGhlIHJlcXVlc3QuJm5ic3A7IFRoZXJl4oCZ cyBhIGJldHRlciBjaGFuY2UgSSBjYW4gY292ZXIgdGhhdCBvbiB0aGUgbGlzdCBvciBpbiBvZmZs aW5lIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpha2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QWFyb24gRmFsayAm bHQ7YWFyb24uZmFsa0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPjIwMTktMDMtMDcg YXQgMTI6NTQ8YnI+DQo8Yj5UbzogPC9iPiZxdW90O0hvbGxhbmQsIEpha2UmcXVvdDsgJmx0O2po b2xsYW5kQGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj50YXBzIFdHICZsdDt0YXBzQGll dGYub3JnJmd0OywgTWljaGFlbCBXZWx6bCAmbHQ7bWljaGF3ZUBpZmkudWlvLm5vJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW1RhcHNdIGNhbGwgZm9yIGFnZW5kYSBpdGVtcyBhdCBUQVBT IElFVEYtMTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SmFrZS08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIHVu Y2xlYXIsIGRvIHlvdSB3YW50IHRvIGRpc2N1c3MgbXVsdGljYXN0IGluIFByYWd1ZSBvciBqdXN0 IFlBTkc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4t LWFhcm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5P biA3IE1hciAyMDE5LCBhdCAxNDoxMCwgSG9sbGFuZCwgSmFrZSB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5IaSBNaWNoYWVsLDxicj4NCjxicj4NClRoYW5rcyBm b3IgcmVzcG9uZGluZywgbXVjaCBhcHByZWNpYXRlZC4gKEFuZCBhbHNvIHRvIFRvbW15PGJyPg0K YW5kIEFhcm9uLik8YnI+DQo8YnI+DQpCYXNlZCBvbiB0aGUgcmVwbGllcyBmcm9tIHlvdSwgVG9t bXksIGFuZCBBYXJvbiwgSSdsbCBwbGFuPGJyPg0KdG8gcHJlc2VudCBzb21ldGhpbmcgaW4gUHJh Z3VlLCBhbmQgY2FuIHlvdSBwbGVhc2UgcHV0IG1lPGJyPg0Kb24gdGhlIHNjaGVkdWxlLCBBYXJv bj88YnI+DQo8YnI+DQpNb3JlIHJlc3BvbnNlcyBpbmxpbmUgd2l0aCAmbHQ7amgmZ3Q7Jmx0Oy9q aCZndDssIGFuZCB0aGFua3MsIHRoZXNlPGJyPg0KcXVlc3Rpb25zIHdlcmUgdmVyeSBoZWxwZnVs IHRvIGhlbHAgbWUgZm9jdXMgb24gd2hhdCBuZWVkczxicj4NCmV4cGxhaW5pbmcgdnMuIHdoYXQn cyBvYnZpb3VzLjxicj4NCjxicj4NCjxicj4NCk9uIDIwMTktMDMtMDcsIDAwOjMyLCAmcXVvdDtN aWNoYWVsIFdlbHpsJnF1b3Q7ICZsdDttaWNoYXdlQGlmaS51aW8ubm8mZ3Q7IHdyb3RlOjxicj4N Cjxicj4NCkhpLDxicj4NCjxicj4NClZlcnkgc29ycnkgZm9yIHRoZSBzaWxlbmNlLiBJIGNhbiBv bmx5IHNwZWFrIGZvciBteXNlbGYsIGJ1dCBoZXJlJ3MgYW4gZXhhbXBsZSBvZiB3aHkgdGhpcyBv bmUgcGVyc29uIHdhcyBzaWxlbnQ6PGJyPg0KLSBXaGVuIHlvdSBjcmVhdGVkIHlvdXIgaXNzdWUg b24gbXVsdGljYXN0IGluIGdpdGh1YiwgSSB0aG91Z2h0IG9mIGFuc3dlcmluZyAocG9zaXRpdmVs eSksIGJ1dCB0aGVuIHRob3VnaHQgdGhhdCB0aGUgcmVwbyBpcyBhYm91dCB0byBtb3ZlLCBhbmQg aXQgd291bGQgcHJvYmFibHkgYmUgYmV0dGVyIHRvIGRlbGF5IHRoaW5ncyB1bnRpbCB0aGUgbW92 ZSBpcyBmaW5pc2hlZC48YnI+DQotIFRoZW4sIHRoZSBpc3N1ZSB3YXMgb3ZlcnJ1bGVkIGJ5IHlv dXIgZW1haWwuIEkgcmVhZCBpdCBhbmQgZm91bmQgaXQgaW50ZXJlc3RpbmcsIGJ1dCBob3BlZCBm b3Igc29tZW9uZSBlbHNlIHRvIGFuc3dlciBiZWNhdXNlLCBmcmFua2x5LCBJIHdhcyBhZnJhaWQg dG8gbWFrZSBhIGZvb2wgb2YgbXlzZWxmIC4uLiBiZWNhdXNlIEkga25vdyBhbG1vc3Qgbm90aGlu ZyBhYm91dCBZQU5HLjxicj4NCjxicj4NCiZsdDtqaCZndDs8YnI+DQpUaGFua3MgZm9yIGV4cGxh aW5pbmcsIEknbSBzeW1wYXRoZXRpYyBhbmQgZ3JhdGVmdWwgdGhhdCB5b3U8YnI+DQpvdmVyY2Ft ZSB5b3VyIGNvbmNlcm5zLiBJIHdhcyBpbiB0aGUgc2FtZSBwbGFjZSBvbiBZQU5HIG5vdDxicj4N CnRvbyBsb25nIGFnbywgYW5kIEkgc3RpbGwgaGF2ZSBhIHdheXMgdG8gZ28sIHRob3VnaCBJIG5v dyB0aGluazxicj4NCkkgc2VlIHNvbWUgb2YgaXRzIHByb21pc2UuPGJyPg0KPGJyPg0KQnV0IEkg ZG9uJ3QgdGhpbmsgSSBjcmVhdGVkIGEgbXVsdGljYXN0IGlzc3VlIG9uIGdpdGh1Yj8gSSBqdXN0 PGJyPg0Kbm90aWNlZCBhIGZldyBuaXRzIHdoaWxlIHJlYWRpbmcgYW5kIHNlbnQgYSBwdWxsIHJl cXVlc3QsIG5vdGhpbmc8YnI+DQpyZWFsbHkgc3Vic3RhbnRpYWwgeWV0Ljxicj4NCiZsdDsvamgm Z3Q7PGJyPg0KPGJyPg0KQnV0IG5vdyBJJ2xsIGJlIGJyYXZlIDopIEknbGwgZ28gYWhlYWQgYW5k IGFzazogaG93IGV4YWN0bHkgaXMgdGhpcyBZQU5HIHByb3Bvc2FsIG1vcmUgdGhhbiBqdXN0IGEg c3ludGF4IGNoYW5nZT8gV2hhdCB3b3VsZCBpdCBnaXZlIHVzPzxicj4NCihJIHVuZGVyc3RhbmQg dGhhdCBZQU5HIGNhbiBiZSBhdXRvbWF0aWNhbGx5IHBhcnNlZCAvIGNoZWNrZWQgYnkgc29tZSB0 b29scywgYnV0Li4uIHdoYXQgZG9lcyBUSEFUIGdpdmUgdXM/KTxicj4NCjxicj4NCiZsdDtqaCZn dDs8YnI+DQpTeW50YXggcGx1cyB0b29sIHN1cHBvcnQgaXMgdGhlIG9ubHkgZGlmZmVyZW5jZSBi ZXR3ZWVuIG1hY2hpbmUgY29kZTxicj4NCmFuZCAmbHQ7eW91ciBmYXZvcml0ZSBwcm9ncmFtbWlu ZyBsYW5ndWFnZSZndDssIHNvIGV2ZW4gaWYgdGhhdCdzIHRoZSBvbmx5PGJyPg0KdGhpbmcgd2Ug Z290LCBpdCdzIG5vdCB0byBiZSBzbmVlemVkIGF0LiAoQW5kIHRoZXJlIGlzIGEgbG90IG9mIHJv b208YnI+DQpmb3IgZ3Jvd3RoIGhlcmUsIGJ1dCB0aGVyZSBhcmUgYWxyZWFkeSB0b29scyB0aGF0 IGNhbiBnZW5lcmF0ZSBBUEk8YnI+DQpoZWFkZXIgY29kZSBmcm9tIHlhbmcsIGUuZzo8YnI+DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3dpa2kub25vc3Byb2plY3Qub3JnX2Rpc3BsYXlfT05PU19ZQU5HLTJCVG9vbHMmYW1wO2Q9 RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9YnFuRlJPaXZEb180aUY4 WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZhbXA7bT1MY3pQTS1XYy1qMkticWQzQ0FlRG9U eUtYaVhvTXplcFI3TURkczFBcHlBJmFtcDtzPWE1WUpuNjRxMFBmeXNrSWVscE90SmtiNWNIU2dC QTROTlRRWktxcTZMYkkmYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+aHR0cHM6 Ly93aWtpLm9ub3Nwcm9qZWN0Lm9yZy9kaXNwbGF5L09OT1MvWUFORyYjNDM7VG9vbHM8L3NwYW4+ PC9hPg0KICk8YnI+DQo8YnI+DQpCdXQgSSdtIGFjdHVhbGx5IHB1c2hpbmcgZnJvbSB0aGUgb3Ro ZXIgZGlyZWN0aW9uOyBteSB1bmRlcnN0YW5kaW5nPGJyPg0Kb2YgdGhlIGN1cnJlbnQgZG9jcyBp cyB0aGF0IHRhcHMtYXJjaCBpcyBhIGhpZ2ggbGV2ZWwgZGVzaWduIGFuZCBnb2Fsczxicj4NCmRv Y3VtZW50LCBhbmQgdGFwcy1pbnRlcmZhY2UgKGFuZCB0YXBzLW1pbnNldCkgbWFrZSBhbiBhdHRl bXB0IHRvPGJyPg0KbGF5IG91dCB0aGUgY29uY3JldGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0 aGF0IHdvdWxkIG1ha2UgdGFwcy1hcmNoIGE8YnI+DQpyZWFsaXR5LCBpZiBhbiBpbXBsZW1lbnRh dGlvbiBjb3ZlcnMgdGhlbS48YnI+DQo8YnI+DQpNeSBjbGFpbSBoZXJlIGlzIHR3b2ZvbGQ6PGJy Pg0KLSB0aGF0IHRhcHMtaW50ZXJmYWNlIGFzIGl0IHN0YW5kcyB0b2RheSBpcyBhbm90aGVyIGhp Z2ggbGV2ZWwgZGVzaWduPGJyPg0KZG9jdW1lbnQsIHdoaWNoIHdpbGwgaGF2ZSBhIG5lY2Vzc2Fy aWx5IGZ1enp5IG1hcHBpbmcgdG8gYW55IGFjdHVhbDxicj4NCmltcGxlbWVudGF0aW9uLjxicj4N Ci0gdGhhdCB0YXBzLWludGVyZmFjZSBpcyBfcmVhbGx5XyBfY2xvc2VfIHRvIGxheWluZyBvdXQg dGhlIGNvbmNyZXRlPGJyPg0KaW1wbGVtZW50YXRpb24gZGV0YWlscyBpbiBhIG5vbi1mdXp6eSB3 YXkgdGhhdCBjYW4gYmUgZGlyZWN0bHkgdXNlZDxicj4NCmJ5IGltcGxlbWVudG9ycywgc28gSSdt IHN1Z2dlc3RpbmcgdGhhdCB0YWtpbmcgdGhhdCBleHRyYSBzdGVwIGlzPGJyPg0KaGlnaGx5IHZh bHVhYmxlLjxicj4NCjxicj4NCk9uIHRoZSBxdWVzdGlvbiBvZiBiZW5lZml0czogSSdsbCBsYXkg b3V0IHNvbWUgb2YgdGhlIG9uZXM8YnI+DQp0aGF0IHNlZW0gaW1wb3J0YW50IHRvIG1lLCBidXQg SSdsbCBmaXJzdCBzYXkgdGhhdCBpbiB0aGVvcnksPGJyPg0KdGhlc2UgYmVuZWZpdHMgY291bGQg YmUgcmVhbGl6ZWQgYnkgYW55IGNvbmNyZXRlIGNvbmZpZ3VyYXRpb248YnI+DQpmb3JtYXQuIFRo ZSBiZW5lZml0IG9mIFlBTkcgc3BlY2lmaWNhbGx5IGNvbWVzIGZyb20gdG9vbDxicj4NCnN1cHBv cnQgYW5kIHRoZSBjb25maWRlbmNlIGZyb20gZXhpc3Rpbmcgd29yayB0aGF0IG1ha2UgaXQgY2xl YXI8YnI+DQppdCdzIGEgcmVhc29uYWJsZSBmb3JtYXQgZm9yIG5ldHdvcmtpbmcgY29uZmlndXJh dGlvbi48YnI+DQo8YnI+DQpCYXNpY2FsbHksIGJlY2F1c2UgdGhlcmUncyBzbyBtdWNoIFlBTkcg d29yayBhbHJlYWR5IGRvbmUgZm9yPGJyPg0KbmV0d29ya2luZywgdXNpbmcgWUFORyBsZXRzIHVz IGxldmVyYWdlIHNvbWUgb2YgdGhhdCB3b3JrIGluIGEgd2F5PGJyPg0Kb3RoZXIgb3B0aW9ucyBk b24ndC48YnI+DQo8YnI+DQpJbiBwYXJ0aWN1bGFyLCB0aGVyZSBhcmUgYSBidW5jaCBvZiBuZXR3 b3JraW5nLXNwZWNpZmljIGNvbmNlcHRzPGJyPg0KdGhhdCBhcmUgYWxyZWFkeSBkZWZpbmVkIGlu IGRldGFpbC4gRm9yIGV4YW1wbGUsIHRoZSBpcHY2LWFkZHJlc3M8YnI+DQp0eXBlIGhhcyBhIGNv bXBsaWNhdGVkIHJlZ2V4IHRoYXQgbWFueSBpbXBsZW1lbnRvcnMgYXJlIGxpa2VseSB0bzxicj4N CmdldCB3cm9uZyBpZiB0aGV5IHRyeSB0byByb2xsIHRoZWlyIG93biAoYXQgbGVhc3QsIEkndmUg Y2VydGFpbmx5PGJyPg0KZG9uZSBzbywgYW5kIHNlZW4gaXQgYSBidW5jaCBvZiB0aW1lcyk6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzY5OTEtMjNwYWdlLTJEMTkmYW1wO2Q9RHdN RmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9YnFuRlJPaXZEb180aUY4WjNS NER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZhbXA7bT1MY3pQTS1XYy1qMkticWQzQ0FlRG9UeUtY aVhvTXplcFI3TURkczFBcHlBJmFtcDtzPVhLT3cyam94UklDVVplbFNxYkZCNTlMaHkxS0tjUmtD YWRjTHdMVWl4Zm8mYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY5OTEjcGFnZS0xOTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0K QnV0IGJ5IG1ha2luZyB0aGUgb2J2aW91cyBjaG9pY2Ugb2YgdXNpbmcgeWFuZyB0b29scyB0byBw YXJzZSB5YW5nPGJyPg0Kc3R1ZmYsIGltcGxlbWVudG9ycyBhdXRvbWF0aWNhbGx5IGdldCBjaGVj a2luZyBhZ2FpbnN0IHRoYXQ8YnI+DQoobm9ybWF0aXZlISkgcmVnZXggZm9yIGZyZWUgd2l0aG91 dCBoYXZpbmcgdG8gbm90aWNlIGFuZCBjaGVjayBpdDxicj4NCnRoZW1zZWx2ZXMuPGJyPg0KPGJy Pg0KVGhlcmUncyBvdGhlciBzaWRlIGJlbmVmaXRzLCBsaWtlIHRoYXQgaW50ZXJmYWNlcyBhcmUg dGhlbXNlbHZlczxicj4NCmV4cGxpY2l0bHkgZGVmaW5lZCAoPGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o dG1sX3JmYzgzNDMtMjNzZWN0aW9uLTJENSZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3 MEY0anBONkxaZyZhbXA7cj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQx T29rJmFtcDttPUxjelBNLVdjLWoyS2JxZDNDQWVEb1R5S1hpWG9NemVwUjdNRGRzMUFweUEmYW1w O3M9RnBRUFdRRV90bTdGYW9JSmtPd2J1Vnp5QWllSElsX3RKWVgzanRQZm41YyZhbXA7ZT0iPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj ODM0MyNzZWN0aW9uLTU8L3NwYW4+PC9hPiksPGJyPg0KYW5kIHNvIHdoZXJlIHRoaW5ncyBsaWtl IGludGVyZmFjZSB0eXBlcyBtaWdodCBiZSB1c2VkLCB0aGUgcGFzdDxicj4NCmFuZCBmdXR1cmUg d29yayBvZiBwZW9wbGUgd2hvIGZvcm1hbGl6ZSBhbmQgZXh0ZW5kIHRoZSBzZXQgb2Y8YnI+DQpp bnRlcmZhY2UgdHlwZXMgZ2V0cyBhdXRvbWF0aWNhbGx5IGltcG9ydGVkIGJ5IHJlZmVyZW5jaW5n IHRoZTxicj4NCm5vcm1hdGl2ZSB5YW5nIGRlZmluaXRpb24gZm9yIG5ldHdvcmsgaW50ZXJmYWNl cy48YnI+DQo8YnI+DQpCdXQgdG8gbGlzdCBhIGZldyBvZiB0aGUgc3BlY2lmaWMgYmVuZWZpdHMg ZnJvbSBoYXZpbmcgYW4gZXhwbGljaXQ8YnI+DQpjb25maWcgZm9ybWF0Ojxicj4NCjxicj4NCi0g Y3Jvc3MtcGxhdGZvcm0gcG9ydGFiaWxpdHk6PGJyPg0KSWYgSSd2ZSBnb3QgYSBwcm9ncmFtIHVz aW5nIGEgdGFwcyBhcGkgdGhhdCB0YWxrcyB0byBzb21lIHNlcnZpY2UsPGJyPg0KYW5kIG5vdyBJ IHdhbnQgdG8gd3JpdGUgYSBuZXcgcHJvZ3JhbSBpbiBhIGRpZmZlcmVudCBsYW5ndWFnZSB0byB0 YWxrPGJyPg0KdG8gdGhhdCBzZXJ2aWNlLCBJIGNhbiBleHBvcnQgdGhlIGNvbmZpZyBhbmQgbG9h ZCBpdCBpbiBteSBuZXc8YnI+DQpwcm9ncmFtIChldmVuIGluIGEgbmV3IGxhbmd1YWdlKSwgYW5k IEkgY2FuIGJlIHJlYXNvbmFibHkgc3VyZTxicj4NCml0J2xsIGZvcm0gdGhlIHNhbWUga2luZCBv ZiBjb25uZWN0aW9uLjxicj4NCjxicj4NCkFsdGhvdWdoIGl0J3MgcG9zc2libGUgdG8gbWFrZSBp dCB3b3JrIGFueXdheSBhcyBsb25nIGFzIHRoZSBBUElzPGJyPg0KaGF2ZSBhIDEtdG8tMSBtYXBw aW5nLCBub3JtYWxpemluZyBvbiBhIGNvbmZpZyBmaWxlIGZvcm1hdCBpbnN0ZWFkPGJyPg0Kb2Yg YSBsaXN0IG9mIGZlYXR1cmVzIHNlZW1zIHRvIG1lIGxpa2UgaXQnbGwgc2F2ZSBtZSBwZXJoYXBz IHVwIHRvIGE8YnI+DQpkYXkgb3Igc28gb2YgZWZmb3J0IGVhY2ggdGltZSBJIGhhdmUgdG8gZG8g dGhpcywgd2hpY2ggd2hlbiBtdWx0aXBsaWVkPGJyPg0KYnkgYWxsIHRoZSBpbXBsZW1lbnRvcnMg aW4gdGhlIHdvcmxkIG92ZXIgdGhlIG5leHQgZGVjYWRlIG9yIDIsIHN0YXJ0czxicj4NCnRvIGFk ZCB1cC48YnI+DQo8YnI+DQotIHRlc3RhYmlsaXR5Ojxicj4NCkFnYWluLCB0aGlzIG1vc3RseSBz YXZlcyB0aW1lLCBidXQgYnkgaGF2aW5nIGEgZGVmaW5lZCBpbnB1dCBmb3JtYXQsPGJyPg0KaXQn cyBwb3NzaWJsZSBmb3IgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyB0byB1c2UgdGhlIHNhbWUg c3VpdGUgb2Y8YnI+DQp0ZXN0IGNvbmZpZ3VyYXRpb24gZmlsZXMgdG8gdmVyaWZ5IHRoZSBzYW1l IGludGVycHJldGF0aW9uIG9mIHRoZWlyPGJyPg0KY29udGVudHMuIElmIGVhY2ggaW1wbGVtZW50 YXRpb24gaGFzIGl0cyBvd24gd2F5IG9mIGNvbmZpZ3VyaW5nIHRoZTxicj4NCmZlYXR1cmVzLCBp dCdzIG5vdCBpbXBvc3NpYmxlIHRvIGRlc2lnbiBhIHN1aXRlIHRoYXQgY2FuIHRlc3QgdGhlbSw8 YnI+DQpidXQgaXQncyB2YXN0bHkgaGFyZGVyLjxicj4NCjxicj4NCi0gY29tcGxldGVuZXNzOjxi cj4NCk9uZSBvZiB0aGUgcG9pbnRzIG9mIGNvbmZ1c2lvbiBJIGhhZCB3aXRoIHRhcHMtaW50ZXJm YWNlIHdhcyB0aGF0IHRoZTxicj4NCkxvY2FsL1JlbW90ZUVuZHBvaW50cyBzZWVtZWQgYm90aCBj cml0aWNhbCB0byBhbiBpbXBsZW1lbnRhdGlvbiBhbmQ8YnI+DQp2ZXJ5IHVuZGVyc3BlY2lmaWVk LiBBbHRob3VnaCBpdCdzIHBvc3NpYmxlIHRvIGFkZHJlc3MgdGhhdCBieSByYWlzaW5nPGJyPg0K Y29uY2VybnMgc3BlY2lmaWNhbGx5IGFib3V0IHRoZSBMb2NhbC9SZW1vdGUgRW5kcG9pbnRzLCBJ J20gbm90IHN1cmU8YnI+DQp0aGVyZSBhcmVuJ3Qgb3RoZXIgdW5kZXJzcGVjaWZpZWQgYXJlYXMg b2YgdGhlIHRhcHMtaW50ZXJmYWNlIGRyYWZ0Ljxicj4NCjxicj4NCkkgZXhwZWN0IHRoYXQgYSBy ZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gYmFzZWQgb24gcGFyc2luZyBhIGNvbmZpZzxicj4NCmZv cm1hdCB3b3VsZCB1bmNvdmVyIGFsbCBzdWNoIHVuZGVyc3BlY2lmaWVkIGFyZWFzIG9mIGNvbmZp Z3VyYXRpb24sPGJyPg0KaWYgdGhlIGNvbmZpZyBmb3JtYXQgZXhhbXBsZXMgYXJlIHVzZWQgdG8g ZGVzY3JpYmUgYWxsIHRoZSBzdXBwb3J0ZWQ8YnI+DQp1c2UgY2FzZXMuPGJyPg0KPGJyPg0KKFNv IHBhcnQgb2YgbXkgZ29hbCB3aXRoIHRoaXMgcHJvcG9zYWwgaXMgdG8gc29sdmUgdGhpcyBwcm9i bGVtIGluPGJyPg0KdGhlIGdlbmVyYWwgY2FzZSwgd2hpY2ggaW1wbGllcyB0aGF0IGl0J2xsIGFs c28gYmUgc29sdmVkIGZvciB0aGU8YnI+DQpzcGVjaWZpYyBjYXNlcyBvZiBMb2NhbC9SZW1vdGUg RW5kcG9pbnRzLCB0aG91Z2ggb2YgY291cnNlIHRoZTxicj4NCmRldGFpbHMgZm9yIGVhY2ggaW5z dGFuY2Ugb2YgaW5jb21wbGV0ZW5lc3MgYXJlIHNlcGFyYXRlIHRvcGljcy4pPGJyPg0KPGJyPg0K VGhlcmUgbWlnaHQgYmUgc29tZSBvdGhlciBiZW5lZml0cywgYnV0IEknbGwgc3RvcCB0aGVyZSwg aG9waW5nIHRoZTxicj4NCnBvaW50IGlzIHN1ZmZpY2llbnRseSBjbGVhci48YnI+DQombHQ7L2po Jmd0Ozxicj4NCjxicj4NCkFsc28sIEkgYWN0dWFsbHkgc2VlIDMgc2VwYXJhYmxlIHRoaW5ncyBi ZWluZyBwcm9wb3NlZCBoZXJlOjxicj4NCjxicj4NCjEpIHRoZSBZQU5HIG1vZGVsPGJyPg0KJmx0 O2poJmd0Ozxicj4NCkknZCBwaHJhc2UgdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBwcm9wb3Nh bCBhcyBhbiBpbi1wcmluY2lwbGU8YnI+DQomcXVvdDt1c2UgYSBZQU5HIG1vZGVsJnF1b3Q7LCBy YXRoZXIgdGhhbiAmcXVvdDt1c2UgdGhpcyBzcGVjaWZpYyBZQU5HIG1vZGVsJnF1b3Q7Ljxicj4N Cjxicj4NClRoZSBjdXJyZW50IGRyYWZ0IGlzIGtpbmQgb2YgYSB0aHJvdy1hd2F5IGV4YW1wbGUg cHJvb2Ygb2YgY29uY2VwdCw8YnI+DQp3aGljaCBpcyBjZXJ0YWlubHkgdmVyeSBpbmNvbXBsZXRl LCBhbmQgc29tZSBvZiBteSByZWFkaW5nIHllc3RlcmRheTxicj4NCnN1Z2dlc3RzIHRoYXQgaXQn cyBhY3R1YWxseSBub3QgdmVyeSB3ZWxsIHN0cnVjdHVyZWQgZWl0aGVyLiBJJ3ZlPGJyPg0KcHJv YmFibHkgYWxyZWFkeSBtYWRlIGEgZm9vbCBvZiBteXNlbGYgdG8gYW55IGFjdHVhbCBZQU5HIGV4 cGVydHMsPGJyPg0KdGhhdCBldmVyIHRyeSB0byByZWFkIGl0LCBidXQgc3VjaCBhcmUgdGhlIHJp c2tzIG9mIHBvc3RpbmcgcHVibGljPGJyPg0KY29tbWVudHMuLi4gOik8YnI+DQombHQ7L2poJmd0 Ozxicj4NCjxicj4NCjIpIG11bHRpY2FzdCBzdXBwb3J0IChJIGZpbmQgeW91ciBjb25jbHVzaW9u IHRoYXQgbm90IG11Y2ggbmVlZHMgdG8gY2hhbmdlIGludGVyZXN0aW5nISBUaG91Z2ggdGhlIGV4 YW1wbGUgeW91J3JlIGdpdmluZyAoam9pbmluZyBhbiBTU00gY2hhbm5lbCkgaXMgb25seSBhIHBh cnQgb2Ygd2hhdCB3ZSdkIG5lZWQsIGFzIHlvdSBhbHNvIHNheS4uLik8YnI+DQombHQ7amgmZ3Q7 PGJyPg0KRmFpciBwb2ludCwgdGhpcyByZWFsbHkgaXMgYSBzZXBhcmF0ZSB0b3BpYy4gSSBicm91 Z2h0IGl0IHVwPGJyPg0KcmVhbGx5IG9ubHkgYmVjYXVzZSBpdCdzIGEgbW90aXZhdGluZyBmYWN0 b3IgaW4gbXkgcGFydGljaXBhdGlvbjxicj4NCmhlcmUsIG5vdCBiZWNhdXNlIGl0J3MgYSBwcmlt YXJ5IGZhY3RvciBmb3IgdGFwcyBpbiBnZW5lcmFsLiBMZXQnczxicj4NCmRyb3AgaXQgZm9yIHRo aXMgdGhyZWFkLCBhbmQgSSdsbCBwbGFuIHRvIHJhaXNlIGl0IGFzIGEgc2VwYXJhdGU8YnI+DQpp c3N1ZSB3aGVuIHRoZSB5YW5nIHF1ZXN0aW9ucyBhcmUgc2V0dGxlZCBhbmQgSSd2ZSBnb3Qgc29t ZXRoaW5nPGJyPg0KbW9yZSB0aG91Z2h0IG91dC48YnI+DQombHQ7L2poJmd0Ozxicj4NCjxicj4N CjMpIGFwcGx5aW5nIHByZWZlcmVuY2VzIHRvIGFkZHJlc3NlcyBhbmQgcG9ydCBudW1iZXJzICh3 aGljaCB5b3Ugc2VlbSB0byB0YWtlIGZvciBncmFudGVkIGluIHlvdXIgZHJhZnQsIGJ1dCB3aGlj aCBJIGRvbid0IHRoaW5rIGlzIHN1cHBvcnRlZCBieSBvdXIgY3VycmVudCBkb2N1bWVudCkuPGJy Pg0KPGJyPg0KJmx0O2poJmd0Ozxicj4NClllcywgdGhpcyBpcyBhIGNhc2UgaW4gcG9pbnQgZm9y IG15IGNvbmNlcm5zIGFib3V0IGluY29tcGxldGVuZXNzPGJyPg0Kb24gdGhlIEVuZHBvaW50IHNw ZWNpZmljYXRpb25zLjxicj4NCjxicj4NCkkgd2Fzbid0IHN1cmUgaG93IHRvIHRyZWF0IHRoaXMs IHNvIEknbSBub3Qgc3VycHJpc2VkIGlmIEkgZ290IGl0PGJyPg0Kd3JvbmcuIEkgd2FzIHNvcnQg b2YgcGF0dGVybi1tYXRjaGluZyBvbiB0aGUgcmVzdCBvZiB3aGF0IHRoZSBzcGVjPGJyPg0KZG9l cywgcGx1cyBndWVzc2luZyBhdCBpbnRlbmRlZCBtZWFuaW5ncyBvZiB0aGlzIHBhcmFncmFwaCBm cm9tPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRHRhcHMtMkRp bnRlcmZhY2UtMkQwMi0yM3NlY3Rpb24tMkQ1LjEmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNh TUY0dzBGNGpwTjZMWmcmYW1wO3I9YnFuRlJPaXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xu RWxUMU9vayZhbXA7bT1MY3pQTS1XYy1qMkticWQzQ0FlRG9UeUtYaVhvTXplcFI3TURkczFBcHlB JmFtcDtzPVJqam4zT21ydUNYRGJLd2dEbUFNcUh2bmUtVUhOcWFfZ21Ja19nOXo2YWcmYW1wO2U9 Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdGFwcy1pbnRlcmZhY2UtMDIjc2VjdGlvbi01LjE8L3NwYW4+PC9hPjo8YnI+ DQo8YnI+DQpNdWx0aXBsZSBlbmRwb2ludCBpZGVudGlmaWVycyBjYW4gYmUgc3BlY2lmaWVkIGZv ciBlYWNoIExvY2FsPGJyPg0KRW5kcG9pbnQgYW5kIFJlbW90ZSBFbmRwb2ludC4gRm9yIGV4YW1w bGUsIGEgTG9jYWwgRW5kcG9pbnQgY291bGQgYmU8YnI+DQpjb25maWd1cmVkIHdpdGggdHdvIGlu dGVyZmFjZSBuYW1lcywgb3IgYSBSZW1vdGUgRW5kcG9pbnQgY291bGQgYmU8YnI+DQpzcGVjaWZp ZWQgdmlhIGJvdGggSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMuIFRoZXNlIG11bHRpcGxlPGJyPg0K aWRlbnRpZmllcnMgcmVmZXIgdG8gdGhlIHNhbWUgdHJhbnNwb3J0IGVuZHBvaW50Ljxicj4NCjxi cj4NCkJ5IHRoZSB0aW1lIEkgZmluaXNoZWQgbWFraW5nIHRoZSBleGFtcGxlcywgSSBoYWQgbm90 aWNlZCBJIHdhczxicj4NCm1heWJlIGRvaW5nIGl0IHdyb25nLCBidXQgSSBkaWRuJ3Qgd2FudCB0 byBib3RoZXIgZml4aW5nIGl0IHVubGVzczxicj4NCnBlb3BsZSBhZ3JlZSBpdCdzIHdvcnRoIHNw ZW5kaW5nIGVmZm9ydCBpbiB0aGlzIGdlbmVyYWwgZGlyZWN0aW9uLCBhbmQ8YnI+DQpJIGRpZG4n dCB3YW50IHRvIGhvbGQgb2ZmIG9uIG9wZW5pbmcgdGhlIGRpc2N1c3Npb24uIE9mIGNvdXJzZSwg aXQ8YnI+DQpzaG91bGQgYmUgY2hhbmdlZCB0byBtYXRjaCB0aGUgY29uc2Vuc3VzIG9mIHRoZSB3 ZyBvbiB3aGF0IGJlbG9uZ3M8YnI+DQpoZXJlLjxicj4NCiZsdDsvamgmZ3Q7PGJyPg0KPGJyPg0K U2lkZSBub3RlOiB1bmxlc3MgSSdtIG1pc3Rha2VuLCB0aGlzIHdvdWxkbid0IGZpdCBvdXIgc3Ry dWN0dXJlIHdlbGw6IGUuZy4gYSBwb3J0IG51bWJlciB3b3VsZCB0aGVuIGJlIGEgVHJhbnNwb3J0 IFByb3BlcnR5IHRoYXQgaGFzIGEgY2VydGFpbiB2YWx1ZSwgYnV0IGFsc28gaGFzIGEgcHJlZmVy ZW5jZSwgYnV0IGN1cnJlbnRseSB3ZSBzYXkgdGhhdCBhIFRyYW5zcG9ydCBQcm9wZXJ0eSBoYXMg JnF1b3Q7b25lIG9mIGEgc2V0IG9mIGRhdGEgdHlwZXMmcXVvdDssDQogb25lIG9mIHdoaWNoIGlz IGEgUHJlZmVyZW5jZS4gSXNuJ3QgdGhhdCBzdHJ1Y3R1cmUgdG9vIGxpbWl0aW5nPyBPciBhbSBJ IG1pc3Npbmcgc29tZXRoaW5nPzxicj4NCjxicj4NCiZsdDtqaCZndDs8YnI+DQpJJ20gbm90IHN1 cmUuIFRoaXMgaXMgcGFydCBvZiB3aGF0IEkgbWVhbiB3aGVuIEkgc2F5IEkgZmluZCB0aGU8YnI+ DQpjdXJyZW50IHRhcHMtaW50ZXJmYWNlIGEgbGl0dGxlIHRvbyBsb29zZS4gSSBfdGhpbmtfIHdo YXQgSSBwb3N0ZWQ8YnI+DQppcyBhIHZhbGlkICh0aG91Z2ggcGVyaGFwcyBub3Qgb3B0aW1hbCkg aW50ZXJwcmV0YXRpb24gb2YgdGhlIGN1cnJlbnQ8YnI+DQp0ZXh0LiBJIG1pZ2h0IGJlIHdyb25n IGFib3V0IHRoYXQsIHNvIEknZCBiZSBncmF0ZWZ1bCBmb3IgYSBwb2ludGVyPGJyPg0KdG8gdGhl IHRleHQgdGhhdCBwcm9oaWJpdHMgdGhpcyBpbnRlcnByZXRhdGlvbi48YnI+DQo8YnI+DQpCdXQg cmVhbGx5LCB0aGF0J3MgYmVzaWRlIHRoZSBwb2ludC4gSSdkIGJlIGV2ZW4gbW9yZSBncmF0ZWZ1 bCBmb3IgYW48YnI+DQphbHRlcm5hdGUgcHJvcG9zYWwgdGhhdCBtb3JlIGNsb3NlbHkgbWF0Y2hl cyB0aGUgaW50ZW5kZWQgZGVzaWduIGZvcjxicj4NCmEgdGFwcyBBUEksIHdpdGggdGhlIHNhbWUg bGV2ZWwgb2YgY29uY3JldGVuZXNzLjxicj4NCiZsdDsvamgmZ3Q7PGJyPg0KPGJyPg0KSSBndWVz cyB0aGF0IDIpIG5lZWRzIDMpLCBidXQgcGVyaGFwcyBpdCdzIHVzZWZ1bCB0byBzZWUgMikgYW5k IDMpIGFzIHNlcGFyYXRlLi4uIG1heWJlIHRoZXJlIGFyZSBvdGhlciB1c2UgY2FzZXMgZm9yIDMp IGFsb25lID88YnI+DQo8YnI+DQombHQ7amgmZ3Q7PGJyPg0KWWVzLCBJIHRoaW5rIHNvLiBJIHRo aW5rIEkgdW5kZXJzdGFuZCBhbiB1bHRpbWF0ZSBnb2FsIGZvciB0YXBzIHRvPGJyPg0KYmUgJnF1 b3Q7YXMgYW4gYXBwIGRlc2lnbmVyLCBkb24ndCB3b3JyeSBhYm91dCB3aGljaCB0cmFuc3BvcnQs IGp1c3Q8YnI+DQpzZW5kIHRoZSBtYWdpYyBBUEkgdG8gZ28gZGlzY292ZXIgb25lIHRoYXQgd29y a3MmcXVvdDsuPGJyPg0KPGJyPg0KSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgaW4gdGhlIGludGVy aW0gdGhhdCBpdCdsbCBiZSBuZWNlc3Nhcnk8YnI+DQp0byBzcGVjaWZ5IHBvcnQgbnVtYmVycyBp biBvcmRlciB0byBpbnRlcm9wZXJhdGUgd2l0aCBhIGxvdCBvZjxicj4NCmV4aXN0aW5nIHNlcnZp Y2VzLCBlc3BlY2lhbGx5IGluIGNhc2VzIGxpa2UgUlRQIChvciBhIGxvdCBvZjxicj4NCm90aGVy IGdlbmVyYWxpemVkIFVEUCBzdHVmZiksIHdoZXJlIHRoZXJlJ3Mgbm90IGFuIGV4cGxpY2l0PGJy Pg0Kc2VydmljZS10by1wb3J0IG1hcHBpbmcuIChBbHNvIHRvIGludGVyb3BlcmF0ZSB3aXRoIGEg bG90IG9mPGJyPg0Kb3RoZXIgZGVwbG95ZWQgc3lzdGVtcyBsaWtlIGZpcmV3YWxscy4pPGJyPg0K PGJyPg0KSSBoYXZlIGEgZmV3IG5lYnVsb3VzIGlkZWFzIGFib3V0IGhvdyBleHBsaWNpdCBsYXll cmluZyBtaWdodCBiZSBhPGJyPg0KZ29vZCB3YXkgdG8gc29sdmUgdGhpcywgYnV0IEkgdGhpbmsg aW4gb3JkZXIgdG8gbWFrZSB0aGUgaWRlYXMgc2hhcnA8YnI+DQplbm91Z2ggdG8gZXZhbHVhdGUs IEkgdGhvdWdodCBJJ2QgZmlyc3QgdHJ5IHRoZSBlYXNpZXIgdGFzayBvZiBtYWtpbmc8YnI+DQp0 YXBzIHNoYXJwIGVub3VnaCB0aGF0IEkgY2FuIGV4cHJlc3MgdGhlIGlkZWFzIGFzIHByb3Bvc2Vk IGNoYW5nZXM8YnI+DQp0byBhbiBleGlzdGluZyB3ZWxsLWZvcm1lZCBjb25jZXB0Ljxicj4NCiZs dDsvamgmZ3Q7PGJyPg0KPGJyPg0KSU1PLCBhbGwgb2YgdGhlc2UgdGhpbmdzIGFyZSBpbnRlcmVz dGluZywgYW5kIHdvdWxkIGJlIGdvb2QgdG8gZGlzY3VzcyBvbiBzaXRlLiBIb3dldmVyLCBJIGRv dWJ0IHRoYXQgd2UgY2FuIGRlYWwgd2l0aCB0aGVtIGFsbCBpbiBvbmx5IDE1IG1pbnV0ZXMgOi0p PGJyPg0KPGJyPg0KJmx0O2poJmd0Ozxicj4NCkZhaXIgcG9pbnQuPGJyPg0KPGJyPg0KSSBwcm9w b3NlIGR1cmluZyB0aGUgdGFwcyBtZWV0aW5nIHRvIGNoZWNrIHByZWxpbWluYXJ5IGNvbnNlbnN1 cyBhYm91dDxicj4NCm1vdmluZyBmb3J3YXJkIHdpdGggYSBZQU5HIG1vZGVsIHdpdGhpbiB0YXBz LCBhbmQgaWYgc28gd2hldGhlciB0bzxicj4NCmludGVncmF0ZSwgcmVwbGFjZSwgb3IgbWFrZSBh IHBhaXJlZCBkb2Mgd2l0aCB0aGUgZXhpc3RpbmcgdGFwcy1pbnRlcmZhY2UuPGJyPg0KU2VwYXJh dGVseSwgSSdsbCBlbmNvdXJhZ2UgdGhvc2UgaW50ZXJlc3RlZCBhbmQgYXZhaWxhYmxlIHRvIHNw ZW5kIHNvbWU8YnI+DQp0aW1lIGluIG9mZmxpbmUgY2xhcmlmeWluZyBkaXNjdXNzaW9uIGR1cmlu ZyB0aGUgd2VlayBwcmlvci48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KSmFrZTxicj4NCiZsdDsv amgmZ3Q7PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCk1pY2hhZWw8YnI+DQo8YnI+DQpQUzogVHJh dmlzIGlzIGRvd24sIG9yIHNvbWV0aGluZy4gQXQgbGVhc3QgdGhlICZxdW90O0VkaXRvcidzIENv cHkmcXVvdDsgbGlua3MgZG9uJ3QgY3VycmVudGx5IHdvcmsuPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KJmd0OyBPbiA3IE1hciAyMDE5LCBhdCAwNDo1NSwgSG9sbGFuZCwgSmFrZSAmbHQ7amhvbGxh bmRAYWthbWFpLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgdGFwcyw8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAoVHJ5aW5nIGFnYWluLCBidXQgc2ltcGxlci4pPGJyPg0KJmd0Ozxi cj4NCiZndDsgSSdtIGxvb2tpbmcgZm9yIGEgY29uc2Vuc3VzIHllcyBvciBubyBhbnN3ZXI6PGJy Pg0KJmd0Ozxicj4NCiZndDsgSXMgYSBub3JtYXRpdmUgY29uZmlnIGlucHV0IGZvcm1hdCBhbiBp bnRlcmVzdGluZyBhbmQgdXNlZnVsPGJyPg0KJmd0OyBkaXJlY3Rpb24/PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IFRoZSBpZGVhIGlzIHRvIGFkZCBmdW5jdGlvbmFsaXR5IGxpa2UgdGhp cywgaW4gdGFwcy1pbnRlcmZhY2U6PGJyPg0KJmd0Ozxicj4NCiZndDsgbmV3UHJlID0gUHJlQ29u bmVjdGlvbi5OZXdGcm9tSnNvbignJyd7PGJyPg0KJmd0OyAmcXVvdDtyZW1vdGUtZW5kcG9pbnQm cXVvdDs6ezxicj4NCiZndDsgJnF1b3Q7aG9zdHMmcXVvdDs6Wzxicj4NCiZndDsgeyAmcXVvdDto b3N0JnF1b3Q7OiZxdW90O2V4YW1wbGUuY29tJnF1b3Q7IH08YnI+DQomZ3Q7IF08YnI+DQomZ3Q7 IH08YnI+DQomZ3Q7IH0nJycpPGJyPg0KJmd0Ozxicj4NCiZndDsgV2l0aCBhIGZ1bGx5IHNwZWNp ZmllZCBqc29uIGlucHV0IGZvcm1hdCB0aGF0IGNhbiBwcm92aWRlIGFsbCB0aGU8YnI+DQomZ3Q7 IGNvbmZpZ3VyYWJsZSB2YWx1ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IElmIG5v LCBJJ2xsIG1vdmUgb24gYW5kIGFzc3VtZSBJIGp1c3QgZG9uJ3QgdW5kZXJzdGFuZCB0YXBzIGdv YWxzLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHllcywgSSdkIGxpa2UgMTUgbWludXRlcyB0byBk aXNjdXNzIGluIFByYWd1ZSwgYW5kIGtlZXAgcmVhZGluZzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ IHRoaW5rIGEgZnVsbCBkZWZpbml0aW9uIG9mIGFuIGlucHV0IGpzb24gZm9ybWF0IGNhbiBiZSBl eGFjdGx5PGJyPg0KJmd0OyBzcGVjaWZpZWQgYnkgYSBZQU5HIG1vZGVsLiAoV2l0aCB4bWwgZm9y IGZyZWUsIGlmIHlvdSB3YW50IGl0Lik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRyaWVkIHRvIHNr ZXRjaCBhIHN0YXJ0IGF0IHdoYXQgYSBZQU5HIG1vZGVsIGZvciB0aGlzIG1pZ2h0IGxvb2sgbGlr ZTo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGpob2xsYW5kLTJE dGFwcy0yRGFwaS0yRHlhbmctMkQwMC0yM3NlY3Rpb24tMkQzJmFtcDtkPUR3TUZhUSZhbXA7Yz05 NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPWJxbkZST2l2RG9fNGlGOFozUjREeU5XS2JiTWVY cjBMT2dMbkVsVDFPb2smYW1wO209TGN6UE0tV2MtajJLYnFkM0NBZURvVHlLWGlYb016ZXBSN01E ZHMxQXB5QSZhbXA7cz0xV3B4Y3lmdTZ6eEV2dDVIb0lHM3ZuUF9wMDBQR0NwUWIzbVlZdlhKN1NZ JmFtcDtlPSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmctMDAjc2VjdGlvbi0zPC9zcGFu PjwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gbm90IGEgWUFORyBleHBlcnQgeWV0LCBhbmQg aXQncyBub3QgbXVjaCBvZiBhIG1vZGVsLiBBbmQgaXQncyB2ZXJ5PGJyPg0KJmd0OyBmYXIgZnJv bSBjb21wbGV0ZS4gQnV0IGl0IGNvbXBpbGVzLCBhbmQgYWxsIHRoZSBleGFtcGxlcyBpbiB0aGUg ZHJhZnQ8YnI+DQomZ3Q7IHZhbGlkYXRlIGFnYWluc3QgdGhhdCBtb2RlbCB3aXRoIGxpYnlhbmcu IElmIGl0J3Mgd29ydGh3aGlsZSwgSSB0aGluazxicj4NCiZndDsgc29tZXRoaW5nIGxpa2UgdGhp cyBjYW4gYmUgZ29vZCAoYW5kIGV4dGVuc2libGUhKSwgaWYgZG9uZSByaWdodC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJIGJlbGlldmUgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxpbmVzIHdvdWxkIHNo YXJwZW4gdXAgdGFwcy1pbnRlcmZhY2U8YnI+DQomZ3Q7IGEgbG90LiAoQWZ0ZXIgZmlsbGluZyBp biBhbGwgdGhlIHRhcHMtaW50ZXJmYWNlIHByb3BlcnRpZXMuKTxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGUgcmVhc29uIEknbSBhc2tpbmcgaXMgYmVjYXVzZSByaWdodCBub3csIHRh cHMtaW50ZXJmYWNlIHRvIG1lPGJyPg0KJmd0OyBzZWVtcyBfYWxtb3N0XyByZWFsbHkgZ29vZCwg ZXhjZXB0IHRvbyBjb25mdXNpbmcgYW5kIHZhZ3VlIHRvIGFjdHVhbGx5PGJyPg0KJmd0OyBidWls ZCBhbiBBUEkgdGhhdCBjYW4gcmVwbGFjZSBCU0Qgc29ja2V0cy4gSSB0aGluayB3aXRoIGEgc29s aWQgY29uZmlnPGJyPg0KJmd0OyBmb3JtYXQgd2l0aCBub3JtYXRpdmUgYW5kIHRlc3RhYmxlIGV4 YW1wbGVzLCB0aGF0IGNvdWxkIGJlIGZpeGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIGNvbnNl bnN1cyBzYXlzICZxdW90O2ludGVyZXN0aW5nJnF1b3Q7LCBJJ2xsIHdhbnQgMTUgbWludXRlcyB0 byBkaXNjdXNzIGl0LCBhbmQ8YnI+DQomZ3Q7IHRvIHN0YXJ0IGRpZ2dpbmcgaW50byBob3cgdG8g bWFrZSBpdCBnb29kLiAoQW5kIGFsc28gdG8gYWRkIG11bHRpY2FzdDxicj4NCiZndDsgc3VwcG9y dCB0byB0aGUgbW9kZWwgYW5kIGF0IGxlYXN0IG9uZSBpbXBsZW1lbnRhdGlvbi4pPGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhhbmtzIGZvciB5b3VyIGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IEpha2U8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDIwMTktMDMtMDQsIDE3OjE5LCAmcXVvdDtIb2xsYW5k LCBKYWtlJnF1b3Q7ICZsdDtqaG9sbGFuZEBha2FtYWkuY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBIaSB0YXBzIGZvbGtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IFRMO0RSOiBJIHRo aW5rIHRoZSBzcGVjIHNob3VsZCBoYXZlIGEgWUFORyBtb2RlbCBhbmQgSSB3YW50IHRvIHVzZSBp dDxicj4NCiZndDsgdG8gZ2V0IG11bHRpY2FzdCBzdXBwb3J0IGluIGFuIGltcGxlbWVudGF0aW9u Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHJlY2VudGx5IHN0YXJ0ZWQgZGlnZ2lu ZyBpbnRvIHRoZSB0YXBzIEFQSSB3aXRoIHRoZSBpbnRlbnQgb2YgYWRkaW5nPGJyPg0KJmd0OyBt dWx0aWNhc3Qgc3VwcG9ydCwgYnV0IGl0IGxvb2tzIGxpa2UgaXQncyBiYXNpY2FsbHkgYWxyZWFk eSB0aGVyZSwgYXM8YnI+DQomZ3Q7IGZhciBhcyBpdCBnb2VzWypdLjxicj4NCiZndDs8YnI+DQom Z3Q7IEJ1dCBJIGVuZGVkIHVwIHdpdGggYSBoaWdoZXItbGV2ZWwgY29tbWVudCwgc28gSSB0aG91 Z2h0IEknZCByYWlzZSBpdDxicj4NCiZndDsgdG8gdGhlIHdnIGFuZCBhc2sgd2hhdCB5b3UgYWxs IHRoaW5rLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZm91bmQgdGhlIHdob2xlICZxdW90O2Fic3Ry YWN0IGludGVyZmFjZSZxdW90OyBhcHByb2FjaCBhIGxpdHRsZSB0b288YnI+DQomZ3Q7IGxvb3Nl eS1nb29zZXksIHNvIEkgdGhvdWdodCBJJ2QgdHJ5IHRvIHN1Z2dlc3QgYSB3YXkgdG8gdGlnaHRl biBpdCB1cC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNeSBnb2FsIHdpdGggdGhpcyBpcyB0byBtYWtl IGl0IG11Y2ggbW9yZSBjbGVhciAodG8gdGhlIHBvaW50IG9mIGJlaW5nPGJyPg0KJmd0OyBtZWNo YW5pY2FsbHkgY2hlY2thYmxlKSBwcmVjaXNlbHkgd2hhdCBhIGNvbXBsaWFudCBBUEkgcHJvdmlk ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSdtIG5vdCBhdHRhY2hlZCB0byB0aGUgc3RydWN0dXJl IEknbSBwcm9wb3Npbmcgb3IgdG8gYW55IG9mIHRoZTxicj4NCiZndDsgcGFydGljdWxhcnMgaW4g dGhlIHN0cmF3LW1hbiBJJ3ZlIHBvc3RlZCwgYnV0IGlmIGl0J3Mgbm90IHRpZ2h0ZW5lZCB1cDxi cj4NCiZndDsgd2l0aCBzb21ldGhpbmcgYXQgYSBzaW1pbGFyIGxldmVsIG9mIGNvbmNyZXRlbmVz cywgSSdtIGNvbmNlcm5lZCB0aGF0PGJyPg0KJmd0OyBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25z IHdpbGwgYmUgbm90IG9ubHkgaW5jb21wYXRpYmxlIGluIHJhbmRvbTxicj4NCiZndDsgdW5kZXJz cGVjaWZpZWQgY29ybmVyIGNhc2VzIChsaWtlIEJTRCBzb2NrZXRzIHRvZGF5IHdoZW4geW91IHRy eSB0byBtYWtlPGJyPg0KJmd0OyBjcm9zcy1wbGF0Zm9ybSBDIGNvZGUpLCBidXQgYWxzbyBhcmUg bGlrZWx5IHRvIGVuZCB1cCB3aXRoIHZlcnkgbWFueTxicj4NCiZndDsgaW1wb3J0YW50IGRpZmZl cmVuY2VzIHRoYXQgd291bGQgbWFrZSB0aGUgd2hvbGUgdGFwcyBlZmZvcnQgbW9yZSBvciBsZXNz PGJyPg0KJmd0OyBtb290Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEluIGEgd29ybGQgd2hlcmUgd2Ug ZW5kIHVwIHdpdGggYSBkb2MgYXQgdGhlIGxldmVsIG9mIGFic3RyYWN0aW9uIEknbTxicj4NCiZn dDsgY3VycmVudGx5IHNlZWluZyBpbiBkcmFmdC10YXBzLWludGVyZmFjZSwgaXQgc2VlbXMgdG8g bWUgdGhhdCBpZiAyPGJyPg0KJmd0OyBkaWZmZXJlbnQgQVBJIGltcGxlbWVudGF0aW9ucyB3ZXJl IHdyaXR0ZW4gaW4gdGhlIHNhbWUgbGFuZ3VhZ2UsIGl0J2xsPGJyPg0KJmd0OyBiZSBwcm9oaWJp dGl2ZWx5IGRpZmZpY3VsdCBmb3IgYW4gYXBwIHRvIG1pZ3JhdGUgZnJvbSB1c2luZyBvbmUgdG8g dXNpbmc8YnI+DQomZ3Q7IHRoZSBvdGhlciwganVzdCBiZWNhdXNlIHNvIG1hbnkgYXNwZWN0cyBv ZiBpdCBhcmUgbGVmdCBvcGVuIHRvIHRoZTxicj4NCiZndDsgaW1wbGVtZW50b3JzLjxicj4NCiZn dDs8YnI+DQomZ3Q7IEluIHRoYXQgY29udGV4dCwgSSB0aG91Z2h0IGEgWUFORyBtb2RlbCB3b3Vs ZCBiZSB1c2VmdWwgaGVyZSB0bzxicj4NCiZndDsgcHJvdmlkZSBhIGNyb3NzLXBsYXRmb3JtIHdh eSB0byBzcGVjaWZ5IHdoYXQgZXhhY3QgcHJvcGVydGllcyBhbmQ8YnI+DQomZ3Q7IG9iamVjdHMg ZXhpc3QsIGFuIGV4YWN0IGZvcm1hdCBpbiB3aGljaCB0aGUgdmFsdWVzIGNhbiBiZSBzcGVjaWZp ZWQsIGFuZDxicj4NCiZndDsgd2hhdCBleGFjdCBzZW1hbnRpY3MgdGhleSBoYXZlLCB3aGlsZSBz dGlsbCBhbGxvd2luZyBmb3IgYSBzYW5lPGJyPg0KJmd0OyBleHRlbnNpb24gcGF0aCBhbmQgbGFu Z3VhZ2Utc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gZGV0YWlscy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJJ20gdGhpbmtpbmcgc29tZSBsYW5ndWFnZSBhIGJpdCBsaWtlIHRoZSBmaXJzdCBidWxsZXQg aW4gU2VjdGlvbiA0LjIgb2Y8YnI+DQomZ3Q7IHRhcHMtaW50ZXJmYWNlOjxicj4NCiZndDs8YnI+ DQomZ3Q7IEEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIFNIT1VMRCBwcm92aWRlIGEgbGFuZ3Vh Z2UtYXBwcm9wcmlhdGUgd2F5IHRvPGJyPg0KJmd0OyBjb25maWd1cmUgYSBQcmVDb25uZWN0aW9u IHVzaW5nIFlBTkcgaW5zdGFuY2UgZGF0YSBmb3IgdGhpcyBtb2RlbCwgYW5kPGJyPg0KJmd0OyBT SE9VTEQgcHJvdmlkZSBhbiBBUEkgdGhhdCBvdXRwdXRzIHRoZSBZQU5HIGluc3RhbmNlIGRhdGEg Zm9yIGFuPGJyPg0KJmd0OyBlc3RhYmxpc2hlZCBDb25uZWN0aW9uLjxicj4NCiZndDs8YnI+DQom Z3Q7IEFuIGltcGxlbWVudGF0aW9uIE1BWSBhbHNvIHByb3ZpZGUgYXBwcm9wcmlhdGUgQVBJcyBm b3IgZGlyZWN0bHkgZWRpdGluZzxicj4NCiZndDsgdGhlIG9iamVjdHMgd2l0aG91dCB1c2luZyBZ QU5HLiBJdCdzIFJFQ09NTUVOREVEIHdoZXJlIHBvc3NpYmxlIHRvIHVzZTxicj4NCiZndDsgbmFt ZXMgdGhhdCBtZWNoYW5pY2FsbHkgdHJhbnNsYXRlIHRvIHRoZSBuYW1lcyBpbiB0aGUgWUFORyBk YXRhIG1vZGVsLDxicj4NCiZndDsgdXNpbmcgY2FwaXRhbGl6YXRpb24gYW5kIHB1bmN0dWF0aW9u IGNvbnZlbnRpb25zIGFzIGV4cGVjdGVkIGZvciB0aGU8YnI+DQomZ3Q7IGxhbmd1YWdlIG9mIHRo ZSBpbXBsZW1lbnRhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmQgdGhlbiBvZiBjb3Vyc2Ug YSBZQU5HIG1vZGVsOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJh ZnQtMkRqaG9sbGFuZC0yRHRhcHMtMkRhcGktMkR5YW5nXyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZa YlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIw TE9nTG5FbFQxT29rJmFtcDttPUxjelBNLVdjLWoyS2JxZDNDQWVEb1R5S1hpWG9NemVwUjdNRGRz MUFweUEmYW1wO3M9OS13TTg2MHl1aW1jOGZiTmRTN09LdDlWaVpwckF2VURfc1NNNllKTnk0RSZh bXA7ZT0iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcvPC9zcGFuPjwvYT48YnI+ DQomZ3Q7IChkcmFmdC1qaG9sbGFuZC10YXBzLWFwaS15YW5nKTxicj4NCiZndDs8YnI+DQomZ3Q7 IElmIHRoaXMgc2VlbXMgdXNlZnVsLCBpdCB3aWxsIG5lZWQgbG90cyBvZiByZWZpbmluZy4gSSds bCBiZSBzdXJwcmlzZWQ8YnI+DQomZ3Q7IGlmIGFueSBwYXJ0IG9mIGl0IHN1cnZpdmVzIGV4YWN0 bHkgYXMgd3JpdHRlbi4gSXQncyBhIHF1aWNrIGFuZDxicj4NCiZndDsgZGlydHkgYXR0ZW1wdCB0 byBjb25jcmV0aXplIGEgZmV3IG9mIHRoZSB0aGluZ3MgSSBzYXcgbGlzdGVkIGluPGJyPg0KJmd0 OyBkcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLCBhcyBhIHN0YXJ0aW5nIHBvaW50IHRvIGZpbGwg b3V0IGlmIGl0IHNlZW1zPGJyPg0KJmd0OyB1c2VmdWwuPGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0 IHRoZSBtb2RlbCBwYXJzZXMsIGFuZCB0aGUgZXhhbXBsZSBkYXRhIGluc3RhbmNlcyBpbiB0aGUg ZHJhZnQ8YnI+DQomZ3Q7IHBhcnNlIGFnYWluc3QgdGhlIG1vZGVsIChhbGwgd2l0aCBsaWJ5YW5n KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmUgb2YgdGhlIG1haW4gcmVhc29ucyBJJ20gZG9pbmcg dGhpcyBpcyBiZWNhdXNlIGl0IHNlZW1zIHRvIG1lIHdoYXQnczxicj4NCiZndDsgc3BlY2lmaWVk IGluIHRhcHMtaW50ZXJmYWNlLTAyIHRvZGF5IGlzIG1pc3Npbmcgc29tZSBrZXkgZmVhdHVyZXMs IGxpa2U8YnI+DQomZ3Q7IGFuIGVudW1lcmF0aW9uIG9mIHRoZSBwcm9wZXJ0aWVzIGluIHRoZSBM b2NhbC9SZW1vdGVFbmRwb2ludCBleGFtcGxlcyBpbjxicj4NCiZndDsgc2VjdGlvbiA1LjEuIEFu ZCBJIGRvbid0IHNlZSB0aGF0IGxpc3RlZCBhcyBhbiBvcGVuIGlzc3VlIGluIGdpdGh1Yiw8YnI+ DQomZ3Q7IHdoaWNoIHN1cnByaXNlZCBtZSBhIGJpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRo aW5rIG92ZXJzaWdodHMgbGlrZSB0aGlzIHdpbGwgYmVjb21lIGltbWVkaWF0ZWx5IGFuZCBwYWlu ZnVsbHk8YnI+DQomZ3Q7IG9idmlvdXMgd2hlbiB0aGVyZSdzIGEgcmVmZXJlbmNlIGltcGxlbWVu dGF0aW9uIHRoYXQgaW5jbHVkZXMgYSBZQU5HPGJyPg0KJmd0OyBwYXJzZXIgYW5kIGFuIGV4cGxp Y2l0IGRhdGEgbW9kZWwsIGFzIG9wcG9zZWQgdG8gdGhlIGNvbWJpbmcgb2YgdGhlPGJyPg0KJmd0 OyBkb2N1bWVudCBhbmQgYSBzb3J0IG9mIGV5ZWJhbGxlZCBjb21wYXJpc29uIHRvIE5FQVQgdGhh dCBJIHRyaWVkPGJyPg0KJmd0OyB0aGlzIHdlZWsgdG8gcmVhY2ggdGhhdCBjb25jbHVzaW9uICh3 aGljaCBJIGZvdW5kIGNoYWxsZW5naW5nIGV2ZW48YnI+DQomZ3Q7IHRob3VnaCBJIHRob3VnaHQg Ym90aCB0aGUgZG9jdW1lbnQgYW5kIHRoZSBsaWJyYXJ5IHdlcmUgbW9zdGx5IHByZXR0eTxicj4N CiZndDsgd2VsbCB3cml0dGVuKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgd2hvbGUgdGhpbmcg YXQgdGhpcyBwb2ludCBqdXN0IHNtZWxscyB0byBtZSBtdWNoIG1vcmUgYWJzdHJhY3QgdGhhbjxi cj4NCiZndDsgaXQgcmVhbGx5IGhhcyB0byBiZSBvciB0aGFuIGl0J3MgcmVhbGx5IHVzZWZ1bCB0 byBiZSwgd2hpY2ggYm90aGVycyBtZTxicj4NCiZndDsgYmVjYXVzZSB0aGUgaWRlYSBvZiByZXBs YWNpbmcgQlNEIHNvY2tldHMgd2l0aCBzb21ldGhpbmcgdXNhYmxlIHNlZW1zPGJyPg0KJmd0OyBs aWtlIHN1Y2ggYSBncmVhdCBpZGVhLiBJJ2QgbGlrZSB0aGlzIHRvIGJlIHNvbWV0aGluZyBJIGNh biBhY3R1YWxseTxicj4NCiZndDsgdXNlIGluIGEgd2F5IHRoYXQgbWFrZXMgbXkgbGlmZSBlYXNp ZXIgc29tZWRheSBzb29uLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCBJIHRoaW5rIEknbSBhdCB0 aGUgcG9pbnQgd2hlcmUgSSBuZWVkIGEgc2FuaXR5IGNoZWNrIHRvIHNlZSBpZiBJJ208YnI+DQom Z3Q7IGp1c3QgbWlzc2luZyBzb21ldGhpbmcsIG9yIGlmIHRoaXMgc2VlbXMgbGlrZSBhIHVzZWZ1 bCBkaXJlY3Rpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhvdWdodHM/IFN1Z2dlc3Rpb25zPyBX b3J0aCBkaXNjdXNzaW5nIGluIFByYWd1ZT8gKElmIHNvLCBjYW4gSTxicj4NCiZndDsgZ2V0IGEg c2xvdD8pPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDsgSmFrZTxicj4NCiZn dDs8YnI+DQomZ3Q7ICo6PGJyPg0KJmd0OyBJIGNvbmNsdWRlZCB0aGF0IHRoZXJlJ3Mgbm8gcmVh c29uIG11bHRpY2FzdCBjb3VsZG4ndCBiZSBzdXBwb3J0ZWQ8YnI+DQomZ3Q7IHRvZGF5LCBpZiB0 aGVyZSB3ZXJlIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgY291bGQgcmVhc29uYWJseSBjbGFpbSB0 byBiZTxicj4NCiZndDsgY29tcGxpYW50LCBieSBqdXN0IGFkYXB0aW5nIHNvbWUgb2YgdGhlIGV4 YW1wbGVzIGluPGJyPg0KJmd0OyBkcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLTAyIGFuZCB1bmRl cnN0YW5kaW5nIHRoZSBzZW1hbnRpYyBtZWFuaW5nIG9mPGJyPg0KJmd0OyBtdWx0aWNhc3QgYWRk cmVzcyBzcGFjZXMgaW5zaWRlIHRoZSBBUEkuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIGV4YW1w bGUsIEkgY291bGRuJ3QgZmluZCBhbnkgcmVhc29uIHRoaXMgY2FuJ3QgYmUgZXhwZWN0ZWQgdG8g c2V0PGJyPg0KJmd0OyB1cCBhbiBTU00gY2hhbm5lbCBzdWJzY3JpcHRpb24gd2l0aG91dCBhbnkg ZnVydGhlciBhZG8sIGdpdmVuIGEgc2FuZTxicj4NCiZndDsgaW1wbGVtZW50YXRpb24gdGhhdCBz dXBwb3J0cyBpdDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZW1vdGVTcGVjaWZpZXIgOj0gTmV3UmVt b3RlRW5kcG9pbnQoKTxicj4NCiZndDsgUmVtb3RlU3BlY2lmaWVyLldpdGhJUHY0QWRkcmVzcygx OTIuMC4yLjIxKTxicj4NCiZndDs8YnI+DQomZ3Q7IExvY2FsU3BlY2lmaWVyIDo9IE5ld0xvY2Fs RW5kcG9pbnQoKTxicj4NCiZndDsgTG9jYWxTcGVjaWZpZXIuV2l0aFBvcnQoMzAwMDApPGJyPg0K Jmd0OyBMb2NhbFNwZWNpZmllci5XaXRoSVB2NEFkZHJlc3MoMjMyLjI1Mi4wLjIpPGJyPg0KJmd0 Ozxicj4NCiZndDsgTmV3UHJlY29ubmVjdGlvbihSZW1vdGVTcGVjaWZpZXIsIExvY2FsU3BlY2lm aWVyKS5MaXN0ZW4oLi4uKTxicj4NCiZndDs8YnI+DQomZ3Q7IE1heWJlIHRoZXJlJ3Mgc29tZSB2 YWx1ZSBpbiBzcGVjaWZ5aW5nIGEgJnF1b3Q7Sm9pblNTTSgpJnF1b3Q7IHRvIG92ZXJyaWRlIGRl ZmF1bHRzPGJyPg0KJmd0OyBpbiB0aGUgUHJlQ29ubmVjdGlvbiwganVzdCB0byBtYWtlIHN1cmUg eW91J3JlIHNwZWNpZmljYWxseSBhc2tpbmcgZm9yPGJyPg0KJmd0OyBtdWx0aWNhc3QuIEkgdGhp bmsgdGhhdCB3b3VsZCBiZSBmaW5lIGZvciBuYXRpdmUgbXVsdGljYXN0LCBidXQgbGlrZSBJPGJy Pg0KJmd0OyBzYWlkLCBhIG11Y2ggc21hbGxlciBwb2ludCB0aGFuIHRoZSBsb29zZW5lc3Mgb2Yg dGhlIEFQSS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGVyZSBpdCBnZXRzIGEgYml0IG1vcmUgY29t cGxpY2F0ZWQgaXMgdHJ5aW5nIHRvIGhhbmRsZSBtdWx0aXBsZSBvcHRpb25zPGJyPg0KJmd0OyBm b3IgZGlzY292ZXJpbmcgYSB1c2FibGUgdW5pY2FzdCB0dW5uZWwgZm9yIG11bHRpY2FzdCB0cmFm ZmljLCBhczxicj4NCiZndDsgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi40LjEgb2YgZHJhZnQtaWV0 Zi1tYm9uZWQtZHJpYWQtYW10LWRpc2NvdmVyeS0wMS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ2Qg bGlrZSB0byBoYXZlIGEgZGVjZW50IHBsYWNlIHRvIHRhY2sgb24gYW4gZXh0ZW5zaW9uIHRvIHRo aXMgQVBJIHRoYXQ8YnI+DQomZ3Q7IGNhbiB0cmFuc3BhcmVudGx5LCB3aXRoaW4gdGhlIGNvbm5l Y3Rpb24gQVBJLCBkaXNjb3ZlciB0aGUgYmVzdCBhdmFpbGFibGU8YnI+DQomZ3Q7IEFNVCByZWxh eSBhbmQgc3RhcnQgdXNpbmcgaXQgd2hlbiBuYXRpdmUgam9pbmluZyBpcyB1bmF2YWlsYWJsZSAo YW5kIGFsc288YnI+DQomZ3Q7IHRvIHByb3ZpZGUgbm9ybWF0aXZlIGNvbnRyb2xzIGZvciBjb25m aWd1cmluZyBpdCB3aGVuIHRoZXJlJ3M8YnI+DQomZ3Q7IGFkbWluaXN0cmF0aXZlIGNvbmZpZ3Vy YXRpb24gdG8gYmUgYWRkZWQpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCB0aGF0J3MgYSAybmQg b3JkZXIgcXVlc3Rpb24gZm9yIG1lIGF0IHRoaXMgcG9pbnQsIGJlY2F1c2UgaW4gdGhlPGJyPg0K Jmd0OyBjdXJyZW50IFRBUFMgQVBJIEkgZG9uJ3Qgc2VlIGFueSBvYnZpb3VzbHkgZ29vZCBzcG90 IHRvIHB1dCBzZWxlY3Rpb248YnI+DQomZ3Q7IGNvbnRyb2xzIGZvciB0aGF0IGtpbmQgb2YgdHVu bmVsIGRpc2NvdmVyeSBzZWxlY3Rpb24sIG9yIHJlYWxseSBhIGdvb2Q8YnI+DQomZ3Q7IHdheSB0 byBleHBsYWluIHdoYXQgaXQncyBzdXBwb3NlZCB0byBkbywgaWYgSSB0cmllZCB0byBhZGQgY29u dHJvbHMgdG88YnI+DQomZ3Q7IHNvbWV0aGluZyB0aGF0J3MgdGhlcmUuPGJyPg0KJmd0Ozxicj4N CiZndDsgU29sdmluZyB0aGF0IGlzIG15IG1haW4gbW90aXZhdGlvbiBmb3IgYmVpbmcgaGVyZS4g KFdlbGwsIGFuZCB0aGF0PGJyPg0KJmd0OyB0aGUgQlNEIHNvY2tldCBBUEkgZm9yIG11bHRpY2Fz dCBpcyBraW5kIG9mIGEgZGlzYXN0ZXIgdG9kYXkuKTxicj4NCiZndDs8YnI+DQomZ3Q7IEFueXdh eSwgaWYgdGFwcyBmaW5kcyB0aGUgd2hvbGUgWUFORyBzdWdnZXN0aW9uIHVzZWZ1bCwgSSdsbCBw cm9iYWJseTxicj4NCiZndDsgc3VnZ2VzdCBzb21lIG5ldyBleHRlbnNpb25zIGFib3V0IHRoaXMs IGFuZCBtYXliZSBhIGZldyBvdGhlciBwb2ludHMsPGJyPg0KJmd0OyBlc3BlY2lhbGx5IG1heWJl IGFyb3VuZCB0cnlpbmcgdG8gcHV0IGluIGEgc3RydWN0dXJlIHRoYXQgY2FuIHN1cHBvcnQ8YnI+ DQomZ3Q7IHNvbWUga2luZCBvZiBzYW5lIGV4cGxpY2l0IGxheWVyaW5nLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEJ1dCBJJ20gbm90IHN1cmUgSSBjYW4gYXJ0aWN1bGF0ZSB0aG9zZSBzdWdnZXN0aW9u cyBpbiBhIHdheSBJJ20gc3VyZSBpczxicj4NCiZndDsgbWVhbmluZ2Z1bCB3aXRob3V0IGZpcnN0 IGdldHRpbmcgYSBtb3JlIGNsZWFyIHNwZWNpZmljYXRpb24gbmFpbGVkIGRvd248YnI+DQomZ3Q7 IGFib3V0IHdoYXQncyBhY3R1YWxseSBpbiB0aGUgdGFwcyBzcGVjLiBCZWNhdXNlIHJpZ2h0IG5v dyBJJ20gbW9zdGx5PGJyPg0KJmd0OyBqdXN0IGNvbmZ1c2VkIGFib3V0IHdoYXQgYW4gQVBJIGlt cGxlbWVudGF0aW9uIHdvdWxkIHJlYWxseSBsb29rIGxpa2UsPGJyPg0KJmd0OyBhbmQgaG93IHlv dSBjb3VsZCB0ZWxsIHdoZXRoZXIgaXQgbWF0Y2hlcyB0aGUgdGFwcy1pbnRlcmZhY2Ugc3BlYy48 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb206IEFhcm9uIEZhbGsg Jmx0O2Fhcm9uLmZhbGtAZ21haWwuY29tJmd0Ozxicj4NCiZndDsgRGF0ZTogMjAxOS0wMy0wNCBh dCAxMDo1Mzxicj4NCiZndDsgVG86IHRhcHMgV0cgJmx0O3RhcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0K Jmd0OyBDYzogWmFoZWR1enphbWFuIFNhcmtlciAmbHQ7emFoZWR1enphbWFuLnNhcmtlckBlcmlj c3Nvbi5jb20mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBbVGFwc10gY2FsbCBmb3IgYWdlbmRhIGl0 ZW1zIGF0IFRBUFMgSUVURi0xMDQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBBbGwtPGJyPg0KJmd0 OyBXaGF0IHNob3VsZCB3ZSB1c2Ugb3VyIHRpbWUgdG8gZGlzY3Vzcz8gTGV04oCZcyBmb2N1cyBv biB0aGluZ3MgdGhhdCB3b3VsZCBiZW5lZml0IGZyb20gZjJmIGRpc2N1c3Npb24sIGNvbnNlbnN1 cyBidWlsZGluZywgb3IganVzdCBhcmd1bWVudC4gOik8YnI+DQomZ3Q7IOKAoiBUQVBTIGRvY3M6 IGFyZSB0aGVyZSBvcGVuIHRvcGljcyB0aGF0IG5lZWQgZ3JvdXAgYXR0ZW50aW9uPyBTZWVtcyBs aWtlIHdlIHNldHRsZWQgbW9zdCBvZiB0aGUgcmVtYWluZGVyIGF0IHRoZSBpbnRlcmltLjxicj4N CiZndDsg4oCiIFRBUFMgc2VjdXJpdHk6IHRoaXMgc2VlbXMgbmVhcmx5IGRvbmUuIEFueXRoaW5n IHRvIGRpc2N1c3M/PGJyPg0KJmd0OyDigKIgSW1wbGVtZW50YXRpb25zOiBhIGdvb2QgdG9waWMg Zm9yIGluZm9ybWF0aW9uIHNoYXJpbmcgYnV0IGxlc3MgaW1wb3J0YW50IHRoYW4gYW55dGhpbmcg bmVlZGluZyBhZ3JlZW1lbnQ8YnI+DQomZ3Q7IOKAoiBNb2JpbGl0eTogPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm Lm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRGRtbS0yRG9uZGVtYW5kLTJEbW9iaWxpdHktMkQxNyZh bXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1icW5GUk9pdkRv XzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJmFtcDttPXBMVzVnU3lldGZWZV9peEc0 X3U3cUtYX1Zjaklxek43SnUyQmdNMnJwUW8mYW1wO3M9SFVzQlZCRl9HaE5pT2szZ3FZX201cVpN RC1zUG1CSjkzR0U1d2QzRDVfcyZhbXA7ZT0iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3Nzci Pmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRkbW0tMkRvbmRlbWFuZC0yRG1vYmlsaXR5 LTJEMTcmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9YnFu RlJPaXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZhbXA7bT1wTFc1Z1N5ZXRm VmVfaXhHNF91N3FLWF9WY2pJcXpON0p1MkJnTTJycFFvJmFtcDtzPUhVc0JWQkZfR2hOaU9rM2dx WV9tNXFaTUQtc1BtQko5M0dFNXdkM0Q1X3MmYW1wO2U9PC9zcGFuPjwvYT4NCiBhbmQgPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19k YXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfcmV2aWV3LTJEaWV0Zi0yRGRtbS0yRG9uZGVtYW5kLTJE bW9iaWxpdHktMkQxNS0yRHRzdmFydC0yRGxjLTJEd2VzdGVybHVuZC0yRDIwMTktMkQwMS0yRDA4 XyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1icW5GUk9p dkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJmFtcDttPXBMVzVnU3lldGZWZV9p eEc0X3U3cUtYX1Zjaklxek43SnUyQmdNMnJwUW8mYW1wO3M9MFltQ19YQ0F1NF9HVllkRmkwSHhp S2FLQnBhbjJDT1lxQkwxbUI2YlhyWSZhbXA7ZT0iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX3Jldmlldy0yRGlldGYtMkRkbW0tMkRvbmRlbWFuZC0y RG1vYmlsaXR5LTJEMTUtMkR0c3ZhcnQtMkRsYy0yRHdlc3Rlcmx1bmQtMkQyMDE5LTJEMDEtMkQw OF8mYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9YnFuRlJP aXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZhbXA7bT1wTFc1Z1N5ZXRmVmVf aXhHNF91N3FLWF9WY2pJcXpON0p1MkJnTTJycFFvJmFtcDtzPTBZbUNfWENBdTRfR1ZZZEZpMEh4 aUthS0JwYW4yQ09ZcUJMMW1CNmJYclkmYW1wO2U9PC9zcGFuPjwvYT48YnI+DQomZ3Q7IC0tYWFy b248YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBUYXBzIG1haWxpbmcg bGlzdDxicj4NCiZndDsgVGFwc0BpZXRmLm9yZzxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb190YXBzJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRq cE42TFpnJmFtcDtyPWJxbkZST2l2RG9fNGlGOFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2sm YW1wO209TGN6UE0tV2MtajJLYnFkM0NBZURvVHlLWGlYb016ZXBSN01EZHMxQXB5QSZhbXA7cz1G Z2FaUHhOWTlwTVV0bGV4cFN2UFNHRXNMVmEwUGs3YUxWTjdPQTlzZ1gwJmFtcDtlPSI+DQo8c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90YXBzPC9zcGFuPjwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRhcHMgbWFpbGluZyBsaXN0 PGJyPg0KVGFwc0BpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fdGFwcyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1i cW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJmFtcDttPUxjelBNLVdj LWoyS2JxZDNDQWVEb1R5S1hpWG9NemVwUjdNRGRzMUFweUEmYW1wO3M9RmdhWlB4Tlk5cE1VdGxl eHBTdlBTR0VzTFZhMFBrN2FMVk43T0E5c2dYMCZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RhcHM8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E66700D441F64C9AB2F29DE6519C9C5Cakamaicom_-- From nobody Thu Mar 7 13:30:19 2019 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 903F613116B for ; Thu, 7 Mar 2019 13:30:18 -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_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 dR5cXA6eDglZ for ; Thu, 7 Mar 2019 13:30:16 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 F4170131164 for ; Thu, 7 Mar 2019 13:30:12 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id a48so18960114qtb.4 for ; Thu, 07 Mar 2019 13:30:12 -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=riIEdMwkPFlNvcHd0YvujMB+RL8ViZjdCt2nfCYakak=; b=e5pAhb4D4edDYjKPB9Lfboxl9o+lHLHbvpREiMBhCWSKE1ENiEGNxs+GQyPkpoUxhS +bUHKm3KzK8QtFk5q1v9+sYjBVYhQiVfr29LSDLXctaVbd4N9YlsyvcqHvZD/c8tKlgo O3aoX0PsvuwhaVCRVpWdQIqO9Pk5SbphMzHpY3+hMufSBZXh0U55uXw+HaP1RGbqcZ1m Yzua6SqHVKQLTisKpy94OZDSy1mb4GL/gkGy0dOxZhwt7FIl53CIEjNHiRDxgOz0v6PS lVE9sYYkystm+8jJNrM+T2PWWeg28uLhxj4JYdiAaA/0s07qxbtKhiO+Bq2ygQ157UrZ t1ng== 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=riIEdMwkPFlNvcHd0YvujMB+RL8ViZjdCt2nfCYakak=; b=hLQ4wjwic2RkM4yrvOPZIFbWWdt1ujai6DtD5obQf2MgIF6A13uSwrYKahGurTTkZb x3FE3/IlU6hdqrocI803wShKn+0WV2rjg9I1JI9s3fK2tYnaYXcrsn6wzRLVLAOtcWSr Tx8INwevMiJXtShVlOL8kh3aMUDqw8qKeeIz4RaMoawY5vrJcQHIkBoQDqy8rjCY4Ln3 XBSxl7MWjVygtgSQ2acMbYeRHRSttrcTdXE0WxnIqxtHVL8TWAR3uJznVuc26/H8XpCS HIJKzEdHYaW6+EWZN65TjETexe44TBRl5Ka9qWUmuiyc+yOgjHI4HbbqeEQOjynCA+74 CEOA== X-Gm-Message-State: APjAAAUX7IVLi7niKilCL3mc7Ytbm0tjUQIJ6rKVofpBwtR4jZYQVMg4 W9rCv9yPKyy7z645Gy2G1agndICl X-Google-Smtp-Source: APXvYqxVqgojDMQeHib8GjI5GZwuR7+6eBZ4sa0fB6Ncy1Yw5Bu2Sel9BIw3QunBxSVdQTu/9pxlEw== X-Received: by 2002:a0c:c906:: with SMTP id r6mr12532767qvj.121.1551994211592; Thu, 07 Mar 2019 13:30:11 -0800 (PST) Received: from [172.19.37.49] ([2001:4878:a000:3000:d113:abb9:4bf3:8f75]) by smtp.gmail.com with ESMTPSA id x25sm3802967qtx.71.2019.03.07.13.30.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 13:30:10 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" Date: Thu, 07 Mar 2019 16:30:09 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_245206D9-8171-41D3-A70F-852272236E0B_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] draft agenda for TAPS IETF-104 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, 07 Mar 2019 21:30:18 -0000 --=_MailMate_245206D9-8171-41D3-A70F-852272236E0B_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Here’s a proposal for an agenda. Did I miss anything? Any other comments? --aaron 1. Agenda bash (2m) 2. WG update - chairs (5m) 3. Core doc discussion: How should we do framing? - Tommy Pauly (20m) 4. ETH Implementation Report - Brian Trammell (15m) 5. Proposal to Create a YANG Model - Jake Holland (20m) 6. Using TAPS for Multicast - Jake Holland (10m) 7. [TAPS & mobility](https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/) - TBD (15m) --=_MailMate_245206D9-8171-41D3-A70F-852272236E0B_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Here=E2=80=99s a proposal for an agenda. Did I miss any= thing? Any other comments?

--aaron

  1. Agenda bash (2m)

  2. WG update - chairs (5m)

  3. Core doc discussion: How should we do fra= ming? - Tommy Pauly (20m)

  4. ETH Implementation Report - Brian Trammel= l (15m)

  5. Proposal to Create a YANG Model - Jake Ho= lland (20m)

  6. Using TAPS for Multicast - Jake Holland (= 10m)

  7. TAPS & = mobility - TBD (15m)

--=_MailMate_245206D9-8171-41D3-A70F-852272236E0B_=-- From nobody Fri Mar 8 05:29:15 2019 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 1FBC11279A1 for ; Fri, 8 Mar 2019 05:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 OQ2BFT5mz2An for ; Fri, 8 Mar 2019 05:29:07 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 509C31279B3 for ; Fri, 8 Mar 2019 05:29:07 -0800 (PST) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h2FYe-0009H1-GS; Fri, 08 Mar 2019 14:29:04 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1h2FYc-0003DS-Tp; Fri, 08 Mar 2019 14:29:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Fri, 8 Mar 2019 14:29:01 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <5A7D2650-A9AE-4F60-8FB6-93C27B1C58C9@ifi.uio.no> References: <3ADB8E2C-CA29-43C5-B7A8-D6C817BC98E6@gmail.com> <33A7614B-4009-4534-93AA-7022F4C436E6@akamai.com> <4E7DBBA1-FCD5-4E64-AEC1-8E52417B3ACA@akamai.com> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2507C37CD71E85DDCC046B4EBAAE5971EA4A4688 Archived-At: Subject: Re: [Taps] call for agenda items at TAPS IETF-104 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, 08 Mar 2019 13:29:13 -0000 Hi, A few answers in line; I'll mark them with MW: > On 7 Mar 2019, at 20:10, Holland, Jake wrote: >=20 > Hi Michael, >=20 > Thanks for responding, much appreciated. (And also to Tommy > and Aaron.) >=20 > Based on the replies from you, Tommy, and Aaron, I'll plan > to present something in Prague, and can you please put me > on the schedule, Aaron? >=20 > More responses inline with , and thanks, these > questions were very helpful to help me focus on what needs > explaining vs. what's obvious. >=20 >=20 > =EF=BB=BFOn 2019-03-07, 00:32, "Michael Welzl" = wrote: >=20 > Hi, >=20 > Very sorry for the silence. I can only speak for myself, but here's = an example of why this one person was silent: > - When you created your issue on multicast in github, I thought of = answering (positively), but then thought that the repo is about to move, = and it would probably be better to delay things until the move is = finished. > - Then, the issue was overruled by your email. I read it and found = it interesting, but hoped for someone else to answer because, frankly, I = was afraid to make a fool of myself ... because I know almost nothing = about YANG. >=20 > > Thanks for explaining, I'm sympathetic and grateful that you > overcame your concerns. I was in the same place on YANG not > too long ago, and I still have a ways to go, though I now think > I see some of its promise. >=20 > But I don't think I created a multicast issue on github? I just > noticed a few nits while reading and sent a pull request, nothing > really substantial yet. MW: Sorry, that might have just been a response to an issue or PR = somewhere, I saw an email flying by, that's all... > >=20 > But now I'll be brave :) I'll go ahead and ask: how exactly is = this YANG proposal more than just a syntax change? What would it give = us? > (I understand that YANG can be automatically parsed / checked by = some tools, but... what does THAT give us?) >=20 > > Syntax plus tool support is the only difference between machine code > and , so even if that's the only > thing we got, it's not to be sneezed at. (And there is a lot of room > for growth here, but there are already tools that can generate API > header code from yang, e.g: > https://wiki.onosproject.org/display/ONOS/YANG+Tools ) >=20 > But I'm actually pushing from the other direction; my understanding > of the current docs is that taps-arch is a high level design and goals > document, and taps-interface (and taps-minset) make an attempt to > lay out the concrete implementation details that would make taps-arch = a > reality, if an implementation covers them. >=20 > My claim here is twofold: > - that taps-interface as it stands today is another high level design > document, which will have a necessarily fuzzy mapping to any actual > implementation. > - that taps-interface is _really_ _close_ to laying out the concrete > implementation details in a non-fuzzy way that can be directly used > by implementors, so I'm suggesting that taking that extra step is > highly valuable. >=20 > On the question of benefits: I'll lay out some of the ones > that seem important to me, but I'll first say that in theory, > these benefits could be realized by any concrete configuration > format. The benefit of YANG specifically comes from tool > support and the confidence from existing work that make it clear > it's a reasonable format for networking configuration. >=20 > Basically, because there's so much YANG work already done for > networking, using YANG lets us leverage some of that work in a way > other options don't. >=20 > In particular, there are a bunch of networking-specific concepts > that are already defined in detail. For example, the ipv6-address > type has a complicated regex that many implementors are likely to > get wrong if they try to roll their own (at least, I've certainly > done so, and seen it a bunch of times): > https://tools.ietf.org/html/rfc6991#page-19 >=20 > But by making the obvious choice of using yang tools to parse yang > stuff, implementors automatically get checking against that=20 > (normative!) regex for free without having to notice and check it > themselves. >=20 > There's other side benefits, like that interfaces are themselves > explicitly defined (https://tools.ietf.org/html/rfc8343#section-5), > and so where things like interface types might be used, the past > and future work of people who formalize and extend the set of > interface types gets automatically imported by referencing the > normative yang definition for network interfaces. >=20 > But to list a few of the specific benefits from having an explicit > config format: >=20 > - cross-platform portability: > If I've got a program using a taps api that talks to some service, > and now I want to write a new program in a different language to talk > to that service, I can export the config and load it in my new > program (even in a new language), and I can be reasonably sure > it'll form the same kind of connection. >=20 > Although it's possible to make it work anyway as long as the APIs > have a 1-to-1 mapping, normalizing on a config file format instead > of a list of features seems to me like it'll save me perhaps up to a > day or so of effort each time I have to do this, which when multiplied > by all the implementors in the world over the next decade or 2, starts > to add up. >=20 > - testability: > Again, this mostly saves time, but by having a defined input format, > it's possible for different implementations to use the same suite of > test configuration files to verify the same interpretation of their > contents. If each implementation has its own way of configuring the > features, it's not impossible to design a suite that can test them, > but it's vastly harder. >=20 > - completeness: > One of the points of confusion I had with taps-interface was that the > Local/RemoteEndpoints seemed both critical to an implementation and > very underspecified. Although it's possible to address that by = raising > concerns specifically about the Local/Remote Endpoints, I'm not sure > there aren't other underspecified areas of the taps-interface draft. >=20 > I expect that a reference implementation based on parsing a config > format would uncover all such underspecified areas of configuration, > if the config format examples are used to describe all the supported > use cases. >=20 > (So part of my goal with this proposal is to solve this problem in > the general case, which implies that it'll also be solved for the > specific cases of Local/Remote Endpoints, though of course the > details for each instance of incompleteness are separate topics.) >=20 > There might be some other benefits, but I'll stop there, hoping the > point is sufficiently clear. > MW: Absolutely, yes - some very good arguments here. The "common config format" argument in particular got me excited! > Also, I actually see 3 separable things being proposed here: >=20 > 1) the YANG model > > I'd phrase the current status of the proposal as an in-principle > "use a YANG model", rather than "use this specific YANG model". >=20 > The current draft is kind of a throw-away example proof of concept, > which is certainly very incomplete, and some of my reading yesterday > suggests that it's actually not very well structured either. I've > probably already made a fool of myself to any actual YANG experts, > that ever try to read it, but such are the risks of posting public > comments... :) > >=20 > 2) multicast support (I find your conclusion that not much needs = to change interesting! Though the example you're giving (joining an SSM = channel) is only a part of what we'd need, as you also say...) > > Fair point, this really is a separate topic. I brought it up > really only because it's a motivating factor in my participation > here, not because it's a primary factor for taps in general. Let's > drop it for this thread, and I'll plan to raise it as a separate > issue when the yang questions are settled and I've got something > more thought out. > MW: To be clear, there has always been only one argument against = multicast in TAPS, and that was: "it's complex, so let's deal with it = later." So I think we're all for it... we just didn't get to work on it. > 3) applying preferences to addresses and port numbers (which you = seem to take for granted in your draft, but which I don't think is = supported by our current document). >=20 > > Yes, this is a case in point for my concerns about incompleteness > on the Endpoint specifications. >=20 > I wasn't sure how to treat this, so I'm not surprised if I got it > wrong. I was sort of pattern-matching on the rest of what the spec > does, plus guessing at intended meanings of this paragraph from > https://tools.ietf.org/html/draft-ietf-taps-interface-02#section-5.1: >=20 > Multiple endpoint identifiers can be specified for each Local > Endpoint and Remote Endpoint. For example, a Local Endpoint could = be > configured with two interface names, or a Remote Endpoint could be > specified via both IPv4 and IPv6 addresses. These multiple > identifiers refer to the same transport endpoint. >=20 > By the time I finished making the examples, I had noticed I was > maybe doing it wrong, but I didn't want to bother fixing it unless > people agree it's worth spending effort in this general direction, and > I didn't want to hold off on opening the discussion. Of course, it > should be changed to match the consensus of the wg on what belongs > here. > >=20 > Side note: unless I'm mistaken, this wouldn't fit our structure = well: e.g. a port number would then be a Transport Property that has a = certain value, but also has a preference, but currently we say that a = Transport Property has "one of a set of data types", one of which is a = Preference. Isn't that structure too limiting? Or am I missing = something? >=20 > > I'm not sure. This is part of what I mean when I say I find the > current taps-interface a little too loose. I _think_ what I posted > is a valid (though perhaps not optimal) interpretation of the current > text. I might be wrong about that, so I'd be grateful for a pointer > to the text that prohibits this interpretation. MW: Things have changed so much since the -02 version, including a = re-organization of properties... and the latest version doesn't seem to = pop up under the "editor's copy" link now, after the move. Therefore, I don't want to point to some specific bit of the text now. = Let's get back to this discussion later, on the basis of the next = -interface draft version. > But really, that's beside the point. I'd be even more grateful for an > alternate proposal that more closely matches the intended design for > a taps API, with the same level of concreteness. MW: I liked your proposal! It just maybe calls for a change of what we = have (rather than changing what you propose). > >=20 > I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) = as separate... maybe there are other use cases for 3) alone ? >=20 > > Yes, I think so. I think I understand an ultimate goal for taps to > be "as an app designer, don't worry about which transport, just > send the magic API to go discover one that works". >=20 > However, it seems to me in the interim that it'll be necessary > to specify port numbers in order to interoperate with a lot of > existing services, especially in cases like RTP (or a lot of > other generalized UDP stuff), where there's not an explicit > service-to-port mapping. (Also to interoperate with a lot of > other deployed systems like firewalls.) >=20 > I have a few nebulous ideas about how explicit layering might be a > good way to solve this, but I think in order to make the ideas sharp > enough to evaluate, I thought I'd first try the easier task of making > taps sharp enough that I can express the ideas as proposed changes > to an existing well-formed concept. > MW: all of that makes sense to me, too. > IMO, all of these things are interesting, and would be good to = discuss on site. However, I doubt that we can deal with them all in only = 15 minutes :-) >=20 > > Fair point. >=20 > I propose during the taps meeting to check preliminary consensus about > moving forward with a YANG model within taps, and if so whether to > integrate, replace, or make a paired doc with the existing = taps-interface. > Separately, I'll encourage those interested and available to spend = some > time in offline clarifying discussion during the week prior. >=20 > Cheers, > Jake > MW: IMO, making a paired doc seems like a good strategy. Cheers, Michael From nobody Fri Mar 8 08:35:50 2019 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 1EA78124B16 for ; Fri, 8 Mar 2019 08:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 W6QrDHmQUJuY for ; Fri, 8 Mar 2019 08:35:46 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 9620112008F for ; Fri, 8 Mar 2019 08:35:45 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x28GZfsA017460 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Mar 2019 17:35:41 +0100 Received: from p200300d4171808004dbe218a2dfa2526.dip0.t-ipconnect.de ([2003:d4:1718:800:4dbe:218a:2dfa:2526]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1h2IRh-0003gH-4Q; Fri, 08 Mar 2019 17:34:05 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: "Philipp S. Tiesel" In-Reply-To: Date: Fri, 8 Mar 2019 17:35:40 +0100 Cc: taps WG , Zaheduzzaman Sarker Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Taps] draft agenda for TAPS IETF-104 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, 08 Mar 2019 16:35:49 -0000 Hi Aaron, We have two additional things we would like to discuss: - TU Berlin PyTAPS Implementation Report (5-10min, depending on the = overlap with the ETH Implementation Report) - Connection Pools for HTTP-like Protocols (10min if there is time left = - still preparing a PR for that) > On 7. Mar 2019, at 22:30, Aaron Falk wrote: >=20 > Here=E2=80=99s a proposal for an agenda. Did I miss anything? Any = other comments? >=20 > --aaron >=20 > =E2=80=A2 Agenda bash (2m) >=20 > =E2=80=A2 WG update - chairs (5m) >=20 > =E2=80=A2 Core doc discussion: How should we do framing? - Tommy = Pauly (20m) >=20 > =E2=80=A2 ETH Implementation Report - Brian Trammell (15m) >=20 > =E2=80=A2 Proposal to Create a YANG Model - Jake Holland (20m) >=20 > =E2=80=A2 Using TAPS for Multicast - Jake Holland (10m) >=20 > =E2=80=A2 TAPS & mobility - TBD (15m) >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Fri Mar 8 09:24:15 2019 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 7AE991313B5 for ; Fri, 8 Mar 2019 09:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 m49Ok4nyto8M for ; Fri, 8 Mar 2019 09:24:10 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 A9EE9131381 for ; Fri, 8 Mar 2019 09:24:10 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x28HLxbO051537 for ; Fri, 8 Mar 2019 09:24:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : from : subject : message-id : date : to; s=20180706; bh=LCefmhSG/Zhmg+Kb8c6fxw4lAsio+A+oX/t7Qmk78pA=; b=Yh9h5x72lKNKsFxbTxHmBDe+3D5vsuxSdPekM0L9Ok8SZwBE68sDYVo4lIjQjCb0z1kx yMoM/j+B7qUO8LQHFzMd9+P6kHtVn2SAKqveXFSUaumVhTUy+Xtz2ZpweeykvWkB+aim 8SV2zlew0rSZkGLPcGGQOlwYXZYXQSEDeHPRnf+6TpNLH5dpRZSWTxSHwBLxfjFAaf8W OdlK7IpNuE37L/EGo9zhuDlv510toQhpxQbQ2Vvuylu2Js7yliMjJcOohFNPfb/ti8Hz xWiGvCIzHACfHY15pizDNCZhSm1fFUGgG0isCTgz+NR5UjN6VFws5eB6nMjiDkpJmXIL LQ== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2qyq9vksd5-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 08 Mar 2019 09:24:10 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO200I7M5O80NH0@ma1-mtap-s01.corp.apple.com> for taps@ietf.org; Fri, 08 Mar 2019 09:24:08 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PO2002005M0SO00@nwk-mmpp-sz11.apple.com> for taps@ietf.org; Fri, 08 Mar 2019 09:24:08 -0800 (PST) X-Va-A: X-Va-T-CD: 2ae3cb41e2a452a17e83043029b284de X-Va-E-CD: f496394c1ab19acd79516a0ac4777662 X-Va-R-CD: 16bf19a0656d704ff54e4c93752580e0 X-Va-CD: 0 X-Va-ID: a4e00bee-ea93-48e6-b455-781b0b84cedd X-V-A: X-V-T-CD: 2ae3cb41e2a452a17e83043029b284de X-V-E-CD: f496394c1ab19acd79516a0ac4777662 X-V-R-CD: 16bf19a0656d704ff54e4c93752580e0 X-V-CD: 0 X-V-ID: 4be11cb4-369f-49e8-9638-7780be351a5c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-08_14:,, signatures=0 Received: from [17.230.173.237] (unknown [17.230.173.237]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO200KDP5O6AL10@nwk-mmpp-sz11.apple.com> for taps@ietf.org; Fri, 08 Mar 2019 09:24:08 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <5B579E9C-B56B-4AA5-AE2F-4B04B1E15445@apple.com> Date: Fri, 08 Mar 2019 09:24:05 -0800 To: taps WG X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-08_14:, , signatures=0 Archived-At: Subject: [Taps] Please review: open PRs for TAPS documents 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, 08 Mar 2019 17:24:13 -0000 Hello TAPS, We'll be revving the Architecture/Interface/Implementation documents soon, and we have a few outstanding PRs: https://github.com/ietf-tapswg/api-drafts/pulls I wanted to solicit input and feedback from the group as we go to merge these in by Monday. Many of these are new, and based on feedback in our Interim. API usage examples https://github.com/ietf-tapswg/api-drafts/pull/293 Caching Boundaries using Connection Groups https://github.com/ietf-tapswg/api-drafts/pull/294 Add Transport Property Names to the API https://github.com/ietf-tapswg/api-drafts/pull/291 Updating implementation https://github.com/ietf-tapswg/api-drafts/pull/274 Thanks! Tommy From nobody Fri Mar 8 09:46:11 2019 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 D5EFE12782C for ; Fri, 8 Mar 2019 09:46: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_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 DoMSOB4WQR46 for ; Fri, 8 Mar 2019 09:46:07 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 5F8BC1277CE for ; Fri, 8 Mar 2019 09:46:07 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id i5so11623647qkd.13 for ; Fri, 08 Mar 2019 09:46:07 -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=gJp6mcakqWLpu/JHH/0wc6Qg6VUTsmRXfgbIQT/dxcg=; b=HQ2oI9CjQMdEgxyp//UvgFETbwu0DOQmvFF25HA1IdPU0KWPYL1KYfxmjr7EG2EZ5x /edKdbtay4MjWMKCxx+uR966l1i1JBed2dmwafMTMJAh+7NOlyEsIQl/qI+2Q6ikUgc2 olsjxjuWBlUrpRw6xn0/+lgShrKJgZ4Emfq7ScxodvOT2kGEriDhQTveUvqIu1Ciz3Fr 2n7yCSP9mF9iO/zLuQJZA+yr/JTqRJ02Y0/UygKuNZAganRkgJ8RR+pc9w2w1/KXRTCN N0B8jLidsSHk5EsvfcFTaEatIW43qqI+CB9RyURu65R6oXcWflFKI9DjJujFbmFo1bkR ydwQ== 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=gJp6mcakqWLpu/JHH/0wc6Qg6VUTsmRXfgbIQT/dxcg=; b=j7d94OSHoGdmQDpTfVJ2hkgqiekwCTlPOu1LVZcLyVO9uh8Zf3l/9rkwV7EMGep6z+ 4tRdtY4tYzsNQhYv/Cpan6R6A4GJiJWLyutWbpjmF3T5jhDACTFo2CRo0UyAO7P1FetN JYJKWln1nTSzPmrJZBL+cmYb9JIV8cJwG1A8aJxg/WsTsQuHpmxxKuLZ/swg91Zv8iEA R0Sx6ww+gyI2Zo9oCIAPMlhYd6K1vLMol5sUJafVu1cuYZRNy5bCjAL6Il9Ko4Ee8drp n3CbVjnpRjxTurWUN/vXLl6kkN1gWlkY3BWqjREChF0SOewKEBzVMzih09J7QV2RcI8Z MHDA== X-Gm-Message-State: APjAAAUQbL4Xk7rxVfJfVSML7afzRHYClxLPgcw9sK7XnuEiy2ETebyR 9ZaWLm6wVEUhXpLvBEH9x+E= X-Google-Smtp-Source: APXvYqz9R7qUoDJNcWjPGZ2XOA9/09R/jurJYTg+Ppe4ERDvHcQ4xNFhLm6yffsfriG+lcyolNaR0w== X-Received: by 2002:a37:e10c:: with SMTP id c12mr14974235qkm.315.1552067166334; Fri, 08 Mar 2019 09:46:06 -0800 (PST) Received: from [172.19.34.44] ([2001:4878:a000:3000:9c67:3a23:1a60:c9c5]) by smtp.gmail.com with ESMTPSA id j139sm4386732qke.26.2019.03.08.09.46.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 09:46:05 -0800 (PST) From: "Aaron Falk" To: "Philipp S. Tiesel" Cc: "taps WG" , "Zaheduzzaman Sarker" Date: Fri, 08 Mar 2019 12:46:04 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0B33AE1A-DDBA-482E-8EE1-799BEC89A5A4_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] draft agenda for TAPS IETF-104 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, 08 Mar 2019 17:46:10 -0000 --=_MailMate_0B33AE1A-DDBA-482E-8EE1-799BEC89A5A4_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Philipp, I added you as the presenter for the two topics you proposed. Let me know if that’s not correct. Revised agenda now posted: TAPS Agenda ============ FRIDAY, March 29, 2019 1050-1250 Morning Session II 1. Agenda bash (2m) 2. WG update - chairs (5m) 3. How should we do framing? - Tommy Pauly (20m) 4. Connection Pools for HTTP-like Protocols - Philipp Tiesel (10m) 5. ETH Implementation Report - Brian Trammell (15m) 6. TU Berlin PyTAPS Implementation Report - Philipp Tiesel (10m) 7. Proposal to Create a YANG Model - Jake Holland (20m) 8. Using TAPS for Multicast - Jake Holland (10m) 9. TAPS & mobility - TBD (15m) On 8 Mar 2019, at 11:35, Philipp S. Tiesel wrote: > Hi Aaron, > > We have two additional things we would like to discuss: > > - TU Berlin PyTAPS Implementation Report (5-10min, depending on the > overlap with the ETH Implementation Report) > - Connection Pools for HTTP-like Protocols (10min if there is time > left - still preparing a PR for that) > >> On 7. Mar 2019, at 22:30, Aaron Falk wrote: >> >> Here’s a proposal for an agenda. Did I miss anything? Any other >> comments? >> >> --aaron >> >> • Agenda bash (2m) >> >> • WG update - chairs (5m) >> >> • Core doc discussion: How should we do framing? - Tommy Pauly >> (20m) >> >> • ETH Implementation Report - Brian Trammell (15m) >> >> • Proposal to Create a YANG Model - Jake Holland (20m) >> >> • Using TAPS for Multicast - Jake Holland (10m) >> >> • TAPS & mobility - TBD (15m) >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > AVE! > Philipp S. Tiesel / phils… > -- > {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, > wenn w eine aube ist dn man au dran dre en > | > o Schr an muss hc h (Kurt > Schwitters) | > :wq! <----(phone: +49-179-6737439)---<---(jabber: > phils@in-panik.de)----' --=_MailMate_0B33AE1A-DDBA-482E-8EE1-799BEC89A5A4_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Philipp, I added you as the presenter for the two topics = you proposed. Let me know if that=E2=80=99s not correct. Revised agenda= now posted:

TAPS Agenda

FRIDAY, March 29, 2019
1050-1250 Morning Session II

  1. Agenda bash (2m)

  2. WG update - chairs (5m)

  3. How should we do framing? - Tommy Pauly (= 20m)

  4. Connection Pools for HTTP-like Protocols = - Philipp Tiesel (10m)

  5. ETH Implementation Report - Brian Trammel= l (15m)

  6. TU Berlin PyTAPS Implementation Report - = Philipp Tiesel (10m)

  7. Proposal to Create a YANG Model - Jake Ho= lland (20m)

  8. Using TAPS for Multicast - Jake Holland (= 10m)

  9. TAPS & mobility - TBD (15m)

On 8 Mar 2019, at 11:35, Philipp S. Tiesel wrote:

H= i Aaron,

We have two additional things we would like to discuss:

- TU Berlin PyTAPS Implementation Report (5-10min, depending on the over= lap with the ETH Implementation Report)
- Connection Pools for HTTP-like Protocols (10min if there is time left = - still preparing a PR for that)

On 7. Mar 2= 019, at 22:30, Aaron Falk <aaron.falk@gmail.com> wrote:

Here=E2=80=99s a proposal for an agenda. Did I miss anything? Any other c= omments?

--aaron

=E2=80=A2 Agenda bash (2m)

=E2=80=A2 WG update - chairs (5m)

=E2=80=A2 Core doc discussion: How should we do framing? - Tommy Pauly (= 20m)

=E2=80=A2 ETH Implementation Report - Brian Trammell (15m)

=E2=80=A2 Proposal to Create a YANG Model - Jake Holland (20m)

=E2=80=A2 Using TAPS for Multicast - Jake Holland (10m)

=E2=80=A2 TAPS & mobility - TBD (15m)

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

AVE!
Philipp S. Tiesel / phils=E2=80=A6
--
{phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = |
o Schr an muss hc h (Kurt Schwitters)= |
:wq! <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.d= e)----'

--=_MailMate_0B33AE1A-DDBA-482E-8EE1-799BEC89A5A4_=-- From nobody Sat Mar 9 22:09:35 2019 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 C495A127979 for ; Sat, 9 Mar 2019 22:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 BtyBu9rjm0w5 for ; Sat, 9 Mar 2019 22:09:32 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 83CFC126DFA for ; Sat, 9 Mar 2019 22:09:32 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2A69JlO009763 for ; Sun, 10 Mar 2019 06:09:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=fghYqmjv2pvcdKa+oPDC6f3+t7fbWs75YDAJ4//S7Yw=; b=Rt8XMly8AG3LwLY8v4XxWtIQdATi244pjtonlw6iGs97gvR4t/AVe0TT1lVbrQFVB3+i 6HdlT1EzQZ8eEBG2WEURzGojOFMrRW8UlqKjBHlaOxZib71RGQJZj3GBeHiy4N56h8xN zC7srIAvqgjItGe26Nf6tAPyY7owC2KxDEegrcKUisyEk6eDpAY1UtntRJc1UyueRvFa RyhrH0vqFdDDB7UCSPstt4Gp8fw6C01eVcF9ASNQ9otp8zQYiZlEUxWBZYqf84MfNmxo y5xnX7lWaK+1I6L64cqpZrk1uVzamkBgCMXlEqLmzDc+Ami3XjD1SdkGJhnNnc0YlbXx 5Q== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2r46dmbphw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 10 Mar 2019 06:09:32 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2A61quv013948 for ; Sun, 10 Mar 2019 01:09:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2r49q0kc6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sun, 10 Mar 2019 01:09:30 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 10 Mar 2019 00:09:30 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Sun, 10 Mar 2019 00:09:30 -0600 From: "Holland, Jake" To: taps WG Thread-Topic: Updated draft-jholland-taps-api-yang Thread-Index: AQHU1wfSbO3gUCGXP0CpmcgnsATCyQ== Date: Sun, 10 Mar 2019 06:09:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.151] Content-Type: text/plain; charset="utf-8" Content-ID: <938B719AE14BCA45A60C36FE9A910E9B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100047 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100048 Archived-At: Subject: [Taps] Updated draft-jholland-taps-api-yang 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: Sun, 10 Mar 2019 06:09:34 -0000 SGkgdGFwcywNCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgdG8gYWxsIHdobyBjb21tZW50ZWQs IGFuZCBzaW5jZSBpdA0Kc2VlbXMgbWF5YmUgdGhlcmUncyBhIGNoYW5jZSBpdCdsbCBiZSB1c2Vm dWwsIEkgdXBkYXRlZA0KdGhlIHlhbmcgZHJhZnQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtamhvbGxhbmQtdGFwcy1hcGkteWFuZy0wMQ0KDQpJIHRoaW5rIHRoaXMgaXMgYSBt dWNoIGNsZWFuZXIgc3RydWN0dXJlIGZvciB0aGUgbW9kZWwsIG9yDQphdCBsZWFzdCBtdWNoIG1v cmUgbm9ybWFsIHJlbGF0aXZlIHRvIG90aGVyIHlhbmcgbW9kZWxzLiBBbmQNCkkgdGhpbmsgaXQn cyBzb21ld2hhdCBjbG9zZXIgdG8gYSBjb21wbGV0ZSByZW5kaXRpb24gb2YgdGhlDQpQcmVDb25u ZWN0aW9uIGNvbmZpZyBmcm9tIHRhcHMtaW50ZXJmYWNlLCB0aG91Z2ggdGhlcmUncyBhDQpmZXcg b2RkaXRpZXMgSSBub3RpY2VkIGFsb25nIHRoZSB3YXkgKGxpc3RlZCBiZWxvdykuDQoNCkhlcmUn cyB0aGUgcmVwbyBJJ20gYnVpbGRpbmcgZnJvbToNCmh0dHBzOi8vZ2l0aHViLmNvbS9HcnVtcHlP bGRUcm9sbC9pZXRmLXRhcHMteWFuZw0KDQpJIHR3ZWFrZWQgdGhlIE1ha2VmaWxlIHNldHVwIGFu ZCB0aGUgaS1kLXRlbXBsYXRlDQpmb3IgeWFuZy1lZGl0aW5nIHNhbml0eSwgc28gaXQncyBwb2lu dGluZyB0byBteSBmb3JrIG9mDQpNYXJ0aW4ncyBsaWIgcmVwbywgYW5kIGl0J3MgYW55b25lJ3Mg Z3Vlc3Mgd2hldGhlciB0aGUNCmJ1aWxkIHdpbGwgd29yayBwcm9wZXJseSBvbiB5b3VyIHN5c3Rl bSwgYWxsIEkga25vdyB5ZXQgaXMNCml0IHdvcmtzIG9uIG1pbmUgKGFuZCBpdCBuZWVkcyBjbWFr ZSB0byBidWlsZCBsaWJ5YW5nKS4gIFNvDQpsZXQgbWUga25vdyBpZiB5b3Ugd2FudCB0byB0cnkg aXQgYW5kIGhhdmUgYW55IHRyb3VibGUuIE9yDQpiZXR0ZXIgeWV0LCBzZW5kIGEgZml4IDopDQoN CkhlcmUncyB0aGUgb2RkaXRpZXMgSSBtZW50aW9uZWQ6DQoxLiBJbnRlcmZhY2UgbmFtZSBpcyBw YXNzZWQgdG8gTG9jYWxFbmRwb2ludCBhcyBhbiBleGFtcGxlDQppbiBTZWN0aW9uIDUuMSwgYnV0 IGFsc28gSW50ZXJmYWNlIEluc3RhbmNlIGlzIGEgdHJhbnNwb3J0DQpwcm9wZXJ0eSBpbiBTZWN0 aW9uIDUuMi44LiAgSSB0aGluayg/KSB0aGlzIGlzIHJlZHVuZGFudCwNCnNvIEkgb25seSBkaWQg dGhlIEludGVyZmFjZSBJbnN0YW5jZSBUcmFuc3BvcnQgcHJvcGVydHkuDQoNCjIuIEkgc3RpbGwg d2Fzbid0IHN1cmUgaG93IGJlc3QgdG8gaW50ZXJwcmV0IHRoZSBvYmplY3RzDQpwYXNzZWQgdG8g TG9jYWxTcGVjaWZpZXIgYW5kIFJlbW90ZVNwZWNpZmllciBpbiB0aGUgZXhhbXBsZXMuDQpJIHRo b3VnaHQgdGhlIGNsZWFuZXN0IGZvciB0aGUgbW9kZWwgd2FzIHRvIGdlbmVyYWxpemUgdGhlaXIN CkFkZFhYWCBmdW5jdGlvbnMgYXMgVHJhbnNwb3J0IFByb3BlcnRpZXMsIGFuZCBwbGFuIHRvIHJh aXNlDQphbiBlcnJvciBpZiB0aGVyZSdzIGEgcHJvYmxlbSBzYXRpc2Z5aW5nIHRoZSBjb25zdHJh aW50cy4NCg0KSSBsaWtlZCBpdCB0aGlzIHdheSBiZXR0ZXIgdGhhbiBhIHNlcGFyYXRlIGxvY2Fs LWVuZHBvaW50IGFuZA0KcmVtb3RlLWVuZHBvaW50IG9iamVjdCwgd2l0aCBzZXBhcmF0ZSBsaXN0 cyBvZiBhZGRyZXNzZXMgYW5kDQpwb3J0cywgYnV0IEkgd291bGRuJ3QgYmUgc3VycHJpc2VkIGlm IHRoZXJlJ3MgYW5vdGhlciBiZXR0ZXINCndheS4gIERpc2N1c3Npb24gYW5kIHB1bGwgcmVxdWVz dHMgd2VsY29tZS4NCg0KMy4gSSBhZGRlZCBwcm90b2NvbCB0eXBlcyBhcyB0cmFuc3BvcnQgcHJv cGVydGllcywgZXZlbiB0aG91Z2gNCml0IHdhc24ndCBpbiB0aGUgaW50ZXJmYWNlIHNwZWMsIGJh c2ljYWxseSBiZWNhdXNlIEkgc2F3IGl0IGluDQp0aGUgTkVBVCBwcm9qZWN0IHByb3BlcnR5IGpz b24gY29uZmlnLCBhbmQgYmVjYXVzZSBpdCBzZWVtcw0KcHJvYmFibHkgbmVjZXNzYXJ5IHRvIG1l Lg0KDQpTb3JyeSBpZiB0aGF0J3Mgb3Bwb3NpdGUgb2YgY29uc2Vuc3VzIG9yIHNvbWV0aGluZywg SSBtaXNzZWQgdGhlDQppbnRlcmltLCBzbyBJIG1pZ2h0IGJlIGEgbGl0dGxlIG91dCBvZiBkYXRl LiAgSXQgY2FuIG9mIGNvdXJzZQ0KYmUgcmVtb3ZlZCBvciBjaGFuZ2VkIGFzIG5lY2Vzc2FyeSwg YnV0IEkgdGhpbmsgaXQgbWFrZXMgZm9yDQpyZWxhdGl2ZWx5IGNsZWFuIGNvbmZpZ3VyYXRpb24g aW5wdXQgd2hlcmUgeW91IG5lZWQgaXQuICBJJ2QNCmJlIGludGVyZXN0ZWQgdG8gc2VlIGNvbW1l bnRzIG9uIHRoZSBleGFtcGxlcywgYW5kIGFsdGVybmF0ZQ0Kc3VnZ2VzdGlvbnMuDQoNCjQuIEkg ZG9uJ3QgaGF2ZSBhbnkgUHJvdmlzaW9uaW5nIERvbWFpbiB0eXBlcy4gIEknbSBub3Qgc3VyZQ0K aWYgdGhlcmUncyBhIGdvb2Qgc291cmNlIHRvIGNyaWIgZnJvbSBzb21ld2hlcmUgdGhhdCBsaXN0 cw0KcmVhc29uYWJsZSB0eXBlcz8NCg0KNS4gTGlrZXdpc2UgSSB3YXNuJ3Qgc3VyZSB3aGF0IHRv IGRvIHdpdGggdGhlIFNlc3Npb24gQ2FjaGUNClBvbGljeSwgaXMgdGhlcmUgYSBsaXN0IG9mIGdv b2QgY2hvaWNlcyBvbiB0aG9zZSBzb21ld2hlcmU/DQoNCg0KQW55d2F5LCBJIHRoaW5rIHRoaXMg bW9kZWwgaXMgaW4gbXVjaCBiZXR0ZXIgc2hhcGUgdGhhbiB0aGUNCmxhc3Qgb25lLCBzbyBub3cg SSdsbCBjaGFuZ2UgbXkgcG9zaXRpb24sIGFuZCBpZiBpdCBoYXBwZW5zIHRoYXQNCndlIHJlYWNo IGEgY29uc2Vuc3VzIGZvciB5ZXMgb24gInVzZSBhIHlhbmcgbW9kZWwiLCB0aGVuIEknbGwNCmFs c28gc3VnZ2VzdCAidXNlIHRoaXMgeWFuZyBtb2RlbCIgYXMgYSByZWFzb25hYmxlIG9wdGlvbiBm b3IgYQ0Kc3RhcnRpbmcgcG9pbnQuDQoNClNlZSB5b3UgaW4gUHJhZ3VlLg0KDQpDaGVlcnMsDQpK YWtlDQoNCg0K From nobody Mon Mar 11 02:10:32 2019 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 65BA3130FE5 for ; Mon, 11 Mar 2019 02:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 fUdxLuqHGZfy for ; Mon, 11 Mar 2019 02:10:29 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 D0492130F3C for ; Mon, 11 Mar 2019 02:10:28 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3Gx0-000BoA-HJ for taps@ietf.org; Mon, 11 Mar 2019 10:10:26 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1h3Gwz-0003Li-TV for taps@ietf.org; Mon, 11 Mar 2019 10:10:26 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <90D24FD6-2B84-4354-8A72-B6D64F207FCF@ifi.uio.no> Date: Mon, 11 Mar 2019 10:10:25 +0100 To: taps WG X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 79A2F0A8F11E07ABB254AB95DB422391A58F149C Archived-At: Subject: [Taps] github "Editor's copy" links 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, 11 Mar 2019 09:10:32 -0000 Hi, Since the move, the "Editor's Copy" links, which produce these very = nicely formatted versions of the latest document version, don't work = anymore. Specifically: the "Editor's Copy" links from here: https://github.com/ietf-tapswg/api-drafts lead to e.g. here: https://taps-api.github.io/drafts/#go.draft-ietf-taps-interface.html which is a page with an error message right now. For whoever knows what they're doing, this may be a short thing, just = re-starting the travis script or something like that. Knowing little = about git and nothing about travis, I'm clueless myself, and so I = thought I'd send this note... Cheers, Michael From nobody Mon Mar 11 04:35:20 2019 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 8CC79130FCB for ; Mon, 11 Mar 2019 04:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 KRDtxQfBZlkW for ; Mon, 11 Mar 2019 04:35:16 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 81DA0129AA0 for ; Mon, 11 Mar 2019 04:35:16 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x2BBZEUT003464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 12:35:14 +0100 Received: from client-141-23-208-145.wlan.tu-berlin.de ([141.23.208.145]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1h3JBZ-0002lN-FZ; Mon, 11 Mar 2019 12:33:37 +0100 From: "Philipp S. Tiesel" Message-Id: <46DCAA79-8235-4133-90EA-860F232F54ED@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D9B5AD7-8E0E-4663-A77F-73640DEB80B7" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 11 Mar 2019 12:35:13 +0100 In-Reply-To: <90D24FD6-2B84-4354-8A72-B6D64F207FCF@ifi.uio.no> Cc: taps WG To: Michael Welzl References: <90D24FD6-2B84-4354-8A72-B6D64F207FCF@ifi.uio.no> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Taps] github "Editor's copy" links 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, 11 Mar 2019 11:35:20 -0000 --Apple-Mail=_9D9B5AD7-8E0E-4663-A77F-73640DEB80B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, just updated Readme.md to fix this=20 > On 11. Mar 2019, at 10:10, Michael Welzl wrote: >=20 > Hi, >=20 > Since the move, the "Editor's Copy" links, which produce these very = nicely formatted versions of the latest document version, don't work = anymore. > Specifically: the "Editor's Copy" links from here: > https://github.com/ietf-tapswg/api-drafts > lead to e.g. here: > https://taps-api.github.io/drafts/#go.draft-ietf-taps-interface.html > which is a page with an error message right now. >=20 > For whoever knows what they're doing, this may be a short thing, just = re-starting the travis script or something like that. Knowing little = about git and nothing about travis, I'm clueless myself, and so I = thought I'd send this note... >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_9D9B5AD7-8E0E-4663-A77F-73640DEB80B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

just = updated Readme.md to fix this 

On 11. = Mar 2019, at 10:10, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

Since the move, the = "Editor's Copy" links, which produce these very nicely formatted = versions of the latest document version, don't work anymore.
Specifically: the "Editor's Copy" links from here:
https://github.com/ietf-tapswg/api-drafts
lead to e.g. here:
https://taps-api.github.io/drafts/#go.draft-ietf-taps-interface= .html
which is a page with an error message right now.

For whoever knows what they're doing, this may = be a short thing, just re-starting the travis script or something like = that. Knowing little about git and nothing about travis, I'm clueless = myself, and so I thought I'd send this note...

Cheers,
Michael

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


AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_9D9B5AD7-8E0E-4663-A77F-73640DEB80B7-- From nobody Mon Mar 11 09:58:45 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7012513114F; Mon, 11 Mar 2019 09:58:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <155232350640.23181.14169988478181979597@ietfa.amsl.com> Date: Mon, 11 Mar 2019 09:58:26 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-06.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:58:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Christopher A. Wood Theresa Enghardt Tommy Pauly Colin Perkins Kyle Rose Filename : draft-ietf-taps-transport-security-06.txt Pages : 37 Date : 2019-03-11 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, MinimalT. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a TAPS system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-06 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 13:13:17 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0A12796B; Mon, 11 Mar 2019 13:13:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <155233519128.23191.10946429055056558664@ietfa.amsl.com> Date: Mon, 11 Mar 2019 13:13:11 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-arch-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:13:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Architecture for Transport Services Authors : Tommy Pauly Brian Trammell Anna Brunstrom Godred Fairhurst Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-arch-03.txt Pages : 25 Date : 2019-03-11 Abstract: This document provides an overview of the architecture of Transport Services, a model for exposing transport protocol features to applications for network communication. In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document further defines the common set of terminology and concepts to be used in definitions of Transport Services APIs and implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-arch-03 https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-arch-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 13:14:32 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0EB126CFF; Mon, 11 Mar 2019 13:14:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <155233527071.23046.9938235186406465611@ietfa.amsl.com> Date: Mon, 11 Mar 2019 13:14:30 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-impl-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:14:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : Implementing Interfaces to Transport Services Authors : Anna Brunstrom Tommy Pauly Theresa Enghardt Karl-Johan Grinnemo Tom Jones Philipp S. Tiesel Colin Perkins Michael Welzl Filename : draft-ietf-taps-impl-03.txt Pages : 37 Date : 2019-03-11 Abstract: The Transport Services architecture [I-D.ietf-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-impl-03 https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-impl-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 13:15:13 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE41311C2; Mon, 11 Mar 2019 13:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <155233530120.23082.15735998445892750422@ietfa.amsl.com> Date: Mon, 11 Mar 2019 13:15:01 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-interface-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:15:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Abstract Application Layer Interface to Transport Services Authors : Brian Trammell Michael Welzl Theresa Enghardt Godred Fairhurst Mirja Kuehlewind Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-interface-03.txt Pages : 59 Date : 2019-03-11 Abstract: This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime. It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-interface-03 https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-interface-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 15 08:58:16 2019 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 64A601277CC for ; Fri, 15 Mar 2019 08:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33DFzk8MS8QH for ; Fri, 15 Mar 2019 08:58:12 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 CDB221279E6 for ; Fri, 15 Mar 2019 08:58:12 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2FFqEIG027483; Fri, 15 Mar 2019 08:58:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=qHbY7vYF9Kbnbu4XlOls7bEvzSGCew6Z6m17CZMt1eM=; b=uCxyiMIiFEWuBHsRv8WWOtkT2OUodsvNnSrainzBTO+meBeZmRJqwtHiCrXsWV8iBr3U NdWg3D+PtCDiREKl9NsEMLJ6SvKy73A6/rLJHCUZspl6jTHgjo8PQ26qitIb4lgfhwaD U3EejQQNyPz57Y+rB5tsElQkd/dj+zkhiiEcSK6ejP/tH4JVa1SPgFuPeYtHahJUj9yf SGLgjq762NfNfPCpmuPKo6DV+JmYQOdM0uNTIgWVY+B49+holPUk1Wfmdi3yHjtrBtPb bb/0WPLjUFQ/uzXr0OQHvqyuUX8LK4u9nYf1oBlNb0Gx+Pu38whbkEN7dkO6qO/ytO3j zg== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2r4axuyxsq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Mar 2019 08:58:11 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII 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.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0POF00NL10CY5990@mr2-mtap-s03.rno.apple.com>; Fri, 15 Mar 2019 08:58:10 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0POF00F0008HX500@nwk-mmpp-sz12.apple.com>; Fri, 15 Mar 2019 08:58:10 -0700 (PDT) X-Va-A: X-Va-T-CD: abbfc553e23064d7ab2d78e9de6e1855 X-Va-E-CD: 53a8def8532e6d0fdee3e308233743f7 X-Va-R-CD: 22e06a07f35f86d8eebdff2c79a3760b X-Va-CD: 0 X-Va-ID: 1362e901-2282-42b3-8593-fd3c15387d92 X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: 53a8def8532e6d0fdee3e308233743f7 X-V-R-CD: 22e06a07f35f86d8eebdff2c79a3760b X-V-CD: 0 X-V-ID: d0e3a612-1a4a-459e-a282-da95d0ebca26 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-15_11:,, signatures=0 Received: from [17.234.2.28] (unknown [17.234.2.28]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0POF007HS0CVQ580@nwk-mmpp-sz12.apple.com>; Fri, 15 Mar 2019 08:58:09 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Fri, 15 Mar 2019 08:58:05 -0700 Cc: taps WG Message-id: References: To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-15_11:, , signatures=0 Archived-At: Subject: Re: [Taps] Updated draft-jholland-taps-api-yang 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, 15 Mar 2019 15:58:16 -0000 Hi Jake, Thanks for updating the document! It's really useful to see things written out this way. Comments inline, responding to your "oddities". > On Mar 9, 2019, at 10:09 PM, Holland, Jake wrote: > > Hi taps, > > Thanks for the feedback to all who commented, and since it > seems maybe there's a chance it'll be useful, I updated > the yang draft: > https://tools.ietf.org/html/draft-jholland-taps-api-yang-01 > > I think this is a much cleaner structure for the model, or > at least much more normal relative to other yang models. And > I think it's somewhat closer to a complete rendition of the > PreConnection config from taps-interface, though there's a > few oddities I noticed along the way (listed below). > > Here's the repo I'm building from: > https://github.com/GrumpyOldTroll/ietf-taps-yang > > I tweaked the Makefile setup and the i-d-template > for yang-editing sanity, so it's pointing to my fork of > Martin's lib repo, and it's anyone's guess whether the > build will work properly on your system, all I know yet is > it works on mine (and it needs cmake to build libyang). So > let me know if you want to try it and have any trouble. Or > better yet, send a fix :) > > Here's the oddities I mentioned: > 1. Interface name is passed to LocalEndpoint as an example > in Section 5.1, but also Interface Instance is a transport > property in Section 5.2.8. I think(?) this is redundant, > so I only did the Interface Instance Transport property. I think that the Interface being a property of the Connection, rather than the Endpoint, is the most important item to support. There is a bit of a fundamental messiness in where the interface goes, as in our Network.framework API we've encountered. Primarily, we expose the ability to require/prohibit a given interface on the generic properties, but it's also possible in IPv6 for an interface to be specified in the scope ID field. Similarly, endpoints that have been resolved on a very particular interface (such as bonjour) carry their own interface scoping, since they are not applicable to other interfaces. In the Network.framework implementation today, the required interface on the overall instance properties takes precedence, but if it is unspecified, we will look to see if there an interface specified as part of the endpoint itself. > > 2. I still wasn't sure how best to interpret the objects > passed to LocalSpecifier and RemoteSpecifier in the examples. > I thought the cleanest for the model was to generalize their > AddXXX functions as Transport Properties, and plan to raise > an error if there's a problem satisfying the constraints. I'd tend to agree with this, but I'd like to have a discussion on it. > > I liked it this way better than a separate local-endpoint and > remote-endpoint object, with separate lists of addresses and > ports, but I wouldn't be surprised if there's another better > way. Discussion and pull requests welcome. > > 3. I added protocol types as transport properties, even though > it wasn't in the interface spec, basically because I saw it in > the NEAT project property json config, and because it seems > probably necessary to me. Do you mean how you have the definitions for "tcp", "udp", etc? I think that is indeed a necessity of a practical implementation, although it in a purist model of TAPS it shouldn't be required. The levels of specificity that are possible are: - Require the protocol named "tcp" - Require one of these protocols: "tcp", "quic", "sctp" - Require some protocol that provides a reliable, in-order stream abstraction > > Sorry if that's opposite of consensus or something, I missed the > interim, so I might be a little out of date. It can of course > be removed or changed as necessary, but I think it makes for > relatively clean configuration input where you need it. I'd > be interested to see comments on the examples, and alternate > suggestions. > > 4. I don't have any Provisioning Domain types. I'm not sure > if there's a good source to crib from somewhere that lists > reasonable types? That list will likely vary across platforms, so probably needs to be extensible. > > 5. Likewise I wasn't sure what to do with the Session Cache > Policy, is there a list of good choices on those somewhere? That's something we're still discussing and fleshing out in the documents, so stay tuned. > > > Anyway, I think this model is in much better shape than the > last one, so now I'll change my position, and if it happens that > we reach a consensus for yes on "use a yang model", then I'll > also suggest "use this yang model" as a reasonable option for a > starting point. Seems like the best starting point we have so far for a yang model, certainly! Best, Tommy > > See you in Prague. > > Cheers, > Jake > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sat Mar 23 04:58:05 2019 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 38D8F12950A for ; Sat, 23 Mar 2019 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 dDZsCp0qYrto for ; Sat, 23 Mar 2019 04:58:01 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 CF8B2127AC2 for ; Sat, 23 Mar 2019 04:57:59 -0700 (PDT) X-Envelope-From: philipp@tiesel.net X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x2NBvveg020645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 23 Mar 2019 12:57:57 +0100 Received: from x2f7f6b5.dyn.telefonica.de ([2.247.246.181] helo=[172.20.10.5]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1h7fG7-0007tr-GN for taps@ietf.org; Sat, 23 Mar 2019 12:56:19 +0100 From: "Philipp S. Tiesel" Content-Type: multipart/signed; boundary="Apple-Mail=_E67340B7-D1EB-4723-AEE8-782E2844BD7F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Sat, 23 Mar 2019 12:57:51 +0100 To: taps WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Taps] Connection Pooling 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, 23 Mar 2019 11:58:03 -0000 --Apple-Mail=_E67340B7-D1EB-4723-AEE8-782E2844BD7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, as I already asked to discuss this on Friday, here a short summary for = the list: During the first discussions about how to map QUIC connections and = streams to TAPS objects, it became apparent that there are two ways how this = mapping could be done: - Map QUIC Streams to TAPS connections - Map QUIC Streams to TAPS messages While the former is a very natural mapping for a multi-streaming = protocol, the latter is more useful for protocols that treat QUIC streams as = messages, like HTTP/3. -> As a way out of this tussle, I propose to add connection pooling to = TAPS. The basic idea for connection pooling is to add an alternate interaction scheme that wraps multiple connection and distributes messages = automatically. How can this be used? - For regular TAPS connections, we map QUIC Streams to TAPS = connections. - For pooled TAPS connections, we map QUIC Streams to TAPS messages. - For regular TAPS connections, we map one UDP 5-tuple to a TAPS = connections. - For pooled TAPS connections, we map all UDP packets with the same local address/port to messages of one TAPS connection. - If we add pseudo-protocol support for HTTP, we can have HTTP = requests/responses as messages and let the transport system framers take care about = whether to use HTTP/1.1, HTTP/2 oder HTTP/3. - We can even upgrade HTTP versions or use two versions at the same = time without bothering the application. - We can bundle multiple underlaying transport connections over = different paths and distribute the messages over these transparently or according to = information provided with the send call. There were already some discussions in GitHub Issue #266 https://github.com/ietf-tapswg/api-drafts/issues/266 I also prepared two Pull-Requests with proposals how Connection Pooling = can be added to TAPS on GitHub: - As separate Object -> = https://github.com/ietf-tapswg/api-drafts/pull/295 - As property of the connection -> = https://github.com/ietf-tapswg/api-drafts/pull/298 Seeing forward to the discussion (writing this from the train to Prague) Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_E67340B7-D1EB-4723-AEE8-782E2844BD7F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAlyWHz8ACgkQ9/dp0G7B PC0/shAAwHkW7wBOq9JToomzbbG5cq6ikFzFKx4mEdiX11dF/Qg9G2M7LxWre4e1 VyguiHRxXkUDmBAZ0XZrc+y+XWuURNyIyf/WLHMFW0IA65poXIFTS9FytVBXssLZ CrEOE6UhKOVYd8FYaUr3jnEG1cWGw0Vz2OcKu6N+VSgG0KqjG9yWrvsF0XSIszpA iDqx5xFxipY/NLRYczDx75VeuQ5/Xaeu9t5GJNnEP2X5JkhgW/MsKvhQ1ACWcQ9B eAnvU5RICsBvN0npK/VBEs/cBP7Z4LgGRqueTRm5iKap8aAugj2P1+27S1KAtXpt DIQcAZ8HfkLCJfGyC5Ro4dCumXa+iVSL9FjEZSNlmkJADBw+zWTSl/PjHheQzLpK en0fsW7YaTAUIY3Z5IhLG+Dbhxcd+zsgZIvdb8HcEF/sEX0XyxV0YA0pSLCItt+8 8O8m2riZ5YOu6OfP2ZiBOLiYOEnZXFHBMTc1wQXttNwBT+03YbiYflpIFSf0w9ID 12YrvaHSbeI+FsdXOVrq+2OoKHD3b+P35+Fzth1w1pSoaDCaglAnyjg1btUUr9Hv DqJF551IA9XSt+VMgVaYvWNih2Dr4oo5kI22meMm80ZD0WJvC8XM1Ce00jAuiJLx p6Nu9rhCDxTQPc1RE2ybtMKLVOPuXvJz6EsloSYeKj5inbsS0Ag= =tNvu -----END PGP SIGNATURE----- --Apple-Mail=_E67340B7-D1EB-4723-AEE8-782E2844BD7F-- From nobody Wed Mar 27 01:09:13 2019 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 8DBF6120274 for ; Wed, 27 Mar 2019 01:09:07 -0700 (PDT) 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, FREEMAIL_FROM=0.001, 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 (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 z-vt_oUN7_R1 for ; Wed, 27 Mar 2019 01:09:03 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 A56A1120250 for ; Wed, 27 Mar 2019 01:09:03 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k17so9394436wrx.10 for ; Wed, 27 Mar 2019 01:09:03 -0700 (PDT) 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=nqa8VsaD6Y9Uru0ZbSE0xPZvzrfj4/WdFUbQucnMb94=; b=HDfWkkDGE2seVuXxUJ7ad89yXfuG9yOp9Wrk0qhBQgCeR36hVa1hFGg5AN3WiVbTpu DRVUPSenjjnTBg/61qxIqSD63PT7PA/QGVwErhY3EqvsbskujiQOuyHzQXWe9bGc3NXj IuI2FtR42Y/FXjOPTwxcULrpzA7o79lbf1ztZsKBoroze73riGPW7qnRQajBbIk0tTZp ZMwHnup22kOeW9XiX2OBEwYXjCLcWzm9nFsP5Ji9MTvYzkuhi6hIEhjOEGWj6uTgJX3+ O1l1sfShV55hYoDc1bkiUqOy3w5wm8lrp6cnYjtGdo1L11aK1sBMP+gZA5pkPB5B4T7i 1nhw== 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=nqa8VsaD6Y9Uru0ZbSE0xPZvzrfj4/WdFUbQucnMb94=; b=AvqcVtsmgmVGZy5BD47zFEqjO5ZTvOnvu3t+ZqvjGQ85Yr+Mrt3RbNV9yegSKm/A52 v+rSbAVurpeAbu9knSWgu1sXUIndcCEe56YpcTUhNOfbMg4ypROHWSUk+nzqAlqJbJ7t P7+TriKWwCFRvc5Fz9v7/9+tuPAATGbBIP73/a8oN03OlHHkw56WU0xv1t4KJZqEDgeD JO83c6U9ExeELOgPIeYEwwzS0LdnBZp2LVG65k/pfELQZnf3B8ffHi8tM/c3c6TwzCV2 MYbUlvoldLFnbdg8a6cXSOlfV9RvZdS5UPhhT3TxAkhAKpXMz/ilMthAWZbD+vMm8/wp BJRA== X-Gm-Message-State: APjAAAVY1qoj+vep/c0UbKjAKloVXW2TtZsZNmbArL1Jcn4R4atVtq+Q u/m9XZkjTBImxOwgE5y4tGQBN5QiVbw= X-Google-Smtp-Source: APXvYqzEkRBRFazJY4fF1Vx9Y1wbuuXQ6g6FTujs9dx0lNfLk3aaRNsj7ZwxDfhMxcVDHvBLAy3SCg== X-Received: by 2002:adf:f8c1:: with SMTP id f1mr23460845wrq.151.1553674141983; Wed, 27 Mar 2019 01:09:01 -0700 (PDT) Received: from [31.133.128.147] ([2001:67c:370:128:c90f:10d8:8d3e:8e78]) by smtp.gmail.com with ESMTPSA id z11sm11832117wmf.12.2019.03.27.01.09.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 01:09:00 -0700 (PDT) From: "Aaron Falk" To: "Zaheduzzaman Sarker" , "taps WG" Date: Wed, 27 Mar 2019 09:08:59 +0100 X-Mailer: MailMate (1.12.4r5594) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_010373D4-2CA7-4D48-8F30-095D479D7A48_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] 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: Wed, 27 Mar 2019 08:09:08 -0000 --=_MailMate_010373D4-2CA7-4D48-8F30-095D479D7A48_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Let’s discuss scheduling for an online interim meeting at Friday’s meeting. --aaron --=_MailMate_010373D4-2CA7-4D48-8F30-095D479D7A48_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Let=E2=80=99s discuss scheduling for an online interim mee= ting at Friday=E2=80=99s meeting.

--aaron

--=_MailMate_010373D4-2CA7-4D48-8F30-095D479D7A48_=-- From tapsbot@magpie.corvid.ch Fri Mar 29 01:30:32 2019 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 37607120391 for ; Fri, 29 Mar 2019 01:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 fs_RW4ibs9v1 for ; Fri, 29 Mar 2019 01:30:30 -0700 (PDT) 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 87B44120026 for ; Fri, 29 Mar 2019 01:30:29 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1h9ms4-0000X3-L6 for taps@ietf.org; Fri, 29 Mar 2019 08:28:16 +0000 Content-Type: multipart/alternative; boundary="===============2982057601937178980==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 29 Mar 2019 08:28:16 +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, 29 Mar 2019 08:33:13 -0000 --===============2982057601937178980== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+5/-12/=F0=9F=92=AC22) 5 issues created: - More expressive multipath transport property (by abrunstrom) https://github.com/ietf-tapswg/api-drafts/issues/303 [API] [discuss] = - UDP idempotence (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/302 [API] = - Add an explicit listener object to the API (by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/301 [API] [ready for t= ext] = - Add property for address privacy (by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/300 = - TAPS ARCH - Textual review to notes (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/299 = 16 issues received 22 new comments: - #45 Do we need to make state storage explicit in the architecture and A= PI? (3 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/45 [API] [Architecture= ] [ready for text] = - #103 Evaluate the applicability of =C2=A76.3 to ICE-like protocols (2 b= y britram, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/103 [API] = - #206 Define the server-side equivalent of racing (2 by adventureloop, t= fpauly) https://github.com/ietf-tapswg/api-drafts/issues/206 [API] [Architectur= e] [ready for text] = - #303 More expressive multipath transport property (2 by philsbln, tfpau= ly) https://github.com/ietf-tapswg/api-drafts/issues/303 [API] [discuss] = - #222 Reusing Preconnections? (2 by philsbln, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/222 [API] [discuss] = - #224 Collapse InitateWithIdempotentData() back in to Initiate() (1 by b= ritram) https://github.com/ietf-tapswg/api-drafts/issues/224 = - #257 Not all Events are shown in the diagram (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/257 [Architecture] = - #188 ARCH: Message Framing, Parsing, and Serialization (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/188 [Architecture] [he= lp wanted] = - #209 Add a few example of Specific Properties (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/209 = - #178 Architecture privacy and security considerations (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/178 [Architecture] [re= ady for text] = - #147 Issues to consider (Handley) (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/147 = - #212 Consider per-context addresses as suggested by draft-gont-taps-add= ress-usage-* (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/212 [API] [Architectur= e] [discuss] = - #220 Message Context Parameters: Ordered and Final (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/220 [discuss] = - #285 Group management (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/285 [API] [ready for t= ext] = - #254 Do we need to have an explicit/separate object for Listener? (1 by= tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/254 [Architecture] [di= scuss] = - #127 Impl: generalise =C2=A74 to incorporate =C2=A710 (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/127 [Implementation] [= discuss] = 12 issues closed: - Group management https://github.com/ietf-tapswg/api-drafts/issues/285 [= API] [ready for text] = - Do we need to have an explicit/separate object for Listener? https://gi= thub.com/ietf-tapswg/api-drafts/issues/254 [Architecture] [discuss] = - Collapse InitateWithIdempotentData() back in to Initiate() https://gith= ub.com/ietf-tapswg/api-drafts/issues/224 = - Connection.Receive(minIncompleteLength, maxLength) https://github.com/i= etf-tapswg/api-drafts/issues/221 [API] = - Message Context Parameters: Ordered and Final https://github.com/ietf-t= apswg/api-drafts/issues/220 [discuss] = - Consider per-context addresses as suggested by draft-gont-taps-address-= usage-* https://github.com/ietf-tapswg/api-drafts/issues/212 [API] [Archite= cture] [discuss] = - Add a few example of Specific Properties https://github.com/ietf-tapsw= g/api-drafts/issues/209 = - ARCH: Message Framing, Parsing, and Serialization https://github.com/ie= tf-tapswg/api-drafts/issues/188 [Architecture] [help wanted] = - Replace long author lists with editors https://github.com/ietf-tapswg/a= pi-drafts/issues/184 [admin stuff] [wontfix] = - Issues to consider (Handley) https://github.com/ietf-tapswg/api-drafts/= issues/147 = - Impl: generalise =C2=A74 to incorporate =C2=A710 https://github.com/iet= f-tapswg/api-drafts/issues/127 [Implementation] [discuss] = - Evaluate the applicability of =C2=A76.3 to ICE-like protocols https://g= ithub.com/ietf-tapswg/api-drafts/issues/103 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+0/-0/=F0=9F=92=AC2) 1 pull requests received 2 new comments: - #298 Add Pooled Connections (2 by philsbln, mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/298 [API] [Architecture]= [discuss] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============2982057601937178980== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday March 29, 2019

Issues

ietf-tapswg/api-drafts (+5/-12/=F0=9F=92=AC22)

5 issues created:

16 issues received 22 new comments:

12 issues closed:

Pull requests

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

1 pull requests received 2 new comments:

Repositories tracked by this digest:

--===============2982057601937178980==-- From nobody Fri Mar 29 02:06:44 2019 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 A6AA8120221 for ; Fri, 29 Mar 2019 02:06:42 -0700 (PDT) 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_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 GL7qdah_njTk for ; Fri, 29 Mar 2019 02:06:40 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 D9E4E12015F for ; Fri, 29 Mar 2019 02:06:39 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id h22so1360983edw.7 for ; Fri, 29 Mar 2019 02:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding:embedded-html; bh=UG8wg0MDIeaXVF+cAgfD2LNz2o369Br9vbzp5BDAxAE=; b=t7klsd5R419hoIVAkhyjsdR2xIunHBodsVQU2g2ZL8qQ7II9iDfyTcUHiG7kldYkt2 InN6OG0n7Zj+pZAq4cuLo/+JoD0kV4+GrSXY9dNjDA2hJF0BjgDoupsFBBtUKUFrRkiC 92kEof5tZcaSYPIYDJFQfpeOau+z3d0iVvZ0wxXTEvaKNPm3hJb1uoHoU3kY3r4vJtfu y5M2KHqADaSwDnS3iHBniiJPLBFdPyjyuvVmLYtVa+zVavjDfrq1x+z9w6wkQtyOpW5S jMZijHL3kobW2fAfrvTP4Ggc8wXA5wD2PmTDmomnPnfO6zGtulMLk7VNogp95Waq9BCp VOyg== 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:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=UG8wg0MDIeaXVF+cAgfD2LNz2o369Br9vbzp5BDAxAE=; b=Kf7eEE4NfDiw3i5Jq15AC4uviRTKO/va1Q5yqtzxCXa7BW496bhlsLWEI2VO/Vvr78 7ekS7VH3fprad8ki3S/E/KuueNcIi3IPKbwzSFi8AKzYlyhI5w14DKVanRrH6oAAhtQg lP9Ue3qsqo80cA0/woiIL/kPINMpL0lRQaD0IccpGYE2lETlaww9xo3TnsBXwuLNnb7w hkVF4dt3A9FsBGb8GFL1Jm/b50NsUGFt/+NTj42cu64yjLE0jgk8snBIr/q4RUQUf0mG 15XURBLM4eRR6KDH23qKXyBz6f05SFDQ3ZK7ByATMAY6NT9HEoFpEvIrCYTYuh5mo0S8 eRag== X-Gm-Message-State: APjAAAUfStqoYPKGQoUndEyDSfBW+E6B5hBym7YMi2usJ6EYgstXoKQX TKj0u0ekLWH4lp4zEavRBpsVgKra/N0= X-Google-Smtp-Source: APXvYqzmIvmrGAYpYTSaxQRxVQrI9N70rDnSAz6746mGlr8vOFR9P6zRxlUjjTsb6C/8kARk7RYNlw== X-Received: by 2002:aa7:d146:: with SMTP id r6mr30925062edo.235.1553850397862; Fri, 29 Mar 2019 02:06:37 -0700 (PDT) Received: from [172.19.153.1] ([2001:67c:1232:144:9a5:a5bc:e3ca:9341]) by smtp.gmail.com with ESMTPSA id g4sm259604ejd.74.2019.03.29.02.06.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 02:06:37 -0700 (PDT) From: "Aaron Falk" To: taps@ietf.org, "Brian Trammell" Date: Fri, 29 Mar 2019 10:06:34 +0100 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B7FEC122-9543-4128-BAEF-062C55B4626A_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[468, 12066], "plain":[106, 4952], "uuid":"9924DBBD-AB6A-48D2-8985-D87F955D87CE"}] Archived-At: Subject: Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 09:06:43 -0000 --=_MailMate_B7FEC122-9543-4128-BAEF-062C55B4626A_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks to Brian Trammell for making this happen! On 29 Mar 2019, at 9:28, TAPS WG status robot wrote: > Issues > ------ > * ietf-tapswg/api-drafts (+5/-12/💬22) > 5 issues created: > - More expressive multipath transport property (by abrunstrom) > https://github.com/ietf-tapswg/api-drafts/issues/303 [API] > [discuss] - UDP idempotence (by mwelzl) > https://github.com/ietf-tapswg/api-drafts/issues/302 [API] - Add > an explicit listener object to the API (by philsbln) > https://github.com/ietf-tapswg/api-drafts/issues/301 [API] [ready > for text] - Add property for address privacy (by tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/300 - TAPS ARCH - > Textual review to notes (by gorryfair) > https://github.com/ietf-tapswg/api-drafts/issues/299 > 16 issues received 22 new comments: > - #45 Do we need to make state storage explicit in the architecture > and API? (3 by tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/45 [API] > [Architecture] [ready for text] - #103 Evaluate the applicability of > §6.3 to ICE-like protocols (2 by britram, tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/103 [API] - #206 > Define the server-side equivalent of racing (2 by adventureloop, > tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/206 [API] > [Architecture] [ready for text] - #303 More expressive multipath > transport property (2 by philsbln, tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/303 [API] > [discuss] - #222 Reusing Preconnections? (2 by philsbln, tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/222 [API] > [discuss] - #224 Collapse InitateWithIdempotentData() back in to > Initiate() (1 by britram) > https://github.com/ietf-tapswg/api-drafts/issues/224 - #257 Not > all Events are shown in the diagram (1 by britram) > https://github.com/ietf-tapswg/api-drafts/issues/257 [Architecture] > - #188 ARCH: Message Framing, Parsing, and Serialization (1 by > tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/188 [Architecture] > [help wanted] - #209 Add a few example of Specific Properties (1 by > britram) > https://github.com/ietf-tapswg/api-drafts/issues/209 - #178 > Architecture privacy and security considerations (1 by tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/178 [Architecture] > [ready for text] - #147 Issues to consider (Handley) (1 by tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/147 - #212 > Consider per-context addresses as suggested by > draft-gont-taps-address-usage-* (1 by britram) > https://github.com/ietf-tapswg/api-drafts/issues/212 [API] > [Architecture] [discuss] - #220 Message Context Parameters: Ordered > and Final (1 by britram) > https://github.com/ietf-tapswg/api-drafts/issues/220 [discuss] - > #285 Group management (1 by mwelzl) > https://github.com/ietf-tapswg/api-drafts/issues/285 [API] [ready > for text] - #254 Do we need to have an explicit/separate object for > Listener? (1 by tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/254 [Architecture] > [discuss] - #127 Impl: generalise §4 to incorporate §10 (1 by > tfpauly) > https://github.com/ietf-tapswg/api-drafts/issues/127 > [Implementation] [discuss] > 12 issues closed: > - Group management > https://github.com/ietf-tapswg/api-drafts/issues/285 [API] [ready for > text] - Do we need to have an explicit/separate object for Listener? > https://github.com/ietf-tapswg/api-drafts/issues/254 [Architecture] > [discuss] - Collapse InitateWithIdempotentData() back in to > Initiate() https://github.com/ietf-tapswg/api-drafts/issues/224 - > Connection.Receive(minIncompleteLength, maxLength) > https://github.com/ietf-tapswg/api-drafts/issues/221 [API] - Message > Context Parameters: Ordered and Final > https://github.com/ietf-tapswg/api-drafts/issues/220 [discuss] - > Consider per-context addresses as suggested by > draft-gont-taps-address-usage-* > https://github.com/ietf-tapswg/api-drafts/issues/212 [API] > [Architecture] [discuss] - Add a few example of Specific Properties > https://github.com/ietf-tapswg/api-drafts/issues/209 - ARCH: Message > Framing, Parsing, and Serialization > https://github.com/ietf-tapswg/api-drafts/issues/188 [Architecture] > [help wanted] - Replace long author lists with editors > https://github.com/ietf-tapswg/api-drafts/issues/184 [admin stuff] > [wontfix] - Issues to consider (Handley) > https://github.com/ietf-tapswg/api-drafts/issues/147 - Impl: > generalise §4 to incorporate §10 > https://github.com/ietf-tapswg/api-drafts/issues/127 [Implementation] > [discuss] - Evaluate the applicability of §6.3 to ICE-like protocols > https://github.com/ietf-tapswg/api-drafts/issues/103 [API] > > > Pull requests > ------------- > * ietf-tapswg/api-drafts (+0/-0/💬2) > 1 pull requests received 2 new comments: > - #298 Add Pooled Connections (2 by philsbln, mwelzl) > https://github.com/ietf-tapswg/api-drafts/pull/298 [API] > [Architecture] [discuss] > > Repositories tracked by this digest: > ----------------------------------- > * https://github.com/ietf-tapswg/api-drafts > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=_MailMate_B7FEC122-9543-4128-BAEF-062C55B4626A_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks to Brian Trammell for making this happen!

On 29 Mar 2019, at 9:28, TAPS WG status robot wrote:

Friday March 29, 2019

Issues

ietf-tapsw= g/api-drafts (+5/-12/=F0=9F=92=AC22)

5 issues created:

16 issues received 22 new comments:

12 issues closed:

Pull requests

ietf-tapsw= g/api-drafts (+0/-0/=F0=9F=92=AC2)

1 pull requests received 2 new comments:

Repositories tracked by this digest:

______________________= _________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_B7FEC122-9543-4128-BAEF-062C55B4626A_=-- From nobody Fri Mar 29 02:26:53 2019 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 0FB821202ED for ; Fri, 29 Mar 2019 02:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 83HWe7jeIVTa for ; Fri, 29 Mar 2019 02:26:41 -0700 (PDT) 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 9B4A61203FE for ; Fri, 29 Mar 2019 02:26:40 -0700 (PDT) Received: from smtp7.infomaniak.ch (smtp7.infomaniak.ch [83.166.132.30]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x2T9Qbq2028956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Mar 2019 10:26:37 +0100 Received: from [IPv6:2001:67c:1232:144:49f2:292b:3102:2b16] ([IPv6:2001:67c:1232:144:49f2:292b:3102:2b16]) (authenticated bits=0) by smtp7.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x2T9QaCj169863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Mar 2019 10:26:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: "Brian Trammell (IETF)" In-Reply-To: Date: Fri, 29 Mar 2019 10:26:36 +0100 Cc: taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.3445.102.3) 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] 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, 29 Mar 2019 09:26:52 -0000 You're welcome! Debugging SMTP is "fun". Very happy to get this running = before the WG meeting started with more than an hour to spare. This is currently scheduled to run 0 9 * * 5 (every Friday at 09:00 = UTC). Let the bikeshedding of the script run time begin. :) Cheers, Brian > On 29 Mar 2019, at 10:06, Aaron Falk wrote: >=20 > Thanks to Brian Trammell for making this happen! >=20 > On 29 Mar 2019, at 9:28, TAPS WG status robot wrote: >=20 > Friday March 29, 2019 >=20 > Issues >=20 > ietf-tapswg/api-drafts (+5/-12/=F0=9F=92=AC22) > 5 issues created: >=20 > =E2=80=A2 #303 More expressive multipath transport property (by = abrunstrom) API discuss > =E2=80=A2 #302 UDP idempotence (by mwelzl) API > =E2=80=A2 #301 Add an explicit listener object to the API (by = philsbln) API ready for text > =E2=80=A2 #300 Add property for address privacy (by tfpauly) > =E2=80=A2 #299 TAPS ARCH - Textual review to notes (by = gorryfair) > 16 issues received 22 new comments: >=20 > =E2=80=A2 #45 Do we need to make state storage explicit in the = architecture and API? (3 by tfpauly) API Architecture ready for text > =E2=80=A2 #103 Evaluate the applicability of =C2=A76.3 to = ICE-like protocols (2 by britram, tfpauly) API > =E2=80=A2 #206 Define the server-side equivalent of racing (2 by = adventureloop, tfpauly) API Architecture ready for text > =E2=80=A2 #303 More expressive multipath transport property (2 = by philsbln, tfpauly) API discuss > =E2=80=A2 #222 Reusing Preconnections? (2 by philsbln, tfpauly) = API discuss > =E2=80=A2 #224 Collapse InitateWithIdempotentData() back in to = Initiate() (1 by britram) > =E2=80=A2 #257 Not all Events are shown in the diagram (1 by = britram) Architecture > =E2=80=A2 #188 ARCH: Message Framing, Parsing, and Serialization = (1 by tfpauly) Architecture help wanted > =E2=80=A2 #209 Add a few example of Specific Properties (1 by = britram) > =E2=80=A2 #178 Architecture privacy and security considerations = (1 by tfpauly) Architecture ready for text > =E2=80=A2 #147 Issues to consider (Handley) (1 by tfpauly) > =E2=80=A2 #212 Consider per-context addresses as suggested by = draft-gont-taps-address-usage-* (1 by britram) API Architecture discuss > =E2=80=A2 #220 Message Context Parameters: Ordered and Final (1 = by britram) discuss > =E2=80=A2 #285 Group management (1 by mwelzl) API ready for text > =E2=80=A2 #254 Do we need to have an explicit/separate object = for Listener? (1 by tfpauly) Architecture discuss > =E2=80=A2 #127 Impl: generalise =C2=A74 to incorporate =C2=A710 = (1 by tfpauly) Implementation discuss > 12 issues closed: >=20 > =E2=80=A2 #285 Group management API ready for text > =E2=80=A2 #254 Do we need to have an explicit/separate object = for Listener? Architecture discuss > =E2=80=A2 #224 Collapse InitateWithIdempotentData() back in to = Initiate() > =E2=80=A2 #221 Connection.Receive(minIncompleteLength, = maxLength) API > =E2=80=A2 #220 Message Context Parameters: Ordered and Final = discuss > =E2=80=A2 #212 Consider per-context addresses as suggested by = draft-gont-taps-address-usage-* API Architecture discuss > =E2=80=A2 #209 Add a few example of Specific Properties > =E2=80=A2 #188 ARCH: Message Framing, Parsing, and Serialization = Architecture help wanted > =E2=80=A2 #184 Replace long author lists with editors admin = stuff wontfix > =E2=80=A2 #147 Issues to consider (Handley) > =E2=80=A2 #127 Impl: generalise =C2=A74 to incorporate =C2=A710 = Implementation discuss > =E2=80=A2 #103 Evaluate the applicability of =C2=A76.3 to = ICE-like protocols API > Pull requests >=20 > ietf-tapswg/api-drafts (+0/-0/=F0=9F=92=AC2) > 1 pull requests received 2 new comments: >=20 > =E2=80=A2 #298 Add Pooled Connections (2 by philsbln, mwelzl) = API Architecture discuss > Repositories tracked by this digest: >=20 > =E2=80=A2 https://github.com/ietf-tapswg/api-drafts > _______________________________________________ > 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 From nobody Fri Mar 29 04:30:38 2019 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 2412512026E for ; Fri, 29 Mar 2019 04:30:36 -0700 (PDT) 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_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 W-x1GlB2imCo for ; Fri, 29 Mar 2019 04:30:33 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 AF7D3120267 for ; Fri, 29 Mar 2019 04:30:33 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id 139so3230373ita.4 for ; Fri, 29 Mar 2019 04:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CjDyilGqvWCMU6AdSfnzvfekzmIQLY07WBPmHVA80tw=; b=D+Y67lAHXm7dnar4d8q8JnQrJMC4HJvt4impNcQv+/Kfm+5ihUjweZbkFuKqpBdNix M7lJ6oKDxsEVV1exG0f+SgOgSX3Ijj7MvEoXIL+2nhdvRva7N3QtOVTdxPeTxBGYzb54 1K93q/icMRuhVozme4nczOJhx7ptyYndUU5cb1HpnG5NZq79uuGk3zxmRVpwAtpWqLR7 9EIbTumxXWBj9Td4a+QEL0SYAK/e9AlgwSyoUWJ6pYrS9VGe27apx+HJ+A9JeOlj0MEM iKp1MiwwykM5pLq9uTR8mtsN1SoWHjw1o38X6gpoxFlXq0Ubx+TChsSvoLfhC+HHkMYz q98Q== 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=CjDyilGqvWCMU6AdSfnzvfekzmIQLY07WBPmHVA80tw=; b=LdMzwA13Jlos/Dv/4Qb05AL33hQVrhJQKl2n9bvsj+H/7lDKmiyMH1AGABEqd428zS ciIDUfuMzwaCAGUUcTOgVtgHZR6Cfn+XmFFbaBL/Mbbb0psJN30lGofFeSc+nsemvya1 /zE1jN1jEpYsz1zKQCnP+AMIGUq74VMwnQPc9sKjNtQz5sQmCepGv7gCs9T68yNPx2S0 z0/jkmWjEJtqMfaloa46wRXbKgbjP0jvutYmmFpXMcJiJ7nwkzA7Z2sRvWCIANTfGRJs JMBLHfImwehcmhUc15LWgNJxypugiW/f+NcdkGQmHiFjCNQ1DQxTgptVPbA6FAODcO3i nl9A== X-Gm-Message-State: APjAAAVAVdR/G9tyGIkqaNH2fXs1Ri1N9xH28f/5KokAeOYTnBGed2xj m7g1ZBCTSgwRQQ6G0ufWcHXtdLWjlsxFYGVwSV+czsfV X-Google-Smtp-Source: APXvYqzyYN/CCjdKdLTZhC0G2EkeB3BkoGxtQrlmG9elW3kn2X0eQnC9YKBETXFxF8qJIkh2zCXXW47PGTuvjIul+QM= X-Received: by 2002:a24:5f8c:: with SMTP id r134mr3953839itb.110.1553859032392; Fri, 29 Mar 2019 04:30:32 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Fri, 29 Mar 2019 12:30:05 +0100 Message-ID: To: taps@ietf.org Content-Type: multipart/alternative; boundary="000000000000a82b27058539ff85" Archived-At: Subject: [Taps] ENDS0 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, 29 Mar 2019 11:30:37 -0000 --000000000000a82b27058539ff85 Content-Type: text/plain; charset="UTF-8" Howdy, At the mic I was pointing out that there were cases like EDNS0 options that resulted in fairly significant changes to the operations of a protocol, and that these can be combined in ways to produce a number of different combinations. My concern is that creating a general purpose framer for all of these combinations may be difficult or ossifying, as new options continue to be introduced. I can see it as a potential implementation choice, depending on the generality required, but I can also see implementations where allowing the DNS application to manage this results in both simpler and more correct behavior. Among EDNS0 options to consider here are things like the TCP-specific options ( ends-tcp-keepalive ), the addition of padding , or the use DNS cookies in different transports. There are also potential odd cases like CHAIN or EXPIRE which are intended to be used only in specific relations. I remain pretty convinced that DNS is a good customer for TAPS, but it is my personal impression that more discussion is needed to understand whether this layering helps or hinders that going forward. I'm glad to know that it will be a topic for the interim, and I'll try to attend. Ted --000000000000a82b27058539ff85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

At the mic I was poin= ting out that there were cases like EDNS0 options that resulted in fairly s= ignificant changes to the operations of a protocol, and that these can be c= ombined in ways to produce a number of different combinations.=C2=A0 My con= cern is that creating a general purpose framer for all of these combination= s may be difficult or ossifying, as new options continue to be introduced.= =C2=A0 I can see it as a potential implementation choice, depending on the = generality required, but I can also see implementations where allowing the = DNS=C2=A0 application to manage this results in both simpler and more corre= ct behavior.

Among EDNS0 options to consider h= ere are things like the TCP-specific options ( ends-tcp-keepalive), the addition of padding, or the use DNS cookies in different transports.=C2= =A0 There are also potential odd cases like CHAIN or EXPIRE which are intended to be used only in specific relations.=C2= =A0

I remain pretty convinced that DNS is a g= ood customer for TAPS, but it is my personal impression that more discussio= n is needed to understand whether this layering helps or hinders that going= forward.=C2=A0 I'm glad to know that it will be a topic for the interi= m, and I'll try to attend.

Ted
--000000000000a82b27058539ff85-- From nobody Fri Mar 29 04:53:17 2019 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 B4600120316 for ; Fri, 29 Mar 2019 04:53:03 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 By_vRtVTGBbh for ; Fri, 29 Mar 2019 04:53:01 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1097D12039F for ; Fri, 29 Mar 2019 04:53:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 4CC5125A1F for ; Fri, 29 Mar 2019 12:52:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553860379; bh=vP2IHONX7jN4/hNS0EptBcvU+5XGLwzIDqSOoZsElyc=; h=From:To:Subject:Date:From; b=V9nCMmbocRJXo4rt1Q1mx9QtOUAhOVuUox5eHc9ZUyU9+wQnT4pne2SS+S0/AhQri MuR5ASLlKghP/tgAKsFamCojjWs7+AQMbSYdK8aEQHKfnNqKpXCHyiW6LrGOdafgDH UZiXTCm1YhW6XsYoDCvh4a8vQjWkxTHlxsKeHOsg= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z7hxPSQJCG4 for ; Fri, 29 Mar 2019 12:52:57 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Fri, 29 Mar 2019 12:52:57 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Fri, 29 Mar 2019 12:52:57 +0100 From: "Scharf, Michael" To: "taps@ietf.org" Thread-Topic: Potential alternatives to YANG Thread-Index: AdTmJJkFb6Zp0XvTRsiCqia1FVlvnQ== Date: Fri, 29 Mar 2019 11:52:56 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28CC16@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Taps] Potential alternatives to YANG 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, 29 Mar 2019 11:53:16 -0000 As mentioned on the mic: There are quite a number of solutions to "rigorous= ly" specify APIs. Some of these general-purpose techniques are IMHO also us= ed for configuration/provisioning tasks in the networking industry, i.e., a= s alternative to YANG. In a former life, I had quite some discussions on the role of YANG as compa= red to, for instance: * swagger.io (https://swagger.io/) * gRPC, gNMI and protocol buffers (see e.g. draft-openconfig-rtgwg-gnmi-spe= c-01 in the IETF) In both cases there is are tooling eco-system that are IMHO widely used by = app developers (and often preferred over YANG). The YANG tooling that exist= s in industry, e.g., for code auto-generation, is quite specific to network= management, as far as I can tell. To me, whether to develop models in YANG or in other data modeling language= s depends a lot on the use case and the target software developer community= . Of course, in the RTG and OPS area YANG is the default data modeling lang= uage. Michael=20 (as somebody who attends RTG and OPS working groups) From nobody Sat Mar 30 01:16:50 2019 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 E7EB9120188 for ; Sat, 30 Mar 2019 01:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 0nGzZ8S8xq5E for ; Sat, 30 Mar 2019 01:16:47 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2A7D4120183 for ; Sat, 30 Mar 2019 01:16:47 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x2U8DOHu011601 for ; Sat, 30 Mar 2019 08:16:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=iSCunwkSGLE8kElmhY1W/LDC1Gd1zHYcRjb3t8axO9k=; b=iOFrN0b2xJIpH3BjeQyZ64dcTV9m/Jv3DsqrHMXx+NFjAkGfzpsIhq4msIsuoEl+Qk7i m/giKpxNmTtznJ/ICxJTO3KNKS/ld2k5+471Vxe7pbJc4NQg85A+JGLBgE0iD1e8ca1O 6JzZ+eaJ+IKbD++W1xud6/YH6NEcs55fHtK7VFof71ttLNFw4XrdetskVN5OvvqPsQ0k 0NAE1/pBiyzIBNdQaEgwrJLZtxEc1wmpBjnGqKKF3a3azWeAv2KP12nOZ1qYIy4J4oot LkVR7Tmirw1spwK9XSI8bEUNIfSHyFVkwY5tWinz5vYQNcOeUlQBPi/twSRHF/h64t9d cA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2rj0v6gmp0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 30 Mar 2019 08:16:46 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2U81udT002125 for ; Sat, 30 Mar 2019 04:16:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2rj3sx0810-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 30 Mar 2019 04:16:43 -0400 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 30 Mar 2019 01:16:41 -0700 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Sat, 30 Mar 2019 03:16:41 -0500 From: "Holland, Jake" To: "taps@ietf.org" Thread-Topic: Follow-up on TTL+multicast send question Thread-Index: AQHU5tDna4q5Q5RmQEaC20U3rz6KHA== Date: Sat, 30 Mar 2019 08:16:40 +0000 Message-ID: <552F35C9-87BE-4F0A-A1DB-EE463F34ACA0@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.48] Content-Type: text/plain; charset="utf-8" Content-ID: <1AD39EC2AACA824E86881C13E177D43F@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-30_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903300058 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-30_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903300059 Archived-At: Subject: [Taps] Follow-up on TTL+multicast send question 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, 30 Mar 2019 08:16:49 -0000 SGkgdGFwcywNCg0KQXQgdGhlIG1pa2UsIEkgYmVsaWV2ZSBHb3JyeSBhc2tlZCB3aGV0aGVyIEkg bmVlZCBzZW5kZXIgVFRMLA0KYW5kIEkgcmVwbGllZCAiWWVzLiINCg0KSSB3YW50IHRvIGFkZCBh IGxpdHRsZSBudWFuY2UgdG8gdGhhdDoNCg0KSSB0aGluayBhIGRlZmF1bHQgdmFsdWUgZm9yIFRU TCB0aGF0IHJlYWNoZXMgcmVtb3RlIHJlY2VpdmVycw0KaXMgcHJvYmFibHkgdGhlIHJpZ2h0IGNo b2ljZSwgc28gdGhhdCBpdCdzIGFuIG9wdGlvbmFsIHNldHRpbmcNCihhcyBvcHBvc2VkIHRvIHRv ZGF5J3MgZGVmYXVsdCBvZiAxIGZvciBtdWx0aWNhc3QgcGFja2V0cywgd2hpY2gNCnlvdSBoYXZl IHRvIGFsd2F5cyBzZXQgaWYgeW91IHdhbnQgbm9uLUxBTiB0cmFmZmljKS4NCg0KSSB0aGluayBh c2tpbmcgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0byBjaG9vc2UgYW4gaW50ZWdlcg0KdmFsdWUg aXMgYWxtb3N0IGNlcnRhaW5seSBoYXJtZnVsLCB0byB0aGUgZXh0ZW50IGl0IGhhcyBhbnkNCmVm ZmVjdC4gIEF0IGxlYXN0LCBJJ20gY2VydGFpbiB0aGF0IHdoZW4gSSd2ZSBzZXQgdGhlIHZhbHVl DQpvdXQgb2YgbmVjZXNzaXR5LCBJIGhhdmUgZG9uZSBzbyBpbiBhbiBlbnRpcmVseSB1bnByaW5j aXBsZWQNCndheSwgd2l0aCBhIGdvYWwgYmVzdCBwaHJhc2VkIGFzICJ3b3JrcyBmb3IgbWUiLiAg KFRob3VnaCBJDQp0aGluayBzb21lIHBlb3BsZSBtaWdodCBoYXZlIHJlYWwgcmVhc29ucyB0aGV5 J2QgcGljayBzcGVjaWZpYw0KdmFsdWVzLCBzbyBtYXliZSBpdCBoYXMgdG8gYmUgYWxsb3dlZC4p DQoNClNvbWUgc2VuZGluZyB1c2UgY2FzZXMgYXJlIGZvciBMQU4gb25seSAoZS5nLiBtYW55IGRp c2NvdmVyeQ0KYW5kIGhlbGxvIHByb3RvY29scyksIGFuZCBJIHRoaW5rIHRoYXQncyB3aHkgdGhl IGRlZmF1bHQgZm9yDQptdWx0aWNhc3Qgd2hlbiBzZW5kaW5nIGZyb20gc29ja2V0cyBpcyBUVEw9 MSwgYW5kIHlvdSBoYXZlIHRvDQpjaGFuZ2UgaXQtLWlmIHlvdSBmb3JnZXQgdG8gc2V0IGl0LCB5 b3Ugd29uJ3QgYmxvdyBhbnl0aGluZyBvdXQsDQp5b3UnbGwganVzdCBzYXkgImh1aCwgSSBndWVz cyBtdWx0aWNhc3QgZG9lc24ndCB3b3JrIi4NCg0KSSB0aGluayB0aGF0IHByb2JhYmx5IG1hZGUg c2Vuc2UgYmFjayB3aGVuIHBlb3BsZSBzdGlsbCB0aG91Z2h0DQpkZW5zZS1tb2RlIGFuZCBnbG9i YWwgc291cmNlLWFjdGl2ZSBhbm5vdW5jZW1lbnRzIG1pZ2h0IGJlIGENCmdvb2QgaWRlYSwgYnV0 IG5vdyBtYXliZSBpdCBkb2Vzbid0IGhhdmUgdG8gYmUgdGhhdCB3YXkuICAoT3INCmlmIGFueWJv ZHkgdGhpbmtzIHRoYXQncyB1bnNhZmUsIG1heWJlIG9ubHkgZm9yIEFTTT8pDQoNCkFueXdheSwg SSB0aGluayBpbiBteSBwZXJmZWN0IHdvcmxkLCBzZW5kZXIgVFRMIGZvciBtdWx0aWNhc3QNClVE UCB3b3VsZCBkZWZhdWx0IHRvIGEgc3lzdGVtLW92ZXJyaWRlYWJsZSBoaWdoIHZhbHVlIG5hbWVk ICJnbG9iYWwiDQpzb21ldGhpbmcsIHdpdGggYSBjb3JyZXNwb25kaW5nIHN5c3RlbS1vdmVycmlk ZWFibGUgbG93IHZhbHVlIG5hbWVkDQoibG9jYWwiIHNvbWV0aGluZyBkZWZhdWx0ZWQgdG8gMSwg YW5kIG1heWJlIChpZiBhbnlvbmUgY2FyZXMpIGENCm1pZGRsZSB0aGluZyBuYW1lZCAic2l0ZSIg c29tZXRoaW5nLCBhbmQgbWF5YmUgZXZlbiBhbGwgdGhlIHJlc3Qgb2YNCnRoZSBzY29wZXMgaWYg eW91IGNhbiBmaW5kIG1lIHNvbWVvbmUgd2hvIHVzZXMgdGhlbSB0aGF0IEkgY2FuIHRhbGsNCnRv LiAgKEFuZCBmb3IgSVA2IHRoZXNlIGNvdWxkIGJlIGluZmVycmVkIGFuZCBkZWZhdWx0ZWQgZnJv bSB0aGUgZ3JvdXANCmFkZHJlc3MncyBzY29wZVsxXSwgd2l0aCBvcHRpb25hbCBvdmVycmlkZS4p DQoNClNvbWV0aGluZyBsaWtlIHRoYXQgd291bGQgYmUgd2F5IGJldHRlciBJTU8gKGFzIGFuIGFw cCBkZXYgYW5kL29yDQpuZXR3b3JrIGFkbWluKSB0aGFuIG91ciBkZWZhdWx0IFRUTD0xIHdvcmxk IGluIEJTRCBzb2NrZXRzLg0KDQpCdXQgYWxsIHdlIHJlYWxseSBuZWVkIGlzIGEgbG9jYWwvbm90 LWxvY2FsIHNlbGVjdGlvbiwgYW5kIHNvbWVib2R5DQpwcm9iYWJseSBkb2VzIHJlYWxseSBuZWVk IHRvIGJlIGFibGUgdG8gcGljayBhIHNwZWNpZmljIHZhbHVlIHNvbWV0aW1lcywNCmJlY2F1c2Ug cGVvcGxlIGFyZSBqdXN0IHRoYXQgY3JhenkuICAoQW5kIEkgd291bGQgYmUgdG90YWxseSBjb21m b3J0YWJsZQ0Kd2l0aCBtYWtpbmcgdGhhdCBhIHByaXZpbGVnZWQgb3BlcmF0aW9uLCBidHcsIGlm IHdlJ3ZlIGdvdCBzdWNoIGENCmNvbmNlcHQuLi4pDQoNCkknbGwgZm9sZCB0aGlzIGludG8gbXkg IzE1MCByZXNvbHV0aW9uIHByb3Bvc2FsWzJdIHdoZW4gSSBnZXQgdGhlcmUsDQpidXQgSSB3YW50 ZWQgdG8ga2ljayBvZmYgZGlzY3Vzc2lvbiBvbiB0aGlzIHBvaW50IGlmIGFueWJvZHkgaGFzDQpv cGluaW9ucy4gIFNvIHBsZWFzZSBjb21tZW50IGlmIHRoaXMgZW1haWwgbWFrZXMgYW55IHNlbnNl IHRvIHlvdSwgb3INCmFzayBxdWVzdGlvbnMgaWYgaXQgZG9lc24ndC4NCg0KQmVzdCwNCkpha2UN Cg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MzQ2I3NlY3Rpb24tMiANClsy XSBodHRwczovL2dpdGh1Yi5jb20vaWV0Zi10YXBzd2cvYXBpLWRyYWZ0cy9pc3N1ZXMvMTUwDQoN Cg0K