From nobody Tue Apr 4 08:56:01 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F70129435 for ; Tue, 4 Apr 2017 08:55:59 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-p_FcLz8FTd for ; Tue, 4 Apr 2017 08:55:57 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 626131293EE for ; Tue, 4 Apr 2017 08:55:57 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id l7so98193235ioe.3 for ; Tue, 04 Apr 2017 08:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version; bh=iievmOvtPNHeOZRuBsegegjlsiOckyZq6aNT3hE2qWc=; b=YBEifApY05FFwO9ct4wIjGs11VZV/xmmcXqE6WN8C+1xXRZo3vpbpl2B/bvnaSE8yn mGLKCLv4zDRfht2o+4ZX8JnpG3ur/RP3cgwcSyvdpuSfSnLVwR+nh+9cgI168AkLDyvN rJYiDCOEnw/BXNG7LJld0cFnFIg3CqtWcSDispyHHhN49ppuOzGQa86ld02AtOKX9d7h u9ToCeagvQY1GvJX3ejfSDtGt5Bms598bfQsEttFqkYGw+4fk5IHWPNNSruzQAXmxUiy kfX66ZS3gz8L5HTwR9zC92tc4Yk6I7EqJaBtiA81VE22DdoxNhWMC3ignWQ+1TsHyL/M pJWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=iievmOvtPNHeOZRuBsegegjlsiOckyZq6aNT3hE2qWc=; b=H6mHcKPi3NVb7XsEq9KGRx+32seStENVtmEv4RwjZouZJfPRxCWSzqLDhDV6+xN21S wYObHcS88ozOHPwxaxNxSSQrB5LOIilERNauhfW4kOZ+xS0ssaewq1LOKYumszcvw20P mwTSRMHQBBdnHiGHXpy65vD+iC81uOIkgkEcoIqBbQeNj/C73NQd7oNzGQH5vYdMO/kB q10FadjVhlrkfPCULxyePjWXe3wkgD7IPSG4wQ1HLb5sJ+e6yGQ/gKhP2DjPJsnjD0RQ pLLqOzuk5AbH13EsdE0yxKJosWGVwyfPt110PDSfpMfOolk0BN61+JmjOuFHWiwONNuz YQ1g== X-Gm-Message-State: AFeK/H1di6Qqc0/AsEGnb9f2IPEtVBC/Ffbz5SuTBX+qhQ8aKsdGbA3QlWHDt4oBQkGvIw== X-Received: by 10.107.7.210 with SMTP id g79mr21885452ioi.34.1491321356234; Tue, 04 Apr 2017 08:55:56 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id r203sm7424359itc.5.2017.04.04.08.55.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 08:55:55 -0700 (PDT) To: tsv-art@ietf.org From: Wesley Eddy Message-ID: Date: Tue, 4 Apr 2017 11:55:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8416FD90D1CFA3AA4F438819" Archived-At: Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 04/04 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:55:59 -0000 This is a multi-part message in MIME format. --------------8416FD90D1CFA3AA4F438819 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi TSV-ARTists, here is my attempt at triaging the documents in last call and assigning some for review. Documents that require TSV attention: * draft-ietf-ipsecme-tcp-encaps -- assigned to Wes (note last call ends 4/18 and on telechat agenda 4/27) * draft-ietf-core-coap-tcp-tls -- assigned to Yoshifumi (note last call ends 4/9 but not yet on telechat agenda) Documents that do not require TSV attention (but reviews are welcome if you have bandwidth): * draft-ietf-dnssd-mdns-dns-interop * draft-ietf-rtcweb-overview (my assumption is that many TSV people are active in RTCWEB already, and this is just an overview document, not actual spec) * draft-ietf-pals-status-reduction * draft-ietf-ippm-twamp-time-format (this is a TSV area document already) * draft-ietf-ippm-6man-pdm-option (this is a TSV area document already) * draft-ietf-i2nsf-problem-and-use-cases * draft-ietf-dhc-relay-server-security * draft-ietf-bess-evpn-vpws * draft-ietf-aqm-codel (this is a TSV area document already) * draft-ietf-alto-multi-cost (this is a TSV area document already) * draft-ietf-isis-auto-conf * draft-ietf-rtwg-yang-key-chain * draft-ietf-isis-mi-bis * draft-ietf-mmusic-dtls-sdp * draft-ietf-httpbis-encryption-encoding --------------8416FD90D1CFA3AA4F438819 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi TSV-ARTists, here is my attempt at triaging the documents in last call and assigning some for review.

Documents that require TSV attention:

  • draft-ietf-ipsecme-tcp-encaps -- assigned to Wes  (note last call ends 4/18 and on telechat agenda 4/27)
  • draft-ietf-core-coap-tcp-tls -- assigned to Yoshifumi  (note last call ends 4/9 but not yet on telechat agenda)


Documents that do not require TSV attention (but reviews are welcome if you have bandwidth):

  • draft-ietf-dnssd-mdns-dns-interop
  • draft-ietf-rtcweb-overview (my assumption is that many TSV people are active in RTCWEB already, and this is just an overview document, not actual spec)
  • draft-ietf-pals-status-reduction
  • draft-ietf-ippm-twamp-time-format (this is a TSV area document already)
  • draft-ietf-ippm-6man-pdm-option (this is a TSV area document already)
  • draft-ietf-i2nsf-problem-and-use-cases
  • draft-ietf-dhc-relay-server-security
  • draft-ietf-bess-evpn-vpws
  • draft-ietf-aqm-codel (this is a TSV area document already)
  • draft-ietf-alto-multi-cost (this is a TSV area document already)
  • draft-ietf-isis-auto-conf
  • draft-ietf-rtwg-yang-key-chain
  • draft-ietf-isis-mi-bis
  • draft-ietf-mmusic-dtls-sdp
  • draft-ietf-httpbis-encryption-encoding


--------------8416FD90D1CFA3AA4F438819-- From nobody Sat Apr 8 20:53:33 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E798B128DE7; Sat, 8 Apr 2017 20:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 xcxBljahfKUU; Sat, 8 Apr 2017 20:53:16 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E112B126E3A; Sat, 8 Apr 2017 20:53:15 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2A03A29C9DC; Sun, 9 Apr 2017 12:53:13 +0900 (JST) Received: by mail-oi0-f43.google.com with SMTP id l63so12047633oig.2; Sat, 08 Apr 2017 20:53:13 -0700 (PDT) X-Gm-Message-State: AFeK/H2OnXmfqg2iRi8GkVofIn8CGqBPchEFjaGPCVLn+FBG2EFFtIbxtdm04TXPDmgJtSRRehr7j+cKhXazPw== X-Received: by 10.202.97.6 with SMTP id v6mr11468290oib.214.1491709991791; Sat, 08 Apr 2017 20:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Sat, 8 Apr 2017 20:53:11 -0700 (PDT) From: Yoshifumi Nishida Date: Sat, 8 Apr 2017 20:53:11 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tsv-art@ietf.org Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=001a113d4fee2b36e8054cb3ccb5 Archived-At: Subject: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 03:53:18 -0000 --001a113d4fee2b36e8054cb3ccb5 Content-Type: text/plain; charset=UTF-8 Document: draft-ietf-core-coap-tcp-tls-07 Reviewer: Yoshifumi Nishida I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Summary: This document is well-written. It is almost ready to be published as a PS draft once the following points are addressed. 1: It is not clear how the protocol reacts the errors from transport layers (e.g. connection failure). The protocol will just inform apps of the events and the app will decide what to do or the protocol itself will do something? 2: There will be situations where the app layer is freezing while the transport layer is still working. Since transport layers cannot detect this type of failures, there should be some mechanisms for it somewhere in the protocol or in the app layer. The doc needs to address this point. For example, what will happen when a PONG message is not returned for a certain amount of time? 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc. -- Yoshi --001a113d4fee2b36e8054cb3ccb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Document: draft-ietf-core-coap-tcp-tls-07
Reviewer: Yoshifumi Nishid= a
<= br>
I've reviewed= this document as part of TSV-ART's ongoing effort to review key IETF d= ocuments. These comments were written primarily for the transport area dire= ctors, but are copied to the document's authors for their information a= nd to allow them to address any issues raised.When done at the time of IETF= Last Call, the authors should consider this review together with any other= last-call comments they receive. Please always CC=C2=A0tsv-art@ietf.org=C2=A0if you reply t= o or forward this review.

Summary:=C2=A0This document is well-written. It is almost ready= to be published as a PS draft once=C2=A0the following points are addressed= .

1: It is not cl= ear how the protocol reacts the errors from transport layers (e.g. connecti= on failure).
= =C2=A0 =C2=A0The protocol will just inform apps of the events and the app w= ill decide what to do or the protocol itself will do something?

2: There will be situations where = the app layer is freezing while the transport layer is still working. Since= transport layers cannot detect this type of failures, there should be some= mechanisms for it somewhere in the protocol or in the app layer.=C2=A0 The= doc needs to address this point. For example, what will happen when a PONG= message is not returned for a certain amount of time?
=C2=A0
3: Since this draft defines new SZX value= , I think the doc needs to update RFC7959. This point should be clarified m= ore in the doc.
--
Yoshi
=
--001a113d4fee2b36e8054cb3ccb5-- From nobody Sun Apr 9 00:25:37 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD89A129456; Sun, 9 Apr 2017 00:25:27 -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] 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 Or48n5sLs9Ea; Sun, 9 Apr 2017 00:25:26 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 83D3B129329; Sun, 9 Apr 2017 00:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v397PMHT000531; Sun, 9 Apr 2017 09:25:22 +0200 (CEST) Received: from client-0060.vpn.uni-bremen.de (client-0060.vpn.uni-bremen.de [134.102.107.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w14bQ1yhBzDHdT; Sun, 9 Apr 2017 09:25:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sun, 9 Apr 2017 09:25:21 +0200 Cc: tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org X-Mao-Original-Outgoing-Id: 513415521.674309-e6e2b439554923e512814b6ee2040d7e Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 07:25:28 -0000 Hi Yoshi, thank you very much for your thoughtful review. For now, let me pick one of your comments: > 3: Since this draft defines new SZX value, I think the doc needs to = update RFC7959. This point should be clarified more in the doc. The spec does indeed define a new SZX value, for use with the = environments this document is used in (reliable transports). It does = not change or add anything to the way RFC 7959 is used with the existing = unreliable transports; as such it does not really update RFC 7959 as = much as it does extend it for its own purposes. (However, the same argument could be made for RFC 7641, which we do say = we update.) Maybe we are not making the point forcefully enough that SZX=3D7 is = meant for use within this spec? (Again, however: any other future COAP transports that have larger = messages might pick up SZX=3D7 as well.) I don=E2=80=99t have a strong opinion on how to populate the = =E2=80=9Cupdates=E2=80=9D graph of RFCs in these boundary cases; it = might help to get some more guidance here. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Apr 9 14:24:33 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C501C1293FC; Sun, 9 Apr 2017 14:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sJZ-ZfgyzHgm; Sun, 9 Apr 2017 14:24:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD04127A97; Sun, 9 Apr 2017 14:24:14 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 05AB129CC3C; Mon, 10 Apr 2017 06:24:12 +0900 (JST) Received: by mail-oi0-f47.google.com with SMTP id g204so56639005oib.1; Sun, 09 Apr 2017 14:24:11 -0700 (PDT) X-Gm-Message-State: AFeK/H2dD9jOkdWNRDjqiQIGTRG25G6qIOjQXAtG7c5+hoiOhdx4xfQlhLGz863SX3wjjH/k+OcdUQPSzgAjZw== X-Received: by 10.157.45.163 with SMTP id g32mr29278825otb.274.1491773050374; Sun, 09 Apr 2017 14:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.132 with HTTP; Sun, 9 Apr 2017 14:24:09 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Sun, 9 Apr 2017 14:24:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Yoshifumi Nishida , tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=94eb2c04fb4ac0d40c054cc27a04 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 21:24:17 -0000 --94eb2c04fb4ac0d40c054cc27a04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On Sun, Apr 9, 2017 at 12:25 AM, Carsten Bormann wrote: > Hi Yoshi, > > thank you very much for your thoughtful review. > > For now, let me pick one of your comments: > > > 3: Since this draft defines new SZX value, I think the doc needs to > update RFC7959. This point should be clarified more in the doc. > > The spec does indeed define a new SZX value, for use with the environment= s > this document is used in (reliable transports). It does not change or ad= d > anything to the way RFC 7959 is used with the existing unreliable > transports; as such it does not really update RFC 7959 as much as it does > extend it for its own purposes. > (However, the same argument could be made for RFC 7641, which we do say w= e > update.) > > Maybe we are not making the point forcefully enough that SZX=3D7 is meant > for use within this spec? > (Again, however: any other future COAP transports that have larger > messages might pick up SZX=3D7 as well.) > > I don=E2=80=99t have a strong opinion on how to populate the =E2=80=9Cupd= ates=E2=80=9D graph of > RFCs in these boundary cases; it might help to get some more guidance her= e. > Ok, I see the point. I don't have a strong opinion here either as I am not a COAP expert. It could be enough if the draft has more texts to articulate that it won't cause conflict with unreliable transport COAP. -- Yoshi --94eb2c04fb4ac0d40c054cc27a04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

On Sun, Apr 9, 2017 at 12:25 AM, Carsten Bormann <cabo@tzi.org= > wrote:
Hi Yoshi,

thank you very much for your thoughtful review.

For now, let me pick one of your comments:

> 3: Since this draft defines new SZX value, I think the doc needs to up= date RFC7959. This point should be clarified more in the doc.

The spec does indeed define a new SZX value, for use with the enviro= nments this document is used in (reliable transports).=C2=A0 It does not ch= ange or add anything to the way RFC 7959 is used with the existing unreliab= le transports; as such it does not really update RFC 7959 as much as it doe= s extend it for its own purposes.
(However, the same argument could be made for RFC 7641, which we do say we = update.)

Maybe we are not making the point forcefully enough that SZX=3D7 is meant f= or use within this spec?
(Again, however: any other future COAP transports that have larger messages= might pick up SZX=3D7 as well.)

I don=E2=80=99t have a strong opinion on how to populate the =E2=80=9Cupdat= es=E2=80=9D graph of RFCs in these boundary cases; it might help to get som= e more guidance here.

Ok, I see the poi= nt. I don't have a strong opinion here either as I am not a COAP expert= .=C2=A0
It could be enough if the draft has more texts to art= iculate that it won't cause conflict with unreliable transport COAP.=C2= =A0
--
Yoshi
--94eb2c04fb4ac0d40c054cc27a04-- From nobody Tue Apr 11 07:55:07 2017 Return-Path: X-Original-To: tsv-art@ietf.org Delivered-To: tsv-art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29012E8FA; Tue, 11 Apr 2017 07:55:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192250152.15649.6637923996602707175@ietfa.amsl.com> Date: Tue, 11 Apr 2017 07:55:01 -0700 Archived-At: Subject: [Tsv-art] Tsvart last call review of draft-ietf-ipsecme-tcp-encaps-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:55:02 -0000 Reviewer: Wesley Eddy Review result: On the Right Track This document is clear and well-written. It can easily be implemented based on the description. There are a few additional issues that should be considered with advice to implementers in Section 12 on performance considerations: 1) Invisibility of packet loss - Inner protocols that require packet losses as a signal of congestion (e.g. TCP) will have a challenge due to not being able to see any packet losses since the outer TCP will repair them (unless sending into a full outer TCP socket buffer shows up back to the inner TCP as a packet loss?). 2) Nesting of ECN - Inner TCP connections will not be able to use effectively ECN on the portion of the path covered by the outer TCP connection. 3) Impact of congestion response on aggregate - The general "TCP in TCP" problem is mentioned, and is mostly appropriate for a single flow. If an aggregate of flows is sharing the same outer TCP connection, there may be additional concerns about how the congestion response behavior impacts an aggregate of flows, since it may cause a shared delay spike even to low-rate flows rather than distributing losses proportional to per-flow throughput. 4) Additional potential for bufferbloat - Since TCP does not bound latency, some applications in the IPsec-protected aggregate could drive latency of the shared connection up and impact the aggregate of flows that may include real-time applications. The socket buffer for the outer TCP connection might need to be limited in size to ensure some bounds? Not addressing these could lead to poor experiences in deployment, if implementations make wrong assumptions or fail to consider them. In the security considerations section, there are several RFCs on mechanisms to increase robustness to RST attacks and SYN floods that could be mentioned if it's worthwhile. From nobody Tue Apr 11 12:14:13 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8212951B; Tue, 11 Apr 2017 12:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 qWctKzCg6tWX; Tue, 11 Apr 2017 12:14:10 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 3905E127010; Tue, 11 Apr 2017 12:14:10 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l28so4171779wre.0; Tue, 11 Apr 2017 12:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=zxlUSKEaMm1Eq+h1p4NutfP7p+TiI+7JXyhJxV/1z+M=; b=GLAGTPH3aHn7YILqAmHozC6KYDZ5MClWv6XZ+YDCizM6kUoIQzxvo/U+hozFDOM60O OcA5Z4/njNL6zm5VFOSBzyPkaqMsgijOp83wl2WaM/phfi7nlyNVHc0Q7iMH8tzFy+vC /FitYubE4LIQigFIylZmK/ajV5mih4x8OnuXy54PrUnqSF50IzfJbsBee3+r0WKytev0 2BKV7XPIXQz7jWv7aT/Iwu7mkOkba7/KI/zU/nACpC5HGxhZX07R6/zxlciWN/SxLeSy wlCDLYUJxnP0Kyf22zfb8M21YsMhkLS57c7mSOxiPVGCfih6V/GiHnjR/Y3EKIzL3qsI sHCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=zxlUSKEaMm1Eq+h1p4NutfP7p+TiI+7JXyhJxV/1z+M=; b=R2cVmObCUHUqXA9IkdrIFdwQSfnG2xJH2MpwITgfmX8Hk1Xe4CyvZwZjNTAvXUsYoF poGce2bk0srsyi1oQEp5BwSFJx8MwmXFnKnfRSoQBKpub0xkUgXIus4LAm7sDLOAJ8F3 +jz8ic/wohhCOyJaEKwtcsYBiaWL0d3/i9E8VF9oOlq5fVdjTWzsZj+7Thsm3rL0SO0V zalEpD+ccJuQKjJBhY/oDhhMy7kGzJ2/+cpWC8PD1DKRVGxwVKLCvgUce2cqeOs9gLJU 1D8GZ+HPInvnoxnGhqNbr7BVO2D9cmrRsrmUU6MRMZIeO2j6zxiSW+zPGzsqNFMacsfn A1OA== X-Gm-Message-State: AFeK/H1oBoPa+7BsnkCFXQNWRyJmc8aYHb7CAx/VLLgILOTBnpfEx68XaWzKJIrhv+zIrQ== X-Received: by 10.223.144.8 with SMTP id h8mr49392107wrh.45.1491938048169; Tue, 11 Apr 2017 12:14:08 -0700 (PDT) Received: from ?IPv6:2003:6:1575:649:78ae:9e4f:62ab:8918? (p200300061575064978AE9E4F62AB8918.dip0.t-ipconnect.de. [2003:6:1575:649:78ae:9e4f:62ab:8918]) by smtp.googlemail.com with ESMTPSA id d7sm22638188wrc.6.2017.04.11.12.14.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 12:14:07 -0700 (PDT) From: Martin Stiemerling To: ipv6@ietf.org Cc: tsv-art@ietf.org Message-ID: <1ff5b4e0-c2bb-0f00-97af-c1b888e29833@gmail.com> Date: Tue, 11 Apr 2017 21:14:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:14:12 -0000 Hi, I've reviewed this document as part of the transport area review team (TSV-ART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Sorry for being so late with the review... Summary: This draft has serious issues out of a transport area perspective, described in the review, and needs to be rethought. Major issues: - Section 4.8. "Defining New Extension Headers and Options": It says new hop-by-hop headers must never ever defined. This is problematic, as this closing the door forever, even if future instances of the IETF do would like to wish to define new hop-by-hop headers. A better way would have to say "that new hop-by-hop headers must have IETF consensus". - Section 4.8. "Defining New Extension Headers and Options": Also the „not recommended“ to define new extension headers looks strange, especially with the phrase "There has to be a very clear justification". The term "clear justification" is not an exact engineering specification. Why not using "technical protocol specification and real word use case required, plus IETF consensus"? Minor issues: none. Thank you, Martin Stiemerling From nobody Tue Apr 11 14:32:05 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2225312869B; Tue, 11 Apr 2017 14:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 XFF5uxprU_uX; Tue, 11 Apr 2017 14:31:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA6A126DC2; Tue, 11 Apr 2017 14:31:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 456176B06C; Tue, 11 Apr 2017 17:31:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=uqV/OHg0cZi6zVEFODWkjOqxp 0Y=; b=EjCHwOleIkWP8mlIA+zUQk7Jx+4+noYS5s4zszzOXQoN9Qvb0iQ5MXBk8 PUfNqFN8a2GEAoOWeMMKsE5gsMMP5sTe81OflokG0unGdI1yjAx1lrdpxT8clGyY bgcG+8ShbipwdU+TJObH++juhc8R+kWIyjm7rM1M+8YT7/hjUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=AAX1ctCeKh7kf7ddBYy F+o8sFDimRLakQeoEQiUou2VCrth3Owcx82lyukXJX0Icivd1jeOpCNHXq7i37yQ hs7o3JIvkpV6R/ig+C5Eej5Zsty0dZE/V2fmDay2hxKxJm2Kzvih0kWka/34bXSD bVUu9U7w/kRkCBHw83qnPMWM= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3A6E76B069; Tue, 11 Apr 2017 17:31:52 -0400 (EDT) Received: from mail-qk0-f176.google.com (unknown [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id B42906B066; Tue, 11 Apr 2017 17:31:51 -0400 (EDT) Received: by mail-qk0-f176.google.com with SMTP id f133so8958062qke.2; Tue, 11 Apr 2017 14:31:51 -0700 (PDT) X-Gm-Message-State: AFeK/H0+jFKIfhWQXy05knO2lmFqTdWlufhTe3kRaoBIZ4INuU7MDWplW2kTCN/uSdUs6SIqzFdCyf/bhPNy9Q== X-Received: by 10.55.3.1 with SMTP id 1mr46925001qkd.245.1491946311309; Tue, 11 Apr 2017 14:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Tue, 11 Apr 2017 14:31:30 -0700 (PDT) From: "C. M. Heard" Date: Tue, 11 Apr 2017 14:31:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Martin Stiemerling , 6man WG Cc: TSV-ART Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 46DD0AA8-1EFE-11E7-BDDF-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:31:57 -0000 On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote: > Major issues: > > - Section 4.8. "Defining New Extension Headers and Options": > > It says new hop-by-hop headers must never ever defined. This is problemat= ic, > as this closing the door forever, even if future instances of the IETF do > would like to wish to define new hop-by-hop headers. A better way would h= ave > to say "that new hop-by-hop headers must have IETF consensus". If a new extension header with hop-by-hop behavior were defined, it would require a router or other forwarding device to look beyond the header immediately following the base IPv6 header, possibly even arbitrarily deep into an IPv6 header chain. That's not backward compatible with the existing specification, which was written the way it was to limit the amount of header processing required in the forwarding path. Can you provide an example of anything that can be done with a new hop-by-hop extension header that cannot also be done with a new hop-by-hop option? > - Section 4.8. "Defining New Extension Headers and Options": > > Also the =E2=80=9Enot recommended=E2=80=9C to define new extension header= s looks strange, > especially with the phrase "There has to be a very clear justification". = The > term "clear justification" is not an exact engineering specification. Why > not using "technical protocol specification and real word use case requir= ed, > plus IETF consensus"? We could perhaps make this clearer by stating that a new extension header must not be defined unless it can be proven that the desired functionality cannot reasonably be provided either by a new destination option or by a new upper layer protocol, but I'm not convinced that it's that much of an improvement - there's that pesky word "reasonably," which still implies an exercise of engineering judgment, which you seem to want to avoid. For a necessarily imprecise analysis of which of the existing extension headers meet the "cannot reasonably be provided" criterion, please see https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html Mike Heard From nobody Wed Apr 12 09:42:05 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2E12EAE8 for ; Wed, 12 Apr 2017 09:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Th80HdZdIhhH for ; Wed, 12 Apr 2017 09:42:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9762D129543 for ; Wed, 12 Apr 2017 09:42:00 -0700 (PDT) Received: (qmail 32698 invoked from network); 12 Apr 2017 18:41:58 +0200 Received: from p5dec24e1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.225) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Apr 2017 18:41:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 12 Apr 2017 18:41:58 +0200 Cc: Martin Stiemerling , 6man WG , TSV-ART Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 16:42:03 -0000 Hi Mike, > Am 11.04.2017 um 23:31 schrieb C. M. Heard : >=20 > On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote: >> Major issues: >>=20 >> - Section 4.8. "Defining New Extension Headers and Options": >>=20 >> It says new hop-by-hop headers must never ever defined. This is = problematic, >> as this closing the door forever, even if future instances of the = IETF do >> would like to wish to define new hop-by-hop headers. A better way = would have >> to say "that new hop-by-hop headers must have IETF consensus". >=20 > If a new extension header with hop-by-hop behavior were defined, > it would require a router or other forwarding device to look > beyond the header immediately following the base IPv6 header, > possibly even arbitrarily deep into an IPv6 header chain. That's > not backward compatible with the existing specification, which was > written the way it was to limit the amount of header processing > required in the forwarding path. >=20 > Can you provide an example of anything that can be done with a > new hop-by-hop extension header that cannot also be done with > a new hop-by-hop option? Given the current hop-by-hop header is partially not usable, = everything=E2=80=A6 I thinking would be to basically replace/deprecate the old one and = define a new one. >=20 >> - Section 4.8. "Defining New Extension Headers and Options": >>=20 >> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >> especially with the phrase "There has to be a very clear = justification". The >> term "clear justification" is not an exact engineering specification. = Why >> not using "technical protocol specification and real word use case = required, >> plus IETF consensus"? >=20 > We could perhaps make this clearer by stating that a new extension > header must not be defined unless it can be proven that the desired > functionality cannot reasonably be provided either by a new > destination option or by a new upper layer protocol, but I'm not > convinced that it's that much of an improvement - there's that > pesky word "reasonably," which still implies an exercise of > engineering judgment, which you seem to want to avoid. >=20 > For a necessarily imprecise analysis of which of the existing > extension headers meet the "cannot reasonably be provided" > criterion, please see >=20 > https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html I have to say I find this phrasing also to be useful. I guess the real = point is to recommend to rather use a destination option if possible = than defining a new extension header. Mirja >=20 > Mike Heard >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Wed Apr 12 12:05:22 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0B12EB6D for ; Wed, 12 Apr 2017 12:05:21 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 qL0dD3-_NJE2 for ; Wed, 12 Apr 2017 12:05:20 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 7F04112EB53 for ; Wed, 12 Apr 2017 12:05:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id a103so54572464ioj.1 for ; Wed, 12 Apr 2017 12:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version; bh=4OxVWoMiIqWlBIzamFZTc7ImmlE1U1sg1DkmCzoHF3Q=; b=BtxQ51f+AZeBcq/FCbeYGiiTBNtZwCapdSToiHG5vPZzj23gaWLuZIo6mS4Rhg7WU3 DVmgcd2OpYFFtZQt568rMxBS04ibQ2vH08X4p4QCYbO52UDstS8lqkUBJENBhpTevLZH eW7vrPqQlXRhk+GPJeN0dlho6ej+nPyK3V3YLI3xKOJOYV0FmXCoTmgStxg+edGNlo0F o+nReOtjwoojLFgsYwd6FMivSDvaoTZrPZq0PsHAi5alKaPH5u5v91VuF9TV/8n+RiJ3 qztHTB27djbGEoAoN4LRMiNeSErTd2jD+BP0vo8CcKzhRN+2x2/LcusyFqvFxywMl995 RLTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=4OxVWoMiIqWlBIzamFZTc7ImmlE1U1sg1DkmCzoHF3Q=; b=N3oO/QGLLCTx6HmAXBGw2naTM4Kd/3w6J07l9l/7qs6MgHDIUxmEEHIRSsToDdu1oE LOqw/18ML57Vs4BSKaaqUJ152sAO2Eq2I8f64CxTHNKDhQ6DGlSQ+QCsJZn2Crh+cu5y G4oQBcFMltc+rdo+yJWXUV8YOxzPmzBiSz8rNJVHPjAeA1idRFUEtmrY6SnTcVJzauOh 0VMpxlb0JGrxeR06e6AOV3NM+eg9UT1ps/oGFcmBMVLgA+fFOtv8XllAS60+CVpHIpYd g3+eJAOZWhSFyDSkVyuZkQBQCULJMVhkvYj9dVfdYB2uHx6msPVK8ywnDrW7XEcFEj74 w33w== X-Gm-Message-State: AN3rC/42O9tM8kOEP+T0OQieodKGnc5QMhdqH9Q/sF+oGntq48bzlHzC YIhv2aznFTmPHIaHXC8= X-Received: by 10.36.82.144 with SMTP id d138mr24488636itb.24.1492023912403; Wed, 12 Apr 2017 12:05:12 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id m63sm9821883ioa.15.2017.04.12.12.05.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:05:11 -0700 (PDT) To: tsv-art@ietf.org From: Wesley Eddy Message-ID: Date: Wed, 12 Apr 2017 15:05:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0B2DE1D5C3F0FAB4B3FA22CC" Archived-At: Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 04/12 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:05:22 -0000 This is a multi-part message in MIME format. --------------0B2DE1D5C3F0FAB4B3FA22CC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi TSV-ARTists, here is my attempt at triaging the documents in last call and assigning some for review. Documents that require TSV attention: * draft-ietf-i2nsf-problem-and-use-cases (assigned to Jana -- there seem to be firewall and network flow definition concepts central to this document that may or may not have transport concerns) * draft-ietf-6man-rfc1981bis-06 (assigned to Joe -- follow-up to -04 review and discussions) Documents that do not require TSV attention (but reviews are welcome if you have bandwidth): * draft-ietf-rtgwg-yang-key-chain (mentions TCP-AO, in case someone wants to review) * draft-ietf-isis-l2bundles * draft-ietf-grow-large-communities-usage * draft-ietf-core-links-json * draft-ietf-avtcore-rfc5285-bis (several TSV people are active in AVTCORE and Magnus is shepherd) * draft-ietf-grow-bgp-reject * draft-ietf-alto-multi-cost (this is a TSV document) * --------------0B2DE1D5C3F0FAB4B3FA22CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi TSV-ARTists, here is my attempt at triaging the documents in last call and assigning some for review.

Documents that require TSV attention:

  • draft-ietf-i2nsf-problem-and-use-cases (assigned to Jana -- there seem to be firewall and network flow definition concepts central to this document that may or may not have transport concerns)
  • draft-ietf-6man-rfc1981bis-06 (assigned to Joe -- follow-up to -04 review and discussions)

Documents that do not require TSV attention (but reviews are welcome if you have bandwidth):

  • draft-ietf-rtgwg-yang-key-chain (mentions TCP-AO, in case someone wants to review)
  • draft-ietf-isis-l2bundles
  • draft-ietf-grow-large-communities-usage
  • draft-ietf-core-links-json
  • draft-ietf-avtcore-rfc5285-bis (several TSV people are active in AVTCORE and Magnus is shepherd)
  • draft-ietf-grow-bgp-reject
  • draft-ietf-alto-multi-cost (this is a TSV document)

--------------0B2DE1D5C3F0FAB4B3FA22CC-- From nobody Wed Apr 12 12:54:30 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683DC12778E; Wed, 12 Apr 2017 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6qHyUan0uq14; Wed, 12 Apr 2017 12:54:19 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 6AAE9124B0A; Wed, 12 Apr 2017 12:54:18 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id a103so56243727ioj.1; Wed, 12 Apr 2017 12:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yqt7rAVDFgHc7zMPC9M1M3o1lmeTBw8VXLPK9rUT4wQ=; b=ZcUVWm94xWz6ke+Xq/OYqgmzed8MpTfCHt64+jtbOiDNzR2PR3rRaXttRF3qYWlMOR KeAY8bNCTrN+ZH4Huv54vXD1omRSuh+yhxN+AMOYOU0UucdBkEdL+5tbMkLnlCdxvDz+ da/6Yyyk+GHQ/YJ2FehCbMtGNDhEFMLbBuSLJk7+lTkZdnOIA8e1j08tyky1C6/po/VD DG9dKmor8eMkziO00rr2AvMGUc8BfFeDtMACW7GrwGUAkCEqMLvwx1E3ZpDkchNfWCGh bhwCvE1xdEu9jA/fvl6b/hQlUE3d7qOtgSwkL5gJCpT4mzMl3uedxvZJVVS5wZSzkEYO B3tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yqt7rAVDFgHc7zMPC9M1M3o1lmeTBw8VXLPK9rUT4wQ=; b=lkVqaCHAueJKT1v2dT/hXReefMfDmdY8BdStAQTk5bnNoZoRQwOLWdL8F3y0/uYFbn YBD/inNe0oZiWTuhYMOcmO1KZ+RpjqrzGspukPgraFh/ao6OiuWaSH7je5DXMriucJwb Fs+2HI8/cXZqQLdnbyZGKsyjgUm0ahnvkARx9vUV1zEW4DOhlUUUEQ6P1+gI+b1EI3+Z oZgzWOayJ60nW9LM2c9P37IjbeOLmPJVjphRFL1/iQWFaIo57i7u30UbHm1NkcHe77KF 6TXiiOQaQdLUeLhY8a6gonx/fKmLT2hdEVWomr1vXoq9dAHRkNPyB0zGNjk/nn9uNU/N zpGg== X-Gm-Message-State: AN3rC/6A269gLotWbGR2lmUfOkzZo5GzvDMPTQ7iB6pqsa/rRZ7iHTDJ9b3VUDD9qd2Cmw== X-Received: by 10.107.20.81 with SMTP id 78mr9534100iou.219.1492026857776; Wed, 12 Apr 2017 12:54:17 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c41sm2880773itd.5.2017.04.12.12.54.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:54:17 -0700 (PDT) From: Bob Hinden Message-Id: <3016FFF1-0676-4063-A884-9AE460314A09@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 12:54:15 -0700 In-Reply-To: <1ff5b4e0-c2bb-0f00-97af-c1b888e29833@gmail.com> Cc: Bob Hinden , IPv6 List , tsv-art@ietf.org To: Martin Stiemerling References: <1ff5b4e0-c2bb-0f00-97af-c1b888e29833@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:54:21 -0000 --Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Martin, Thanks for your review. Comments below. Thanks, Bob > On Apr 11, 2017, at 12:14 PM, Martin Stiemerling = wrote: >=20 > Hi, >=20 > I've reviewed this document as part of the transport area review team = (TSV-ART) ongoing effort to review key IETF documents. These comments = were written primarily for the transport area directors, but are copied = to the document's authors for their information and to allow them to = address any issues raised. When done at the time of IETF Last Call, the = authors should consider this review together with any other last-call = comments they receive. Please always CC tsv-art@=E2=80=A6 if you reply = to or forward this review. >=20 > Sorry for being so late with the review... >=20 > Summary: > This draft has serious issues out of a transport area perspective, = described in the review, and needs to be rethought. >=20 > Major issues: >=20 > - Section 4.8. "Defining New Extension Headers and Options": >=20 > It says new hop-by-hop headers must never ever defined. This is = problematic, as this closing the door forever, even if future instances = of the IETF do would like to wish to define new hop-by-hop headers. A = better way would have to say "that new hop-by-hop headers must have IETF = consensus=E2=80=9D. I think there is a misunderstanding here. There can only be one = hop-by-hop header. It has to be the first extension header in the = packet. =46rom Section 4: The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. I think the text in Section 4.8 is correct: New extension headers that require hop-by-hop behavior must not be defined because, as specified in Section 4 of this document, the only Extension Header that has hop-by-hop behavior is the Hop-by-Hop Options header. New Hop-by-Hop header options (that go inside of a hop-by-hop header) = can be defined, but are not recommended. >=20 > - Section 4.8. "Defining New Extension Headers and Options": >=20 > Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, especially with the phrase "There has to be a = very clear justification". The term "clear justification" is not an = exact engineering specification. Why not using "technical protocol = specification and real word use case required, plus IETF consensus=E2=80=9D= ? Personally, I think the writing is clear. It does mention = standardization: There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. =E2=80=9Cstandardization=E2=80=9D implies IETF consensus, etc., etc. We could change it is "standardized in the IETF=E2=80=9D or similar. >=20 >=20 > Minor issues: >=20 > none. >=20 > Thank you, >=20 > Martin Stiemerling >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203 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 - https://gpgtools.org iQEcBAEBCgAGBQJY7oXnAAoJEK7rdBF357uoJMAIAKJEI07F98DMh9FQ16Xejk53 zZUYR9jAmhI8y3mbXryVoBz7g0mRVnncd2KB9JiHG4tzec/Ilfjf8RJRwf/itLiq F9b08F4bFlEpYqWfTvfLAuoaRzZRZSnKppNzaCrVNFThkizDUyfwtak3qGNCjmwZ /TOevQXSPyPB2k810HZI0aSUhjp++/w9VgNEyPK+xcParr+1Xsjqji1q/hS5o6xs XJ1KUfV3ldKHSpi9ouqnD/TnDq7eO6qCqqYfWJ01Lr5IgVyU9RmHBXMz5/Hwt/LY dHnzdzouIgNGfPIbDu2HIF+oePP/2phZJMBMnmv7vcwTBft/sarThWIeKeLwGUg= =KBNH -----END PGP SIGNATURE----- --Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203-- From nobody Thu Apr 20 12:31:52 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D4E1315BF; Thu, 20 Apr 2017 12:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 qfttccClCqb1; Thu, 20 Apr 2017 12:31:41 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EF21315FD; Thu, 20 Apr 2017 12:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gZQXEn5AMfW0SBRFJEmxpLjuTJxdKqTjytB5LVLRDiE=; b=SD6+8mXBtOaz/KX0yX0mbAUC9HcBxzUb79V7N2m707E74qAOVlsuq7DBrL1jOL8I9REXm2RL6FEOK54Zf8HrooN6eU5JPr5FrcdX8dokihbG9dxGXYBC/YRn9OsGvTTSFCOtmb19HV1a27pZnX+DOXMkzWT5yF1s1uTZR9GojiU= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0083.namprd21.prod.outlook.com (10.162.78.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Thu, 20 Apr 2017 19:31:38 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Thu, 20 Apr 2017 19:31:38 +0000 From: Brian Raymor To: Yoshifumi Nishida , "tsv-art@ietf.org" CC: "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Thread-Topic: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsOTWicthTbHq+0Cl6wEpb6SnVKHOtjQA Date: Thu, 20 Apr 2017 19:31:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sfc.wide.ad.jp; dkim=none (message not signed) header.d=none;sfc.wide.ad.jp; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0083; 7:rWzV/MddUNs53nBT3v6eGgbIIJPr5ZooUjY/MeGMkEDdnhAHkAeKvWBaM3vIv0cezKcqstjTqSUfN0du9Mtvhk3B7rx2cl0LMo3CuYX9Dh8odSWtHv72Ve0ATl7skOsq+VHXhvN+SyASxUOHRTTVizyjjPirFFmU+3K3yItnGeIGYgfy4cJ9KhFxNpHvrwj54fQrUwzGEhwoA98fjMp8DPeMx7lv+9xyr3ORNkWWW40gojujKt4mBaIMMMOVdvcg9S9TA4kbXt3Im1issFqb3scQlYbhcfL9X6LzqMwQsyCzf0qwZ2WmvGeZMNtKCvlqSgmNdJSZhv0ooxyns9/GFn5J4mNizUL6gaS0Zpzy9oo= x-ms-office365-filtering-correlation-id: de05cb43-ed75-4b8d-6352-08d48823dd64 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR21MB0083; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123558043)(201703131423075)(201702281528075)(201703061421075)(201703061406096)(20161123564025)(20161123560025)(6072148); SRVR:BY2PR21MB0083; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0083; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39860400002)(39450400003)(39400400002)(39840400002)(6436002)(6116002)(50986999)(55016002)(54906002)(74316002)(99286003)(38730400002)(6506006)(66066001)(4326008)(6246003)(2900100001)(53936002)(76176999)(9686003)(8676002)(6306002)(8936002)(81166006)(54356999)(3846002)(7736002)(7696004)(5660300001)(305945005)(25786009)(102836003)(2950100002)(77096006)(10090500001)(5005710100001)(33656002)(86362001)(3660700001)(2906002)(3280700002)(2501003)(122556002)(189998001)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0083; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 19:31:38.2636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0083 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 19:31:44 -0000 DQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suDQoNCj4gMTogSXQgaXMgbm90IGNsZWFyIGhvdyB0 aGUgcHJvdG9jb2wgcmVhY3RzIHRoZSBlcnJvcnMgZnJvbSB0cmFuc3BvcnQgbGF5ZXJzIChlLmcu IGNvbm5lY3Rpb24gZmFpbHVyZSkuDQo+ICAgIFRoZSBwcm90b2NvbCB3aWxsIGp1c3QgaW5mb3Jt IGFwcHMgb2YgdGhlIGV2ZW50cyBhbmQgdGhlIGFwcCB3aWxsIGRlY2lkZSB3aGF0IHRvIGRvIG9y IHRoZSBwcm90b2NvbCBpdHNlbGYgd2lsbCBkbyBzb21ldGhpbmc/DQoNClRoZSBXZWJTb2NrZXRz IGNhc2UgaXMgYWRkcmVzc2VkIGJ5IFJGQzY0NTU6DQoNCiAgIFdoZW4gdGhlIHVuZGVybHlpbmcg VENQIGNvbm5lY3Rpb24gaXMgY2xvc2VkLCBpdCBpcyBzYWlkIHRoYXQgX1RoZQ0KICAgV2ViU29j a2V0IENvbm5lY3Rpb24gaXMgQ2xvc2VkXyBhbmQgdGhhdCB0aGUgV2ViU29ja2V0IGNvbm5lY3Rp b24gaXMNCiAgIGluIHRoZSBDTE9TRUQgc3RhdGUuICBJZiB0aGUgVENQIGNvbm5lY3Rpb24gd2Fz IGNsb3NlZCBhZnRlciB0aGUNCiAgIFdlYlNvY2tldCBjbG9zaW5nIGhhbmRzaGFrZSB3YXMgY29t cGxldGVkLCB0aGUgV2ViU29ja2V0IGNvbm5lY3Rpb24NCiAgIGlzIHNhaWQgdG8gaGF2ZSBiZWVu IGNsb3NlZCBfY2xlYW5seV8uDQoNCi1hbmQtDQoNCiAgIElmIGF0IGFueSBwb2ludCB0aGUgdW5k ZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgY29ubmVjdGlvbiBpcw0KICAgdW5leHBlY3RlZGx5IGxv c3QsIHRoZSBjbGllbnQgTVVTVCBfRmFpbCB0aGUgV2ViU29ja2V0IENvbm5lY3Rpb25fLg0KDQpJ dCdzIHBvc3NpYmxlIHRvIGFkZCBsYW5ndWFnZSBzaW1pbGFyIHRvIHRoZSBhYm9ydCBjYXNlLCBh bG9uZyB0aGUgbGluZXMgb2YgIldoZW4gdGhlIHVuZGVybHlpbmcgVENQIGNvbm5lY3Rpb24gaXMg Y2xvc2VkIG9yIHJlc2V0LCB0aGUgQ29BUCBjb25uZWN0aW9uIGlzIGNsb3NlZCBhbmQgaW4gZmxp Z2h0IG1lc3NhZ2VzIG1heSBiZSBsb3N0Ii4NCg0KPiAyOiBUaGVyZSB3aWxsIGJlIHNpdHVhdGlv bnMgd2hlcmUgdGhlIGFwcCBsYXllciBpcyBmcmVlemluZyB3aGlsZSB0aGUgDQo+IHRyYW5zcG9y dCBsYXllciBpcyBzdGlsbCB3b3JraW5nLiBTaW5jZSB0cmFuc3BvcnQgbGF5ZXJzIGNhbm5vdCBk ZXRlY3QgDQo+IHRoaXMgdHlwZSBvZiBmYWlsdXJlcywgdGhlcmUgc2hvdWxkIGJlIHNvbWUgbWVj aGFuaXNtcyBmb3IgaXQgc29tZXdoZXJlIGluIHRoZSBwcm90b2NvbCBvciBpbiB0aGUgYXBwIGxh eWVyLiAgVGhlIGRvYyBuZWVkcyB0byBhZGRyZXNzDQo+IHRoaXMgcG9pbnQuIEZvciBleGFtcGxl LCB3aGF0IHdpbGwgaGFwcGVuIHdoZW4gYSBQT05HIG1lc3NhZ2UgaXMgbm90IHJldHVybmVkIGZv ciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWU/DQoNClBPTkcgaXMgbW9kZWxlZCBvbiBzaW1pbGFy IG1lY2hhbmlzbXMgaW4gUkZDNjQ1NSBhbmQgUkZDNzU0MC4gTmVpdGhlciBwcm92aWRlcyBhbnkg Z3VpZGFuY2UgZm9yIHRoaXMgY2FzZS4gSXQncyBleHBlY3RlZCB0aGF0IGFuIGFwcGxpY2F0aW9u IGZyYW1ld29yayB3b3VsZCBkZWZpbmUgYW5kIGVuZm9yY2UgdGhlIGFwcHJvcHJpYXRlIHBvbGlj eSBmb3IgdGltZW91dHMgb3IgcmV0cmllcy4NCiANCj4gMzogU2luY2UgdGhpcyBkcmFmdCBkZWZp bmVzIG5ldyBTWlggdmFsdWUsIEkgdGhpbmsgdGhlIGRvYyBuZWVkcyB0byB1cGRhdGUgUkZDNzk1 OS4gVGhpcyBwb2ludCBzaG91bGQgYmUgY2xhcmlmaWVkIG1vcmUgaW4gdGhlIGRvYy4NCg0KQ2Fy c3RlbiByZXNwb25kZWQgdG8gdGhpcyBpc3N1ZSBhbmQgdGhlIGZpbmFsIGV4Y2hhbmdlIGlzIGhl cmUgLSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9t c2cwODU2Mi5odG1sIA0KDQpNeSBzZW5zZSBpcyB0aGF0IHdlIHNob3VsZCB0cmVhdCB0aGlzIGFz IGFuIHVwZGF0ZSB0byBSRkM3OTU5IGJhc2VkIG9uIHRoZSBvcmlnaW5hbCBsYW5ndWFnZToNCg0K ICAgICBUaGUgdmFsdWUgNyBmb3IgU1pYICh3aGljaCB3b3VsZA0KICAgICAgaW5kaWNhdGUgYSBi bG9jayBzaXplIG9mIDIwNDgpIGlzIHJlc2VydmVkLCBpLmUuLCBNVVNUIE5PVCBiZSBzZW50DQog ICAgICBhbmQgTVVTVCBsZWFkIHRvIGEgNC4wMCBCYWQgUmVxdWVzdCByZXNwb25zZSBjb2RlIHVw b24gcmVjZXB0aW9uDQogICAgICBpbiBhIHJlcXVlc3QuDQoNCmFuZCB0aGUgdXNlIG9mICJleHRl bnNpb24iIGluIGNvYXAtdGNwLXRsczoNCg0KICAgIFRoZSDigJlCbG9jay13aXNlIEV4dGVuc2lv biBmb3IgUmVsaWFibGUgVHJhbnNwb3J0IChCRVJUKeKAmSBleHRlbmRzIHRoZSBCbG9jayBwcm90 b2NvbA0KICAgIHRvIGVuYWJsZSB0aGUgdXNlIG9mIGxhcmdlciBtZXNzYWdlcyBvdmVyIGEgcmVs aWFibGUgdHJhbnNwb3J0Lg0KDQpUaGUgZXhpc3RpbmcgSUFOQSBlbnRyaWVzIGZvciBCbG9jazEg YW5kIEJsb2NrMiB3aWxsIGFsc28gbmVlZCB0byByZWZlcmVuY2UgY29hcC10Y3AtdGxzIGluIGFk ZGl0aW9uIHRvIFJGQzc5NTkuDQoNClRyYWNraW5nIGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTI5DQoNCg0K From nobody Thu Apr 20 22:18:28 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B50129462 for ; Thu, 20 Apr 2017 22:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no 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 pAhAjbXeeGsE for ; Thu, 20 Apr 2017 22:18:26 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0032B12940F for ; Thu, 20 Apr 2017 22:18:25 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 37D7919F36D; Fri, 21 Apr 2017 13:08:43 +0800 (HKT) Message-ID: From: "weigengyu" To: "Brian Raymor" , "Yoshifumi Nishida" , Cc: , , References: In-Reply-To: Date: Fri, 21 Apr 2017 13:08:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 05:18:27 -0000 Hi， > It's possible to add language similar to the abort case, along the lines > of "When the underlying TCP connection is closed or reset, > the CoAP connection is closed and in flight messages may be lost". It is not necessary when CoAP over WEBSocket is concerned, I think. By the API or the interface, CoAP only interacts with WEB socket, does not need to touch issues of TCP. CoAP would react to the events of WebSokcet. But, issues on TCP should be concerned if it is CoAP over TCP. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Brian Raymor Sent: Friday, April 21, 2017 3:31 AM To: Yoshifumi Nishida ; tsv-art@ietf.org Cc: draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf.org ; ietf@ietf.org Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thanks for your feedback. > 1: It is not clear how the protocol reacts the errors from transport > layers (e.g. connection failure). > The protocol will just inform apps of the events and the app will > decide what to do or the protocol itself will do something? The WebSockets case is addressed by RFC6455: When the underlying TCP connection is closed, it is said that _The WebSocket Connection is Closed_ and that the WebSocket connection is in the CLOSED state. If the TCP connection was closed after the WebSocket closing handshake was completed, the WebSocket connection is said to have been closed _cleanly_. -and- If at any point the underlying transport layer connection is unexpectedly lost, the client MUST _Fail the WebSocket Connection_. It's possible to add language similar to the abort case, along the lines of "When the underlying TCP connection is closed or reset, the CoAP connection is closed and in flight messages may be lost". > 2: There will be situations where the app layer is freezing while the > transport layer is still working. Since transport layers cannot detect > this type of failures, there should be some mechanisms for it somewhere in > the protocol or in the app layer. The doc needs to address > this point. For example, what will happen when a PONG message is not > returned for a certain amount of time? PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither provides any guidance for this case. It's expected that an application framework would define and enforce the appropriate policy for timeouts or retries. > 3: Since this draft defines new SZX value, I think the doc needs to update > RFC7959. This point should be clarified more in the doc. Carsten responded to this issue and the final exchange is here - https://www.ietf.org/mail-archive/web/core/current/msg08562.html My sense is that we should treat this as an update to RFC7959 based on the original language: The value 7 for SZX (which would indicate a block size of 2048) is reserved, i.e., MUST NOT be sent and MUST lead to a 4.00 Bad Request response code upon reception in a request. and the use of "extension" in coap-tcp-tls: The ’Block-wise Extension for Reliable Transport (BERT)’ extends the Block protocol to enable the use of larger messages over a reliable transport. The existing IANA entries for Block1 and Block2 will also need to reference coap-tcp-tls in addition to RFC7959. Tracking in https://github.com/core-wg/coap-tcp-tls/issues/129 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Apr 21 01:25:55 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB71288B8; Fri, 21 Apr 2017 01:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8gs9nIIjJ9cq; Fri, 21 Apr 2017 01:25:46 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDF4126CC7; Fri, 21 Apr 2017 01:25:45 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A4B8A279C66; Fri, 21 Apr 2017 17:25:43 +0900 (JST) Received: by mail-oi0-f49.google.com with SMTP id y11so52400910oie.0; Fri, 21 Apr 2017 01:25:43 -0700 (PDT) X-Gm-Message-State: AN3rC/6396mJRhNyNXJaX0mk76s/nsdo1daScsz1xO/XHW7B959kPIE/ 4EtjqIYIFCOwOKqN5eujEl5/h8Txbw== X-Received: by 10.202.97.85 with SMTP id v82mr7096714oib.214.1492763139122; Fri, 21 Apr 2017 01:25:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Fri, 21 Apr 2017 01:25:38 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 21 Apr 2017 01:25:38 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a113d45f4a42cd6054da900d7 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 08:25:48 -0000 --001a113d45f4a42cd6054da900d7 Content-Type: text/plain; charset=UTF-8 Hi Brian, On Thu, Apr 20, 2017 at 12:31 PM, Brian Raymor wrote: > > Thanks for your feedback. > > > 1: It is not clear how the protocol reacts the errors from transport > layers (e.g. connection failure). > > The protocol will just inform apps of the events and the app will > decide what to do or the protocol itself will do something? > > The WebSockets case is addressed by RFC6455: > > When the underlying TCP connection is closed, it is said that _The > WebSocket Connection is Closed_ and that the WebSocket connection is > in the CLOSED state. If the TCP connection was closed after the > WebSocket closing handshake was completed, the WebSocket connection > is said to have been closed _cleanly_. > > -and- > > If at any point the underlying transport layer connection is > unexpectedly lost, the client MUST _Fail the WebSocket Connection_. > > It's possible to add language similar to the abort case, along the lines > of "When the underlying TCP connection is closed or reset, the CoAP > connection is closed and in flight messages may be lost". > OK. I also think we should state that the protocol should notify the failure events to applications. Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not be enough. > > > 2: There will be situations where the app layer is freezing while the > > transport layer is still working. Since transport layers cannot detect > > this type of failures, there should be some mechanisms for it somewhere > in the protocol or in the app layer. The doc needs to address > > this point. For example, what will happen when a PONG message is not > returned for a certain amount of time? > > PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither > provides any guidance for this case. It's expected that an application > framework would define and enforce the appropriate policy for timeouts or > retries. > The figure 1 in the draft indicates that this draft and RFC7252 are in the same level. So, I am looking at this draft and 7252. When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol provides such things. However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that there need to be some guidance here. BTW, PONG is one example. > > 3: Since this draft defines new SZX value, I think the doc needs to > update RFC7959. This point should be clarified more in the doc. > > Carsten responded to this issue and the final exchange is here - > https://www.ietf.org/mail-archive/web/core/current/msg08562.html > > My sense is that we should treat this as an update to RFC7959 based on the > original language: > > I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people. Thanks, -- Yoshi --001a113d45f4a42cd6054da900d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Thu, Apr 20, 2017 at 12:31 PM, Brian Raymor <Bri= an.Raymor@microsoft.com> wrote:

Thanks for your feedback.

> 1: It is not clear how the protocol reacts the errors from transport l= ayers (e.g. connection failure).
>=C2=A0 =C2=A0 The protocol will just inform apps of the events and the = app will decide what to do or the protocol itself will do something?

The WebSockets case is addressed by RFC6455:

=C2=A0 =C2=A0When the underlying TCP connection is closed, it is said that = _The
=C2=A0 =C2=A0WebSocket Connection is Closed_ and that the WebSocket connect= ion is
=C2=A0 =C2=A0in the CLOSED state.=C2=A0 If the TCP connection was closed af= ter the
=C2=A0 =C2=A0WebSocket closing handshake was completed, the WebSocket conne= ction
=C2=A0 =C2=A0is said to have been closed _cleanly_.

-and-

=C2=A0 =C2=A0If at any point the underlying transport layer connection is =C2=A0 =C2=A0unexpectedly lost, the client MUST _Fail the WebSocket Connect= ion_.

It's possible to add language similar to the abort case, along the line= s of "When the underlying TCP connection is closed or reset, the CoAP = connection is closed and in flight messages may be lost".

OK. I also think we should state that the protocol = should notify the failure events to applications.=C2=A0
Since err= ors can happen not only in TCP, but also TLS and websocket level, mentionin= g only TCP close or reset might not be enough.
=C2=A0

> 2: There will be situations where the app layer is freezing while the<= br> > transport layer is still working. Since transport layers cannot detect=
> this type of failures, there should be some mechanisms for it somewher= e in the protocol or in the app layer.=C2=A0 The doc needs to address
> this point. For example, what will happen when a PONG message is not r= eturned for a certain amount of time?

PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neithe= r provides any guidance for this case. It's expected that an applicatio= n framework would define and enforce the appropriate policy for timeouts or= retries.

The figure 1 in the draft ind= icates that this draft and RFC7252 are in the same level.
So, I a= m looking at this draft and 7252.=C2=A0
When we use 7252, I think= applications basically don't need to implement timeouts or retry mecha= nisms as the protocol provides such things.=C2=A0
However, when w= e use this one, it seems applications will need to have such mechanisms. Is= n't it a bit confusing? I am thinking that there need to be some guidan= ce here.
BTW, PONG is one example.=C2=A0


> 3: Since this draft defines new SZX value, I think the doc needs to up= date RFC7959. This point should be clarified more in the doc.

Carsten responded to this issue and the final exchange is here - https://www.ietf.org/mail-archive/= web/core/current/msg08562.html

My sense is that we should treat this as an update to RFC7959 based on the = original language:

I don't have a strong opini= on here. Updating 7959 is fine for me if it's clearer to CoAP people.

Thanks,
--
Yoshi=C2=A0


--001a113d45f4a42cd6054da900d7-- From nobody Fri Apr 21 11:16:00 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1512EAAF; Fri, 21 Apr 2017 11:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 GVp5ZPV_J0TA; Fri, 21 Apr 2017 11:15:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A386B129B31; Fri, 21 Apr 2017 11:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/VZ5UsaK7vLD4NN+KKgNG84lH2X7MR+V4XHDq6pQ1Z8=; b=dqtqqR4Vy/z2qdG9Thi8Dy2l+mCZxv5hnL/it86gAxt74iuS/iMlmAcO3bpPVkzMQY2ivOOtHafnacfeU0q1udO6fSOlA3IM3wjhnYeXL4jLB16WmZ7W6/zFbGa7SJN/axuy+R1S4cphDFcqmLy0SwH+QyKmMCEBUqrJYoj71qo= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0081.namprd21.prod.outlook.com (10.162.78.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Fri, 21 Apr 2017 18:15:41 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Fri, 21 Apr 2017 18:15:41 +0000 From: Brian Raymor To: Yoshifumi Nishida CC: "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Thread-Topic: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsOTWicthTbHq+0Cl6wEpb6SnVKHOtjQAgADZuACAAKJUUA== Date: Fri, 21 Apr 2017 18:15:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sfc.wide.ad.jp; dkim=none (message not signed) header.d=none;sfc.wide.ad.jp; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0081; 7:qfCLDnaB8/U9ttbrq86XBAMJRHA+UXepMmUysJRHVSqaxY9gk7mTbF8siP2YSAMCgyUr8Fba8vb9ATo4JDGeqamPlbQZjBCPGeK0l5bhoBx+gPeW3YzLYVfzwgq6e2oHbNNaJFUiX8csdV4IRo5vvmgoAMzNFSXtoTsw6c/+2xhP1DqfVhHmuQPV3GcUR4LJVNKt/tQZtU7TRgoybyRE2daHmpn4GcnPC/Br857L++1KRFez+7/n5YZfUFuzAbe1FY06W9sacWAGeLze29gcEMMfuQLKs59numfvJTM2NM2h7s0fRqXQNvOwlhBd51cgMLIFKJ78pH4qCZKyvIS2A1BV1l5yilEb3SDVs9SItPI= x-ms-office365-filtering-correlation-id: eaef3a27-4556-4407-68e1-08d488e26bb7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR21MB0081; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558055)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406108)(20161123555025)(20161123560025)(6072148); SRVR:BY2PR21MB0081; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0081; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(39400400002)(43784003)(86362001)(2950100002)(102836003)(6916009)(6246003)(4326008)(7696004)(74316002)(38730400002)(110136004)(7906003)(230783001)(229853002)(33656002)(7736002)(122556002)(54356999)(5660300001)(790700001)(6116002)(76176999)(3846002)(189998001)(50986999)(9686003)(10090500001)(55016002)(66066001)(6306002)(54896002)(99286003)(54906002)(53936002)(2906002)(3280700002)(25786009)(236005)(606005)(8936002)(8676002)(81166006)(9326002)(3660700001)(6506006)(77096006)(6436002)(10290500002)(5005710100001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0081; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 18:15:41.3988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0081 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 18:15:46 -0000 --_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNCg0KDQo+IE9LLiBJIGFsc28gdGhpbmsgd2Ugc2hvdWxkIHN0YXRlIHRoYXQg dGhlIHByb3RvY29sIHNob3VsZCBub3RpZnkgdGhlIGZhaWx1cmUgZXZlbnRzIHRvIGFwcGxpY2F0 aW9ucy4NCg0KPiBTaW5jZSBlcnJvcnMgY2FuIGhhcHBlbiBub3Qgb25seSBpbiBUQ1AsIGJ1dCBh bHNvIFRMUyBhbmQgd2Vic29ja2V0IGxldmVsLCBtZW50aW9uaW5nIG9ubHkgVENQIGNsb3NlIG9y IHJlc2V0IG1pZ2h0IG5vdA0KDQo+IGJlIGVub3VnaC4NCg0KDQoNCkFmdGVyIHJldmlld2luZyB3 aXRoIHRoZSBhdXRob3JzLCBhbiBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24gd2FzIGFwcGVuZGVk IHRvIDMuNCBDb25uZWN0aW9uIEhlYWx0aCAtIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2Nv YXAtdGNwLXRscy9wdWxsLzE0MC9maWxlcw0KDQoNCg0KVGhlIG9waW5pb24gb2YgdGhlIGF1dGhv cnMgKGFuZCBHZW5neXUgV0VJ4oCZcyByZWNlbnQgcmVzcG9uc2UgLSBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sKSBpcyB0aGF0 IFJGQzY0NTUgY292ZXJzIHRoZSBXZWJTb2NrZXQgY2FzZSBhbmQgZG9lcyBub3QgbmVlZCB0byBi ZSByZXBlYXRlZCBoZXJlLg0KDQoNCg0KPiBXaGVuIHdlIHVzZSA3MjUyLCBJIHRoaW5rIGFwcGxp Y2F0aW9ucyBiYXNpY2FsbHkgZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgdGltZW91dHMgb3IgcmV0 cnkgbWVjaGFuaXNtcyBhcyB0aGUgcHJvdG9jb2wNCg0KPiBwcm92aWRlcyBzdWNoIHRoaW5ncy4N Cg0KDQoNClJGQzcyNTIgcHJvdmlkZXMgdGltZW91dHMgYW5kIHJldHJpZXMgYmVjYXVzZSBpdCdz IGltcGxlbWVudGluZyBhIFRDUC1saWtlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbSBvdmVyIFVEUCAt IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMi4xDQoNCg0KDQo+ IEhvd2V2ZXIsIHdoZW4gd2UgdXNlIHRoaXMgb25lLCBpdCBzZWVtcyBhcHBsaWNhdGlvbnMgd2ls bCBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5pc21zLiBJc24ndCBpdCBhIGJpdCBjb25mdXNpbmc/ IEkgYW0gdGhpbmtpbmcgdGhhdA0KDQo+IHRoZXJlIG5lZWQgdG8gYmUgc29tZSBndWlkYW5jZSBo ZXJlLg0KDQo+IEJUVywgUE9ORyBpcyBvbmUgZXhhbXBsZS4NCg0KDQoNCkZvciBjb2FwLXRjcC10 bHMsIHRoZXJlIGFyZSBtdWx0aXBsZSBlYXJseSBpbXBsZW1lbnRhdGlvbnMuIFRoaXMgaGFzIG5l dmVyIGJlZW4gcmVwb3J0ZWQgYXMgYSBzb3VyY2Ugb2YgY29uZnVzaW9uLg0KDQoNCg0KPj4gTXkg c2Vuc2UgaXMgdGhhdCB3ZSBzaG91bGQgdHJlYXQgdGhpcyBhcyBhbiB1cGRhdGUgdG8gUkZDNzk1 OSBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2U6DQoNCj4gSSBkb24ndCBoYXZlIGEgc3Ry b25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5lIGZvciBtZSBpZiBpdCdzIGNs ZWFyZXIgdG8gQ29BUCBwZW9wbGUuDQoNCg0KDQpJJ3ZlIG1lcmdlZCB0aGUgY2hhbmdlIC0gaHR0 cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTM4L2ZpbGVzDQoNCg0K VGhhbmtzIGFnYWluIGZvciBoZWxwaW5nIHVzIHRvIGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgdGhl IGRyYWZ0LA0KDQrigKZCcmlhbg0K --_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkgWW9zaGksPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT0suIEkgYWxzbyB0aGluayB3ZSBzaG91bGQgc3Rh dGUgdGhhdCB0aGUgcHJvdG9jb2wgc2hvdWxkIG5vdGlmeSB0aGUgZmFpbHVyZSBldmVudHMgdG8g YXBwbGljYXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBTaW5jZSBlcnJvcnMgY2FuIGhhcHBlbiBub3Qgb25seSBpbiBUQ1AsIGJ1dCBhbHNv IFRMUyBhbmQgd2Vic29ja2V0IGxldmVsLCBtZW50aW9uaW5nIG9ubHkgVENQIGNsb3NlIG9yIHJl c2V0IG1pZ2h0IG5vdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGJlIGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWZ0ZXIgcmV2aWV3 aW5nIHdpdGggdGhlIGF1dGhvcnMsIGFuIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbiB3YXMgYXBw ZW5kZWQgdG8gMy40IENvbm5lY3Rpb24gSGVhbHRoIC0NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9wdWxsLzE0MC9maWxlcyI+aHR0cHM6Ly9naXRodWIu Y29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTQwL2ZpbGVzPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGUgb3BpbmlvbiBvZiB0aGUgYXV0aG9ycyAoYW5kIEdlbmd5dSBX RUnigJlzIHJlY2VudCByZXNwb25zZSAtDQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sPC9hPikg aXMgdGhhdCBSRkM2NDU1IGNvdmVycyB0aGUgV2ViU29ja2V0IGNhc2UgYW5kIGRvZXMgbm90IG5l ZWQgdG8gYmUgcmVwZWF0ZWQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBXaGVuIHdlIHVzZSA3MjUyLCBJIHRoaW5rIGFwcGxpY2F0aW9ucyBiYXNpY2FsbHkgZG9uJ3Qg bmVlZCB0byBpbXBsZW1lbnQgdGltZW91dHMgb3IgcmV0cnkgbWVjaGFuaXNtcyBhcyB0aGUgcHJv dG9jb2w8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcHJvdmlk ZXMgc3VjaCB0aGluZ3MuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SRkM3MjUyIHBy b3ZpZGVzIHRpbWVvdXRzIGFuZCByZXRyaWVzIGJlY2F1c2UgaXQncyBpbXBsZW1lbnRpbmcgYSBU Q1AtbGlrZSByZWxpYWJpbGl0eSBtZWNoYW5pc20gb3ZlciBVRFAgLQ0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2VjdGlvbi0yLjEiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEhvd2V2ZXIsIHdoZW4gd2UgdXNlIHRoaXMgb25lLCBpdCBzZWVtcyBh cHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5pc21zLiBJc24ndCBpdCBh IGJpdCBjb25mdXNpbmc/IEkgYW0gdGhpbmtpbmcgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGVyZSBuZWVkIHRvIGJlIHNvbWUgZ3VpZGFuY2UgaGVy ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQlRXLCBQT05H IGlzIG9uZSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Gb3IgY29hcC10 Y3AtdGxzLCB0aGVyZSBhcmUgbXVsdGlwbGUgZWFybHkgaW1wbGVtZW50YXRpb25zLiBUaGlzIGhh cyBuZXZlciBiZWVuIHJlcG9ydGVkIGFzIGEgc291cmNlIG9mIGNvbmZ1c2lvbi4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBNeSBzZW5zZSBpcyB0aGF0IHdlIHNob3Vs ZCB0cmVhdCB0aGlzIGFzIGFuIHVwZGF0ZSB0byBSRkM3OTU5IGJhc2VkIG9uIHRoZSBvcmlnaW5h bCBsYW5ndWFnZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg SSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5l IGZvciBtZSBpZiBpdCdzIGNsZWFyZXIgdG8gQ29BUCBwZW9wbGUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkndmUgbWVyZ2VkIHRoZSBjaGFuZ2UgLSA8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvcHVsbC8xMzgvZmlsZXMiPg0KaHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTM4L2ZpbGVzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBhZ2FpbiBmb3IgaGVs cGluZyB1cyB0byBpbXByb3ZlIHRoZSBxdWFsaXR5IG9mIHRoZSBkcmFmdCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+4oCmQnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR21MB00849DB795086F08F6D7A98A831A0BY2PR21MB0084namp_-- From nobody Fri Apr 21 14:08:16 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6F1129479; Fri, 21 Apr 2017 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ahQJJ6NZu6_S; Fri, 21 Apr 2017 14:07:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C25128B44; Fri, 21 Apr 2017 14:07:56 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 30195279D8E; Sat, 22 Apr 2017 06:07:54 +0900 (JST) Received: by mail-oi0-f48.google.com with SMTP id x184so112867488oia.1; Fri, 21 Apr 2017 14:07:54 -0700 (PDT) X-Gm-Message-State: AN3rC/6vOngQAXDkGNCJhPiowtR0CAmuNZcCGZ/dXd6RBnVt/7rUy+YN DHiFeUG4clDLVb8RwnaykgToU2grPw== X-Received: by 10.157.40.87 with SMTP id h23mr9949234otd.274.1492808872850; Fri, 21 Apr 2017 14:07:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Fri, 21 Apr 2017 14:07:52 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 21 Apr 2017 14:07:52 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a11396afc957e3a054db3a6cc Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 21:07:59 -0000 --001a11396afc957e3a054db3a6cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Just in case, Reliable transports only provide reliability at transport level. It doesn't provide reliability in application protocol level. RFC7252 has reliability mechanisms in it since it uses UDP. This means it has abilities to check both transport and app level reliability. This draft only provides transport level reliability and apps will need to detect app protocol failure by themselves. This means 7252 and this draft are not totally equivalent from the viewpoint of applications. I am not saying this is wrong or bad, but I believe app developer should aware this point. -- Yoshi On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor wrote: > Hi Yoshi, > > > > > OK. I also think we should state that the protocol should notify the > failure events to applications. > > > Since errors can happen not only in TCP, but also TLS and websocket > level, mentioning only TCP close or reset might not > > > be enough. > > > > After reviewing with the authors, an additional clarification was appende= d > to 3.4 Connection Health - https://github.com/core-wg/ > coap-tcp-tls/pull/140/files > > > > The opinion of the authors (and Gengyu WEI=E2=80=99s recent response - > https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that > RFC6455 covers the WebSocket case and does not need to be repeated here. > > > > > When we use 7252, I think applications basically don't need to implemen= t > timeouts or retry mechanisms as the protocol > > > provides such things. > > > > RFC7252 provides timeouts and retries because it's implementing a TCP-lik= e > reliability mechanism over UDP - https://tools.ietf.org/html/ > rfc7252#section-2.1 > > > > > However, when we use this one, it seems applications will need to have > such mechanisms. Isn't it a bit confusing? I am thinking that > > > there need to be some guidance here. > > > BTW, PONG is one example. > > > > For coap-tcp-tls, there are multiple early implementations. This has neve= r > been reported as a source of confusion. > > > > >> My sense is that we should treat this as an update to RFC7959 based on > the original language: > > > I don't have a strong opinion here. Updating 7959 is fine for me if it'= s > clearer to CoAP people. > > > > I've merged the change - https://github.com/core-wg/ > coap-tcp-tls/pull/138/files > > > > Thanks again for helping us to improve the quality of the draft, > > > > =E2=80=A6Brian > --001a11396afc957e3a054db3a6cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Just in case,
Relia= ble transports only provide reliability at transport level. It doesn't = provide reliability in application protocol level.=C2=A0

RFC7252 has reliability mechanisms in it since it uses UDP. This mea= ns it has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will ne= ed to detect app protocol failure by themselves.=C2=A0
This means= 7252 and this draft are not totally equivalent from the viewpoint of appli= cations.=C2=A0

I am not saying this is wrong or ba= d, but I believe app developer should aware this point.
--
Yoshi

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <= ;Brian.Raym= or@microsoft.com> wrote:

Hi Yoshi,

=C2=A0<= /p>

> OK. I also think= we should state that the protocol should notify the failure events to appl= ications.=C2=A0

> Since errors can= happen not only in TCP, but also TLS and websocket level, mentioning only = TCP close or reset might not

> be enough.

=C2=A0<= /p>

After reviewin= g with the authors, an additional clarification was appended to 3.4 Connect= ion Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files=

=C2=A0<= /p>

The opinion of the au= thors (and Gengyu WEI=E2=80=99s recent response - https://www.ietf.org/mail-archive/web/core/current= /msg08622.html) is that RFC6455 covers the WebSocket case and does= not need to be repeated here.

=C2=A0<= /p>

> When we use 7252= , I think applications basically don't need to implement timeouts or re= try mechanisms as the protocol

> provides such th= ings.

=C2=A0<= /p>

RFC7252 provid= es timeouts and retries because it's implementing a TCP-like reliabilit= y mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

=C2=A0<= /p>

> However, when we= use this one, it seems applications will need to have such mechanisms. Isn= 't it a bit confusing? I am thinking that

> there need to be= some guidance here.

> BTW, PONG is one= example.

=C2=A0<= /p>

For coap-tcp-t= ls, there are multiple early implementations. This has never been reported = as a source of confusion.

=C2=A0<= /p>

>> My sense is = that we should treat this as an update to RFC7959 based on the original lan= guage:

> I don't have= a strong opinion here. Updating 7959 is fine for me if it's clearer to= CoAP people.

=C2=A0<= /p>

I've merge= d the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

=C2=A0<= /p>

Thanks again for helping us to improve the quality of the draft,<= span class=3D"gmail-HOEnZb">

=C2=A0

=E2=80=A6Brian


--001a11396afc957e3a054db3a6cc-- From nobody Fri Apr 21 14:58:30 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AC0128896; Fri, 21 Apr 2017 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 v8M7J2GgLu_N; Fri, 21 Apr 2017 14:58:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0137.outbound.protection.outlook.com [104.47.38.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786AC127419; Fri, 21 Apr 2017 14:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RCNcGBcpFMFACwUzgRWino9j/YiAC0OIqEzpt7Mk0q8=; b=QlBZJCF597JET/z8/JXFo4r92pAerWliExHW561i1rm6G+hOZCSJeB/ltKB8tpykewXM1KZUiwJjh+oiv273hnehCpsQUPnfPAPzFR3sPW+7Acr7fKqyXwh40MOBm3HiCuxU6OPWyTmVrPXk5C/a0mP0ZZvL01xwApOvKnkv/CA= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0083.namprd21.prod.outlook.com (10.162.78.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Fri, 21 Apr 2017 21:57:39 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Fri, 21 Apr 2017 21:57:39 +0000 From: Brian Raymor To: Yoshifumi Nishida CC: "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Thread-Topic: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsOTWicthTbHq+0Cl6wEpb6SnVKHOtjQAgADZuACAAKJUUIAAMqMAgAADmmA= Date: Fri, 21 Apr 2017 21:57:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0083; 7:SUyyCBTp6tIPDmMkBxW3jAig8ww5pYu2G79NPVVNK1yBkyOowbioy+N+Xf618XodNeWh5DuwyqEAztWNW+TqU+98EWQvilEXXUskZdQych/mntocKRsqi/3jbXi/mYQAYub6rUWyAtmwS2i2vwle8KVWu9rdph0gGWD1tfYyqYTYtggO4NtncBGx5YX0YQECDeeSNIuKHg8zQ0Q/uMvZBjF+uKg6/kDbWzM4I02co41tq9pgyVRf+pDoKw672+xVXFf2MyGqpnpcEP+EXTYeR2LYZTJQEKwMM1EWsj+hCgw1dIF2+pSoIpjGy+zraJSF/FPaho6wFZ+uO4NgyDdmmCFAg4Cts9m1WFVqqi8tUUs= x-ms-office365-filtering-correlation-id: 76a0f5b2-64ee-453c-8300-08d489016d76 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR21MB0083; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(43784003)(51444003)(377454003)(199003)(189002)(24454002)(3660700001)(230783001)(10290500002)(6436002)(189998001)(86612001)(5005710100001)(7696004)(105586002)(6506006)(6246003)(77096006)(4326008)(74316002)(86362001)(3280700002)(5660300001)(110136004)(7736002)(76176999)(54356999)(236005)(50986999)(101416001)(33656002)(7906003)(8990500004)(2900100001)(9686003)(97736004)(229853002)(606005)(55016002)(19609705001)(54906002)(99286003)(8676002)(6916009)(25786009)(68736007)(93886004)(790700001)(10090500001)(6116002)(102836003)(3846002)(81156014)(8936002)(54896002)(6306002)(2950100002)(66066001)(53546009)(122556002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0083; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 21:57:38.8246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0083 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 21:58:27 -0000 --_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IEkgdW5kZXJzdGFuZCB5b3VyIHBlcmNlcHRpb25zIGJldHRlci4gUHJpb3Ig dG8gYWRvcHRpb24gb2YgY29hcC10Y3AtdGxzIGFuZCBiZWZvcmUgSSB3YXMgYWN0aXZlIGluIHRo ZSBXRywgSSByZWNhbGwgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byB0aGUgY29uZnVzaW9uIG92ZXIg YXBwbGljYXRpb24gdnMgdHJhbnNwb3J0IHJlbGlhYmlsaXR5IGluIENvQVAgZXNwZWNpYWxseSBh cyByZWxhdGVkIHRvIENPTiBhbmQgTk9OLiBXaGF0IHdhcyBpbnRlbmRlZD8NCg0KVGltIENhcmV5 IG91dGxpbmVkIHNvbWUgY29uY2VybnMgaW46DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2FyZXktY29yZS1zdGQtbXNnLXZzLXRyYW5zLWFkYXB0LTAwI3NlY3Rpb24tMg0KDQpU aGlzIHRvcGljIHdhcyBwcmVzZW50ZWQgaW4gZGV0YWlsIGF0IElFVEYgOTMgLSBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLWNvcmUtMC5wZGYgLSBz dGFydGluZyBvbiBzbGlkZSAyMy4NCg0KQW5kIGluIGEgcmVsYXRlZCB0aHJlYWQgb24gdGhlIG1h aWxpbmcgbGlzdCBiYWNrIGluIDIwMTUgLSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2NvcmUvY3VycmVudC9tc2cwNjI4MC5odG1sIC0gQ2Fyc3RlbiByZXNwb25kZWQ6DQoN Cj4gSW4gYW55IGNhc2UsIENPTiBhbmQgTk9OIGFyZSBhYm91dCBtZXNzYWdlIGxheWVyIHNlbWFu dGljcywgbm90IGFib3V0IGFwcGxpY2F0aW9uIHNlbWFudGljcw0KPiAtLSB5b3UgZ2F2ZSB0aGVt IGEgbWVhbmluZyB0aGV5IGRvbid0IGhhdmUuDQoNCkJ5IElFVEYgOTQsIHRoZSBhdXRob3JzIHdl cmUgcmVwb3J0aW5nIOKAkyDigJxNb3N0IG9mIHRoZSBDb25mdXNpb24gYXJvdW5kICAgICAgICAg ICAgICBDT04vTk9OIHdhcyByZXNvbHZlZOKAnS4NCg0KV2hlcmUgcmVsZXZhbnQsIEnigJl2ZSBh ZGRlZCBjbGFyaWZpY2F0aW9ucyAtIHN1Y2ggYXMgdGhlIEFwcGVuZGl4IHJlbGF0ZWQgdG8gZGlm ZmVyZW5jZXMgaW4gT2JzZXJ2ZSBmb3IgcmVsaWFibGUgdHJhbnNwb3J0cy4NCg0KQm90aCBDYXJz dGVuIGFuZCBIYW5uZXMgY291bGQgcHJvYmFibHkgb2ZmZXIgbW9yZSBjb250ZXh0IGlmIG5lZWRl ZC4NCg0KRnJvbTogWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53aWRlLmFk LmpwXQ0KU2VudDogRnJpZGF5LCBBcHJpbCAyMSwgMjAxNyAyOjA4IFBNDQpUbzogQnJpYW4gUmF5 bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NCkNjOiBZb3NoaWZ1bWkgTmlzaGlkYSA8 bmlzaGlkYUBzZmMud2lkZS5hZC5qcD47IHRzdi1hcnRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29y ZS1jb2FwLXRjcC10bHNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBUU1YtQVJUIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz LTA3DQoNCkhpIEJyaWFuLA0KDQpKdXN0IGluIGNhc2UsDQpSZWxpYWJsZSB0cmFuc3BvcnRzIG9u bHkgcHJvdmlkZSByZWxpYWJpbGl0eSBhdCB0cmFuc3BvcnQgbGV2ZWwuIEl0IGRvZXNuJ3QgcHJv dmlkZSByZWxpYWJpbGl0eSBpbiBhcHBsaWNhdGlvbiBwcm90b2NvbCBsZXZlbC4NCg0KUkZDNzI1 MiBoYXMgcmVsaWFiaWxpdHkgbWVjaGFuaXNtcyBpbiBpdCBzaW5jZSBpdCB1c2VzIFVEUC4gVGhp cyBtZWFucyBpdCBoYXMgYWJpbGl0aWVzIHRvIGNoZWNrIGJvdGggdHJhbnNwb3J0IGFuZCBhcHAg bGV2ZWwgcmVsaWFiaWxpdHkuDQpUaGlzIGRyYWZ0IG9ubHkgcHJvdmlkZXMgdHJhbnNwb3J0IGxl dmVsIHJlbGlhYmlsaXR5IGFuZCBhcHBzIHdpbGwgbmVlZCB0byBkZXRlY3QgYXBwIHByb3RvY29s IGZhaWx1cmUgYnkgdGhlbXNlbHZlcy4NClRoaXMgbWVhbnMgNzI1MiBhbmQgdGhpcyBkcmFmdCBh cmUgbm90IHRvdGFsbHkgZXF1aXZhbGVudCBmcm9tIHRoZSB2aWV3cG9pbnQgb2YgYXBwbGljYXRp b25zLg0KDQpJIGFtIG5vdCBzYXlpbmcgdGhpcyBpcyB3cm9uZyBvciBiYWQsIGJ1dCBJIGJlbGll dmUgYXBwIGRldmVsb3BlciBzaG91bGQgYXdhcmUgdGhpcyBwb2ludC4NCi0tDQpZb3NoaQ0KDQpP biBGcmksIEFwciAyMSwgMjAxNyBhdCAxMToxNSBBTSwgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXlt b3JAbWljcm9zb2Z0LmNvbTxtYWlsdG86QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KSGkgWW9zaGksDQoNCg0KDQo+IE9LLiBJIGFsc28gdGhpbmsgd2Ugc2hvdWxkIHN0YXRl IHRoYXQgdGhlIHByb3RvY29sIHNob3VsZCBub3RpZnkgdGhlIGZhaWx1cmUgZXZlbnRzIHRvIGFw cGxpY2F0aW9ucy4NCg0KPiBTaW5jZSBlcnJvcnMgY2FuIGhhcHBlbiBub3Qgb25seSBpbiBUQ1As IGJ1dCBhbHNvIFRMUyBhbmQgd2Vic29ja2V0IGxldmVsLCBtZW50aW9uaW5nIG9ubHkgVENQIGNs b3NlIG9yIHJlc2V0IG1pZ2h0IG5vdA0KDQo+IGJlIGVub3VnaC4NCg0KDQoNCkFmdGVyIHJldmll d2luZyB3aXRoIHRoZSBhdXRob3JzLCBhbiBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24gd2FzIGFw cGVuZGVkIHRvIDMuNCBDb25uZWN0aW9uIEhlYWx0aCAtIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL2NvYXAtdGNwLXRscy9wdWxsLzE0MC9maWxlcw0KDQoNCg0KVGhlIG9waW5pb24gb2YgdGhl IGF1dGhvcnMgKGFuZCBHZW5neXUgV0VJ4oCZcyByZWNlbnQgcmVzcG9uc2UgLSBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODYyMi5odG1sKSBp cyB0aGF0IFJGQzY0NTUgY292ZXJzIHRoZSBXZWJTb2NrZXQgY2FzZSBhbmQgZG9lcyBub3QgbmVl ZCB0byBiZSByZXBlYXRlZCBoZXJlLg0KDQoNCg0KPiBXaGVuIHdlIHVzZSA3MjUyLCBJIHRoaW5r IGFwcGxpY2F0aW9ucyBiYXNpY2FsbHkgZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgdGltZW91dHMg b3IgcmV0cnkgbWVjaGFuaXNtcyBhcyB0aGUgcHJvdG9jb2wNCg0KPiBwcm92aWRlcyBzdWNoIHRo aW5ncy4NCg0KDQoNClJGQzcyNTIgcHJvdmlkZXMgdGltZW91dHMgYW5kIHJldHJpZXMgYmVjYXVz ZSBpdCdzIGltcGxlbWVudGluZyBhIFRDUC1saWtlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbSBvdmVy IFVEUCAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMi4xDQoN Cg0KDQo+IEhvd2V2ZXIsIHdoZW4gd2UgdXNlIHRoaXMgb25lLCBpdCBzZWVtcyBhcHBsaWNhdGlv bnMgd2lsbCBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5pc21zLiBJc24ndCBpdCBhIGJpdCBjb25m dXNpbmc/IEkgYW0gdGhpbmtpbmcgdGhhdA0KDQo+IHRoZXJlIG5lZWQgdG8gYmUgc29tZSBndWlk YW5jZSBoZXJlLg0KDQo+IEJUVywgUE9ORyBpcyBvbmUgZXhhbXBsZS4NCg0KDQoNCkZvciBjb2Fw LXRjcC10bHMsIHRoZXJlIGFyZSBtdWx0aXBsZSBlYXJseSBpbXBsZW1lbnRhdGlvbnMuIFRoaXMg aGFzIG5ldmVyIGJlZW4gcmVwb3J0ZWQgYXMgYSBzb3VyY2Ugb2YgY29uZnVzaW9uLg0KDQoNCg0K Pj4gTXkgc2Vuc2UgaXMgdGhhdCB3ZSBzaG91bGQgdHJlYXQgdGhpcyBhcyBhbiB1cGRhdGUgdG8g UkZDNzk1OSBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2U6DQoNCj4gSSBkb24ndCBoYXZl IGEgc3Ryb25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5lIGZvciBtZSBpZiBp dCdzIGNsZWFyZXIgdG8gQ29BUCBwZW9wbGUuDQoNCg0KDQpJJ3ZlIG1lcmdlZCB0aGUgY2hhbmdl IC0gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTM4L2ZpbGVz DQoNCg0KVGhhbmtzIGFnYWluIGZvciBoZWxwaW5nIHVzIHRvIGltcHJvdmUgdGhlIHF1YWxpdHkg b2YgdGhlIGRyYWZ0LA0KDQrigKZCcmlhbg0KDQo= --_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbS0zMDU4NDQ4 ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0LCBsaS5nbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdt c29wbGFpbnRleHQsIGRpdi5nbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQN Cgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4 dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwt DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXttc28tc3R5 bGUtbmFtZTpnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IEkgdW5kZXJzdGFuZCB5b3Vy IHBlcmNlcHRpb25zIGJldHRlci4gUHJpb3IgdG8gYWRvcHRpb24gb2YgY29hcC10Y3AtdGxzIGFu ZCBiZWZvcmUgSSB3YXMgYWN0aXZlIGluIHRoZSBXRywgSSByZWNhbGwgZGlzY3Vzc2lvbnMgcmVs YXRlZCB0byB0aGUgY29uZnVzaW9uIG92ZXIgYXBwbGljYXRpb24NCiB2cyB0cmFuc3BvcnQgcmVs aWFiaWxpdHkgaW4gQ29BUCBlc3BlY2lhbGx5IGFzIHJlbGF0ZWQgdG8gQ09OIGFuZCBOT04uIFdo YXQgd2FzIGludGVuZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaW0gQ2FyZXkgb3V0bGluZWQgc29tZSBj b25jZXJucyBpbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jYXJleS1jb3JlLXN0ZC1tc2ctdnMtdHJhbnMtYWRhcHQtMDAjc2VjdGlvbi0yIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FyZXktY29yZS1zdGQtbXNnLXZzLXRyYW5zLWFk YXB0LTAwI3NlY3Rpb24tMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyB0b3BpYyB3YXMgcHJlc2Vu dGVkIGluIGRldGFpbCBhdCBJRVRGIDkzIC0NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzkzL3NsaWRlcy9zbGlkZXMtOTMtY29yZS0wLnBkZiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1jb3JlLTAucGRmPC9hPiAt IHN0YXJ0aW5nIG9uIHNsaWRlIDIzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQgaW4gYSByZWxhdGVkIHRo cmVhZCBvbiB0aGUgbWFpbGluZyBsaXN0IGJhY2sgaW4gMjAxNSAtDQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwNjI4MC5odG1s Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cw NjI4MC5odG1sPC9hPiAtIENhcnN0ZW4gcmVzcG9uZGVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IElu IGFueSBjYXNlLCBDT04gYW5kIE5PTiBhcmUgYWJvdXQgbWVzc2FnZSBsYXllciBzZW1hbnRpY3Ms IG5vdCBhYm91dCBhcHBsaWNhdGlvbiBzZW1hbnRpY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgLS0geW91IGdhdmUgdGhl bSBhIG1lYW5pbmcgdGhleSBkb24ndCBoYXZlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJ5IElFVEYgOTQs IHRoZSBhdXRob3JzIHdlcmUgcmVwb3J0aW5nIOKAkyDigJxNb3N0IG9mIHRoZSBDb25mdXNpb24g YXJvdW5kJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENPTi9OT04gd2FzIHJlc29sdmVk4oCdLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPldoZXJlIHJlbGV2YW50LCBJ4oCZdmUgYWRkZWQgY2xhcmlmaWNhdGlvbnMg LSBzdWNoIGFzIHRoZSBBcHBlbmRpeCByZWxhdGVkIHRvIGRpZmZlcmVuY2VzIGluIE9ic2VydmUg Zm9yIHJlbGlhYmxlIHRyYW5zcG9ydHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJvdGggQ2Fyc3RlbiBhbmQg SGFubmVzIGNvdWxkIHByb2JhYmx5IG9mZmVyIG1vcmUgY29udGV4dCBpZiBuZWVkZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gWW9zaGlmdW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53aWRl LmFkLmpwXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMjEsIDIwMTcgMjowOCBQ TTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gUmF5bW9yICZsdDtCcmlhbi5SYXltb3JAbWljcm9zb2Z0 LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFlvc2hpZnVtaSBOaXNoaWRhICZsdDtuaXNoaWRhQHNm Yy53aWRlLmFkLmpwJmd0OzsgdHN2LWFydEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLWNvYXAt dGNwLXRsc0BpZXRmLm9yZzsgY29yZUBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogVFNWLUFSVCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNw LXRscy0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpYW4sPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGluIGNhc2UsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWxpYWJsZSB0 cmFuc3BvcnRzIG9ubHkgcHJvdmlkZSByZWxpYWJpbGl0eSBhdCB0cmFuc3BvcnQgbGV2ZWwuIEl0 IGRvZXNuJ3QgcHJvdmlkZSByZWxpYWJpbGl0eSBpbiBhcHBsaWNhdGlvbiBwcm90b2NvbCBsZXZl bC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UkZDNzI1MiBoYXMgcmVsaWFiaWxpdHkgbWVjaGFuaXNtcyBpbiBpdCBzaW5jZSBpdCB1 c2VzIFVEUC4gVGhpcyBtZWFucyBpdCBoYXMgYWJpbGl0aWVzIHRvIGNoZWNrIGJvdGggdHJhbnNw b3J0IGFuZCBhcHAgbGV2ZWwgcmVsaWFiaWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IG9ubHkgcHJvdmlkZXMgdHJhbnNw b3J0IGxldmVsIHJlbGlhYmlsaXR5IGFuZCBhcHBzIHdpbGwgbmVlZCB0byBkZXRlY3QgYXBwIHBy b3RvY29sIGZhaWx1cmUgYnkgdGhlbXNlbHZlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVhbnMgNzI1MiBhbmQgdGhpcyBk cmFmdCBhcmUgbm90IHRvdGFsbHkgZXF1aXZhbGVudCBmcm9tIHRoZSB2aWV3cG9pbnQgb2YgYXBw bGljYXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzYXlpbmcgdGhpcyBpcyB3cm9uZyBvciBiYWQsIGJ1dCBJ IGJlbGlldmUgYXBwIGRldmVsb3BlciBzaG91bGQgYXdhcmUgdGhpcyBwb2ludC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3NoaTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEFwciAyMSwgMjAxNyBhdCAxMTox NSBBTSwgQnJpYW4gUmF5bW9yICZsdDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUmF5bW9yQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5Ccmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50 ZXh0Ij5IaSBZb3NoaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4 MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jmd0OyBPSy4gSSBhbHNv IHRoaW5rIHdlIHNob3VsZCBzdGF0ZSB0aGF0IHRoZSBwcm90b2NvbCBzaG91bGQgbm90aWZ5IHRo ZSBmYWlsdXJlIGV2ZW50cyB0byBhcHBsaWNhdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7IFNp bmNlIGVycm9ycyBjYW4gaGFwcGVuIG5vdCBvbmx5IGluIFRDUCwgYnV0IGFsc28gVExTIGFuZCB3 ZWJzb2NrZXQgbGV2ZWwsIG1lbnRpb25pbmcgb25seSBUQ1AgY2xvc2Ugb3IgcmVzZXQgbWlnaHQg bm90DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2 NDdtc29wbGFpbnRleHQiPiZndDsgYmUgZW5vdWdoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0 Ij5BZnRlciByZXZpZXdpbmcgd2l0aCB0aGUgYXV0aG9ycywgYW4gYWRkaXRpb25hbCBjbGFyaWZp Y2F0aW9uIHdhcyBhcHBlbmRlZCB0byAzLjQgQ29ubmVjdGlvbiBIZWFsdGggLQ0KPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL3B1bGwvMTQwL2ZpbGVzIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMv cHVsbC8xNDAvZmlsZXM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4 NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPlRoZSBvcGluaW9u IG9mIHRoZSBhdXRob3JzIChhbmQgR2VuZ3l1IFdFSeKAmXMgcmVjZW50IHJlc3BvbnNlIC0NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY29yZS9jdXJyZW50 L21zZzA4NjIyLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvY29yZS9jdXJyZW50L21zZzA4NjIyLmh0bWw8L2E+KSBpcyB0aGF0IFJG QzY0NTUgY292ZXJzIHRoZSBXZWJTb2NrZXQgY2FzZSBhbmQgZG9lcyBub3QgbmVlZCB0byBiZSBy ZXBlYXRlZCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgx NTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7IFdoZW4gd2UgdXNl IDcyNTIsIEkgdGhpbmsgYXBwbGljYXRpb25zIGJhc2ljYWxseSBkb24ndCBuZWVkIHRvIGltcGxl bWVudCB0aW1lb3V0cyBvciByZXRyeSBtZWNoYW5pc21zIGFzIHRoZSBwcm90b2NvbDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4 dCI+Jmd0OyBwcm92aWRlcyBzdWNoIHRoaW5ncy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQi PlJGQzcyNTIgcHJvdmlkZXMgdGltZW91dHMgYW5kIHJldHJpZXMgYmVjYXVzZSBpdCdzIGltcGxl bWVudGluZyBhIFRDUC1saWtlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbSBvdmVyIFVEUCAtDQo8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTIuMSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24t Mi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3 NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwt bS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7IEhvd2V2ZXIsIHdoZW4gd2Ug dXNlIHRoaXMgb25lLCBpdCBzZWVtcyBhcHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGhhdmUgc3Vj aCBtZWNoYW5pc21zLiBJc24ndCBpdCBhIGJpdCBjb25mdXNpbmc/IEkgYW0gdGhpbmtpbmcgdGhh dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21z b3BsYWludGV4dCI+Jmd0OyB0aGVyZSBuZWVkIHRvIGJlIHNvbWUgZ3VpZGFuY2UgaGVyZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFp bnRleHQiPiZndDsgQlRXLCBQT05HIGlzIG9uZSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYzNzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxh aW50ZXh0Ij5Gb3IgY29hcC10Y3AtdGxzLCB0aGVyZSBhcmUgbXVsdGlwbGUgZWFybHkgaW1wbGVt ZW50YXRpb25zLiBUaGlzIGhhcyBuZXZlciBiZWVuIHJlcG9ydGVkIGFzIGEgc291cmNlIG9mIGNv bmZ1c2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMzA1ODQ0ODgxNTYz NzY3NjY0N21zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21h aWwtbS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mZ3Q7Jmd0OyBNeSBzZW5zZSBp cyB0aGF0IHdlIHNob3VsZCB0cmVhdCB0aGlzIGFzIGFuIHVwZGF0ZSB0byBSRkM3OTU5IGJhc2Vk IG9uIHRoZSBvcmlnaW5hbCBsYW5ndWFnZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPiZndDsgSSBkb24ndCBoYXZlIGEg c3Ryb25nIG9waW5pb24gaGVyZS4gVXBkYXRpbmcgNzk1OSBpcyBmaW5lIGZvciBtZSBpZiBpdCdz IGNsZWFyZXIgdG8gQ29BUCBwZW9wbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwt bS0zMDU4NDQ4ODE1NjM3Njc2NjQ3bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQiPkkndmUg bWVyZ2VkIHRoZSBjaGFuZ2UgLSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9j b2FwLXRjcC10bHMvcHVsbC8xMzgvZmlsZXMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0 aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9wdWxsLzEzOC9maWxlczwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTMwNTg0NDg4MTU2Mzc2NzY2NDdtc29wbGFpbnRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rcyBhZ2FpbiBmb3IgaGVscGluZyB1cyB0byBpbXByb3ZlIHRoZSBxdWFsaXR5 IG9mIHRoZSBkcmFmdCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPuKApkJyaWFuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR21MB008453149ADC1A998FEA56D3831A0BY2PR21MB0084namp_-- From nobody Thu Apr 27 01:54:00 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72212708C for ; Thu, 27 Apr 2017 01:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VakEY1RddJnX for ; Thu, 27 Apr 2017 01:53:58 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 BE5961243FE for ; Thu, 27 Apr 2017 01:53:57 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m123so11617599wma.0 for ; Thu, 27 Apr 2017 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=/akECkXbIDtVtYBGfxVbXaPoTe4/KMdnIFRL4gGwlMc=; b=OrsFSY6vhkITj1iPyDjy8xT0thyS7c3RHPEHnys/Ltwy7AKIi81gDUAiUG4gXghSkI n70MRrovCVxpcPMsUmIPvYtQhhO6LygHCNB3Azn74ZrFNQR6QvgPPke9IJRFwnbLr/XR 7lIacE828u/RQ/KB3PzvjzUqRMKBHWnQHydckpsUaAQGm+onDWcNgIoGagvSuj63jOzk IPGlVBRa71dN76nb5TFCOaDX24RRQvNgLtL621+KujrcXde9jleh1v0E+b7b+FOJ+rc8 iZpQ2KpGTwfm1Na/W5ECHgvlnIqgV1HM0BEd9Ycv7HyOQMSh0HGBvjEMZJknHEWyfgYa n1Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=/akECkXbIDtVtYBGfxVbXaPoTe4/KMdnIFRL4gGwlMc=; b=thaPf08rIS4rg4gAYQ0O0NCA24Y0b++v3KwePEo0G+YmXenpAT9hNQt5kj0gZQNEJ1 jQpqXN2/PbK2ueM2rgKo2diU9SiBn57pAm+c3kTz6fdkIK5aqP2z9BTDxjYwKPwxQ3o1 eQJrlhx82XuTZwON8uSb8WdLJwywpwMuA1exrg7fSzpUi0tHFZoP9Vwy9pbLNybLHz6r p4SO8/nQwj5je0a+ukTTdK1QVHXGyltDpMmxuTkhXniuzJJ5KdapvVxhcV/dRuZmYfZX gzaGGJ2B5Q8y6O/csblR7sBE6yycL2biwE2uFFqhrmj0skUJtkpGWBnQO55/2q17s2SS 8YvQ== X-Gm-Message-State: AN3rC/6QPcNo5zZaF/puSLpG6Cbzn7miXuMYsK30QRlqZEv0Ej1Ldmsa 0OPb1ly3jGn+7or4 X-Received: by 10.28.17.21 with SMTP id 21mr1466377wmr.83.1493283235915; Thu, 27 Apr 2017 01:53:55 -0700 (PDT) Received: from ?IPv6:2003:74:cf5d:f692:8ec:7e34:df76:379b? (p200300061500B99208EC7E34DF76379B.dip0.t-ipconnect.de. [2003:6:1500:b992:8ec:7e34:df76:379b]) by smtp.googlemail.com with ESMTPSA id 3sm2051923wrv.33.2017.04.27.01.53.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 01:53:55 -0700 (PDT) From: Martin Stiemerling To: tsv-art@ietf.org Message-ID: Date: Thu, 27 Apr 2017 10:53:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 04/27 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 08:53:59 -0000 Dear TSVers, I did work through all documents that are in IETF LC, IESG processing or being requested for publication as of 04/27, 10:30 am CEST. Please find below all documents checked and what to do with these documents. Documents that require TSV attention: draft-ietf-anima-grasp-11 -- assigned to $me, as this sounds somewhat like NSIS... Documents that do not require TSV attention: draft-ietf-dnsop-nsec-aggressiveuse-09 draft-ietf-dprive-dtls-and-tls-profiles-09 -- Colin did review -08 draft-ietf-spring-resiliency-use-cases-08 draft-ietf-spring-ipv6-use-cases-10 draft-ietf-manet-olsrv2-multipath-12 draft-ietf-sipcore-status-unwanted-05 Thanks to all reviewers Martin From nobody Sat Apr 29 21:27:12 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D408012420B; Sat, 29 Apr 2017 21:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 Smy9Vbl3vhCc; Sat, 29 Apr 2017 21:26:52 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CC61292D3; Sat, 29 Apr 2017 21:24:41 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A9DF229CA6F; Sun, 30 Apr 2017 13:24:39 +0900 (JST) Received: by mail-oi0-f48.google.com with SMTP id x184so62464533oia.1; Sat, 29 Apr 2017 21:24:39 -0700 (PDT) X-Gm-Message-State: AN3rC/4S76KihGisreuTUda46+/nmDsyZ+fOmaHMXgHkrb1wmykvWYxA HEyCq0PMAfUS5IBnuPIG5G+NO2p0SA== X-Received: by 10.157.2.101 with SMTP id 92mr7246001otb.211.1493526278364; Sat, 29 Apr 2017 21:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Sat, 29 Apr 2017 21:24:37 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Sat, 29 Apr 2017 21:24:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03918c48e9d8054e5aaf1a Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 04:26:56 -0000 --94eb2c03918c48e9d8054e5aaf1a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, As far as I've read -08 draft, I think this point has not been addressed yet. I hope some folks could elaborate a bit more if they think this is not an important point for the draft. -- Yoshi On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor wrote: > I think that I understand your perceptions better. Prior to adoption of > coap-tcp-tls and before I was active in the WG, I recall discussions > related to the confusion over application vs transport reliability in CoA= P > especially as related to CON and NON. What was intended? > > > > Tim Carey outlined some concerns in: > > https://tools.ietf.org/html/draft-carey-core-std-msg-vs-tran > s-adapt-00#section-2 > > > > This topic was presented in detail at IETF 93 - > https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - > starting on slide 23. > > > > And in a related thread on the mailing list back in 2015 - > https://www.ietf.org/mail-archive/web/core/current/msg06280.html - > Carsten responded: > > > > > In any case, CON and NON are about message layer semantics, not about > application semantics > > > -- you gave them a meaning they don't have. > > > > By IETF 94, the authors were reporting =E2=80=93 =E2=80=9CMost of the Con= fusion > around CON/NON was resolved=E2=80=9D. > > > > Where relevant, I=E2=80=99ve added clarifications - such as the Appendix = related > to differences in Observe for reliable transports. > > > > Both Carsten and Hannes could probably offer more context if needed. > > > > *From:* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > *Sent:* Friday, April 21, 2017 2:08 PM > *To:* Brian Raymor > *Cc:* Yoshifumi Nishida ; tsv-art@ietf.org; > draft-ietf-core-coap-tcp-tls@ietf.org; core@ietf.org; ietf@ietf.org > *Subject:* Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 > > > > Hi Brian, > > > > Just in case, > > Reliable transports only provide reliability at transport level. It > doesn't provide reliability in application protocol level. > > > > RFC7252 has reliability mechanisms in it since it uses UDP. This means it > has abilities to check both transport and app level reliability. > > This draft only provides transport level reliability and apps will need t= o > detect app protocol failure by themselves. > > This means 7252 and this draft are not totally equivalent from the > viewpoint of applications. > > > > I am not saying this is wrong or bad, but I believe app developer should > aware this point. > > -- > > Yoshi > > > > On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor > wrote: > > Hi Yoshi, > > > > > OK. I also think we should state that the protocol should notify the > failure events to applications. > > > Since errors can happen not only in TCP, but also TLS and websocket > level, mentioning only TCP close or reset might not > > > be enough. > > > > After reviewing with the authors, an additional clarification was appende= d > to 3.4 Connection Health - https://github.com/core-wg/coa > p-tcp-tls/pull/140/files > > > > The opinion of the authors (and Gengyu WEI=E2=80=99s recent response - > https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that > RFC6455 covers the WebSocket case and does not need to be repeated here. > > > > > When we use 7252, I think applications basically don't need to implemen= t > timeouts or retry mechanisms as the protocol > > > provides such things. > > > > RFC7252 provides timeouts and retries because it's implementing a TCP-lik= e > reliability mechanism over UDP - https://tools.ietf.org/html/rf > c7252#section-2.1 > > > > > However, when we use this one, it seems applications will need to have > such mechanisms. Isn't it a bit confusing? I am thinking that > > > there need to be some guidance here. > > > BTW, PONG is one example. > > > > For coap-tcp-tls, there are multiple early implementations. This has neve= r > been reported as a source of confusion. > > > > >> My sense is that we should treat this as an update to RFC7959 based on > the original language: > > > I don't have a strong opinion here. Updating 7959 is fine for me if it'= s > clearer to CoAP people. > > > > I've merged the change - https://github.com/core-wg/coa > p-tcp-tls/pull/138/files > > > > Thanks again for helping us to improve the quality of the draft, > > > > =E2=80=A6Brian > > > --94eb2c03918c48e9d8054e5aaf1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
As far as I've read -08 draft, I think this= point has not been addressed yet. I hope some folks could elaborate a bit = more if they think this is not an important point for the draft.
= --
Yoshi

On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <Brian.= Raymor@microsoft.com> wrote:

I think that I understand your perceptions better. = Prior to adoption of coap-tcp-tls and before I was active in the WG, I reca= ll discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. Wha= t was intended?

=C2=A0

Tim Carey outlined some concerns in:<= /span>

https://tools.i= etf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2=

=C2=A0

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-9= 3-core-0.pdf - starting on slide 23.

=C2=A0

And in a related thread on the mailing list back in= 2015 - https://www.ietf.org/mail-archive/web/core/current= /msg06280.html - Carsten responded:

=C2=A0

> In any case, CON and NON are about message lay= er semantics, not about application semantics

> -- you gave them a meaning they don't have= .

=C2=A0

By IETF 94, the authors were reporting =E2=80=93 = =E2=80=9CMost of the Confusion around=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CON/NON was resolved=E2=80=9D.

=C2=A0

Where relevant, I=E2=80=99ve added clarifications -= such as the Appendix related to differences in Observe for reliable transp= orts.

=C2=A0

Both Carsten and Hannes could probably offer more c= ontext if needed.

=C2=A0=

From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad= .jp]
Sent: Friday, April 21, 2017 2:08 PM
To: Brian Raymor <Brian.Raymor@microsoft.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>; tsv-art@ietf.org; draft-ietf-core-coap-tcp= -tls@ietf.org; = core@ietf.org; ietf@= ietf.org
Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07<= u>

=C2=A0

Hi Brian,

=C2=A0

Just in case,

Reliable transports only provide reliability at tran= sport level. It doesn't provide reliability in application protocol lev= el.=C2=A0

=C2=A0

RFC7252 has reliability mechanisms in it since it us= es UDP. This means it has abilities to check both transport and app level r= eliability.

This draft only provides transport level reliability= and apps will need to detect app protocol failure by themselves.=C2=A0<= /u>

This means 7252 and this draft are not totally equiv= alent from the viewpoint of applications.=C2=A0

=C2=A0

I am not saying this is wrong or bad, but I believe = app developer should aware this point.

--

Yoshi

=C2=A0

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <<= a href=3D"mailto:Brian.Raymor@microsoft.com" target=3D"_blank">Brian.Raymor= @microsoft.com> wrote:

Hi Yoshi,

=C2=A0

> OK. I also think we should s= tate that the protocol should notify the failure events to applications.=C2= =A0

> Since errors can happen not = only in TCP, but also TLS and websocket level, mentioning only TCP close or= reset might not

> be enough.

=C2=A0

After reviewing with the authors,= an additional clarification was appended to 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files

=C2=A0

The opinion of the authors (and G= engyu WEI=E2=80=99s recent response - https://www.ietf.org/mail-archive/web/core/current/msg08622.html<= /a>) is that RFC6455 covers the WebSocket case and does not need to be repe= ated here.

=C2=A0

> When we use 7252, I think ap= plications basically don't need to implement timeouts or retry mechanis= ms as the protocol

> provides such things.

=C2=A0

RFC7252 provides timeouts and ret= ries because it's implementing a TCP-like reliability mechanism over UD= P - https://tools.ietf.org/html/rfc7252#section-2.1

=C2=A0

> However, when we use this on= e, it seems applications will need to have such mechanisms. Isn't it a = bit confusing? I am thinking that

> there need to be some guidan= ce here.

> BTW, PONG is one example.=

=C2=A0

For coap-tcp-tls, there are multi= ple early implementations. This has never been reported as a source of conf= usion.

=C2=A0

>> My sense is that we shou= ld treat this as an update to RFC7959 based on the original language:

> I don't have a strong op= inion here. Updating 7959 is fine for me if it's clearer to CoAP people= .

=C2=A0

I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

=C2=A0

Thanks again for helping us to improve the quality = of the draft,

=C2=A0

=E2=80=A6Brian

=C2=A0


--94eb2c03918c48e9d8054e5aaf1a--